Wie die Schöpfer bösartiger Software versuchen, ihre Entdeckung zu vermeiden: Wir analysieren Spy.GmFUToMitm als Beispiel



Bild: Unsplash

Experten des Positive Technologies Security Centers (PT Expert Security Center) entdeckten ein interessantes Beispiel für die Verbreitung von Malware im chinesischen Internetsegment. Diese Software wird unter anderem zur Durchführung von MITM-Angriffen eingesetzt und zeichnet sich durch die Kombination verschiedener Techniken zur Vermeidung von Erkennungen aus. Wir haben uns entschlossen, sie zu analysieren, um zu zeigen, wie Entwickler bösartiger Software ihre Aktivitäten verbergen.

Wie alles begann


Das System zur Analyse des Netzwerkverkehrs hat uns darauf aufmerksam gemacht, dass eine böswillige Anwendung regelmäßig ein Bild mit zusätzlichen Inhalten anfordert. Der Download erfolgte von einer legitimen Quelle zum Speichern von Bildern - imgsa.baidu.com. Außerdem war es, wie sich herausstellte, ein Bild mit einem überwältigenden Maß an Niedlichkeit :) Und wie blasphemisch danach der Versuch von Angreifern aussah, mit ihm verschiedene böswillige Lasten zu verbergen!



Abb. 1. Bild, das verwendet wird, um die Tatsache der Lieferung der Nutzlast zu verbergen

Zunächst haben wir eine Suche nach ähnlichen Proben durchgeführt, um die anfänglichen Daten zu sammeln und die Proben zu vergleichen - und einige gefunden. Möglich wurde dies durch die charakteristischen Daten in der Netzwerkinteraktion und unsere umfangreiche Datenbank für böswilligen Datenverkehr. Insbesondere ist im Netzwerkverkehr ein eindeutiges Muster zu erkennen, das darin besteht, dass dieselbe Aktion von einer böswilligen Anwendung wiederholt wird.



Abb. 2. Netzwerkverkehr mit markierten Mustern

Wir haben die erste Anfrage untersucht, als Antwort darauf hat der Server eine verschlüsselte Konfiguration (Abb. 3) zurückgegeben, die die Adressen der Images enthält, die die Nutzdaten enthalten. Diese Daten werden unter hxxp://63634[.]top:8081/koded .



Abb. 3. Verschlüsselte Konfiguration

Datenentschlüsselung


Die empfangenen Daten werden vom DES-Algorithmus im elektronischen Codebuchmodus mit dem Schlüssel 0x6a 0x5f 0x6b 0x2a 0x61 0x2d 0x76 0x62 entschlüsselt, der im Hauptteil des Schadprogramms enthalten ist. Nach der Entschlüsselung ist der Klartext eine Zeichenfolge (Abb. 4), die jeweils einen Link zum Bild enthält. Basierend auf der Gleichheit von MD5-Hashes ist dies das gleiche Bild. Offensichtlich haben die Angreifer aus Gründen der Stabilität des Zustellungsschemas dieselben Daten an verschiedenen Adressen gefunden.



Abb. 4. Beispiel einer entschlüsselten Bootloader-Konfiguration

Der nächste Schritt besteht darin, dass der böswillige Downloader mit den erhaltenen Daten den Download des Bildes initiiert. Es schneidet die ersten 5120 Bytes (duckling und puppy) ab und verwendet nur die Nutzlast (Abb. 5), die unmittelbar ab dem 5121. Byte folgt.



5. Payload-Beispiel.

Nach dem Entschlüsseln der Daten erhielten wir die nächste Formatkonfiguration, ähnlich der im ersten Schritt erhaltenen. Das ist ein weiterer Teil der Bildverknüpfungen, aber dieses Mal sind alle MD5-Hashes unterschiedlich und am Ende jeder Zeile befinden sich zwei Zeichensuffixe:



Abb. 6. Zweiter Satz von Links und verdächtigen Suffixen

Bösartiger Algorithmus


Dies sind nun echte Nutzlastmodule. Wie sich herausstellte, werden die beiden Zeichen am Ende jeder Zeile verwendet, um ein bestimmtes Bild, dh eine bestimmte Nutzlast, auszuwählen. Zunächst wird eine Zeile mit dem Suffix „AD“ verwendet (Abb. 7). Diese Auswahl ist bereits in der Phase der Erstellung des Schadprogramms festgelegt. Das heißt, die Ladesequenz ist in Form von zweistelligen Suffixen vordefiniert.



Abb. 7. Link mit dem Suffix "AD" auswählen

Das heruntergeladene Bild enthält bereits ein bösartiges Modul, dies kann zumindest anhand seiner Größe festgestellt werden. Die Daten sind weiterhin als Bilder maskiert und befinden sich im selben Versatz von 5120 Bytes. Nachdem die zusätzlichen Bytes verworfen wurden, extrahiert der Loader, überprüft die Hash-Menge und entschlüsselt dann ein Modul namens TkRep.dll in die PE-Datei.



Abb. 8. Ein Beispiel für ein verschlüsseltes Modul im Bildkörper und seine Hashsumme

Diese Bibliothek wird in einen bösartigen Prozess geladen und überprüft zunächst die Umgebung, in der das Modul ausgeführt wird:



Abb. 9. Überprüfen der Virtualisierungsumgebung

Überprüft unter laufenden Prozessen das Vorhandensein von Prozessen mit den Namen devenv.exe, OLLYDBG.EXE, Dbgview.exe, windbg.exe, MSDEV.exe, Delphi32.exe, E.exe, PCHunter32.exe, PCHunter64.exe sowie das Vorhandensein von Antivirenprogrammen.



Abb. 10. Überprüfung des Prozesses

Führt eine Standard-Debug-Prüfung durch.



Abb. 11. Überprüfen des Starts des Prozesses im Kontext des Debuggers

Prüft auf offene Rohre, die in der Tabelle aufgeführt sind.
\\. \ FltMouseKb\\. \ GameGuard\\. \ GxWfpFlt
\\. \ XxGamesFilter\\. \ GpeNetSafe\\. \ TeSafe
\\. \ Sdriver\\. \ PowerChange\\. \ xspeed
\\. \ gmMemProt\\. \ diafahbb

Der nächste Schritt besteht darin, den infizierten Knoten auf dem böswilligen Server zu registrieren und verschlüsselte Informationen über den infizierten Knoten mit einer POST-Anforderung an das HTTP-Protokoll zu senden (Abb. 12).



Abb. 12. Antrag auf Registrierung auf dem Server von Cyberkriminellen

Es ist bemerkenswert, dass die Antwort vom Server immer die gleichen Daten enthält und außerdem nur der Server-Antwortcode vom Client berücksichtigt wird.

Wie Malware ihre Aktivität verbirgt


In Übereinstimmung mit einer gegebenen Abfolge von Nutzlasten fahren wir mit dem Studium des Folgenden fort. Sein Suffix ist "AR". Der Client lädt gemäß dem vorhandenen Schema die nächste Verknüpfung des Abbilds mit der verschlüsselten Last vom Abbildspeicherdienst von Baidu Images herunter, entschlüsselt das Modul und startet es in einem neuen Prozess mit einem zufälligen Namen. Diese Funktionalität dient unserer Meinung nach dazu, eine böswillige Anwendung unschädlich zu machen. Oft ist dies ein Client eines Online-Spiels (Abb. 13). Und das war eine andere Verkleidungstechnik.



Abb. 13. Online-Spieloberfläche

Nach diesem ablenkenden Manöver geht der böswillige Prozess zum Fixierungsstadium auf dem infizierten Knoten über. Zu diesem Zweck werden Funktionen verwendet, die denen von Rootkit-Programmen ähneln. Insbesondere die Einführung eines eigenen sicheren Treibers in das System.

Und so passiert es. Aus der entschlüsselten Konfiguration wird die Last mit dem Suffix "AE" ausgewählt. Dies ist die TaskReportDLL.dll-Bibliothek. Es hat die gleichen Funktionen wie die Bibliothek TkRep.dll aus der vorherigen Phase - senden Sie Informationen über das System und überprüfen Sie, ob Schutzausrüstung verfügbar ist.

Dann wird die RealWorkDll.dll-Bibliothek heruntergeladen. Unter den Funktionen von RealWorkDll.dll ist es wichtig, den Treiber, der teilweise durch VMPROTECT geschützt ist, und die PE-Datei, die dieser Treiber auf dem System installiert, herunterzuladen.



Abb. 14. Pfad zur Treiberdatenbank

Anschließend werden die zur Installation des Treibers verwendeten PE-Dateien gelöscht, und dieser Fixierungsschritt ist abgeschlossen.

Eine Suche in der Treiberdatenbankzeile führte uns zum Rootkit [.] Com Resource Mirror Repository, in dem eine Instanz des FUTo-Rootkits mit dem entsprechenden Namen im Pfad „objfre_wxp_x86“ gefunden wurde (Abb. 14). In unserem Unternehmensblog wurde dieses Rootkit bereits 2006 in Betracht gezogen .

Betrachten wir die Arbeit im System des Treibers SDriverBlogx86, der vom Modul RealWorkDll.dll installiert wird, genauer. In der ersten Phase werden die Registrierungsdaten des Kunden an das Netzwerk gesendet. POST wird als Anforderung verwendet, jetzt jedoch auf Portnummer 8081 (Abb. 15). Anscheinend wird dieser Port zum Empfangen von Daten verwendet, wenn die Aktivität auf dem infizierten System die Aktivierungsphase des Rootkits "FUTo" erreicht hat.



Abb. 15. Fordern Sie C2 von dem auf dem System installierten Treiber an

Der Zugriff auf den Server von Cyberkriminellen erfolgt verschlüsselt, Daten vor der Verschlüsselung sind Informationen über das System. Die Trennung von Datenfeldern, Darstellungsformat und Anzahl der Felder ist für alle Module gleich (Abb. 16).



Abb. 16. Systeminformationen zur Identifizierung eines infizierten Knotens

Darüber hinaus stimmt der Funktionsmechanismus des im System eingebetteten Treibers mit dem einleitenden Bootloader überein. Der einzige Unterschied besteht darin, dass diesmal Verknüpfungen zu Images vom Rootkit-Port angefordert wurden und der Konfigurationsspeicherpfad von / koded nach / qqwe geändert wurde. Vielleicht hängt das irgendwie mit den Diensten qq.com und wechat.com zusammen.

Die Liste der Module, die der Prozess empfängt, enthält eine Liste der PE-Dateien. In diesem Fall steht anstelle des aus zwei Buchstaben bestehenden Suffixes für die Auswahl der Last am Ende der Zeile ein Schlüssel in Form eines Dateinamens:



Abb. 17. Vom Treiber empfangene Konfiguration im System behoben

Nach dem Laden der Bilder befindet sich die Nutzlast ebenfalls in einem Versatz von 5120 Bytes. Die Nutzlaststruktur für den installierten Treiber enthält den Schlüssel aus der vorherigen Liste in Form eines Dateinamens und dann die PE-Datei selbst. Im Gegensatz zu den vorherigen Schritten wird die Nutzlast hier nicht verschlüsselt.



Abb. 18. Nutzdaten, die vom auf dem System installierten Rootkit empfangen werden

Unter allen zu diesem Zeitpunkt empfangenen Nutzdaten ist das Modul zur Durchführung von MITM-Angriffen hervorzuheben. Sein Hash ist gleich b9fcf48376083c71db0f13c9e344c0383bafa5b116fbf751672d54940082b99a , das Bild mit ihm wird an dieser Adresse gespeichert.

Das resultierende Modul prüft auf Prozesse mit den Namen devenv.exe, OLLYDBG.EXE, Dbgview.exe, windbg.exe, MSDEV.exe, Delphi32.exe, E.exe, PCHunter32.exe, PCHunter64.exe sowie auf Prozesse ZhuDongFangYu, 360Safe, 360Tray.

Bei der Arbeit mit Hilfe einer GET-Anforderung werden die Zertifikate server.crt, server.key, server.der und startcom.crt heruntergeladen.



Abb. 19. Antrag auf Zertifikate

Die Klassennamen des Moduls zur Durchführung eines MITM-Angriffs lassen keinen Zweifel an den Absichten der Angreifer (Abb. 20).



Abb. 20. Klassennamen des Moduls zur Durchführung eines MITM-Angriffs

Fazit


Diese Malware besteht aus einem Bootloader, einer Verkleidungsdatei, einem Rootkit-Treiber und einem Modul zur Durchführung eines Angriffs. Für die verdeckte Übermittlung von Nutzdaten verwendet die Software eine Technik zum Zusammenfügen von Daten mit JPEG-Bildern. Bei Befehlsservern registrieren Angreifer Namen in den Domänenbereichen "Top", "Gebot" sowie auf der Basis von Cloud-Plattformen.

Hier sind einige Methoden zum Maskieren der Aktivität, die von den Entwicklern bösartiger Software verwendet wird:

  • Verkleidung als legale Anwendung,
  • Maskieren des Verkehrs für Bilder,
  • als Rootkit andocken.

Die in Betracht gezogene Bedrohung wird vom Netzwerkverkehrsanalysesystem PT Network Attack Discovery als Spy.GmFUToMitm erkannt.

IOC
1953db709a96bc70d86f7dfd04527d3d0cb7c94da276ddf8f0ef6c51630a2915
1ab1b2fe3ce0fd37a0bb0814a2cac7e974f20963800f43d2f5478fc88c83a3da
1c8dbaf0a5045e2b4a6787635ded8f51d8e89a18e398c0dd79b1b82a968df1a0
9b7082ac4165b25a3b22f2aafdd41ea5f3512a76693f6a6b3101873a9cded961
9cee3f6d6e39adfa0d4712541c070b9c2423275698be0c6cd6cd8239d8793250
b9fcf48376083c71db0f13c9e344c0383bafa5b116fbf751672d54940082b99a
df3e7b04d988cf5634ec886321cb1ac364a46181e7a63f41f0788753e52dcf34
eb67c1d69eb09e195b8333e12c41a0749e7e186c9439f1e2c30f369712ce2c12
63634.top
anli.bid
shangdai.bid
b-blog.oss-cn-beijing.aliyuncs.com

Autoren : Dmitry Makarov, Evgeny Ustinov, Positive Technologies

Source: https://habr.com/ru/post/de477916/


All Articles