ReliaQuest bezeichnet dieses Vorgehen als “Bring Your Own Runtime”-Angriff (BYOR): Deno ist eine legitime Laufzeitumgebung, die das Ausführen von JavaScript- und TypeScript-Code außerhalb des Browsers auf einem System erlaubt. Da das Programm signiert und legitim ist, umgeht es Sperrlisten und Filter, die sonst die Ausführung unbekannter Binärdateien verhindern.
“Statt einen eigenen Malware-Loader einzusetzen, der eher auffällt, installieren die Angreifer die legitime Deno-Datei und nutzen sie zur Ausführung von Schadcode”, erläutert ReliaQuest. In den beobachteten Fällen wurde der Vorgang über Visual-Basic-Skripte und PowerShell-Skripte angestoßen, die auffällig als Romeo*.ps1 und Juliet*.vbs benannt waren.
Entscheidend ist die direkte Ausführung im Arbeitsspeicher: Die Aktivität hinterlässt nur minimale forensische Artefakte und erscheint wie eine gewöhnliche Entwickleraufgabe. Nach dem Start erfasst der Code Merkmale des Hosts, erzeugt eine eindeutige Opfer-ID und verbindet sich mit dem Command-and-Control-Server (C2), um die Nutzlast der zweiten Stufe nachzuladen. Parallel dazu läuft eine dauerhafte Abfrageschleife, über die neue Befehle vom C2 entgegengenommen werden.
In der Phase nach der Erstinfektion greift LeakNet auf eine Reihe weiterer Techniken zurück: DLL-Sideloading (jli.dll wird über Java in C:\ProgramData\USOShared geladen), C2-Beaconing, das Ausspähen von Zugangsdaten über die Enumeration mit “klist”, laterale Bewegung mittels PsExec sowie das Bereitstellen von Nutzlasten und das Abfließen von Daten unter Missbrauch von Amazon-S3-Buckets.
Die Forscher betonen, dass gerade die Beständigkeit und Wiederholbarkeit dieser Angriffskette Verteidigern Ansatzpunkte zur Erkennung bietet. Deutliche Hinweise auf mögliche LeakNet-Aktivität sind laut ReliaQuest ein Deno-Prozess außerhalb von Entwicklungsumgebungen, verdächtige “misexec”-Ausführungen aus Browsern heraus, ungewöhnliche PsExec-Nutzung, unerwarteter ausgehender Datenverkehr zu S3 sowie DLL-Sideloading in untypischen Verzeichnissen.