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

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.

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

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).

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

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

  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 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

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

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

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.

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.

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

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:

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

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

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 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

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

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

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"

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)

MITRE ATT&CK techniques