Leben in der Cloud: Ein Python-Implantat, das sein gesamtes C2-System in Microsoft 365 und Azure versteckt

Veröffentlicht am 18. August 2026

• Zusammenfassung
• Wichtigste Ergebnisse
• Wie es dazu kam
• Angriffskette
• Was wir geborgen haben
• C2-Architektur: Alles innerhalb der Vertrauensgrenze
  • SOCKS5 als Ebene für die seitliche Bewegung umkehren
  • Teams TURN als interaktive Datenebene
  • Headless Edge als Graph-Transport
  • Ausweichmöglichkeiten und Konfigurationsausfallsicherheit
• Diebstahl von Anmeldedaten über einen gefälschten Windows-Sperrbildschirm
• Persistenz: Eine Technik, die Sie kennen sollten
  • NTUSER.MAN: Erstellen eines „mandatory-profile“-Hives (keine Administratorrechte erforderlich)
• Implantatfunktionen
• Vorbereitung der Infrastruktur
• Intelligente Bedrohung
  • Betreiberprofil
• Empfehlungen
• Indikatoren für Kompromisse
• Referenzen

Zusammenfassung

Die Ontinue- und Cyber Defense Center-Teams entdeckten im Juli 2026 bei der Untersuchung einer laufenden Kampagne ein bisher nicht dokumentiertes Python-Implantat-Framework. Wir verfolgen es intern unter dem Namen TWINLOOT, benannt nach seinem SharePoint-C2-Ordner ‘TwinLoot’.’

TWINLOOT ist ein modulares, mit PyArmor gehärtetes Python-Implantat, das für den Betrieb seiner die gesamte Command-and-Control-Infrastruktur innerhalb vertrauenswürdiger Microsoft-Dienste. Die Aufgabenübermittlung erfolgt über SharePoint Online-Datei-“Dead Drops” mittels der Microsoft Graph-API. Der interaktive Operatorzugriff wird über WebRTC-Datenkanäle geleitet, die von Microsoft Teams-TURN-Servern weitergeleitet werden. Der Datenverkehr der Graph-API wird über eine „headless“-Instanz des Edge-Browsers des Opfers geleitet, wodurch er von legitimen Benutzeraktivitäten nicht zu unterscheiden ist. Das Implantat sammelt Windows-Anmeldedaten über pixelgenaue gefälschte Sperrbildschirme, ermöglicht einen „Reverse SOCKS5“-Pivot in die Netzwerke der Opfer, führt beliebige Befehle aus und sichert seine Persistenz durch vier Mechanismen. In einem Fall handelte es sich um eine offline gefälschte Hive-Datei für ein obligatorisches Profil, die ohne Administratorrechte erstellt wurde. Dabei kam eine Technik namens „Corrupting the Hive Mind“ zum Einsatz – der erste dokumentierte Fall einer böswilligen Nutzung dieser Persistenzmethode in freier Wildbahn.

Wir haben die Module aus dem Schutz von PyArmor 9.2.5 extrahiert und die darin enthaltene Konfiguration entschlüsselt, wodurch wir Einblick in die Infrastruktur der Angreifer erhielten, einschließlich der SharePoint-C2-Site, des Azure-Blob-Konfigurations-Dead-Drops und der von den Angreifern registrierten Domains.

Wichtigste Ergebnisse

1. Alle primären C2-Kanäle enden im IP-Bereich von Microsoft. SharePoint Online (Graph-API) für die Aufgabenvergabe, Teams-TURN-Relays für den interaktiven Zugriff und der Edge-Browser des Opfers für den Graph-Datenverkehr. Standardmäßig läuft keine C2-Kommunikation über eine dem Angreifer gehörende Domain.
2. Eine Persistenztechnik namens “Corrupting the Hive Mind“ erfordert keine Administratorrechte. Das Implantat erstellt offline mithilfe von “offreg.dll” und “RegLoadAppKeyW” eine obligatorische Profilstruktur (NTUSER.MAN) und erreicht so Persistenz, ohne dass Änderungen an der Registrierungsdatenbank vorgenommen werden müssen und ohne Berechtigungserweiterung.
3. Der zweite Fall von Missbrauch durch Teams TURN in freier Wildbahn und der erste, bei dem WebRTC-Datenkanäle zum Einsatz kamen. Nach „Backdoor.Turn“ von DragonForce (Symantec, Juni 2026) ist TWINLOOT der zweite bekannte Fall eines Missbrauchs des Teams-TURN-Relays und der erste, bei dem tatsächlich WebRTC-Datenkanäle zum Einsatz kommen, wie in der TURNt-Studie von Praetorian gezeigt wurde.
4. „Headless Edge“ macht prozessbasierte Erkennung zunichte. Graph-API-Aufrufe werden wie folgt ausgegeben: fetch() mit gleicher Herkunft Anfragen aus einem Edge-Browser-Tab über CDP, wodurch der C2-Datenverkehr so aussieht, als stamme er von einer legitimen msedge.exe Prozess statt python.exe.
5. Der Phisher, der Passwörter niemals überprüft. Der primäre Sperrbildschirm verwendet ein natives Tkinter-Fenster, wobei eine HTML-Version (aus dem Windows11LockScreenSimulator) als Ausweichlösung dient.
6. Vollständige statische Wiederherstellung. 115 von 120 verschlüsselten Modulen wurden entschlüsselt, die eingebettete AES-256-GCM-Konfiguration wurde offline wiederhergestellt. Es wurden die vollständigen C2-Endpunkte, der Befehlssatz des Betreibers sowie die Anmeldedaten für die Infrastruktur ermittelt.
7. Die Infrastruktur wurde bewusst über sieben Wochen hinweg aufgebaut unter Verwendung von „Drop-Caught“-Domains, einem gemeinsamen TLS-Zertifikat, das die Kontrolle durch einen einzigen Betreiber belegt, und einer Hosting-ASN, die zuvor im Zusammenhang mit Kampagnen mit Anmelde-Angriffen markiert worden war.

Wie es dazu kam

Der erste Kompromittierungsversuch erfolgte über Social Engineering in Microsoft Teams. Ein externer Akteur, der sich als IT-Support ausgab, überredete einen Benutzer, einen PowerShell-Befehl auszuführen, der ein Archiv herunterlud, das eine vorinstallierte einbettbare Python 3.12.9-Laufzeitumgebung sowie eine 39 MB große kompilierte Nutzlast enthielt. Als wir hinzugezogen wurden, war das Implantat bereits in Betrieb. Eine erste Analyse ergab, dass die Payload „bootstrap-fat.pyc“ ein Stage-0-Loader war, der eine eingebettete 29-MB-ZIP-Datei mit Abhängigkeiten und Malware-Modulen enthielt. Die zweite Stufe war durch eine PyArmor 9.2.5 Pro-Verschlüsselung geschützt, wodurch etwa 120 Module durch herkömmliche Dekompilierung nicht lesbar waren. Anstatt die Probe in einer Sandbox auszulösen, wählten wir den statischen Ansatz. Mithilfe des Open-Source-Tools „Pyarmor-Static-Unpack-1shot“ konnten wir 115 Module wiederherstellen. Die eingebettete Konfiguration ließ sich problemlos entschlüsseln und lieferte uns die vollständige aktive C2-Infrastruktur.

Was dabei zum Vorschein kam, war keine einfache Hintertür. Es handelte sich um ein voll funktionsfähiges Implantat-Framework, das von jemandem entwickelt wurde, der sich sowohl mit Angriffstechniken als auch mit der Cloud-Architektur von Microsoft auskannte. Der Entwickler hatte Wochen im Voraus zwei abgelaufene Domains vorbereitet, eine speziell dafür entwickelte Azure-AD-Anwendung registriert, eine SharePoint-Site als Dead-Drop eingerichtet und ein hochmodernes Konferenztool in ein produktionsreifes Python-Implantat portiert – und das alles innerhalb von sieben Wochen. Das Ergebnis: ein interaktiver SOCKS5-Proxy, der vom eigenen Prozess des Opfers aus in dessen internes Netzwerk vordringt und so einen einzelnen kompromittierten Endpunkt zu einem Dreh- und Angelpunkt für laterale Bewegungen macht.

TWINLOOT ist das erste uns bekannte Tool, das Microsoft 365-Dead-Drop-C2, den Missbrauch des Teams-TURN-Relays und den Transport über einen Headless-Browser in einem einzigen Framework vereint. Dies zeigt, dass sich die Kluft zwischen “Konferenzforschung” und “operativen Werkzeugen” auf wenige Wochen verringert hat.

Angriffskette

Abbildung 1 – Angriffskette

Was wir geborgen haben

Die Schadlast wird als serienmäßige, gültig signierte, einbettbare Python-3.12.9-Laufzeitumgebung (unverändert; Authenticode-Signaturen lassen sich überprüfen) zusammen mit einer einzigen Datei ausgeliefert: „bootstrap-fat.pyc“, einem 39 MB großen kompilierten Python-Modul, das ein 29 MB großes eingebettetes Abhängigkeitspaket enthält.

Der Stage-0-Loader ist nicht verschleiert. Seine eigene Docstring beschreibt seine Aufgabe: ‘Stage0-Loader (nur stdlib): VENDOR_ZIP_B64 -> ./lib -> launcher.bootstrap_core.’ Es startet sich selbst fensterlos über „pythonw.exe“ neu, erzwingt eine Einzelinstanz über eine PID-Sperrdatei, extrahiert die eingebettete ZIP-Datei (mit SHA-256-Pinning und Zip-Slip-Schutz), stellt sicher, dass eine Tcl/Tk-GUI-Laufzeitumgebung vorhanden ist, und übergibt die Kontrolle an die zweite Stufe.

Diese zweite Stufe (etwa 120 Module) wurde geschützt durch PyArmor 9.2.5 Pro (durchgesickerte Lizenz 011971, Build-Tag LAUNCHER). Unter Verwendung der Open-Source-Software Pyarmor-Static-Unpack-1shot Mit diesem Tool haben wir statisch entschlüsselt 115 der rund 120 Module. Der Stage-1-Launcher speichert seine Konfiguration als AES-256-GCM-Blob, in den der Schlüssel und die AAD eingebettet sind, sodass wir diesen ebenfalls offline entschlüsselt haben. Reine Kryptografie, keine Sandbox erforderlich.

Das Ergebnis: vollständige Transparenz hinsichtlich jedes C2-Endpunkts, jedes Operatorbefehls, jedes Persistenzmechanismus und jeder Anmeldeinformation in der Build-Umgebung. In den kompilierten Bytecode durchgesickerte Pfade der Build-Maschine verweisen auf den Entwickler unter C:\Users\Admin\LAUNCHER\…, wobei die Module am 24. Juli 2026 zwischen 18:13 und 18:15 UTC kompiliert wurden. Zwischengespeicherte .pyc-Dateien im Tkinter-Verzeichnis zeigen, dass der Betreiber das Bundle vor der Auslieferung auf dem Build-Rechner getestet hat.

C2-Architektur: Alles innerhalb der Vertrauensgrenze

TWINLOOT läuft zwei parallele Kanäle vom betroffenen Rechner, wobei jeder einen anderen Zweck erfüllt. Das Verständnis dieser Aufteilung ist für die Erkennung wichtig.

Die SharePoint-Dead-Drop ist der ständig aktive Aufgabenkanal. Das Implantat (pythonw.exe) authentifiziert sich ausgehend beim Azure-Tenant des Angreifers und fragt alle 15 Sekunden ein SharePoint-Laufwerk nach Befehlen ab. Auf diese Weise erteilt der Operator Aufgaben, empfängt Ergebnisse und exfiltriert gesammelte Anmeldedaten sowie Aufklärungsdaten. Der Datenverkehr geht vom Endpunkt des Opfers aus und wird an login.microsoftonline.com, graph.microsoft.com und kerteransens.sharepoint.com gesendet, die sich alle im Tenant des Angreifers befinden. Die eigene M365-Umgebung der Opferorganisation ist an diesem Authentifizierungsablauf nicht beteiligt.

Die Rückwärtsfahrt durch den Tunnel SOCKS5 ist der interaktive Zugangskanal. Er läuft entweder über eine direkte TLS/WebSocket-Verbindung zum Server des Angreifers oder über das Teams-TURN-WebRTC-Relay. Der Angreifer richtet auf seinem eigenen Rechner (127.0.0.1:1080) einen SOCKS5-Listener ein und leitet den Datenverkehr über diesen in das interne Netzwerk des Opfers weiter. Diese Verbindungen werden von der Datei „pythonw.exe“ auf dem Host des Opfers zu internen Zielen auf Ports wie 445 (SMB), 3389 (RDP), 5985 (WinRM) und 1433 (MSSQL). Für das interne Netzwerk des Opfers sieht es so aus, als würde der kompromittierte Host normale laterale Verbindungen herstellen.

Beide Kanäle laufen gleichzeitig innerhalb desselben „pythonw.exe“-Prozesses. Der SharePoint-Kanal übernimmt asynchrone Aufgaben und die Datenexfiltration; der SOCKS5-Tunnel ermöglicht den interaktiven Echtzeitzugriff und die laterale Bewegung.

SOCKS5 als Ebene für die seitliche Bewegung umkehren

Der Reverse-Tunnel „SOCKS5“ ist der Ort, an dem der eigentliche operative Schaden entsteht. Sobald dieser eingerichtet ist (entweder über den direkten TLS/WS-Tunnel oder den Teams-TURN-Kanal), verfügt der Angreifer über einen interaktiven Proxy, der vom „pythonw.exe“-Prozess des Opfers aus Zugang zum internen Netzwerk des Opfers erhält.

Der Multiplexer (tunnel/multiplexer.py, tunnel/stream.py) unterstützt bis zu 128 gleichzeitige TCP-Streams über einen einzigen verschlüsselten C2-Kanal. Jeder Stream transportiert eine andere proxybasierte Verbindung. Die CLI „socks-ctl“ des Betreibers (im Sliver-Stil) verwaltet die Verbindungen über diesen Tunnel.

Was dies in der Praxis bedeutet: Der Angreifer erlangt über den gefälschten Sperrbildschirm (der über den SharePoint-Kanal exfiltriert wurde) das Passwort des Opfers und nutzt diese Anmeldedaten dann sofort über den SOCKS5-Tunnel, um per RDP oder WinRM auf den nächsten Host zuzugreifen. Der kompromittierte Endpunkt wird so zu einem Sprungbrett. Für die internen Netzwerkabwehrmechanismen sieht der Datenverkehr der lateralen Bewegung so aus, als würde die Workstation des kompromittierten Benutzers normale administrative Verbindungen herstellen.

Die Erkennungsnaht ist der folgende Vorgang: pythonw.exe Die Verteilung auf mehrere interne IP-Adressen über Verwaltungsports (445, 3389, 5985, 22, 1433, 135, 389) entspricht nicht dem normalen Verhalten einer Workstation, unabhängig davon, welche Anmeldedaten verwendet werden.

Teams TURN als interaktive Datenebene

Der Reverse-Tunnel SOCKS5 benötigt eine Transportverbindung, um den Betreiber zu erreichen. TWINLOOT bietet zwei Möglichkeiten: eine direkte TLS/WebSocket-Verbindung zum Server des Angreifers (sharepointx.th2ch[.]com:443) und eine unauffälligere Option, die über die Microsoft-eigene Teams-Medieninfrastruktur geleitet wird.

Für den ‘Teams“-Pfad richtet das Implantat WebRTC-Datenkanäle ein, die über „turns:worldaz-msit.relay.teams.microsoft[.]com:443’. Der Datenverkehr des Betreibers mit der Kennung „SOCKS5“ tritt auf dessen Seite in den WebRTC-Kanal ein, durchläuft das Microsoft-TURN-Relay und tritt am Host des Opfers über „pythonw.exe“ wieder aus. Ein Verteidiger sieht, dass der Endpunkt des Opfers eine langlebige TLS-Sitzung zu einem legitimen Microsoft-Relay-Server unterhält. Der darin enthaltene SOCKS5-Proxy-Datenverkehr ist ohne TLS-Überprüfung unsichtbar.

Die TURN-Anmeldedaten sind nicht fest codiert. Sie werden live von den Endpunkten für anonyme Besucher in Teams gestohlen: über einen POST-Request an teams.microsoft.com/api/authsvc/v1.0/authz/visitor mit einem leeren ’Authorization: Bearer und Ms-Teams-Auth-Type: ExplicitLogin liefert ein Skype-Token, das unter /trap-exp/tokens gegen einen TURN-Benutzernamen und ein Passwort mit einer Gültigkeitsdauer von einer Stunde eingetauscht wird.

Abbildung 2 – Teams TURN

Der Code ist eine Python-Portierung von Praetorians TURNt (https://github[.]com/praetorian-inc/turnt), dem Tool, das im Rahmen der ‘Ghost Calls’-Studie auf der Black Hat USA 2025 veröffentlicht wurde. ICE wird auf reinen Relay-Betrieb beschränkt (die echte IP-Adresse des Opfers erscheint niemals in den Signalisierungsdaten), SDP-Angebot und -Antwort werden über den SharePoint-Dead-Drop weitergeleitet, und das Ergebnis ist ein nicht authentifizierter SOCKS5-Proxy auf dem Rechner des Betreibers, der innerhalb des Netzwerks des Opfers endet. Jede interne Verbindung scheint von der eigenen „pythonw.exe“ des Opfers zu stammen.

Dies ist erst der zweite beobachtete Missbrauch der Teams-TURN-Infrastruktur in der Praxis, nach DragonForces Go-basiertem „Backdoor.Turn“ (Symantec, Juni 2026). Die Implementierungen unterscheiden sich jedoch grundlegend: DragonForce nutzte QUIC-Sitzungen über das Relay, während TWINLOOT echte WebRTC-DataChannels über aiortc verwendet – genau wie es TURNt selbst demonstriert hat. Am 23. Juli 2026, einen Tag vor der Kompilierung von TWINLOOT, veröffentlichte Cisco Talos seinen Analyse des msaRAT der „Chaos“-Gruppe, das dieselbe Technik (Headless-Browser + TURN-Relay) nutzt, die Daten jedoch über Twilio statt über Teams weiterleitet. Drei unabhängige Akteure nutzten den Missbrauch des TURN-Relays innerhalb von sechs Monaten nach dem Black-Hat-Vortrag aus.

Headless Edge als Graph-Transport

Dies ist die Komponente, die wir unter dem Gesichtspunkt der Erkennung und Umgehung am interessantesten finden.

Das Implantat startet den eigenen Microsoft Edge des Opfers im Headless-Modus:

Es verbindet sich über das Chrome DevTools-Protokoll über einen lokalen WebSocket, wechselt in einem Tab zu graph.microsoft[.]com und führt alle Graph-API-Aufrufe wie folgt aus: “Same-Origin“ „”fetch()“ Anfragen aus dem Kontext der Browser-Seite heraus über Runtime.evaluate.

Abbildung 3 – Headless-Edge-Transport

Im Zusammenhang mit der Telemetrie im Netzwerk handelt es sich beim Graph-C2-Datenverkehr um die Kommunikation zwischen dem Browser des Benutzers und Microsoft – denn genau das ist es. Der Prozess „msedge.exe“ mit einem legitimen Benutzerdatenverzeichnis sendet HTTPS-Anfragen an „graph.microsoft.com“. Jede Erkennungsregel, die auf die Kommunikation von „python.exe“ oder „pythonw.exe“ mit Graph-Endpunkten abzielt, wird dies vollständig übersehen. Das Abrufen des Tokens selbst erfolgt weiterhin über urllib (eine potenzielle Erkennungslücke), doch der eigentliche Austausch der C2-Nutzdaten läuft über Edge.

msaRAT von Chaos Group nutzt dieselbe Architektur mit einem Headless-Browser über CDP, allerdings für WebRTC-Signalisierung über Cloudflare Workers. Die Parallele ist bemerkenswert: Zwei voneinander unabhängige Akteure kamen innerhalb desselben Monats unabhängig voneinander zu dem Ansatz, ‘den Browser des Opfers selbst als C2-Transport zu nutzen’.

Ausweichmöglichkeiten und Konfigurationsausfallsicherheit

Die Laufzeitkonfiguration wird alle 300 Sekunden aus einem „Dead-Drop“ im Azure Blob Storage aktualisiert. Wir haben überprüft, dass dieser Endpunkt zum Zeitpunkt der Veröffentlichung aktiv ist. Das zurückgegebene JSON-Datenformat stimmt exakt mit der entschlüsselten, eingebetteten Konfiguration überein, was sowohl unsere Entschlüsselung als auch die fortgesetzte Aktivität des Betreibers bestätigt.

Ein Ethereum-Modul namens „eth_call“ (Blockchain-Konfigurationsauflösung im Stil von EtherHiding) ist im Quellcode enthalten, wird in dieser Version jedoch nicht verwendet. Der Mechanismus ist vorhanden, die RPC-Endpunkte sind jedoch nicht belegt, was darauf hindeutet, dass es sich um ein aktiv weiterentwickeltes Framework mit Varianten handelt, die wir bisher noch nicht gesehen haben.

Diebstahl von Anmeldedaten über einen gefälschten Windows-Sperrbildschirm

Auf Befehl des Bedieners (credz_waiting) zeigt das Implantat einen pixelgenauen gefälschten Windows-Sperrbildschirm an. Es gibt Tkinter-basierte Kits sowohl für Windows 10 als auch für Windows 11, die anhand der Build-Nummer des Betriebssystems ausgewählt werden und jeweils mit den echten Daten des Opfers gefüllt sind:

• Anzeigenamen über GetUserNameExW
• Profilbild aus dem Verzeichnis „%APPDATA%\Microsoft\Windows\AccountPictures“
• Hintergrundbild für den Sperrbildschirm, das aus den Registrierungsschlüsseln „PersonalizationCSP“, „SystemData“ oder „Spotlight“ stammt

Ein 250 ms langer schwarzer Blitz verdeckt den Übergang. Das Fenster wird im Vollbildmodus und immer im Vordergrund angezeigt, wobei die Schaltfläche zum Schließen deaktiviert ist.

Für Verteidiger sind zwei Details von Bedeutung. Erstens gibt es keinerlei Passwortüberprüfung. Der primäre Sperrbildschirm ist ein natives, auf Tkinter basierendes Fenster; eine HTML-Variante (abgeleitet von Windows11LockScreenSimulator) dient als Fallback. Keine der beiden Varianten gleicht das eingegebene Passwort mit der Windows-Authentifizierung oder einem anderen Mechanismus ab. Jeder Versuch wird als JSON-Datenstruktur verpackt, verschlüsselt und auf das SharePoint-Laufwerk hochgeladen. Das Opfer sieht nach dem ersten Versuch die Meldung ‘Das Passwort ist falsch. Versuchen Sie es erneut.’, unabhängig davon, was eingegeben wurde (entsprechend dem tatsächlichen Verhalten des Sperrbildschirms), und das Fenster schließt sich nach dem zweiten Versuch, wodurch in der Regel sowohl das falsch eingegebene als auch das richtige Passwort erfasst werden.

Zweitens ist die Ausbruchsicherung bewusst auf ein Minimum beschränkt. Vollbild und oberste Ebene, aber keine Tastatur-Hooks, kein „BlockInput“ (deklariert, aber nicht verwendet). Der Entwickler hat die Bindung an das System zugunsten von Zuverlässigkeit und einfacher Programmierung in Kauf genommen. Die Fensterklassen lauten „launcher_black_screen_31337“ und „launcher_fake_lockscreen_view“.

Die HTML-Variante des Sperrbildschirms basiert auf Windows11LockScreenSimulator (https://github[.]com/PrPunk/Windows11LockScreenSimulator), ein öffentliches GitHub-Projekt. Die Payload bündelt diese Ressourcen nicht; sie verlinkt zur Laufzeit direkt auf ein Hintergrundvideo und eine Ladeanimation von https://raw.githubusercontent[.]com und i.postimg.cc, sodass der Sperrbildschirm nur auf Hosts mit ausgehendem Internetzugang gerendert wird. Wir erheben keinen Anspruch darauf zu wissen, wer dieses Projekt verfasst oder kontrolliert, und haben nichts gefunden, was es oder seine Betreuer mit dieser Kampagne in Verbindung bringt; es scheint opportunistisch als vorgefertigtes Markup ausgewählt worden zu sein. Das Abrufen stellt ein brauchbares Erkennungssignal dar: Ausgehende Anfragen von Nicht-Browser-Prozessen an `raw.githubusercontent[.]com/PrPunk/WEBFILES/` sind auf den meisten Endpunkten anomal, es handelt sich jedoch nicht um die Infrastruktur des Angreifers und wurde bewusst aus der Indikatorentabelle ausgeschlossen. Kombinieren Sie dies mit einem hostseitigen Signal, anstatt die Hosting-Domain zu blockieren, da diese weit verbreitet und legitim genutzt wird. Beachten Sie außerdem, dass das Blockieren des Abrufs den Sperrbildschirm unterdrückt, ohne andere Teile der Kette zu beeinträchtigen: Das Fehlen des Sperrbildschirms ist kein Hinweis auf eine fehlgeschlagene Ausführung.

Unsere Arbeitshypothese zum Erfassen von Anmeldedaten: Das per Phishing erlangte Passwort wird direkt für die laterale Bewegung über den Reverse-Tunnel „SOCKS5“ genutzt. Der Angreifer verfügt über einen interaktiven Proxy in das Netzwerk des Opfers; die erfassten Anmeldedaten ermöglichen den RDP-, SMB- oder WinRM-Zugriff auf interne Hosts, die der Rechner des Opfers erreichen kann. RDP-, SMB- oder WinRM-Zugriff auf interne Hosts, die vom Opferrechner aus erreichbar sind.

Persistenz: Eine Technik, die Sie kennen sollten

TWINLOOT umfasst vier Persistenzmechanismen, die alle vom Betreiber ausgelöst werden und nicht automatisch ablaufen (PERSIST_ENABLED=False in dieser Version). Drei davon sind in der vorhandenen Literatur gut dokumentiert. Einer wurde zwar öffentlich erforscht, bisher jedoch noch nicht in böswilliger Anwendung beobachtet.

TypeLib-COM-Scriptlet-Hijack: HKCU\Software\Classes\TypeLib\{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}\1.1\0\win32|win64, das auf das Skript „C:\ProgramData\PackageCache\Config.sct“ verweist, sowie einen „Run“-Schlüssel (UserExperienceSync). Klassischer Missbrauch der Datei „scrobj.dll“ – effektiv, aber allgemein bekannt.

Manipulation des TaskCache im GhostTask-Stil: Binäre Blobs, die direkt in HKLM\Schedule\TaskCache\{Tree,Tasks,Plain} ohne den Wert des SD-Sicherheitsdeskriptors geschrieben werden, wodurch die Aufgabe für „schtasks /query“ und den Taskplaner unsichtbar wird. Der Name der Aufgabe lautet „UserExperienceSyncTask“ mit einem Wiederholungsintervall von sechs Stunden. Hierfür sind Administratorrechte und ein Neustart des Schedule-Dienstes erforderlich. Die Technik ist seit der Offenlegung von Tarrask im Jahr 2022 öffentlich dokumentiert.

Automatische Aktualisierung: Ein „reobf.json“-Manifest stellt einen vollständigen Ersatz-Bootstrap mit drei Neustartmodi bereit (Datei, Spawn, schtasks /Run). Hauptsächlich aus Gründen der Betriebshygiene.

NTUSER.MAN: Erstellen eines „mandatory-profile“-Hives (keine Administratorrechte erforderlich)

Dies ist das erste Mal, dass wir diese Technik bei einem Angreifer in der Praxis beobachtet haben.

Die zugrunde liegende Studie wurde erstmals im Januar 2026 von Praetorian veröffentlicht (“Corrupting the Hive Mind”). Prätorianer hat das Open-Source-Tool „Swarmer“ für den Einsatz durch Red Teams veröffentlicht, das seit Februar 2025 in Betrieb ist. Die Implementierung von TWINLOOT nutzt denselben Ansatz mit „RegLoadAppKeyW“ und „offreg.dll“, der in dieser Studie beschrieben wurde, und wurde an die Python-Codebasis des Implantats angepasst.

Abbildung 4 – Persistenz von NTUSER.MAN

Das Implantat erstellt mithilfe von zwei APIs vollständig offline einen obligatorischen Windows-Profil-Hive: RegLoadAppKeyW (wodurch ein Registrierungs-Hive in einen privaten Anwendungsnamensraum geladen wird ohne dass Administratorrechte erforderlich sind) sowie die Offline-Registrierungsbibliothek „offreg.dll“ von Microsoft (ORCreateKey, ORSetValue, ORSaveHive). Die daraus resultierende Registrierungsstruktur wird in den Ordner „%USERPROFILE%\NTUSER.MAN“ geschrieben.

Wenn Windows ein Benutzerprofil lädt, prüft es zunächst, ob die Datei „NTUSER.MAN“ (eine obligatorische Profilüberschreibung) vorhanden ist, bevor es „NTUSER.DAT“ überprüft. Ist „NTUSER.MAN“ vorhanden, hat deren Inhalt Vorrang. Durch die Offline-Erstellung dieser Hive-Datei mit entsprechend integrierten „Run“-Schlüsseln oder COM-Hijack-Werten erreicht das Implantat eine Persistenz, die:

• Erfordert keine Administratorrechte (Der Benutzer ist Eigentümer seines eigenen Profilverzeichnisses.)
• Erzeugt keine Ereignisse zur Änderung der Registrierungsdatenbank zum Zeitpunkt des Schreibvorgangs (der Hive wird offline erstellt und nicht in die Live-Registrierung geschrieben)
• Bleibt auch nach dem Neuladen des Profils und nach Anmelde- und Abmeldevorgängen erhalten
• Wird von den meisten gängigen Tools zum Scannen auf Persistenz nicht erkannt

Der Betreiber löst dies über den Befehl „ntuser_man apply“ aus. Eine statische Analyse des entschlüsselten Codes bestätigte, dass bei einer erfolgreichen Bereitstellung die Datei „NTUSER.MAN“ in das Benutzerprofilverzeichnis geschrieben wird (2.138.112 Byte, offreg_ok: true). Es wurde bestätigt, dass bei einer erfolgreichen Bereitstellung die Datei „NTUSER.MAN in das Benutzerprofilverzeichnis schreibt (2.138.112 Byte, offreg_ok: true).

Implantatfunktionen

Neben den Komponenten „C2“ und „Credential“ umfasst der vollständige Befehlssatz (der aus dem entschlüsselten Code gewonnen wurde) Folgendes:

• recon: ausschließlich Umgebungsvariablen und NetAPI-Aufrufe (kein WMI, kein cmd.exe): Hostname, FQDN, Status der Domänenzugehörigkeit, Auflistung von ‘%ProgramData%’, Aufzählung von Domänencontrollern und Computern über NetServerEnum, Mitgliedschaft in der Gruppe „Domain Admins“ über NetGroupGetUsers sowie Auflistung der Domänenvertrauensstellungen über DsEnumerateDomainTrustsW.
• Screenshot: Ein PowerShell-Einzeiler mit „CopyFromScreen“, Ausgabe in „shot.png“.
• Tunnel-/TURN-Steuerung: Start, Stopp und Status sowohl für den direkten WS/TLS-Tunnel als auch für den Teams-TURN-Kanal.
• wakeup [Sek.]: Putzintervall anpassen.
• loadconfig/reloadconfig: Konfiguration aus dem Azure-Blob-Dead-Drop im laufenden Betrieb neu laden.
• ntuser_man show|apply: der oben beschriebene Persistenzmechanismus.
• fd/on azure: Konfiguration des Azure Front Door-Edge-Servers zur Laufzeit.
• fb/main: Befehle für das Tenant-Failover.
• Sonstiges: Jeder nicht erkannte Befehl wird direkt an den Unterprozess weitergeleitet, wobei „shell=True“, ein Timeout von 120 Sekunden, eine Ausgabebegrenzung von 65 KB und „CREATE_NO_WINDOW“ festgelegt sind. Im Standardfall erfolgt die Ausführung eines beliebigen Befehls.

Vorbereitung der Infrastruktur

Der zeitliche Ablauf der Aktion zeugt von Planung und nicht von Opportunismus. Bei beiden C2-Domains handelt es sich um alte, abgelaufene Domains, die im Abstand von zwei Wochen neu registriert wurden. Dies ist ein Manöver zur Übernahme der Reputation, um Heuristiken zum Domain-Alter zu umgehen:

Datum (2026)	Veranstaltung
07. Juni	th2ch[.]com wurde nach Ablauf der Laufzeit neu registriert (NameCheap, Privacy Shield). Vorheriger Inhaber: Website eines Kleinunternehmens, noch bis März 2026 online.
07. Juni	Das Let’s Encrypt-Zertifikat für sharepointx.th2ch[.]com wurde etwa 8 Stunden nach der Registrierung ausgestellt. Die Domain wurde zu diesem Zweck erworben.
21. Juni	lpi-web[.]com wurde an dem Tag, an dem es in den Status „pending-delete“ überging, aufgefangen (derselbe Registrar, dasselbe Datenschutzmuster). Der Name ist eine Markenpiraterie gegenüber dem Linux Professional Institute.
21. Juli	Ein einziges gemeinsames LE-Zertifikat, das sowohl lpi-web[.]com als auch sharepointx.th2ch[.]com abdeckt und belegt, dass ein Betreiber beide Zonen kontrollierte.
24. Juli	Implant wurde kompiliert (PyArmor-Build-Zeitstempel von 18:13 bis 18:15 UTC).
27. bis 30. Juli	Beobachteter kontinuierlicher Herzschlag der C2-Konfiguration

Der Failover-Edge befindet sich unter der Adresse 193.24.211[.]221 und wird von AS215929 (‘Data Campus Limited’) angekündigt, einem Hosting-ASN, der zuvor von GreyNoise als eines von vier Netzwerken dokumentiert wurde, die Ende 2025 hinter mehr als neun Millionen Angriffe auf Anmeldedaten bei Palo Alto GlobalProtect-Portalen standen. Wir gehen davon aus, dass der Akteur kriminelle Hosting-Infrastruktur mietet, anstatt sie direkt zu betreiben.

Intelligente Bedrohung

Betreiberprofil

Ohne konkrete Zuordnungen vornehmen zu wollen, weist die Operation doch einen eindeutigen Fingerabdruck auf. Trotz gründlicher Analyse konnten wir keine Überschneidungen bei der Infrastruktur, keine gemeinsam genutzten Tools und keine Code-Abstammung feststellen, die TWINLOOT mit einem bekannten Angreifer oder einer bekannten Malware-Familie in Verbindung bringen würden.

Der Bereich Infrastruktur ist stark vertreten. Ein siebenwöchiges Staging-Fenster, die Übernahme der Reputation abgelaufener Domains, gemeinsame TLS-Zertifikate, Dual-Tenant-Redundanz in SharePoint, verschlüsselte Konfiguration zur Erstellungszeit sowie ein Live-Azure-Blob-Konfigurationskanal, über den Implantate ohne Schlüsselrotation umgeleitet werden können. Die Entscheidung, sich beim eigenen Azure-Tenant des Angreifers zu authentifizieren, anstatt den des Opfers zu missbrauchen, zeugt von einer bewussten architektonischen Planung, um zu vermeiden, dass Spuren in den Identitätsprotokollen des Opfers zurückbleiben.

Die Verbreitung öffentlicher Forschungsergebnisse schreitet rasch voran. Der TURN-Kanal ist eine von Grund auf neu entwickelte Python-Portierung von TURNt, die innerhalb weniger Wochen nach DragonForce’s Backdoor.Turn hat den Missbrauch von Teams TURN ins Rampenlicht gerückt. Es gibt keine öffentliche Python-Portierung von TURNt; diese wurde eigenständig entwickelt. Das EtherHiding-Modul, der Edge-CDP-Transport und das Failover für zwei Mandanten deuten auf ein aktiv weiterentwickeltes Framework hin, dessen Varianten wir noch nicht kennen. Die Konvergenz mit msaRAT von Chaos Group (veröffentlicht einen Tag vor TWINLOOT (wurde zusammengestellt) auf Basis derselben „Headless-Browser-via-CDP“-Technik wurde unabhängig davon entwickelt und nicht weitergegeben. Ebenfalls enthalten ist die „Hive Forging“-Technik, die aus einer im Januar veröffentlichten Forschungsarbeit übernommen wurde.

Die Arbeitsweise basiert auf Social Engineering. Der erste Zugriff erfolgte über einen Teams-Anruf, bei dem sich der Angreifer als IT-Support ausgab – eine Technik, die keinerlei technische Exploits erfordert und die Endpunktkontrollen vollständig umgeht. Dies steht im Einklang mit einem allgemeinen Trend zu vishing-basierten Angriffen, der in den Jahren 2025–2026 bei mehreren Akteursgruppen zu beobachten war.

Es gibt operative Parallelen zu zwei öffentlich nachverfolgten Kampagnen, wobei keine der beiden einen Zuordnungszusammenhang darstellt. „Backdoor.Turn“ von DragonForce nutzt zwar dieselbe TURN-Relay-Technik wie Teams, unterscheidet sich jedoch in allen anderen Aspekten:

Faktor	DragonForce	TWINLOOT	Stimmt das?
Erstzugang	MSSQL-/Access-Broker	Teams – Vishing	Nein
Sprache	Los	Python	Nein
TURN-Missbrauch	Ja (Teams TURN)	Ja (Teams TURN)	Ja
Werkzeuge	DLL-Sideloading, BYOVD	PyArmor Python, Headless Edge	Nein
Ransomware	DragonForce-Spind	In dieser Version nicht vorhanden	Anders

Ein von Sophos beobachteter Angreifer, STAC4749, ein Aktivitätscluster, das mit der „Chaos“-Ransomware-as-a-Service-Operation in Verbindung steht, weist stärkere operative Parallelen auf:

Faktor	STAC4749	TWINLOOT	Stimmt das?
Erstzugang	Vishing-Angriffe durch Teams, gefälschter IT-Support	Vishing-Angriffe durch Teams, gefälschter IT-Support	Ja
Python-Hintertür	Mit PyArmor verschleierte PyInstaller-Hintertür	PyArmor 9.2.5 Pro Python-Implantat	Ja
SOCKS-Proxy umkehren	Maßgeschneidertes Reverse-Proxy-Tool SOCKS (sc5.exe), das zusammen mit einer Hintertür bereitgestellt wurde	Integrierte Rückwärtsfunktion SOCKS5 (128 Streams)	Ja
Persistenz	HKCU: Schlüssel mit maskierten Namen ausführen	HKCU-Schlüssel ausführen (UserExperienceSync)	Ja
C2 über Cloudflare/CDN	Hinter Cloudflare gehostete Payloads	Azure Blob + SharePoint (in der Cloud gehostet)	Teilweise
Zeitleiste	Februar bis Juni 2026	Errichtet im Juli 2026	Angrenzend
Zielgruppenansprache	Nordamerika (Kanada 50%, USA 44%)	Nicht bekannt gegeben	Unbekannt
Zertifikat-Pinning	Fest codierte CA-Zertifikate in Payloads	Gepinnte ISRG Root X1 (Let’s Encrypt)	Ähnliches Muster
Ransomware	Ransomware „Chaos“ im Einsatz	Diese Version enthält keine Ransomware	Anders
Sprache	Go-Implantate + Python-Hintertür	Nur Python	Teilweise
msaRAT-Link	Die Chaos Group hat außerdem msaRAT entwickelt (Headless-Browser + CDP + TURN)	Headless Edge + CDP + Teams TURN	Gleicher Technikunterricht

Die Überschneidungen bei STAC4749 sind bemerkenswert: Teams-Vishing-Verteilung, eine mit PyArmor verschleierte Python-Backdoor, ein Reverse-SOCKS5-Proxy, Persistenz über den HKCU-Run-Schlüssel und eine angrenzende Zeitachse. Die zugrunde liegenden Implementierungen unterscheiden sich jedoch erheblich. STAC4749 nutzt PyInstaller-Pakete, Go-basierte Implantate, eigenständige SOCKS5-Proxy-Tools und .top-Domains hinter Cloudflare. TWINLOOT nutzt die Ausführung von rohen .pyc-Dateien, reines Python, einen integrierten SOCKS5-Multiplexer sowie abgefangene, ältere Domains mit einem SharePoint-Dead-Drop-C2. Sollte es sich um denselben Betreiber handeln, wurden die Tools von Grund auf neu entwickelt, anstatt weiterentwickelt zu werden. Wir sehen anhand der derzeitigen Beweislage keinen direkten Zusammenhang, weisen jedoch auf die Parallelen hin, um sie künftig zu einer Korrelation heranzuziehen.

Empfehlungen

• Überwachen Sie die Netzwerk-Telemetriedaten der Endgeräte hinsichtlich Verbindungen zu SharePoint-Websites außerhalb Ihrer Organisation. Das C2 von TWINLOOT läuft über eine SharePoint-Website im Azure-Tenant des Angreifers, nicht in dem des Opfers. Da sich das Implantat mithilfe eingebetteter Anmeldedaten direkt beim Tenant des Angreifers authentifiziert, erscheinen in den Entra ID-Protokollen des Opfers keine Anmelde- oder Überwachungsereignisse. Die Erkennung erfolgt auf Endpunkt- und Netzwerkebene: Konfigurieren Sie Ihr EDR, Ihren Proxy oder Ihr CASB so, dass verwaltete Endpunkte, die eine Verbindung zu *.sharepoint[.]com-Hostnamen herstellen, die nicht zur Tenant Ihrer Organisation gehören, gekennzeichnet werden.
• Den externen Zugriff auf Teams einschränken oder deaktivieren, sofern er nicht erforderlich ist um die externe Kommunikation zwischen dem Angreifer und den Benutzern zu unterbinden.
• Headless-Modus und Remote-Debugging für Microsoft Edge deaktivieren
  auf Standard-Arbeitsplätzen da TWINLOOT beide Funktionen erfordert
  um den Graph-API-Datenverkehr über den Browser des Benutzers weiterzuleiten. Zwei Edge-Server
  Die Richtlinien wirken dem direkt entgegen:
  • HeadlessModeEnabled > Deaktiviert
    (Intune: Microsoft Edge > Nutzung des Headless-Modus steuern)
  • RemoteDebuggingAllowed > Deaktiviert
    (Intune: Microsoft Edge > Remote-Debugging zulassen)
  Wird eines von beiden deaktiviert, funktioniert die Technik nicht mehr. Entwickler oder Automatisierung ausschließen
  Arbeitsplätze, an denen die Nutzung von Headless-Browsern eine berechtigte geschäftliche Anforderung darstellt.
• Python-Laufzeitumgebungen in Pfaden, auf die der Benutzer Schreibzugriff hat, sind als verdächtig einzustufen. TWINLOOT liefert eine ordnungsgemäß signierte, einbettbare Python-Laufzeitumgebung an einem nicht standardmäßigen Speicherort aus. Überprüfen Sie, ob ‘python.exe’ oder ‘pythonw.exe’ aus den Verzeichnissen %APPDATA%, %LOCALAPPDATA%, %TEMP% oder C:\ProgramData\ ausgeführt werden, sofern dies nicht im Rahmen zugelassener Softwarebereitstellungen geschieht.
• Setzen Sie die Anmeldedaten aller Benutzer zurück, die möglicherweise auf die Phishing-Seite auf dem Sperrbildschirm gestoßen sind. Der gefälschte Sperrbildschirm von TWINLOOT erfasst jeden Passwortversuch, ohne diesen zu validieren. Bei Verdacht auf eine Kompromittierung sollten Sie das Passwort des betroffenen Benutzers unverzüglich zurücksetzen und dessen Aktualisierungstoken über „revokeSignInSessions“ widerrufen.
• Setzen Sie Phishing-resistente Authentifizierungsmethoden wie FIDO2-Schlüssel und Passkeys ein. Durch den unternehmensweiten Einsatz dieser Maßnahmen wird die Technik des „Credential Harvesting“ vollständig unterbunden, ganz gleich, wie überzeugend der gefälschte Sperrbildschirm auch sein mag.

Indikatoren für Kompromisse

Das IOC-Dokument finden Sie hier: GitHub-Link.

Referenzen

• Praetorian – TURNt / “Ghost Calls” – Black Hat USA 2025. Missbrauch des TURN-Relays als verdeckter C2-Kanal. Vorläufer der TURN-Implementierung von TWINLOOT Teams.
• Symantec – Backdoor.Turn: DragonForce – Juni 2026. Erstmals dokumentierter Missbrauch der TURN-Relay-Infrastruktur von Microsoft Teams in freier Wildbahn.
• Cisco Talos – Chaos msaRAT – Juli 2026. Headless-Browser über CDP + Twilio TURN-Relay C2. Unabhängige Konvergenz auf die „Browser-as-Transport“-Technik.
• FortiGuard Labs – Chaos durch SharePoint – März 2025. SharePoint + Graph-API-Dead-Drop-C2.
• Group-IB – HOLLOWGRAPH – Juli 2026. Microsoft 365-Kalendertermine als bidirektionaler C2-Dead-Drop über die Graph-API.
• CyCraft – GRAPHBROTLI / GRAPHRELOOK – März 2026. Mehrere graphbasierte Dead-Drop-Resolver, die auf Taiwan abzielen.
• Pyarmor-Static-Unpack-1shot – Open-Source-Tool zur statischen Entschlüsselung von PyArmor.
• Microsoft – Tarrask / GhostTask – April 2022. Ursprüngliche Dokumentation zur Manipulation des TaskCache für unsichtbare geplante Aufgaben.
• GreyNoise – AS215929 / Data Campus – Dezember 2025. Angriffe zur Erlangung von Anmeldedaten aus der Infrastruktur AS215929.
• Microsoft Edge – Richtlinie „HeadlessModeEnabled“ – Edge-Richtlinie zum Deaktivieren des Headless-Browser-Modus. CIS-Benchmark-Stufe 2.
• Microsoft Edge – Richtlinie „RemoteDebuggingAllowed“ – Edge-Richtlinie zum Deaktivieren der Remote-Fehlerbehebung. CIS-Benchmark-Stufe 1.
• Kanadisches Zentrum für Cybersicherheit – EtherHiding – März 2026. Analyse der „EtherHiding“-Technik zur Auflösung von C2-Konfigurationen.
• STAC4749 – Am 28. Juli 2026 untersuchten Sophos-Analysten eine als STAC4749 erfasste Voice-Phishing-Kampagne (Vishing) über Microsoft Teams, bei der eine einheitliche Reihe von Cloud-Domains mit IT-Bezug zum Einsatz kam.