ESET-Forscher entdeckten eine Ballistic Bobcat-Kampagne, die auf verschiedene Einrichtungen in Brasilien, Israel und den Vereinigten Arabischen Emiraten abzielt und eine neuartige Backdoor verwendet, die wir Sponsor nennen.

Wir entdeckten Sponsor, nachdem wir ein interessantes Sample analysiert hatten, das wir im Mai 2022 auf dem System eines Opfers in Israel entdeckten, und die Opfergruppe nach Ländern untersuchten. Bei der Untersuchung wurde uns klar, dass es sich bei dem Sample um eine neuartige Backdoor handelte, die von der APT-Gruppe Ballistic Bobcat eingesetzt wurde.

Ballistic Bobcat, früher von ESET Research als APT35/APT42 (auch bekannt als Charming Kitten, TA453 oder PHOSPHORUS) verfolgt, ist eine mutmaßlich mit dem Iran verbündete Gruppe für hochentwickelte, anhaltende Bedrohungen (APT), die es auf Bildungs-, Regierungs- und Gesundheitsorganisationen sowie Menschenrechtsaktivisten und Journalisten abgesehen hat. Sie ist vor allem in Israel, im Nahen Osten und in den Vereinigten Staaten aktiv. Während der Pandemie hatte sie es vor allem auf Organisationen abgesehen, die mit COVID-19 in Verbindung stehen, darunter die Weltgesundheitsorganisation und Gilead Pharmaceuticals, sowie auf medizinisches Forschungspersonal.

Die Überschneidungen zwischen den Ballistic Bobcat-Kampagnen und den Sponsor-Backdoor-Versionen zeigen ein ziemlich klares Muster der Tool-Entwicklung und des Einsatzes mit eng begrenzten Kampagnen, die jeweils nur von kurzer Dauer sind. In der Folge entdeckten wir vier weitere Versionen der Sponsor-Backdoor. Insgesamt sahen wir, dass Sponsor bei mindestens 34 Opfern in Brasilien, Israel und den Vereinigten Arabischen Emiraten eingesetzt wurde, wie in Abbildung 1dargestellt .

Die wichtigsten Punkte dieses Blogposts:

• Wir entdeckten eine neue Backdoor, die von Ballistic Bobcat eingesetzt wurde und die wir im Folgenden Sponsor nannten.
• Ballistic Bobcat stellte die neue Backdoor im September 2021 bereit, während es die in der CISA-Warnung AA21-321A und der PowerLess-Kampagne dokumentierte Kampagne abschloss.
• Die Sponsor-Backdoor verwendet Konfigurationsdateien, die auf der Festplatte gespeichert sind. Diese Dateien werden diskret über Batch-Dateien bereitgestellt und absichtlich so gestaltet, dass sie harmlos erscheinen, um so die Erkennung durch Scan-Engines zu umgehen.
• Sponsor wurde bei mindestens 34 Opfern in Brasilien, Israel und den Vereinigten Arabischen Emiraten eingesetzt; wir haben diese Aktivität als Sponsoring Access-Kampagne bezeichnet.

Erster Zugang

Ballistic Bobcat verschaffte sich den ersten Zugang, indem es bekannte Schwachstellen in über das Internet zugänglichen Microsoft Exchange-Servern ausnutzte, indem es zunächst sorgfältige Scans des Systems oder Netzwerks durchführte, um potenzielle Schwachstellen oder Sicherheitslücken zu ermitteln und anschließend diese Schwachstellen gezielt ansteuerte und ausnutzte. Die Gruppe ist seit einiger Zeit dafür bekannt, dass sie auf diese Weise vorgeht. Viele der 34 Opfer, die in den ESET-Telemetriedaten identifiziert wurden, sind jedoch eher als Gelegenheitsopfer zu bezeichnen als als vorausgewählte und ausgespähte Opfer, da wir vermuten, dass Ballistic Bobcat das oben beschriebene Scan- und Exploit-Verhalten anwenden konnte, weil es nicht der einzige Bedrohungsakteur mit Zugang zu diesen Systemen war. Wir haben diese Aktivitäten von Ballistic Bobcat unter Verwendung der Sponsor-Backdoor als Sponsoring Access-Kampagne bezeichnet.

Die Sponsor-Backdoor verwendet Konfigurationsdateien auf der Festplatte, die von Batch-Dateien abgelegt werden, und beide sind so harmlos, dass sie Scan-Engines umgehen könnten. Dieser modulare Ansatz wurde von Ballistic Bobcat in den letzten zweieinhalb Jahren recht häufig und mit mäßigem Erfolg eingesetzt. Auf kompromittierten Systemen setzt Ballistic Bobcat auch weiterhin eine Reihe von Open-Source-Tools ein, die wir - zusammen mit der Sponsor-Backdoor - in diesem Blogpost beschreiben.

Viktimologie

Die große Mehrheit der 34 Opfer befand sich in Israel, nur zwei in anderen Ländern:

• Brasilien, bei einer medizinischen Genossenschaft und einem Krankenversicherungsunternehmen und
• die Vereinigten Arabischen Emirate, bei einer nicht identifizierten Organisation.

Tabelle 1 beschreibt die Branchen und die organisatorischen Details der Opfer in Israel.

Tabelle 1. Vertikale und organisatorische Details für die Opfer in Israel

Attribution

Im August 2021 wurde das oben genannte israelische Opfer, das einen Versicherungsmarktplatz betreibt, von Ballistic Bobcat mit den von CISA im November 2021 gemeldeten Tools angegriffen. Die von uns beobachteten Indikatoren für eine Kompromittierung (IoC) sind:

• MicrosoftOutlookUpdateSchedule,
• MicrosoftOutlookUpdateSchedule.xml,
• GoogleChangeManagement und
• GoogleChangeManagement.xml.

Die Ballistic Bobcat-Tools kommunizierten mit demselben Command-and-Control-Server (C&C) wie im CISA-Bericht: 162.55.137[.]20.

Im September 2021 erhielt dasselbe Opfer die nächste Generation der Ballistic Bobcat-Tools: die PowerLess-Backdoor und das dazugehörige Toolset. Die von uns beobachteten Indikatoren für eine Kompromittierung waren:

• http://162.55.137[.]20/gsdhdDdfgA5sS/ff/dll.dll,
• windowsprocesses.exe und
• http://162.55.137[.]20/gsdhdDdfgA5sS/ff/windowsprocesses.exe.

Am 18. November 2021 setzte die Gruppe dann ein weiteres Tool (Plink) ein, das im CISA-Bericht als MicrosoftOutLookUpdater.exe beschrieben wurde . Zehn Tage später, am 28. November 2021, setzte Ballistic Bobcat den Merlin-Agenten ein (den Agent-Teil eines in Go geschriebenen Open-Source-Post-Exploitation-C&C-Servers und -Agenten). Auf der Festplatte trug dieser Merlin-Agent den Namen googleUpdate.exe, wobei die gleiche Namenskonvention wie im CISA-Bericht verwendet wurde, um sich unauffällig zu verstecken.

Der Merlin-Agent führte eine Meterpreter-Reverse-Shell aus, die einen neuen C&C-Server unter 37.120.222[.]168:80 aufrief. Am 12. Dezember 2021 legte die Reverse-Shell eine Batch-Datei, install.bat, ab , und innerhalb weniger Minuten nach der Ausführung der Batch-Datei setzten die Betreiber von Ballistic Bobcat ihre neueste Backdoor, Sponsor, ein. Dabei handelte es sich um die dritte Version der Backdoor.

Technische Analyse

Erster Zugriff

Bei 23 der 34 Opfer, die wir in der ESET-Telemetrie beobachtet haben, konnten wir eine wahrscheinliche Methode für den Erstzugang identifizieren. Ähnlich wie in den Berichten über PowerLess und von der CISA nutzte Ballistic Bobcat wahrscheinlich eine bekannte Schwachstelle (CVE-2021-26855) in Microsoft Exchange-Servern aus, um auf diesen Systemen Fuß zu fassen.

Bei 16 der 34 Opfer war Ballistic Bobcat offenbar nicht der einzige Bedrohungsakteur mit Zugang zu den Systemen. Dies könnte zusammen mit der großen Vielfalt der Opfer und dem Fehlen eines offensichtlichen Informationswerts bei einigen Opfern darauf hindeuten, dass Ballistic Bobcat eher ein Scan-and-Exploit-Verhalten an den Tag gelegt hat als eine gezielte Kampagne gegen vorher ausgewählte Opfer.

Toolset

Open-Source-Tools

Ballistic Bobcat setzte während der Sponsoring-Access-Kampagne eine Reihe von Open-Source-Tools ein. Diese Tools und ihre Funktionen sind in Tabelle 2aufgeführt .

Tabelle 2. Von Ballistic Bobcat verwendete Open-Source-Tools

Batch-Dateien

Ballistic Bobcat hat kurz vor der Installation der Sponsor-Backdoor Batch-Dateien auf den Systemen der Opfer installiert. Die uns bekannten Dateipfade sind:

• C:\inetpub\wwwroot\aspnet_client\Install.bat
• %USERPROFILE%\Desktop\Install.bat
• %WINDOWS%\Aufgaben\Install.bat

Leider waren wir nicht in der Lage, an diese Batchdateien zu gelangen. Wir glauben jedoch, dass sie harmlose Konfigurationsdateien auf die Festplatte schreiben, die die Sponsor-Backdoor benötigt, um vollständig zu funktionieren. Die Namen dieser Konfigurationsdateien wurden von den Sponsor-Backdoors übernommen, aber nie gesammelt:

• config.txt
• node.txt
• error.txt
• Uninstall.bat

Wir glauben, dass die Batch-Dateien und Konfigurationsdateien Teil des modularen Entwicklungsprozesses sind, den Ballistic Bobcat in den letzten Jahren bevorzugt hat.

Sponsor-Backdoor

Sponsor-Backdoors sind in C++ geschrieben, mit Zeitstempeln für die Kompilierung und Pfaden zur Programmdatenbank (PDB), wie in Tabelle 3 dargestellt. Ein Hinweis zu den Versionsnummern: Die Spalte Version steht für die Version, die wir intern verfolgen, basierend auf der linearen Entwicklung der Sponsor-Backdoors, bei der Änderungen von einer Version zur nächsten vorgenommen werden. Die Spalte Internal version enthält die Versionsnummern, die in den einzelnen Sponsor-Backdoors beobachtet wurden, und dient der besseren Vergleichbarkeit bei der Untersuchung dieser und anderer potenzieller Sponsor Samples.

Tabelle 3. Zeitstempel der Sponsor-Kompilierung und PDBs

Die anfängliche Ausführung von Sponsor erfordert das Laufzeitargument install, ohne welches Sponsor ordnungsgemäß beendet wird - wahrscheinlich eine einfache Anti-Emulation/Anti-Sandbox-Technik. Wenn dieses Argument übergeben wird, erstellt Sponsor einen Dienst namens SystemNetwork (in v1) und Update (in allen anderen Versionen). Er setzt den Starttyp des Dienstes auf Automatisch und legt fest, dass er seinen eigenen Sponsor-Prozess ausführt, und gewährt ihm vollen Zugriff. Dann wird der Dienst gestartet.

Sponsor, der nun als Dienst läuft, versucht, die oben erwähnten Konfigurationsdateien zu öffnen, die zuvor auf der Festplatte abgelegt wurden. Er sucht nach config.txt und node.txt, die sich beide im aktuellen Arbeitsverzeichnis befinden. Fehlt die erste Datei, setzt Sponsor den Dienst auf "Angehalten" und beendet sich selbsttätig.

Backdoor-Konfiguration

Die Konfiguration von Sponsor, die in config.txt gespeichert ist, enthält zwei Felder:

• Ein Aktualisierungsintervall in Sekunden, in dem der C&C-Server regelmäßig nach Befehlen gefragt wird.
• Eine Liste von C&C-Servern, die in den Binärdateien von Sponsor als relays bezeichnet werden.

Die C&C-Server werden verschlüsselt gespeichert (RC4), und der Entschlüsselungsschlüssel befindet sich in der ersten Zeile von config.txt. Jedes der Felder, einschließlich des Entschlüsselungsschlüssels, hat das in Abbildung 3 dargestellte Format .

Diese Unterfelder sind:

• config_start: gibt die Länge von config_name an , falls vorhanden, oder Null, falls nicht. Wird von der Backdoor verwendet, um zu wissen, wo config_data beginnt.
• config_len: Länge von config_data.
• config_name: optional, enthält einen Namen, der dem Konfigurationsfeld gegeben wird.
• config_data: die Konfiguration selbst, verschlüsselt (im Falle von C&C-Servern) oder unverschlüsselt (alle anderen Felder).

Abbildung 4 zeigt ein Beispiel mit farbkodiertem Inhalt einer möglichen config.txt Datei. Beachten Sie, dass es sich nicht um eine tatsächliche Datei handelt, die wir beobachtet haben, sondern um ein erfundenes Beispiel.

Die letzten beiden Felder in config.txt werden mit RC4 verschlüsselt, wobei die String-Darstellung des SHA-256-Hashes des angegebenen Entschlüsselungsschlüssels als Schlüssel für die Verschlüsselung der Daten verwendet wird. Die verschlüsselten Bytes werden hexadezimal kodiert als ASCII-Text gespeichert.

Sammeln von Host-Informationen

Sponsor sammelt Informationen über den Host, auf dem er läuft, meldet alle gesammelten Informationen an den C&C-Server und erhält eine Node-ID, die in node.txt geschrieben wird. Tabelle 4 listet die Schlüssel und Werte in der Windows-Registrierung auf, die Sponsor zum Abrufen der Informationen verwendet, und enthält ein Beispiel für die gesammelten Daten.

Tabelle 4. Von Sponsor gesammelte Informationen

Sponsor sammelt auch die Windows-Domäne des Hosts, indem er den folgenden WMIC-Befehl verwendet:

wmic computersystem get domain

Schließlich verwendet Sponsor Windows-APIs, um den aktuellen Benutzernamen zu ermitteln (GetUserNameW), festzustellen, ob der aktuelle Sponsor-Prozess als 32- oder 64-Bit-Anwendung läuft (GetCurrentProcess, dann IsWow64Process(CurrentProcess)), und um festzustellen, ob das System im Batteriebetrieb läuft oder an eine Wechsel- oder Gleichstromquelle angeschlossen ist (GetSystemPowerStatus).

Eine Merkwürdigkeit bezüglich der Überprüfung von 32- oder 64-Bit-Anwendungen ist, dass alle beobachteten Smaples von Sponsor 32-Bit waren. Dies könnte bedeuten, dass einige der Tools der nächsten Stufe diese Informationen benötigen.

Die gesammelten Informationen werden in einer base64-kodierten Nachricht gesendet, die vor der Kodierung mit r beginnt und das in Abbildung 5 gezeigte Format hat .

Die Informationen werden mit RC4 verschlüsselt, und der Verschlüsselungsschlüssel ist eine vor Ort generierte Zufallszahl. Der Schlüssel wird mit dem MD5-Algorithmus gehasht, nicht mit SHA-256, wie zuvor erwähnt. Dies ist bei allen Kommunikationen der Fall, bei denen der Sponsor verschlüsselte Daten senden muss.

Der C&C-Server antwortet mit einer Nummer, die zur Identifizierung des betroffenen Computers in späteren Kommunikationen verwendet und in die Datei node.txt geschrieben wird. Beachten Sie, dass der C&C-Server nach dem Zufallsprinzip aus der Liste ausgewählt wird, wenn die r-Nachricht gesendet wird, und dass derselbe Server in allen nachfolgenden Kommunikationen verwendet wird.

Befehlsverarbeitungsschleife

Sponsor fordert Befehle in einer Schleife an, die entsprechend dem in config.txt festgelegten Intervall schläft . Die Schritte sind:

1. Wiederholtes Senden einer chk=Test-Nachricht, bis der C&C-Server mit Ok antwortet .
2. Senden einer c (IS_CMD_AVAIL)-Nachricht an den C&C-Server und Empfangen eines Operator-Befehls.
3. Verarbeiten des Befehl
   • Wenn eine Ausgabe an den C&C-Server zu senden ist, senden einer a (ACK)-Nachricht, einschließlich der Ausgabe (verschlüsselt), oder
   • Wenn die Ausführung fehlgeschlagen ist, senden einer f (FAILED)-Nachricht. Die Fehlermeldung wird nicht gesendet.
4. Schlafen.

Die c-Nachricht wird gesendet, um die Ausführung eines Befehls anzufordern, und hat das in Abbildung 6 dargestellte Format (vor der base64-Kodierung) .

Das Feld encrypted_none in der Abbildung ist das Ergebnis der Verschlüsselung der hartcodierten Zeichenfolge None mit RC4. Der Schlüssel für die Verschlüsselung ist der MD5-Hash von node_id.

Die URL, die zur Kontaktaufnahme mit dem C&C-Server verwendet wird, lautet: http://<IP_oder_domain>:80. Dies könnte darauf hindeuten, dass 37.120.222[.]168:80 der einzige C&C-Server ist, der während der Sponsoring Access-Kampagne verwendet wurde, da dies die einzige IP-Adresse war, an die sich die Opferrechner über Port 80 gewandt haben.

Operator-Befehle

Die Operator-Befehle sind in Tabelle 5 beschrieben und erscheinen in der Reihenfolge, in der sie im Code zu finden sind. Die Kommunikation mit dem C&C-Server erfolgt über Port 80.

Tabelle 5. Operator-Befehle und Beschreibungen

Aktualisierungen für Sponsor

Die Programmierer von Ballistic Bobcat haben den Code zwischen Sponsor v1 und v2 überarbeitet. Die beiden wichtigsten Änderungen in letzterer sind:

• Optimierung des Codes, wobei mehrere längere Funktionen in Funktionen und Unterfunktionen minimiert wurden, und
• Tarnung von Sponsor als Aktualisierungsprogramm durch Aufnahme der folgenden Meldung in die Dienstkonfiguration:

App updates are great for both app users and apps – updates mean that developers are always working on improving the app, keeping in mind a better customer experience with each update.
"App-Updates sind sowohl für die App-Benutzer als auch für die Apps von Vorteil - Updates bedeuten, dass die Entwickler ständig an der Verbesserung der App arbeiten und bei jedem Update ein besseres Kundenerlebnis im Auge behalten."

Netzwerk-Infrastruktur

Ballistic Bobcat nutzte nicht nur die in der PowerLess-Kampagne verwendete C&C-Infrastruktur, sondern führte auch einen neuen C&C-Server ein. Die Gruppe nutzte außerdem mehrere IPs, um während der Sponsoring Access-Kampagne Support-Tools zu speichern und zu liefern. Wir haben bestätigt, dass derzeit keine dieser IPs in Betrieb ist.

Fazit

Ballistic Bobcat arbeitet weiterhin mit einem Scan-and-Exploit-Modell und sucht nach Gelegenheitszielen mit ungepatchten Sicherheitslücken in Microsoft Exchange-Servern, die dem Internet ausgesetzt sind. Die Gruppe verwendet weiterhin ein vielfältiges Open-Source-Toolset, das durch mehrere benutzerdefinierte Anwendungen ergänzt wird, darunter auch ihre Sponsor-Backdoor. Verteidiger sind gut beraten, alle Geräte, die dem Internet ausgesetzt sind, mit Patches zu versehen und auf neue Anwendungen zu achten, die in ihren Unternehmen auftauchen.

Wenn Sie Fragen zu unserer auf WeLiveSecurity veröffentlichten Studie haben, kontaktieren Sie uns bitte unter threatintel@eset.com.
ESET Research bietet private APT Intelligence Reports und Datenfeeds an. Wenn Sie Fragen zu diesem Service haben, besuchen Sie die ESET Threat Intelligence Seite.

IoCs

Dateien

Dateipfade

Im Folgenden finden Sie eine Liste der Pfade, in denen die Sponsor-Backdoor auf den betroffenen Computern bereitgestellt wurde.

%SYSTEMDRIVE%\inetpub\wwwroot\aspnet_client\

%USERPROFILE%\AppData\Local\Temp\file\

%USERPROFILE%\AppData\Local\Temp\2\low\

%USERPROFILE%\Desktop\

%USERPROFILE%\Downloads\a\

%WINDIR%\

%WINDIR%\INF\MSExchange Delivery DSN\

%WINDIR%\Tasks\

%WINDIR%\Temp\%WINDIR%\Temp\crashpad\1\Files

Netzwerk

IP	Provider	First seen	Last seen	Details
162.55.137[.]20	Hetzner Online GMBH	2021-06-14	2021-06-15	PowerLess C&C.
37.120.222[.]168	M247 LTD	2021-11-28	2021-12-12	Sponsor C&C.
198.144.189[.]74	Colocrossing	2021-11-29	2021-11-29	Support tools download site.
5.255.97[.]172	The Infrastructure Group B.V.	2021-09-05	2021-10-28	Support tools download site.

MITRE ATT&CK-Techniken

Diese Tabelle wurde mit der Version 13 des MITRE ATT&CK-Frameworks erstellt.