Fehlerhafte Ransomware Analyse der BlackMatter-Ransomware
Anbieter zum Thema
Ransomware ist eine Software wie jede andere, und die ist selten fehlerfrei. Eine Analyse zeigt, wie Betroffene von einem Logikfehler bei BlackMatter profitieren können, und wie man verhindert, dass die Ransomware Remote Shares verschlüsselt.

Bei BlackMatter handelt es sich um eine raffiniert agierende Ransomware-Familie, die Multithreading und verschiedene Anti-Debugging-Techniken nutzt, allesamt bereits ausführlich beschrieben. Ein schwerwiegender Fehler in der Logik von BlackMatter könnte jedoch geeignet sein, die Ausbreitung eines Angriffs zu verhindern oder doch zumindest einzugrenzen.
Zwar sah sich die BlackMatter-Gruppe unter dem wachsenden Druck der Ermittler im Spätherbst letzten Jahres genötigt, ihr Erpressungsgeschäft (vorläufig) aufzugeben. Die Analyse zeigt allerdings, dass der Logikfehler bereits in der DarkSide-Ransomware vor BlackMatter aufgetreten ist und vermutlich weiter vorkommen wird.
Laut Yan Linkov, Leiter Security Research bei Illusive, sollte insbesondere die Erstellung eines Computerobjekts, das aus lexikografischer Sicht an erster Stelle steht und ein leeres dNSHostName-Attribut im Standard-Computer-Container aufweist, die Ransomware-Verbreitung stoppen und damit zumindest die Reichweite des Angriffs minimieren.
An dieser Stelle wollen wir uns darauf konzentrieren, wie man ein vordefiniertes Verhalten nutzt, um zu verhindern, dass BlackMatter Remote Shares verschlüsselt.
Wer Opfer eines Angriffs mit BlackMatter geworden ist, sieht zunächst einen der typischen Ransomware-Bildschirme, hier in Form eines Wallpapers. Interessant ist das weitere Verhalten der Schadsoftware, das sich durch einen genaueren Blick auf die Netzwerkaktivitäten offenlegen lässt (Abbildung 1 in der Bildergalerie).
Dabei zeigt sich, dass andere Computer in der gleichen Umgebung nur dann verschlüsselt werden, wenn die integrierte Konfiguration dies zulässt. Dazu versucht BlackMatter zunächst, alle Computer aus dem Active Directory abzurufen (Abb. 2 in der Bildergalerie). Es ist erwähnenswert, dass BlackMatter nur Objekte aus dem vordefinierten Container „Computer“ anfordert, aber keine Objekte aus anderen betrieblichen Abteilungen (Organisationseinheiten (OUs). Wenn ein Unternehmen keine Computerobjekte im Container COMPUTER vorhält, sondern in einer anderen OU, sind die Folgen der Attacke weit weniger schwerwiegend.
Nachdem BlackMatter alle Computerobjekte in der Domain abgerufen hat, werden die Attribute der einzelnen Computerkonten über LDAP abgerufen, beispielsweise für COMP1 (Abb. 3 in der Bildergalerie). Die entsprechende LDAP-Antwort gibt dann die Attribute zurück (Abb.4 in der Bildergalerie).
Zum Auflisten der Computer im Active Directory verwendet BlackMatter die Standard-API-Funktionen: ADsOpenObject, AdsBuildEnumerator, ADsEnumerateNext. Die Schleife, in der die Computerkonten aufgelistet sind, wird dann für die weitere Verwendung gespeichert (Abb.5 in der Bildergalerie).
Im weiteren Verlauf der Analyse stellt sich dann heraus, dass ADsEnumerateNext bei jeder Iteration der Schleife aufgerufen wird. Die Schleife bricht allerdings ab, wenn einer der folgenden Fälle auftritt:
- ADsEnumerateNext schlägt fehl
- Es werden 0 Elemente von ADsEnumerateNext zurückgegeben
- Das Attribut „dNSHostName“ kann nicht abgerufen werden
Das Interessante daran ist, dass BlackMatter die Iteration abbricht, wenn ein bestimmtes Attribut nicht gesetzt ist, nämlich "dNSHostName''.
Im nächsten Schritt versucht BlackMatter mithilfe der NetShareEnum-Funktion (von Netapi32.dll), die eine NetShareEnumAll-Anforderung über RPC erstellt, zuzuordnen, über welche Freigaben jeder einzelne Computer verfügt und welche Detailinformationen zu diesen Freigaben noch zu bekommen sind (Abb. 6 und 7 in der Bildergalerie).
Anschließend versucht BlackMatter über SMB auf diese Freigaben zuzugreifen, speziell auf die „Secrets“-Freigaben und die Dateien zu verschlüsseln. Tatsächlich werden dabei aber bestimmte Freigaben ignoriert. Nämlich solche die weder vom Typ STYPE_DISKTREE oder STYPE_SPECIAL sind und die weder „admin$“ noch „C$“ sind (Abb. 8 und 9 in der Bildergalerie)
LDAP-Steuerelemente
Eine besondere Funktion kommt den LDAP-Steuerelementen zu. Das LDAP-Wiki beschreibt sie so: „Ein LDAP-Steuerelement ist ein Element, das in eine LDAP-Benachrichtigung eingebunden werden kann. Wenn es in einer Anforderungsbenachrichtigung enthalten ist, kann es verwendet werden, um zusätzliche Informationen über die Art und Weise, wie die Operation verarbeitet werden soll, bereitzustellen. Wenn es in der Antwortbenachrichtigung enthalten ist, kann es verwendet werden, um zusätzliche Informationen über die Art und Weise zu geben, wie die Operation verarbeitet wurde."
Wenn also beispielsweise das Steuerelement LDAP_SERVER_SORT_OID gesendet wird, gibt der Server die Ergebnisse sortiert zurück. In unserem Fall verwendet die Funktionalität von BlackMatter das Steuerelement LDAP_PAGED_RESULT_OID_STRING, was die Reihenfolge der Ergebnisse gerade nicht garantiert.
Unter Laborbedingungen hat der LDAP-Server im Active Directory die Computernamen jedoch bei jeder Anfrage alphanumerisch sortiert (ohne Berücksichtigung von Groß- und Kleinschreibung) zurück gegeben, auch wenn es sich um eine große Anzahl von Computerkonten handelt. Anders formuliert – das für die LDAP-Anforderung für Computer verwendete Steuerelement gewährleistet nicht, dass die Ergebnisse sortiert werden (Abb. 10 in der Bildergalerie).
Verhindern, dass die BlackMatter-Ransomware verfügbare Remote Shares verschlüsselt
Wie bereits erwähnt, fragt BlackMatter keine weiteren Computernamen ab, wenn die Ransomware auf ein Computerobjekt trifft, dem das Attribut "dNSHostName" fehlt. Wenn BlackMatter also zuerst ein Computerkonto ohne das Attribut "dNSHostName" aufruft, wird die Ransomware nicht versuchen, Informationen zu den übrigen Computern abzurufen, also keine verfügbaren Remote-Freigaben verschlüsseln. Wie gerade erläutert, ist die Reihenfolge der Ergebnisse für die Auflistung mit ADsBuildEnumerator und ADsEnumerateNext nicht garantiert, obwohl unter Laborbedingungen nur alphabetisch sortierte Ergebnisse beobachten wurden.
Der Grundgedanke, wie man verhindert, dass BlackMatter remote verfügbare Freigaben verschlüsselt, besteht darin, ein Computerkonto zu erstellen, dem das Attribut "dNSHostName" fehlt, und das in alphabetischer Reihenfolge der Computerkonten der Domain an erster Stelle steht. Ein Beispiel für diesen Namen könnte „aaa-comp“ sein (Abb. 11 in der Bildergalerie), bei dem zusätzlich das Attribut dNSHostName nicht gesetzt wurde (Abb. 12 in der Bildergalerie).
Man kann zwar nicht verhindern, dass BlackMatter auf einer Workstation in dieser AD-Umgebung die betreffenden Computer verschlüsselt. Was man aber sehr wohl verhindern kann ist, dass die Ransomware remote zugängliche Dateifreigaben verschlüsselt.
Darüber hinaus sei abschließend noch einmal darauf hingewiesen: Wenn Computerkonten nicht unter COMPUTERS, sondern unter einer anderen OU oder auch in einem anderen Container liegen, dann sind diese Computer ebenfalls vor der Verschlüsselung von Remote Shares gefeit.
Schlussendlich wurde die Analyse des BlackMatter-Logikfehlers auf zwei weitere äußerst aktive Ransomware-Gruppen ausgeweitet, die bereits davor in Erscheinung getreten sind: DarkSide und REvil. Bei letzter ließ sich der Logikfehler nicht verifizieren, allerdings auch keine Funktion zur Verschlüsselung von Remote Shares. DarkSide hingegen verfügt sehr wohl über genau diese Funktion und weist ebenfalls den analysierten Logikfehler auf.
Beim Thema Cybersicherheit legen wir den Schwerpunkt zumeist auf kritische Schwachstellen und Lücken, wie gerade jüngst bei Log4j. Es ist aber nicht ganz unwichtig zu realisieren, dass auch Malware ihre ganz eigenen Schwachstellen hat. Schwachstellen, die sich versierte Fachleute ihrerseits zunutze machen können, um die allgemeine Sicherheitslage zu verbessern. Es ist mit einiger Wahrscheinlichkeit davon auszugehen, dass der in DarkSide und BlackMatter beobachtete Logikfehler uns zukünftig an anderer Stelle wieder begegnen wird.
Über den Autor: Shahar Zelig ist Security Researcher bei Illusive.
(ID:48016142)