EmoCrash: Impfschutz vor Emotet-Infektionen hielt 6 Monate

[English]Sechs Monate lang haben Sicherheitsspezialisten eine Art 'Schutzsoftware' (EmoCrash) gegen die Ransomware Emotet für Behörden und Betreiber kritischer Infrastrukturen ausgerollt. EmoCrash macht sich einen Bug in Emotet zunutze, um die Systeme vor einer Infektion zu schützen. Erst Anfang August 2020 gelang es der Emotet-Gang, EmoCrash auszuschalten.


Anzeige

Emotet auf einen Blick

Emotet ist ein Erpressungs-Trojaner (Ransomware), der per E-Mail verteilt wird, dann Systeme befällt und die Opfer erpresst. Die Malware taucht ursprünglich erstmals als unbedeutender Banking-Trojaner in 2014 auf. Seitdem entwickelte sich die Schadsoftware von einem unbedeutenden Banking-Trojaner zu einer Art Schweizer-Messer der Ransomware-Szene. Die Malware kann sich nach einer Infektion der Opfer über ihr gesamtes Netzwerk verbreiten, sensible Daten stehlen und Dateien verschlüsseln.

Die Hintermänner, die in der ehemaligen Sowjetunion vermutet werden, vermieten inzwischen den Zugang zu den infizierten Hosts an andere Gruppen. Seit Monaten laufen Botnet-gesteuerte Spam-Kampagnen, um Emotet zu verbreiten und Lösegeld zu erpressen. Die Gang ist recht erfolgreich und konnte Millionen an Lösegeld einheimsen.

Ein Fehler in der Malware

Aber jede Software enthält Fehler – Emotet enthielt eine Schwachstelle, die es Cyber-Sicherheitsforschern erlaubte, einen Kill-Switch zu aktivieren. Ich hatte bereits vor einigen Tagen mitbekommen, dass Sicherheitsforscher einen Bug in der Emotet-Ransomware gefunden hatten, mit dem sich der Schädling aushebeln lässt. Aber der Ansatz, der in den letzten sechs Monaten in Sachen 'Impfung gegen Emotet' lief, war unter meinem Radar geblieben. Vor einigen Stunden habe ich dann folgenden Tweet gesehen.

Dieser gefundene Kill-Switch ermöglichte es, die Malware sechs Monate lang daran zu hindern, Systeme zu infizieren. Entsprechende Abwehrsoftware wurde laut CERT-Bund auch in Deutschland allen Behörden der Bundes- und Landesverwaltung sowie KRITIS-Unternehmen nach IT-SiG zur Verfügung gestellt. Der Kill-Switch war zwischen dem 6. Februar 2020 und dem 6. August 2020 182 Tage lang aktiv, bevor die Malware-Autoren ihre Malware gepatcht und die Schwachstelle geschlossen haben.

Einige Details

James Quinn von Binary Defense stieß bei der Analyse im Februar 2020 auf einen Bug im Emotet-Trojaner. Quinn verfolgt die Aktivitäten von Emotet seit Jahren und bemerkte im Februar 2020 eine Änderung in Teilen des Codes. The Hacker News berichtete im Februar hier über diese Änderung, mit der sich nahegelegene Wi-Fi-Netzwerke infizieren ließen. Diese Änderung betraf den "Persistenzmechanismus" von Emotet, den Teil des Codes, der es der Malware ermöglicht, einen Neustart des Systems zu überleben.

Emotet-Registry-Key
(Emotet-Registry-Key, Quelle: Binary Defense)

Quinn bemerkte, dass Emotet dazu einen Windows-Registrierungsschlüssel erstellte und darin einen XOR-Chiffrierschlüssel speicherte, wie er hier schreibt. Zusammen mit dieser Funktionsaktualisierung wurde "ein Dateiname zum Speichern der Malware auf jedem Opfersystem generierte, wobei ein zufällig gewählter exe- oder dll-Systemdateiname aus dem Verzeichnis system32 verwendet wurde".


Anzeige

Killswitch v1

Etwa 37 Stunden, nach dieser Entdeckung im Emotet-code, hatte Quinn bereits die erste Version des Killswitch fertig (aus der später EmoCrash entwickelt wurde). In der Urversion generierte das PowerShell-Skript zum Schutz vor Emotet den Registrierungsschlüsselwert für jedes Opfer und setzte die Daten für jeden Wert auf null.

Überprüfte Emotet die Registrierung auf diese Installationsmarkierung, fand es den neu generierten Nullwert und generierte daraus den Exe-Namen ".exe". Dann durchsuchte die Malware dann Pfad zum normalen Installationsort (%AppdataLocal%, C:\Windows\System32,C:\Windows\Syswow64, basierend auf der Umgebung) nach dieser exe. Da die Datei '.exe' nicht existierte, wurde lediglich eine Datei mit dem Namen ".exe" am normalen Emotet-Installationsort abgelegt. Der Versuch der Malware, diese ".exe" auszuführen, scheiterte jedoch, da "." bei vielen Betriebssystemen das aktuelle Arbeitsverzeichnis bezeichnete.

Obwohl dieser Mechanismus funktionierte, war er sehr unübersichtlich und erlaubte Emotet trotzdem die Installation – er verhinderte nur, dass Emotet erfolgreich ausgeführt werden konnte und sich über das Netzwerk ausbreitete.

Killswitch v2

Etwa 48 Stunden nachdem Emotet die neueste Loader-Version veröffentlichte, stellte Binary Defense die zweite Version des Killswitch fertig. Diese Version machte sich einen einfachen Pufferüberlauf zunutze, der in der Installationsroutine von Emotet entdeckt wurde. Der Killswitch brachte Emotet während der Malware-Installation zum Absturz, bevor die Malware sich auf dem Zielsystem installieren konnte. Dadurch wurde die Installation der Malware vollständig verhindert.

Zusätzlich wurden zwei Ereigniseinträge mit den Ereignis-IDs 1000 und 1001 in der Ereignisprotokollierung erzeugt. Diese dienten zur Identifizierung von Endpunkten mit deaktivierten und toten Emotet-Binärdateien, verursacht durch den Einsatz des Killswitch (und einem Neustart des Computers).

Verteilung der Schutzroutine

In einer koordinierten Aktion zwischen der Infosec- und der CERT-Gemeinschaft, begann Binary Defense am 12. Februar 2020 mit der weltweiten Verteilung des EmoCrash-Angriffsskripts an Stellen auf der ganzen Welt, mit der strikten Anweisung, es nicht öffentlich zu veröffentlichen. Denn es das Ziel, den Nutzen dieses Exploits zu maximieren und gleichzeitig zu verhindern, dass die Bedrohungsakteure einen Tipp erhalten und ihren Code patchen können.

Alles in allem konnte Emotet so für die letzten sechs Monate auf den geimpften Systemen an einer Installation gehindert werden. Und die Sicherheitsforscher erhielten hilfreiches Feedback, unter anderem zu Kompatibilitätsprobleme unter Windows 7, die vom CERT der Universität Frankfurt in Deutschland beigesteuert wurden.

Die Emotet-Gang riecht den Braten

So um den 7. Februar 2020 ging die Emotet-Gang wohl in eine Art Entwicklermodus über, da man vermutlich den Braten gerochen hatte. Die Emotet-Gang war  in der Zeit vom 7. Februar bis zum 17. Juli 2020 inaktiv und stellte das Spamming ein – um an der Entwicklung ihrer Malware zu arbeiteten. Während die Spam-Verbreitung vollständig gestoppt wurde, lieferte die Gruppe weiterhin einige wenige Kern-Updates von Binärdateien und Protokoll-Updates aus. Zusätzlich wurde beobachtet, dass Emotet bereits am 2. April 2020 Trickbot für die Verteilung verwendete.

Mitte April veröffentlichte Emotet eine neue Protokolländerung, zusammen mit Änderungen an der Kernbinärdatei. Eine der wichtigsten Änderungen war die Einführung einer neuen Installationsmethode, mit der die Explorer-Registrierungsschlüsselmethode abgeschafft wurde. Außerdem entfernte dieses neue Update die Verwendung von Gleichzeitigkeits-Mutexen, möglicherweise in dem Bestreben, andere, öffentlichere Killswitches zu umgehen.

Die Installationsmethode für Explorer-Registrierungsschlüssel wurde zwar zurückgezogen, aber nicht vollständig aus dem Code entfernt. Stattdessen griff die Malware auf den Explorer-Registrierungsschlüssel zu, als sie prüfte, ob es alte Installationen gab, die entfernt werden mussten.

Wurde auf diesen Schlüssel zugegriffen, brachte EmoCrash die Malware trotzdem zum Absturz ,und zwar, bevor sie nach außen kommunizieren konnte. Unglücklicherweise wurde dieser Absturz ausgelöst, nachdem Emotet sich selbst installiert hatte (einschließlich der Erstellung von Diensten und dem Löschen von Dateien). Die Malware konnte jedoch keine Verbindung zu den Controll-Servern herstellen und der Dienst konnte nicht ausgeführt werden. Da der Absturz außerdem immer noch die Ereignis-ID 1000 und 1001 auslöste, konnten die Responder diese Dateien leicht lokalisieren und entfernen.

Während Emotet erst am 17. Juli 2020 wieder aktiv wurde, erhielt Binary Defense Benachrichtigungen von verschiedenen Organisationen, die EmoCrash eingesetzt und eine anhaltende Emotet-Infektion festgestellt und eingedämmt hatten. Da Emotet während dieser Zeit nicht spammte, musste sich der Verlust ganzer Opferorganisationen negativ auf den Betrieb des Botnets auswirken. Ab dem 17. Juli 2020, nach einer mehrmonatigen Entwicklungsphase, konnten die infizierten Systeme wieder zum Spamming zurück. Da EmoCrash zu dieser Zeit noch aktiv war, konnte die Software bis zum 6. August einen vollständigen Schutz vor Emotet bieten.  Jetzt haben die Malware-Autoren diese Schwachstelle aber geschlossen, der EmoCrash wirkt also nicht mehr. Details sind hier nachlesbar.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

5 Antworten zu EmoCrash: Impfschutz vor Emotet-Infektionen hielt 6 Monate

  1. Dietmar sagt:

    Alle Menschen sind gleich, manche halt gleicher. Manche bekommen den Schutz bei anderen ist es scheinbar egal. Datalife matters?
    Würde mich interessieren wie die Situation bei einem Corona-Killswitch wär….

    • Günter Born sagt:

      Nun ja, die Vorgehensweise macht in meinen Augen in solchen Fällen sehr viel Sinn. Ansonsten ist jeder für seinen Schutz verantwortlich …

      • Joerg Odenwald sagt:

        Hallo Günter,
        sehr oft bin ich mit dir einer Meinung und auch ein großer Fan deines Blogs, aber in diesem Fall sehe ich das anders! Hier wäre aus meiner Sicht ‚full disclosure' angesagt gewesen und nicht eine kurzzeitige Vorteilnahme durch ein paar Behördenbüros… Das hat weder was gebracht, noch kann man es als fair bezeichnen… Jetzt kommt es für uns alle umso heftiger…

        LG
        Joerg

        • Manfred sagt:

          Wieso umso heftiger? Du wirst bei Fehlverhalten genauso infiziert wie davor.
          Wenn man das öffentlich gemacht hätte, hätte die Gang das Problem viel schneller bemerkt und behoben, sodass die kritische Infrastruktur (!!!!!!) keinen Vorteil gehabt hätte. Und die ist mir ehrlich gesagt auch wichtiger als ein paar private Fotos…

          Auch wenn das als Einzelner durchaus schlecht ist, aber etwas weniger Egoismus hat in diesem Fall ein halbes Jahr Zeit verschafft, die IT Systeme mehr abzusichern.

  2. Bitte RICHTIG recherchieren, keine Märchen verbreiten, und die vielen Grammatik-Fehler korrigieren!

    Insbesonders Dein folgender Satz ist hanebüchener Blödsinn:
    | Der Versuch der Malware, diese ".exe" auszuführen, scheiterte jedoch, da "."
    | bei vielen Betriebssystemen das aktuelle Arbeitsverzeichnis bezeichnete.

    .exe ist ein (fast) normaler Dateiname, der ÜBERHAUPT nichts mit dem durch "." referenzierten "current working directory" zu tun hat.
    Zur Demonstration startest Du eine Eingabeaufforderung und führst folgende Kommandos aus:
    COPY %COMSPEC% .exe
    .\.exe (oder nur .exe)
    START .exe (oder START .\.exe)

    JFTR: statt der Endung^W^Wdes Dateinamens .exe kannst Du auch .bin oder .xxx oder .wuensch-dir-was angeben: der Win32-Funktion CreateProcess() ist die Dateiendung völlig wurscht (dito bei DLLs und LoadLibrary())!

Schreibe einen Kommentar zu Stefan Kanthak Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.