Ramsay: Ein Cyberspionage‑Toolkit speziell für Air‑Gap‑Netzwerke | WeLiveSecurity

Ramsay: Ein Cyberspionage‑Toolkit speziell für Air‑Gap‑Netzwerke

ESET-Forscher haben ein bisher unbekanntes Cyberspionage-Framework entdeckt, das wir Ramsay genannt haben. Es ist auf die Erfassung und Exfiltration sensibler Dokumente aus Air-Gap-Netzwerken zugeschnitten.

ESET-Forscher haben ein bisher unbekanntes Cyberspionage-Framework entdeckt, das wir Ramsay genannt haben. Es ist auf die Erfassung und Exfiltration sensibler Dokumente aus Air-Gap-Netzwerken zugeschnitten.

ESET-Forscher haben ein bisher unbekanntes Cyberspionage-Framework entdeckt, das wir Ramsay genannt haben. Es ist auf die Erfassung und Exfiltration sensibler Dokumente aus Air-Gap-Netzwerken zugeschnitten. Air-Gap-Netzwerke sind Systeme, die physisch und logisch voneinander getrennt sind und die die Übertragung von Daten nur durch ein transportables Speichermedium zulassen.

Zunächst haben wir eine Instanz von Ramsay in VirusTotal gefunden. Diese Probe wurde aus Japan hochgeladen und brachte uns auf die Spur weiterer Komponenten und Versionen des Frameworks. Wir konnten wesentliche Beweise dafür ermitteln, dass sich dieses Framework noch in einem Entwicklungsstadium befindet und seine Distributionsvektoren noch einer Feinabstimmung unterzogen werden.

Derzeit sind kaum Ziele für das Toolkit auszumachen. Laut ESETs Telemetriedaten wurden bisher nur wenige Opfer entdeckt. Wir glauben, dass die geringe Zahl von Opfern für die Hypothese spricht, dass sich das Framework in einem laufenden Entwicklungsprozess befindet. Jedoch kann die geringe Zahl entdeckter Opfer auch darauf zurückzuführen sein, dass es sich bei den Zielsystemen um Air-Gap-Netzwerke handelt.

Es konnten außerdem Gemeinsamkeiten mit der Retro Backdoor gefunden werden. Diese Malware wurde in der Vergangenheit mit DarkHotel in Verbindung gebracht, einer berüchtigten APT-Gruppe, deren Cyberspionage-Operationen bis ins Jahr 2004 zurückreichen und die in der Vergangenheit Regierungsstellen in China und Japan angegriffen hat.

Angriffsvektoren

Während der Entdeckung der verschiedenen Instanzen von Ramsay fanden wir heraus, dass sie mit einer Reihe von Angriffsvektoren eingesetzt wurden. Es sind die folgenden:

Abbildung 1: Überblick der entdeckten Ramsay-Versionen

Abbildung 1: Überblick der entdeckten Ramsay-Versionen

Schädliche Dokumente, die Ramsay Version 1 freisetzen

Dieser Angriffsvektor besteht aus schädlichen Dokumenten, die die Schwachstelle CVE-2017-0199 ausnutzen, um eine ältere Version von Ramsay freizusetzen.
Ein solches Dokument enthält ein erstes Visual Basic-Skript, das im folgenden Screenshot OfficeTemporary.sct heißt und die Ramsay-Malware im Dokumentkörper extrahiert. Es tarnt sich als JPG-Bild und enthält ein Base64-codiertes PE unter einem JPG-Header.

IDIndexOLE Object
00x80c8Format_id: 2 (Embedded)
Class name: ‘Package’
Data size: 8994
OLE Package object:
Filename: u‘OfficeTemporary.sct’
Source path: u‘C:\\Intel\\OfficeTemporary.sct’
Temp path = u:‘C\\Intel\\OfficeTemporary.sct’
MD5 = ‘cf133c06180f130c471c95b3a4ebd7a5’
EXECUTABLE FILE
10xc798Format_id: 2 (Embedded)
Class name: ‘OLE2Link’
Data size: 2560
MD5 = ‘daee337d42fba92badbea2a4e085f73f’
CLSID: 00000300-0000-0000-C000-000000000046
StdOleLink (embedded OLE object - known related to CVE-2017-0199, CVE-2017-8570, CVE-2017-8759 or CVE-2018-8174.
Possibly an exploit for the OLE2Link vulnerability (VU#921560, CVE-2017-0199)

Tabelle 1: OLE Objektlayout innerhalb der RTF-Datei von Ramsay Version 1 (wie von oletools angezeigt)

Wir haben festgestellt, dass diese spezifische, durch die Dokumente freigesetzte, Ramsay-Instanz eine geringe Komplexität in ihrer Implementierung aufwies und dass ihr viele der erweiterten Funktionen fehlten, die von späteren Ramsay-Versionen genutzt wurden.

Mehrere Instanzen dieser schädlichen Dokumente wurden als Uploads öffentlicher Sandbox-Engines entdeckt, gekennzeichnet als Testgegenstände wie „access_test.docx“ oder „Test.docx“. Dies deutet auf weiterlaufende Tests dieses spezifischen Angriffsvektors hin.

Aufgrund der geringen Komplexität des freigesetzten Ramsay-Agenten ist es möglich, dass die Entwickler diese Instanz nur zur Evaluation in die schädlichen Dokumente einbetten.

Köder-Installer setzt Ramsay Version 2.a frei

Wir haben auf VirusTotal eine hochgeladene Instanz von Ramsay gefunden, die sich als 7zip-Installationsprogramm tarnt.
Der Grund, warum wir diese Malware Ramsay genannt haben, beruht auf einigen, in dieser Binärdatei enthaltenen, Zeichenfolgen.

Abbildung 2: Strings die „Ramsay“ enthalten

Abbildung 2: Strings die „Ramsay“ enthalten

Diese Version von Ramsay zeigt raffiniertere Verschleierungs- und Persistenz-Taktiken sowie die Einführung neuer Funktionen, wie einer Spreader-Komponente und eines Rootkits. Die Spreader-Komponente wird in Punkt 3 im Abschnitt Funktionen ausführlicher dokumentiert.

Schädliche Dokumente, die Ramsay Version 2.b freisetzen

Dieser Angriffsvektor besteht aus der Distribution eines anderen schädlichen Dokuments, das CVE-2017-11882 missbraucht. Dieses Dokument dropt ein Ramsay-Installer mit dem Namen lmsch.exe (siehe Abbildung 3).

IDIndexOLE Object
00x80c8Format_id: 2 (Embedded)
Class name: ‘Package’
Data size: 644790
OLE Package object:
Filename: u‘lmsch.exe’
Source path: u‘C:\\fakepath\\lmsch.exe’
Temp path = u:‘C:\\fakepath\\lmsch.exe’
MD5 = ‘27cd5b330a93d891bdcbd08050a5a6e1’
10xc798Format_id: 2 (Embedded)
Class name: ‘Equation.3’
Data size: 3584
MD5 = ‘5ae434c951b106d63d79c98b1a95e99d’
CLSID: 0002CE02-0000-0000-C000-000000000046
Microsoft Equation 3.0 (Known related to CVE-2017-11882 or CVE-2018-0802)
Possibly an exploit for the Equation Editor vulnerability (VU#421280, CVE-2017-11882)

Tabelle 2: OLE Objektlayout innerhalb der RTF-Datei von Ramsay Version 2.b (wie von oletools angezeigt)

Die in diesem Dokument genutzte Ramsay-Version ist eine leicht modifizierte Version von Ramsay Version 2.a, mit dem Hauptunterschied, dass die Spreader-Komponente nicht genutzt wird. Die Funktionalität der übrigen Komponenten ist in Bezug auf Ramsay Version 2.a gleich.

Client-Ausführung infizierter Dateien

Wie bereits erwähnt, liefert Ramsay Version 2.a eine Spreader-Komponente, die sich wie ein Dateiinfektor verhält und die Struktur von gutartigen ausführbaren PE-Dateien auf Wechseldatenträgern und gemeinsam genutzten Netzwerklaufwerken ändert, um schädliche Ramsay-Artefakte einzubetten, die bei der Ausführung der Hostdatei ausgelöst werden.

Der Spreader ist in seinem Ausbreitungsmechanismus sehr aggressiv. Alle ausführbaren PE-Dateien auf den Ziellaufwerken wären Kandidaten für eine Infektion.

Anhand der Kompilierungszeitstempel in den Komponenten der verschiedenen, gefundenen Versionen von Ramsay können wir die folgende Entwicklungszeitleiste des Frameworks abschätzen:

Abbildung 3: Schätzung zum Zeitstrahl von Ramsay’s Entwicklung

Abbildung 3: Schätzung zum Zeitstrahl von Ramsay’s Entwicklung

Die Analyse der verschiedenen Kompilierungszeitstempel, die für verschiedene Komponenten gefunden wurden, lässt darauf schliessen, dass dieses Framework seit Ende 2019 entwickelt wird. Es besteht außerdem die Möglichkeit, dass derzeit zwei Versionen gepflegt werden, die auf verschiedene Ziele zugeschnitten sind.

Persistenzmechanismen

Je nach Version implementiert Ramsay verschiedene Persistenzmechanismen von unterschiedlicher Komplexität. Hier sind einige dieser Persistenzmechanismen:

  • AppInit DLL-Registrierschlüssel
    Das Windows-Betriebssystem bietet die Funktion, dass benutzerdefinierte DLLs mithilfe des AppInit DLL-Registrierungsschlüssel in den Adressraum fast aller Anwendungsprozesse geladen werden können. Diese Technik ist nicht besonders komplex. Sie ist in frühen Ramsay-Versionen implementiert und in anderen Malware-Familien ebenfalls verbreitet.
  • Scheduled Tasks via COM-API
    Scheduled Tasks erlauben Administratoren Aufgaben oder „Jobs“ zu festgelegten Zeiten ausführen, anstatt jedes Mal, wenn das System gestartet wird oder der Benutzer sich anmeldet. Diese Funktion kann über die Windows COM-API implementiert werden, an die die ersten Versionen von Ramsay angepasst wurden. Aufgrund der hohen Übereinstimmung mit Carberps Implementierung ist es sehr wahrscheinlich, dass die bei Ramsay verwendete Implementierung aus dem öffentlich verfügbaren Quellcode von Carberp übernommen wurde.
  • Phantom-DLL-Hijacking
    Ausgereiftere Versionen von Ramsay weisen eine zunehmende Komplexität seiner Persistenztechniken auf. Dazu gehört auch eine manchmal als „Phantom DLL Hijacking“ bezeichnete Technik.
    Phantom DLL Hijacking missbraucht die Tatsache, dass viele Windows-Anwendungen veraltete Abhängigkeiten verwenden, die für die Funktionalität der Anwendung selbst nicht unbedingt erforderlich sind. Diese ermöglichen die Nutzung bösartiger Versionen dieser Abhängigkeiten.Zwei Dienste werden für diese Technik angegriffen: Die WSearch (Windows Search) um die msfte.dll zu hijacken

    Abbildung 4: Hijacking des Microsoft Search Dienstes msfte.dll

    und den MSDTC Dienst (Microsoft Distributed Transaction Coordinator) um eine Oracle Abhängigkeit namens oci.dll zu hijacken.

    Abbildung 5: Hijacking des MSDTC Dienstabhängigkeit oci.dll

    Abbildung 5: Hijacking des MSDTC Dienstabhängigkeit oci.dll

    Diese Persistenztechnik ist äußerst vielseitig und ermöglicht es den Ramsay-Agents, die als DLLs bereitgestellt werden, ihre Logik in separate Abschnitte zu fragmentieren und verschiedene Funktionen zu implementieren, die auf die jeweiligen Prozesse angepasst sind, in die der Agent geladen wird. Darüber hinaus erschwert die Verwendung dieser Technik die Erkennung, weil das Laden dieser DLLs in ihre jeweiligen Prozesse / Dienste nicht unbedingt einen Alarm auslöst.

Fähigkeiten

Die Architektur von Ramsay bietet eine Reihe von Funktionen, die mittels eines Protokollierungsmechanismus überwacht werden. Dieser soll den Angreifern beim Erreichen ihrer Ziele helfen, indem er einen Feed mit verwertbaren Informationen zur Durchführung von Exfiltrations-, Steuerungs- und Verschiebungssaktionen sowie allgemeine Verhaltens- und Systemstatistiken für jedes kompromittierte System bereitstellen. Die Realisierung dieser Aktionen ist aufgrund der folgenden Fähigkeiten möglich:

1. Dateisammlung und verdeckte Speicherung

Das Hauptziel des Frameworks ist die Sammlung aller vorhandenen Microsoft Word-Dokumente im Zieldateisystem. Alle Erfassungsphasen sind in Abbildung 8 dargestellt:

Abbildung 6: Datensammel-Mechanismus

Word-Dokumente werden zuerst gesammelt und in einem vorläufigen Verzeichnis gespeichert. Der Speicherort dieses Verzeichnisses kann je nach Ramsay-Version variieren. Zwei der Verzeichnisse, die wir für diesen Zweck beobachtet haben, waren %APPDATA%\Microsoft\UserSetting und %APPDATA%\Microsoft\UserSetting\MediaCache.

Abhängig von der Ramsay-Version ist die Dateisammlung nicht auf das lokale Systemlaufwerk beschränkt, sondern durchsucht auch weitere Laufwerke wie Netzwerk- oder Wechsellaufwerke:

Abbildung 7: Hex-Ray Output des Verfahrens um Wechsellaufwerke für die Dateisammlung zu scannen

Abbildung 7: Hex-Ray Output des Verfahrens um Wechsellaufwerke für die Dateisammlung zu scannen

Abbildung 8: Hex-Ray Output des Verfahrens um Netzlaufwerke für die Dateisammlung zu scannen

Abbildung 8: Hex-Ray Output des Verfahrens um Netzlaufwerke für die Dateisammlung zu scannen

Die gesammelten Dokumente werden mit dem RC4 Stream Cipher-Algorithmus verschlüsselt.

Der RC4-Schlüssel, der zum Verschlüsseln jeder Datei verwendet wird, ist ein berechneter MD5-Hash mit einer zufällig generierten Sequenz von 16 Bytes, der mit einem fest in der Malware codierten Salt von 16 Bytes versehen ist. Die ersten 16 Bytes des Puffers, in dem die verschlüsselte Datei gespeichert wird, entsprechen dem tatsächlich verwendeten RC4-Schlüssel:

Abbildung 9: Hex-Ray Output der RC4-Schlüsselgenerierung und Speicherung

Abbildung 9: Hex-Ray Output der RC4-Schlüsselgenerierung und Speicherung

Gesammelte Dateien im vorläufigen Verzeichnis werden mithilfe einer WinRAR-Instanz komprimiert, die der Ramsay-Installer dropt. Dieses komprimierte Archiv wird im vorläufigen Verzeichnis gespeichert und generiert dann ein Ramsay-Container-Artefakt:

Abbildung 10: Hex-Ray Output der Container-Generierung

Abbildung 10: Hex-Ray Output der Container-Generierung

Wie im vorherigen Screenshot gezeigt, enthalten diese Ramsay-Container einen Magischen Wert am Anfang der Datei sowie eine Hardwareprofil-GUID, die eine Kennung für den angegriffenen Computers darstellt. Eine zusätzliche XOR-basierte Verschlüsselungsschicht wird auf das generierte komprimierte Archiv angewendet. Das folgende Diagramm zeigt die Struktur dieser Artefakte:

Abbildung 11: Struktur der Ramsay Container

Abbildung 11: Struktur der Ramsay Container

Ramsay implementiert eine dezentrale Methode zum Speichern dieser Artefakte im Dateisystem des Opfers mithilfe von Inline-Hooks, die auf zwei Windows-API-Funktionen, WriteFile und CloseHandle, angewendet werden.

Der Hauptzweck der verknüpften WriteFile-Prozedur besteht darin, das Dateihandle der zu speichernden Datei zu speichern und einen weiteren Hook in der CloseHandle-API-Funktion zu installieren. Die CloseHandle gehookte Prozedur prüft dann, ob der Name der betreffenden Datei die Erweiterung .doc hat. In diesem Fall wird am Ende des betreffenden Dokuments das Artefakt des Ramsay-Containers angehängt, gefolgt von einem Stream von 1024 Byte, der eine Microsoft Word-Dokumentfußzeile bezeichnet.

Dies geschieht als Verschleierungsmaßnahme, um das eingebettete Artefakt im betreffenden Dokument vor dem bloßen Auge zu verbergen:

Abbildung 12: Hex-Rays Output für den Code um einen Word-Dokument-Footer am Ende des Zieldokuments anzuhängen.

Abbildung 12: Hex-Rays Output für den Code um einen Word-Dokument-Footer am Ende des Zieldokuments anzuhängen.

An Word-Dokumente angehängte Ramsay-Container werden markiert, um zu vermeiden, dass redundante Artefakte an bereits betroffene Dokumente angehängt werden. Außerdem wird das vorläufige Verzeichnis gelöscht, um in Intervallen ein brandneues Ramsay-Artefakt zu generieren.

Obwohl die betroffenen Dokumente verändert werden, wird ihre Integrität wird nicht beeinträchtigt. Jedes betroffene Word-Dokument bleibt auch nach dem Anhängen des Artefakts voll funktionsfähig.

Die Exfiltration dieser Artefakte erfolgt über eine externe Komponente, die wir nicht aufspüren konnten. Jedoch glauben wir, entsprechend der dezentralen Methodik, die Ramsay für die Speicherung gesammelter Artefakte implementiert, dass diese Komponente das Dateisystem des Opfers nach den magischen Werten des Ramsay-Containers durchsuchen würde, um die Speicherorte der zu exfiltrierenden Artefakte zu finden.

2. Befehl-Ausführungen der Ramsay-Malware

Im Gegensatz zu herkömmlicher Malware verfügt Ramsay weder über ein netzwerkbasiertes C&C-Kommunikationsprotokoll, noch wird versucht, eine Verbindung zu einem Remote Host für Kommunikationszwecke herzustellen. Ramsays Steuerungsprotokoll folgt der gleichen dezentralen Philosophie, die für die Speicherung zu sammelnder Daten implementiert wurde.

Die Malware scannt alle Netzwerkfreigaben und Laufwerke (außer A: und B:, die normalerweise für Disketten reserviert sind) nach möglichen Steuerungsdateien. Zunächst sucht Ramsay nach Word-Dokumenten und, in neueren Versionen, auch nach PDFs und ZIP-Archiven:

Abbildung 13: Hex-Rays-Ausgabe des Ramsay-Scans zum Abrufen von Steuerungsdateien.

Abbildung 13: Hex-Rays-Ausgabe des Ramsay-Scans zum Abrufen von Steuerungsdateien.

Diese Dateien werden auf das Vorhandensein eines für das Steuerdateiformat spezifischen „magischen Markers“ analysiert. Genauer gesagt, sucht Ramsay nach einer von zwei vorgegebenen kodierten Hardware-Profil-GUIDs. Eine dieser GUIDs ist, wie Abbildung 14 zeigt, fest im Malware-Code eingebettet. Die andere ID wird dynamisch, auf der Grundlage des Computers des Opfers generiert. Wird einer der Subject Identifiers gefunden, wird ein Parsing auf eine Befehlssignatur versucht.

Abbildung 14: Hex-Rays-Ausgabe der Ramsay Steuerungsdatei-Analyse

Abbildung 14: Hex-Rays-Ausgabe der Ramsay Steuerungsdatei-Analyse

Die Suche nach diesen beiden GUID-Instanzen impliziert, dass Ramsays Steuerungsdokumente absichtlich „opferunabhängig“ gestaltet werden können und dieselbe Steuerungsdokumente-Instanz für eine Reihe von Opfern bereitgestellt werden kann, indem eine „globale“ GUID in Steuerungsdokumenten verwendet wird. Auf der anderen Seite können Steuerungsdokumente erstellt werden, indem eine bestimmte GUID eingebettet wird, die ausschließlich auf dem Computer eines einzelnen Opfers abgelegt werden soll. Dieser Indikator für die Implementierung des Ramsay Steuerprotokolls impliziert, dass das Backend-Gegenstück möglicherweise automatisiert ist.

Das Ramsay-Steuerprotokoll unterstützt die drei folgenden Befehle:

SignatureCommand
Rr*e#R79m3QNU3SyFile Execution
CNDkS_&pgaU#7Yg9DLL Load
2DWcdSqcv3?(XYqTBatch Execution

Tabelle 3. Ramsays Steuerbefehle

Nachdem eine gegebene Befehlssignatur abgerufen wurde, wird das auszuführende Tool, im Body des Steuerungsdokuments extrahiert, um anschließend wiederhergestellt zu werden, wobei das Steuerungsdokument nach der Befehlsausführung in seine ursprüngliche Form überführt wird.

3. Verbreitung der Ramsay-Malware

Unter den verschiedenen Dateien, die von den neuesten Versionen von Ramsay fallen gelassen wurden, finden wir eine Spreader-Komponente. Diese ausführbare Datei sucht nach Netzwerkfreigaben und Laufwerken (mit Ausnahme der Laufwerke A: und B: ):

Abbildung 15: Hex-Rays-Ausgabe von Spreader-Scanroutinen

Man beachte, dass es einen Zusammenhang zwischen den Ziellaufwerken gibt, die Ramsay für die Verbreitung scannt, und dem Abruf von Steuerungsdokumenten. Dadurch wird die Beziehung zwischen den Ausbreitungs- und Steuerungsfähigkeiten von Ramsay beurteilt, wobei sich zeigt, wie die Ramsay Malware-Entwickler das Framework für die seitliche Bewegung in Netzwerken nutzen. Es ist sehr wahrscheinlich, dass dieses Framework für den Betrieb innerhalb sogenannter Air-gapped-Netzwerke konzipiert ist.

Der Verbreitungsmechanismus besteht hauptsächlich aus einer Datei-Kompromittierung, um für jede zugängliche PE-Datei innerhalb der oben genannten Ziellaufwerke ausführbare Dateien zu erzeugen, die in ihrer Struktur den Lockvogel-Installationsprogrammen von Ramsay ähneln.

Die folgende Darstellung veranschaulicht die Änderungen, die nach der Kompromittierung der anvisierten ausführbaren Dateien vorgenommen wurden, und wie diese Komponenten bei der Ausführung zusammenwirken:

Abbildung 16: Änderungen der Dateistruktur während Kompromittierung und Ausführung

Abbildung 16: Änderungen der Dateistruktur während Kompromittierung und Ausführung

Alle verschiedenen Tools, die im Infektionsstadium involviert sind, stehen im Zusammenhang mit der Verbreitung der Malware oder wurden zuvor von einer anderen Ramsay-Komponente im System abgelegt. Einige der Tools werden für die folgenden Token geparst:

Abbildung 17: Hex-Rays-Ausgabe von Token zur Suche nach verschiedenen Tools innerhalb des Verbreitungsmechanismus

Abbildung 17: Hex-Rays-Ausgabe von Token zur Suche nach verschiedenen Tools innerhalb des Verbreitungsmechanismus

Nachdem einer Kompromittierung einer bestimmten Datei, wird diese mithilfe eines Tokens am Ende markiert, um dem Spreader-Mechanismus zu signalisieren, dass eine Kompromittierung hier bereits erfolgte.

Darüber hinaus verfügen einige Ramsay-komponenten über einen Netzwerkscanner, der Computer im Subnetz des kompromittierten Hosts aufdecken soll, die nicht gegen die EternalBlue SMBv1-Schwachstelle gepatcht sind.

Diese Informationen werden zu Logdaten hinzugefügt, die Ramsay sammelt. Die Ramsay-Operatoren können die Informationen später dazu benutzen, das Netzwerk zu einem späteren Zeitpunkt über einen anderen Eintrittskanal seitlich zu durchforsten.

Weitere Anmerkungen

Bei der Analyse der Ramsay Version 2.a Spreader-Komponente stellte man fest, dass eine Reihe von Token verwendet wurden, die zuvor bereits in der Darkhotel Retro Backdoor zu sehen waren. Dabei handelt es sich um die folgenden Tokens:

Abbildung 18: Hex-Rays-Ausgabe der wiederverwendeten Token aus Retro stammend

Abbildung 18: Hex-Rays-Ausgabe der wiederverwendeten Token aus Retro stammend

Abbildung 19: Token-Wiederverwendung bei der Retro-URL-Erstellung

Abbildung 19: Token-Wiederverwendung bei der Retro-URL-Erstellung

Ramsay ordnet die Opfer mithilfe der GetCurrentHwProfile-API an, um eine sezifische GUID für den Computer des Opfers zu generieren. Gleiches passiert auch in Retro und beide nutzen zudem dieselbe Standard-GUID für den Fall, dass der API-Abruf fehlschlägt:

Abbildung 20: Ramsay und Retro GUID-Generierung

Abbildung 20: Ramsay und Retro GUID-Generierung

Sowohl Ramsay als auch Retro verwenden den gleichen Encoding-Algorithmus zur Kodierung der abgerufenen GUID.

Abbildung 21: Ramsay und Retro GUID Encoding-Schema

Abbildung 21: Ramsay und Retro GUID Encoding-Schema

Die von GetCurrentHwProfile abgerufene GUID ist für die Hardware des Systems spezifisch, aber nicht in Bezug auf die Benutzer- oder die PC-Instanz. Daher ist es wahrscheinlich, dass die Ramsay-Betreiber allein durch die Verwendung der GUID auf Duplikate stoßen könnten, mit der Absicht, verschiedene Opfer zu serialisieren.

Der Zweck des zu Grunde liegenden Schemas besteht darin, eine GUID zu erzeugen, die weniger anfällig für eine Duplikate-Erstellung ist. Deshalb wird der GUID die Ethernet-Adapteradresse des Rechners angehängt (Salting). Ramsay und Retro verwenden dasselbe Schema zur Generierung eindeutiger Identifikatoren.

Ähnlichkeiten fanden wir auch in der Art und Weise, wie Ramsay und Retro einige ihrer Protokolldateien abspeichern:

Abbildung 22: Dateinamen-Konvention bei Ramsay- und Retro

Abbildung 22: Dateinamen-Konvention bei Ramsay- und Retro

An dieser Stelle möchten wir hervorheben, dass Retro neben den dokumentierten Techniken auf schädliche Instanzen von msfte.dll, oci.dll und lame_enc.dll sowie auf Phantom-DLL-Hijacking zurückgreift. Ähnliches beobachteten wir auch bei Ramsay in Bezug auf msfte.dll und oci.dll.

Ramsay und Retro benutzen für ihr Toolset gleichermaßen Open-Source-Software, wie z.B. UACMe für die Privilege Escalation und ImprovedReflectiveDLLInjection für das Deployen.

Wir bemerkten schließlich Metadaten in koreanischer Sprache in den von Ramsay verwendeten schädlichen Dokumenten. Das deutet auf die Verwendung koreanischer Vorlagen hin.

Abbildung 23: Metadaten bösartiger Dokumente mit dem koreanischen Wort für "Titel"

Abbildung 23: Metadaten bösartiger Dokumente mit dem koreanischen Wort für „Titel“

Fazit

Ausgehend von den verschiedenen Instanzen des gefundenen Frameworks, durchlief Ramsay verschiedene Entwicklungsstadien, was eine zunehmende Progression in der Anzahl und Komplexität der Fähigkeiten bedeutete.

Malware-Entwickler, die auf Angriffsvektoren spezialisiert sind, probieren verschiedene Varianten aus, um in ein Netzwerk / System zu gelangen. Dazu gehören in unserem Fall ein älteres Exploit für eine Word-Schwachstelle aus dem Jahr 2017 und der Einsatz einer Anwendung mit eingebettetem Trojaner.

Wir interpretieren das so, dass sich die Malware-Entwickler vorher ein Verständnis der Netzwerk-Umgebung der Opfer verschaffen und daraufhin Angriffsvektoren maßschneidern. Damit können sie erfolgreich in Zielsysteme eindringen, ohne unnötige Ressourcen verschwenden zu müssen.

Einige Instanzen des Ramsay-Frameworks werden nach wie vor evaluiert, was die derzeit geringe Opferzahl erklären könnte. Beachten sollte man auch, dass die von Ramsay anvisierten Ziele innerhalb eines Air-gapped-Netzwerks liegen, was zur niedrigen Sichtbarkeit in Bezug auf kompromittierte Opfer beiträgt.

Wir werden die Ramsay-Aktivitäten weiterhin beobachten und relevante Informationen in unserem Blog veröffentlichen. Fragen und Anregungen senden Sie bitte in Englisch an threatintel@eset.com.

Die IoCs finden Sie auch auf unserem GitHub-Repo.

Indicators of Compromise (IoCs)

SHA-1ESET detection nameComments
f79da0d8bb1267f9906fad1111bd929a41b18c03 Win32/TrojanDropper.Agent.SHN Initial Installer
62d2cc1f6eedba2f35a55beb96cd59a0a6c66880 Win32/Ramsay.A Installer Launcher
baa20ce99089fc35179802a0cc1149f929bdf0fa Win32/HackTool.UACMe.T UAC Bypass Module
5c482bb8623329d4764492ff78b4fbc673b2ef23 Win32/HackTool.UACMe.T UAC Bypass Module
e7987627200d542bb30d6f2386997f668b8a928c Win32/TrojanDropper.Agent.SHM Spreader
3bb205698e89955b4bd07a8a7de3fc75f1cb5cde Win32/TrojanDropper.Agent.SHN Malware Installer
bd8d0143ec75ef4c369f341c2786facbd9f73256 Win32/HideProc.M HideDriver Rootkit
7d85b163d19942bb8d047793ff78ea728da19870 Win32/HideProc.M HideDriver Rootkit
3849e01bff610d155a3153c897bb662f5527c04c Win64/HackTool.Inject.A Darkhotel Retro Backdoor Loader
50eb291fc37fe05f9e55140b98b68d77bd61149e Win32/Ramsay.B Ramsay Initial Installer (version 2.b)
87ef7bf00fe6aa928c111c472e2472d2cb047eae Win32/Exploit.CVE-2017-11882.H RTF file that drops 50eb291fc37fe05f9e55140b98b68d77bd61149e
5a5738e2ec8af9f5400952be923e55a5780a8c55 Win32/Ramsay.C Ramsay Agent DLL (32bits)
19bf019fc0bf44828378f008332430a080871274 Win32/Ramsay.C Ramsay Agent EXE (32bits)
bd97b31998e9d673661ea5697fe436efe026cba1 Win32/Ramsay.C Ramsay Agent DLL (32bits)
eb69b45faf3be0135f44293bc95f06dad73bc562 Win32/Ramsay.C Ramsay Agent DLL (32bits)
f74d86b6e9bd105ab65f2af10d60c4074b8044c9 Win64/Ramsay.C Ramsay Agent DLL (64bits)
ae722a90098d1c95829480e056ef8fd4a98eedd7 Win64/Ramsay.C Ramsay Agent DLL (64bits)

MITRE ATT&CK techniques

TacticIDNameDescription
Initial AccessT1091Replication Through Removable MediaRamsay’s spreading mechanism is done via removable drives.
ExecutionT1106Execution through APIRamsay’s embedded components are executed via CreateProcessA and ShellExecute .
T1129Execution through Module LoadRamsay agent can be delivered as a DLL.
T1203Exploitation for Client ExecutionRamsay attack vectors exploit CVE-2017-1188 or CVE-2017-0199.
T1035Service ExecutionRamsay components can be executed as service dependencies.
T1204User ExecutionRamsay Spreader component infects files within the file system.
PersistenceT1103AppInit DLLsRamsay can use this registry key for persistence.
T1050New ServiceRamsay components can be executed as service dependencies.
T1053Scheduled TaskRamsay sets a scheduled task to persist after reboot.
Privilege EscalationT1088Bypass User Account ControlRamsay drops UACMe instances for privilege escalation.
Defense EvasionT1038DLL Order HijackingRamsay agents will masquerade as service dependencies leveraging Phantom DLL Hijacking.
T1107File DeletionRamsay installer is deleted after execution.
T1055Process InjectionRamsay’s agent is injected into various processes.
T1045Software PackingRamsay installer may be packed with UPX.
DiscoveryT1083File and Directory DiscoveryRamsay agent scans for files and directories on the system drive.
T1135Network Share DiscoveryRamsay agent scans for available network shares.
T1057Process DiscoveryRamsay will attempt to find if host is already compromised by checking the existence of specific processes.
Lateral MovementT1210Exploitation of Remote ServicesRamsay network scanner may scan the host’s subnet to find targets vulnerable to EternalBlue.
T1105Remote File CopyRamsay attempts to infect files on network shares.
T1091Replication Through Removable MediaRamsay attempts to infect files on removable drives.
CollectionT1119Automated CollectionRamsay agent collects files in intervals.
T1005Data from Local SystemRamsay agent scans files on system drive.
T1039Data from Network Shared DriveRamsay agent scans files on network shares.
T1025Data from Removable MediaRamsay agent scans files on removable drives.
T1113Screen CaptureRamsay agent may generate and collect screenshots.
Command and ControlT1092Communication Through Removable MediaRamsay agent scans for control files for its file-based communication protocol on removable drives.
T1094Custom Command and Control ProtocolRamsay implements a custom, file-based C&C protocol.
ExfiltrationT1002Data CompressedRamsay agent compresses its collection directory.

Newsletter-Anmeldung

Hier können Sie mitdiskutieren