Summary

Das Hornetsecurity Security Lab präsentiert Details zu den Webshells hinter Emotet, einschliesslich Einblicken in Download Zahlen der Malware und wie von 2020-07-22 bis 2020-07-24 Emotet Download-URLs durch HTML-Code mit GIFs ersetzt wurden. Die Analyse zeigt, dass die Anzahl der Downloads des bösartigen Inhalts hinter den Emotet Download-URLs signifikant ist und im Spitzenwert 50.000 Downloads erreichen kann. Das verdeutlicht, dass die schadhaften Links in Emotet-Mails druchaus aufgerufen werden. Die Analyse zeigt ferner, dass kompromittierte Websites nicht nur einmal, sondern mehrfach von verschiedenen Akteuren kompromittiert werden und dass die Bereinigungsversuche der Website-Administratoren oft unzureichend sind, was dazu führt, dass die als entfernt geglaubten bösartigen Emotet-Downloads oft wieder aktiviert werden.

Hintergrund

Emotet ist einer der größten Malspam-Akteure. Sie verbreiten ihre Malware über Malspam-E-Mails, die entweder einen bösartigen Dokumentanhang mit VBA-Makros oder Download-Links zu diesen bösartigen Dokumenten enthalten. Diese bösartigen Dokumente laden dann den Emotet-Loader von den Emotet-Download-URLs herunter. Diese Downloads werden auf kompromittierten Websites gehostet. Zu diesem Zweck verwenden die hinter Emotet stehenden Akteure Webshell-Malware auf den kompromittierten Websites. Diese Webshells werden verwendet, um neue Payloads, entweder bösartige Dokumente, die über bösartige Links in E-Mails verteilt werden, oder den Emotet Loader, auf den kompromittierten Websites zu platzieren. Da kompromittierte Websites auf Block-Listen gesetzt oder die Emotet-Malware von den Websites bereinigt wird, verbrauchen die Akteure etwa 300 bis 400 URLs pro Tag.

Technical Analysis

In dieser Analyse werfen wir einen Blick auf die Emotet-Webshells.

S.A.P.-Webshell

Wenn man Zugriff auf das Dateisystem einer von Emotet kompromittierten Website hat, ist es sehr einfach, die von Emotet verwendete Webshell zu bekommen. Mit etwas Glück, wenn man sich auf Fehlkonfigurationen in den kompromittierten Websites verlässt und sich auf einen anderen Akteur im Webshell-Malware-Bereich verlässt, kann jedoch jeder Emotet-Webshell-Samples auch ohne Zugriff auf die kompromittierten Webserver erhalten.

Meist befinden sich die Emotet-Webshells in dem Verzeichnis eine Ebene unterhalb des Verzeichnisses, das den Emotet-Download enthält, d.h. entweder ein Emotet-Maldoc oder der Download der ausführbaren Emotet-Loader-Datei. Wenn die URL des Emotet-Downloads also https://www.example.com/wp-includes/LYnUiE/ lautet, befindet sich die Web-Shell normalerweise in https://www.example.com/wp-includes/. Wir haben jedoch auch Web-Shells in anderen Verzeichnissen gesehen. Als nächstes können wir auf Fehlkonfigurationen in den kompromittierten Websites hoffen und hoffen, dass das Verzeichnis, das die Web-Shell enthält, ein offenes Verzeichnis (engl. Open Directory) ist, d.h. es wird den Verzeichnisinhalt wie im folgenden Beispiel auflisten:

Emotet Open Directory

In diesem Beispiel ist import.php die Emotet-Webshell und lpyc42 ist das Verzeichnis, das die Emotet-Malware ausliefert. Bekannte Dateinamen von Emotet-Webshells sind user.php, common.php, import.php, update.php, link.php, license.php, menu. php, image.php, options.php, tools.php, core.php, edit.php, functions.php, config.php und wp-list.php.

Offensichtlich ist der Zugriff auf die Web-Shell geschützt, d.h. wenn die Datei import.php angefordert wird, wird der PHP-Code vom Webserver ausgeführt und nur seine Ausgabe ausgeliefert. Auf einigen Servern beobachteten wir jedoch PHP-Dateien, die umbenannt worden waren, indem der Datei eine zusätzliche `.suspected‘-Erweiterung hinzugefügt wurde.

Emotet Open Directory mit umbenannter Webshell

Diese Umbenennung wurde höchstwahrscheinlich von einer anderen Malware namens Vigilante Malware Cleaner vorgenommen. Informationen über Vigilante Malware Cleaner wurden zuerst in 2019 von Bruce Ediger entdeckt und dokumentiert [VigilanteMalwareCleaner]. Die Existenz solcher Umbenennung geht mindestens bis auf das Jahr 2015 zurück. Die Malware Vigilante Malware Cleaner scheint bereits kompromittierte Websites selbst zu kompromittieren, durchsucht dann vorhandene PHP-Dateien nach verdächtiger Malware und deaktiviert verdächtige bösartige PHP-Skripte, indem sie an ihre Dateinamen .suspected anhängt und so die Dateien aus der Liste der Dateien ausschließt, die der Server als PHP-Code ausführt. Dadurch wird der Server veranlasst, den Dateiinhalt, d.h. den PHP-Quellcode der Webshell, stattdessen direkt auszuliefern. Auf diese Weise können wir den PHP-Code der Emotet Webshell herunterladen. Bevor jedoch auf die Webshell zugegriffen werden kann, fragt der Code einen Parameter f_pp ab, der zur Dekodierung der Webshell verwendet wird:

Enkodierte Emotet Webshell

Dieser f_pp-Parameter fungiert als Passwort für die Webshell. Durch Nachforschungen in öffentlich zugänglichen Quellen fanden wir heraus, dass die kodierte Webshell identisch ist mit einer im Januar von einem anderen Forscher gefunden und entschlüsselen Webshell [EmotetWebshellSamples] war.

Um dem Leser zu veranschaulichen, was jemand sehen würde, der sich mit dem korrekten f_pp-Parameter in diese Webshell einloggt, haben wir den entschlüsselten PHP-Code auf einem Testsystem laufen lassen:

Emotet S.A.P. v.2.1 Webshell

Die Webshell identifiziert sich als S.A.P.-Webshell mit Version v.2.1. Die Webshell ermöglicht es einem Angreifer, Dateien zu suchen, hoch- und herunterzuladen. Sie erlaubt die Ausführung beliebiger Befehle. Außerdem bietet sie bequeme Werkzeuge, um SQL-Datenbanken vom Server zu dumpen, Netzwerk-Scans durchzuführen und/oder Brute-Force-Passwort-Angriffe durchzuführen.

Die Tatsache, dass der Dekodierungsprozess auf dem f_pp-Parameter als Passwort beruht und wir mehrere Instanzen des identischen verschlüsselten Webshell-Codes gefunden haben, der bis auf Januar zurückgeht, legt nahe, dass Emotet Passwörter für ihre Web-Shells wiederverwendet.

GIF-Ersetzungen

Auch wenn uns keine Log-Dateien oder andere forensische Artefakte der fraglichen Systeme vorliegen, stimmen wir auf der Grundlage unserer zuvor skizzierten Ergebnisse mit der von anderen Forschern geäußerten Meinung überein, dass der jüngste Vorfall, bei dem Emotet-Downloads durch HTML-Code ersetzt wurden, der GIFs anzeigt, auf eine unzureichende Sicherheit der Emotet-Webshells zurückzuführen ist. Diese Hypothese wird durch die Tatsache gestützt, dass Emotet am 27.07.2020 ihre Webshell geändert hat und die GIF-Ersetzungen darauf hin gestoppt haben. Am 31.07.2020 gab es jedoch Anzeichen für neue GIF-Ersetzungen. Das könnte die Zeit sein, die der GIF-Ersetz-Akteur brauchte, um das neue Passwort herauszufinden. Neue GIF-Ersetzungen sind jedoch nicht weit verbreitet, was darauf hindeuten könnte, dass das, was auch immer Emotet tut, um sich gegen die GIF-Ersetzungen zu verteidigen, funktioniert. Die zuletzt verwendeten GIFs können als eine Nachricht an die Akteure hinter Emotet interpretiert werden, dass die Akteure hinter den GIF-Ersetzungen Emotet weiterhin beobachten und entschlossen sind, ihr Unterbrechungen der Emotet-Operation fortzusetzen:

Emotet im Auge haben GIF

Emotet im Auge haben GIF

Auf späteren kompromittierten Websites von Emotet fanden wir auch mehrfach Variationen der folgenden Webshell:

Mögliche neue Emotet Webshell

Wir sind uns jedoch nicht sicher, ob dies die neue Emotet-Webshell ist, möchten daher gleichzeitig darauf hinweisen, dass der Webshell-Bereich ein sehr überfüllter Raum ist, z.B. beobachteten wir einen Webserver, auf dem zwei GIF-Ersetzungen stattfanden, zwei (vermutlich) durch Vigilante Malware Cleaner zu .suspected umbenannten Webshells, sowie, ein neuer aktiver Emotet-Download alle zusammen in nur einem Verzeichnis enthalten war (andere Teile des Servers enthielten noch mehr Webshells):

Emotet Open Directory mit 2 GIF-Ersetzungen

Das bedeutet, dass die Website nicht ein- oder zweimal, sondern mindestens dreimal als Download für Emotet genutzt wurde (2020-07-23 und 2020-07-28). Die Website würde wahrscheinlich immer noch Emotet-Payloads serverseitig zur Verfügung stellen, aber glücklicherweise wurde das Bandbreitenlimit überschritten:

Emotet Download funktioniert wegen Überschreitung der Bandbreitenbegrenzung nicht

Es besteht also die Möglichkeit, dass die Akteure, die die GIFs platzieren, über eine Schwachstelle der Website selbst Zugriff erhalten oder sogar mit der Vigilante Malware Cleaner Malware in Verbindung stehen. Aber wir sind ein Cloud Security Provider für E-Mail und haben daher nicht genug Einblick in die Aktivitäten hinter Angriffen auf Webseiten, um hier definitive Aussagen machen zu können.

Download Statistiken

Es gibt eine Möglichkeit, die Download-Statistik von Emotet URLs extern zu überwachen. Emotet verwendet ein PHP-Skript, um Download-Statistiken zu sammeln, gruppiert nach Betriebssystemen, die im User-Agent des Downloaders angegeben sind. Diese Statistiken sind als JSON-Objekt in einem Unterverzeichnis des Emotet-Payload-Download-Verzeichnisses mit dem Namen $path , '/.' . sha1(basename($path)) aufrufbar:

Emotet Download Statistiken

So kann z.B. die Statistiken für https://www.example.com/wp-includes/LYnUiE/ unter https://www.example.com/wp-includes/LYnUiE/.a2dd7d055bb668528c29e16f789755fb3aae277b abgefragt werden.

Geht man erneut von zuvor veröffentlichtem Emotet Webshell-Code [EmotetWebshellSamples] aus, so entsprechen die Zahlen Windows (4), Linux (3), Apple (2), Android (1) und unbekannten (0) Betriebssystemen, die in der User-Agent-Zeichenkette des Downloaders gefunden wurden:

Emotet PHP Statistik Code

Wir fuhren damit fort, diese Statistiken zu sammeln. Die Zähler werden jedes Mal zurückgesetzt, wenn die Emotet Tier-2-Server aktualisierte Maldocs (dt. schadhafte Dokumente) und den ausführbare Emotet Loader über die Webshells auf die kompromittierten Websites übertragen. Wenn eine neue Zählung höher war als eine vorherige, haben wir die Differenz als die Anzahl der Downloads zwischen den beiden Aufrufen der Download Statistiken gewertet. Ist die Anzahl jedoch niedriger als eine frühere Zählung, gehen wir davon aus, dass die Zählung zurückgesetzt wurde, und nehmen die neue Zählung als Anzahl der Downloads seit unserem letzten Aufruf der Download Statistik an. Auf diese Weise ignorieren wir auch festsitzende Download-Statistiken, d.h. Download-Statistiken, die nicht mehr zurückgesetzt werden und daher auf sehr hohen Zählerständen hängen geblieben sind. Wir haben mit einer Häufigkeit von 1 Minute zwischen den Aufrufen die Download Statistiken abgerufen. Emotet aktualisierte die Dokumente mit einer Häufigkeit von etwa 10 Minuten. Da Emotet auf das Windows-Betriebssystem abzielt, berücksichtigen wir im Folgenden nur die Download-Statistiken für das Windows-Betriebssystem. Für 12 Stunden am 29.7.2020 können die erhaltenen Statistiken von 739 Emotet-Download-URLs (533 davon registrierten aktive Downloads im dargestellten Zeitrahmen) wie folgt visualisiert werden:

Emotet Downloads am 29.7.2020

Es handelt sich um eine gestapelte Darstellung, d.h. jede URL-Download-Nummer wird einzeln dargestellt, aber ihre Summe zeigt die kumulative Anzahl aller Download-URLs. Jede Farbe steht für eine andere Emotet Download-URL. Diese Zahlen beinhalten natürlich auch Downloads durch Sicherheitsforscher und automatisierte Sicherheitssysteme wie Sandboxen. Es fehlen auch alle Downloads, die zwischen einem unserer Abrufen der Download Statistik und dem Zurücksetzen des Download-Zählers durch Emotet stattfanden. Die Zahlen geben jedoch immer noch einen interessanten Einblick in die Emotet-Downloads und damit in die Klickrate von Emotet. Unserer Beobachtung zufolge erreichte die kumulative Anzahl der Emotet-Downloads einen Spitzenwert von 50.000 Downloads pro Stunde.

Trennt man die Download-URLs nach der aufgelieferten Malware Art (basierend auf einer MIME-Typ-Analyse), so zeigt sich, dass die meisten Downloads auf Emotet Maldocs (dt. schadhafte Dokumente) entfallen. Der Emotet Loader wird weit weniger oft heruntergeladen:

Emotet Downloads am 29.7.2020

Wenn wir die Downloadzahlen nach der Zeit auftragen, nachdem die URL zum ersten Mal beobachtet wurde, sehen wir, dass die Downloadzahlen jeder URL innerhalb der ersten Stunde, in der die URL zum ersten Mal beobachtet wurde, ihren Höhepunkt erreichen. Zu diesem Zeitpunkt erhielt jede beobachtete Emotet-URL etwa 200 Downloads pro Stunde. Allerdings werden die URLs auch 12 Stunden nach der ersten Beobachtung der URL noch heruntergeladen. Daher ist jede blockierte oder abgeschaltete Download-URL potenziell ein Emotet-Opfer weniger, selbst wenn die Blockierung oder Abschaltung 12 Stunden zu spät erfolgt.

Das folgende Liniendiagramm veranschaulicht die Leistung einzelner URL-Downloads:

Emotet-Downloads nach Zeitpunkt der ersten Beobachtung der URL

Stapelt man die Downloadzahlen für URLs, ist der Rückgangstrend deutlich zu beobachten. Nach 9 Stunden sinkt die Zahl der Downloads auf 1/3 der unmittelbar nach der erneuten Beobachtung der URL beobachteten Downloads:

Emotet-Downloads ausgerichtet nach der Zeit, zu der die URL zum ersten Mal beobachtet wurde

Wir glauben, dass ein Teil des anfänglichen Spitzenwertes darauf zurückzuführen ist, dass automatisierte Sicherheitssysteme den Emotet-Malspam scannen und somit die Emotet-Maldocs von den Emotet-Download-URLs herunterladen. Dies wird durch eine erneute Trennung der Daten in URLs, die die Emotet-Maldocs ausliefern, und URLs, die den Emotet-Loader ausliefern, bestätigt:

Emotet-Downloads nach Zeitpunkt der ersten Beobachtung der URL

Die Anzahl der Downloads des Emotet-Loaders steigt langsamer auf seinen Spitzenwert als die der Emotet-Maldocs, was unsere Hypothese stützt. Außerdem gibt es keinen steilen Abfall bei den Downloads des Emotet-Loaders.

Im Durchschnitt wurde der Emotet-Loader mit einer Rate von etwa 1500 pro Stunde heruntergeladen, während die Emotet-Maldocs mit einer Rate von etwa 7500 pro Stunde heruntergeladen wurden.

Fehlgeschlagene Bereinigungsversuche

Bei der genaueren Beobachtung der Emotet-Download-URLs wurden wir auch mehrmals Zeuge fehlgeschlagener Säuberungsversuche. Häufig löschen Webseiten-Administratoren das Verzeichnis, das den Emotet Download enthält. Sie versäumen es jedoch, alle Webshells zu bereinigen. Die Akteure hinter Emotet regenerieren dann einfach die gelöschten Dateien mit ihrem nächsten Payload-Update. Wir haben auch beobachtet, wie Emotet eine zuvor kompromittierte Website erneut missbraucht hat.

Andere beobachtete Fehler

Bei einer so großen Operation wie Emotet ist es unvermeidlich, dass die Akteure hinter Emotet Fehler machen. Während es ein Fehler ist, einem anderen Akteur zu erlauben, die Download URLs zu kapern, haben wir noch andere Fehler entdeckt. So wurde z.B. das Ersetzen eines Regulären-Ausdrucks vergessen, so dass wir Download-URLs beobachten konnten, die Emotet-Maldocs mit kaputten Dateinamen lieferten, wie z.B. InvJP0732{:REGEX:.doc, INVOICE-Q84{:REGEX:.doc, invoice-UBO7631{:REGEX:.doc, usw. Wir sind sicher, dass der {:REGEX: Teil {:REGEX:[0-9]{3,6} (oder so ähnlich) sein sollte, eine spezielle Syntax, die von den Emotet Generierungsprozessen verwendet wird, um die Dateinamensbasis nach einem zufälligen, aber zeichenbeschränkten Muster zu erweitern. Diese {:REGEX:[...] Muster sind zuvor auch in Dateinamen von Anhängen aufgetaucht und sind Teil des Automatisierungsprozesses von Emotets. Zu beachten ist, dass je nach Browser das : in den Dateinamen durch _ ersetzt werden kann, da : kein gültiges Zeichen auf dem Windows-Betriebssystem ist. Wenn man den Betrieb von Emotet sehr genau beobachtet, werden im Laufe der Zeit viele solcher Fehler aufgedeckt, und die so gewonnenen Erkenntnisse können zur Stärkung der eigenen Abwehr gegen Emotet genutzt werden.

Schlussfolgerung und Gegenmaßnahme

Wie diese Analyse des Hornetsecurity Security Lab zeigt, wird Emotet nicht nur in großen Mengen versandt, sondern sein bösartiger Inhalt wird auch in beträchtlich großer Zahl heruntergeladen.

Im Netzwerk sollten bekannte Emotet-URLs blockiert werden. Für den Fall, dass das Browsen zu beliegen Websites nicht benötigt wird, können Sie die Domains und nicht nur die spezifischen URLs blockieren. Dies bietet einen besseren Schutz, da, wie sich gezeigt hat, Emotet und potenziell andere Akteure die kompromittierte Website erneut missbrauchen können, entweder durch Wiedererlangen des Zugriffs über hinterlassene Webshells oder durch erneutes Infizieren der Website über den ursprünglichen Zugangsvektor, z.B. eine WordPress-Schwachstelle oder ein schwaches Passwort. Die Sperre sollte auch dann beibehalten werden, wenn der Emotet-Download weg ist, da die Website immer noch kompromittiert sein kann. Es ist sehr wahrscheinlich, dass man den Großteil der Websites überhaupt nicht besuchen muss, so dass das Beibehalten der Sperre keine negativen Auswirkungen haben sollte.

Hornetsecurity’s Spam und Malware Protection, mit den höchsten Erkennungsraten auf dem Markt, erkennt und blockiert Emotet-Mails bereits auf der Grundlage bekannter Indikatoren. Hornetsecurity’s Advanced Threat Protection erweitert diesen Schutz, indem es zusätzlich noch unbekannte Bedrohungen erkennt.

Verweise