Zwischen August 2025 und August 2026 führten die Angriffe zu Opfern auf den Philippinen, in Taiwan, Afghanistan, Namibia und mit hoher Wahrscheinlichkeit in Südkorea. Hinweise aus der Analyse deuten darauf hin, dass die Akteure überwiegend in der Zeitzone UTC+8 aktiv sind. “Der markanteste technische Marker für Bronze Sandcastle ist die konsequente Nutzung von Sandboxie-DLL-Sideloading”, schrieb der Sophos-Sicherheitsforscher Gabor Szappanos in einem am Dienstag veröffentlichten Beitrag.
DLL-Sideloading nutzt die Art und Weise aus, wie Windows DLL-Dateien lädt: Gibt eine Anwendung beim Start keinen vollständigen Pfad zu einer benötigten Bibliothek an, sucht das Betriebssystem diese in einer festgelegten Reihenfolge von Verzeichnissen. Platzieren Angreifer eine Schad-DLL mit identischem Namen in einem Ordner, der vor dem eigentlichen Ablageort durchsucht wird, lädt das legitime Programm den fremden Code.
“Da der Schadcode von einer vertrauenswürdigen und oft digital signierten Anwendung ausgeführt wird, ist es weniger wahrscheinlich, dass Antivirensoftware und andere Sicherheitslösungen ihn melden”, hielt Zscaler in einer Analyse fest. Läuft die legitime Anwendung mit erhöhten Rechten, erbt die Schad-DLL diese Berechtigungen und kann sensiblere Aktionen auf dem System ausführen. Ist das missbrauchte Programm so konfiguriert, dass es bei jedem Neustart automatisch startet, sorgt die Technik zugleich für Persistenz.
In mehreren Opferumgebungen fand Sophos legitime Sandboxie-Programmdateien zusammen mit einer bösartigen Datei “sbiedll.dll”, die die vertrauenswürdige Anwendung “SandboxieWUAU.exe” dazu bringt, zur Laufzeit von den Angreifern kontrollierten Code zu laden. Daneben nutzte Bronze Sandcastle sieben weitere Sideloading-Kombinationen:
- javaw.exe (Java-Anwendung) – jli.dll
- Krita.exe (Malprogramm Krita) – Krita.dll
- NvdaHelper.exe (NVDA NonVisual Desktop Access) – NvdaHelperRemote.dll
- Jcef_helper.exe (Java Chromium Embedded Framework Helper) – Libcef.dll
- Vmmap.exe (Sysinternals-Speicheranalyse) – version.dll
- LineAppMgr.exe (Messenger LINE) – msvcp140.dll
- bginfo64.exe (Sysinternals-Werkzeug zur Anzeige von Systeminformationen) – snmpapi.dll
“Die per Sideloading geladenen DLLs lesen und starten typischerweise Payloads, die in verschlüsselten config.ini-Dateien abgelegt sind”, so Sophos. Dieses Vorgehen minimiere die statische Erkennbarkeit und erlaube es den Betreibern, das Verhalten anzupassen, ohne die DLL-Binaries auszutauschen. Umbenannte legitime Programmdateien würden häufig eingesetzt, um sich in die Opferumgebungen einzufügen; die Ausführung münde in Shellcode-Aktivität im Arbeitsspeicher statt in zusätzlichen Artefakten auf der Festplatte.
Die entschlüsselte Payload arbeitet als Backdoor: Sie zählt das lokale Netzwerk und Benutzerkonten auf, sammelt Systemmetadaten, laufende Prozesse, Tastatureingaben und Bildschirmfotos. Bislang wurden zwei Versionen identifiziert, 1.1.5 und 1.1.7.
Zur Kommunikation greift die Schadsoftware auf externe Dienste wie file[.]io, gofile[.]io, ably[.]net und ably[.]io zurück, vermutlich um weitere Aufträge der Betreiber zu empfangen. Version 1.1.5 nutzte zudem dc.cathaypacifice[.]com und net.dpworldto[.]com zur Befehls- und Kontrollsteuerung. Payloads der Version 1.1.7 luden dagegen über die GitHub-API verschlüsselte Konfigurationsdateien aus Repositories unter github[.]com/LatonyCharnleyaW herunter; das Konto ist nicht mehr erreichbar.
Weder der Einsatz von DLL-Sideloading durch chinesische Gruppen noch der Missbrauch von Sandboxie sind neu: Im Juli 2024 verwendete der Akteur APT41 eine andere von Sandboxie signierte Programmdatei (“taskhost.exe”), um eine manipulierte Fassung von “sbiedll.dll” nachzuladen und darüber die Backdoor MoonWalk auszuliefern.
“Die Gruppe verwendet überwiegend verschlüsselte Payload- und Konfigurationsdateien, die zur Laufzeit dekodiert werden, weshalb statische, dateibasierte Erkennung wirkungslos sein kann”, erklärte Sophos. Organisationen sollten stattdessen auf Verhaltensindikatoren achten – etwa DLLs, die lokale Dateien lesen und unmittelbar danach Code im Arbeitsspeicher ausführen, was auf Dekodierungs- und Staging-Aktivität hindeuten kann.