Nach Angaben von Sysdig ersetzte ENCFORGE die zuvor verwendeten Ad-hoc-Skripte durch ein kompiliertes Programm. Die Forscher luden die Binärdatei vom Command-and-Control-Server des Angreifers herunter, wo sie als /.lockd verborgen war. Ein direkter Abruf über /lockd lieferte 404, und der führende Punkt blendete die Datei in einfachen Verzeichnislisten aus. Es handelt sich um eine mit UPX 5.20 gepackte statische Go-1.22.12-ELF-Datei.
Bedrohungsdatenplattformen lieferten zum Zeitpunkt der Sysdig-Analyse keine Treffer für den gepackten oder entpackten Hash. Als interner Projektname taucht encfile auf; Fehlermeldungen der Binärdatei verweisen zudem auf ein begleitendes Schlüsselwerkzeug namens keyforge. Sysdig wertet beide Zeichenfolgen als stabile Erkennungsmerkmale, da sie auch nach einer Neukompilierung derselben Codebasis erhalten bleiben.
Die standardmäßige Erweiterungsliste umfasst laut den Forschern unter anderem Checkpoints für PyTorch und TensorFlow, Hugging Face SafeTensors, das Austauschformat ONNX, GGUF und dessen Vorgänger GGML, FAISS-Vektorindizes, Trainingsdatensätze in Parquet und Arrow, NumPy-Arrays sowie TensorFlow Records. Über den Schalter –include kann der Angreifer zusätzliche Dateimuster anhängen; die integrierte Hilfe nennt dafür LoRA-Fine-Tuning-Adapter und ältere GGML-Gewichte als Beispiele. Insgesamt umfasst die Liste rund 180 Erweiterungen. Für Sysdig spricht diese Auswahl für eine gezielte Ausrichtung auf KI-Umgebungen und nicht für bloße Mitnahmeeffekte.
Technisch setzt ENCFORGE auf AES-256-CTR für die Dateidaten; der pro Ausführung erzeugte symmetrische Schlüssel wird mit einem in diese Version einkompilierten öffentlichen RSA-2048-Schlüssel umschlossen. Die Ransomware verschlüsselt nicht komplette Dateien, sondern ausgewählte Bereiche. Jede verarbeitete Datei erhält die Endung .locked. Vor der Verschlüsselung beendet die Binärdatei Prozesse, die Dateien geöffnet halten, sie kann Neustarts verarbeiten, ohne bereits abgeschlossene Dateien erneut zu verschlüsseln, legt Lösegeldnotizen als README, HOW_TO_DECRYPT und README_DECRYPT ab und löscht sich nach der Ausführung selbst.
Eine Funktion zur Datenabfuhr fanden die Forscher in der wiederhergestellten ENCFORGE-Datei nicht. Laut Sysdig enthält sie weder Netzwerkcode noch einen Cloud-Speicher-Client oder einen Mechanismus zur Zwischenablage. Während der beobachteten Sitzung fanden die Forscher zudem keine Hinweise auf Datenabfluss, eine Leak-Seite oder ein Tor-Zahlungsportal. Als Kontakt für die Erpressung ist in den Notizen die Adresse e78393397@proton.me hinterlegt — dieselbe Proton-Mail-Adresse wie in der vorherigen Kampagne. Sysdig bezeichnet das als stärkste Attributionsverbindung zwischen beiden Operationen.
Für den eigentlichen Ausbruch auf den Host nutzte JADEPUFFER nach der Codeausführung den im Container gefundenen Docker-Socket unter /var/run/docker.sock. Ein erster Versuch, ENCFORGE vom GCP-Command-and-Control-Server nachzuladen, scheiterte. Innerhalb von fünf Minuten und 24 Sekunden erstellte und überarbeitete der Akteur daraufhin sechs Python-Skripte über denselben Langflow-RCE-Kanal, bis ein funktionierender Pfad auf den Host stand. Das erste Skript wurde zeilenweise aufgebaut, sodass einzelne Anfragen für signaturbasierte Prüfungen wirkungslos blieben. Ab der zweiten Version wurden vollständige Skripte in Base64 kodiert und innerhalb eines exec()-Aufrufs dekodiert.
Die finale Variante startete über die Docker-API einen privilegierten Container mit der PID-Namensraum des Hosts und eingebundenem Root-Dateisystem, lokalisierte den Zielprozess, kopierte ENCFORGE über /proc/<pid>/root und führte die Datei anschließend mit nsenter auf dem Host aus. In allen Iterationen waren die Container mit Privileged: true, PidMode: host, NetworkMode: host und schreibbar eingebundenem Root-Dateisystem erstellt. Vor dem eigentlichen Lauf setzte der Angreifer zunächst –try-run zur Dateisystemprüfung ein und danach –lock für den Live-Verschlüsselungslauf. Die letzte Skriptversion prüfte den Prozessstatus, las das Sperrprotokoll und zählte Dateien mit der Endung .locked.
Sysdig veröffentlichte eine beobachtete Sitzung, nannte die betroffene Organisation aber nicht. Auch Opferzahlen oder Belege für weitere ENCFORGE-Einsätze legten die Forscher nicht vor. Die offengelegten Hinweise belegten einen realen Verschlüsselungsversuch, nicht jedoch, wie viele Modell- oder Datensatzdateien erfolgreich verschlüsselt wurden. Den Schalter –task-id gcp_h1 wertet Sysdig als Hinweis darauf, dass der Akteur den Host als GCP-Ziel in einer breiteren Kampagne verfolgte; zuvor war in derselben Sitzung eine Testausführung mit der Kennung gcp_test zu sehen. In seinem vollständigen Bericht hat Sysdig nach eigenen Angaben Quell- und C2-Adressen, den Fingerabdruck des eingebetteten RSA-2048-Schlüssels, eine YARA-Regel sowie die SHA-256-Hashes der gepackten und entpackten Binärdatei veröffentlicht.