Die jüngsten Erkenntnisse zu TWINLOOT SharePoint Teams zeigen, wie geschickt Angreifer Microsoft-Ökosysteme missbrauchen können. Sicherheitsforscher haben einen bisher undokumentierten, modularen Python-Implant entdeckt, der seine Steuer- und Kommunikationswege so in vermeintlich vertrauenswürdige Dienste einbettet, dass Netzwerkaktivitäten schwerer von legitimen Mustern zu unterscheiden sind.
Besonders kritisch: TWINLOOT sammelt Windows-Credentials über täuschende Sperrbildschirm-Interaktionen, schafft anschließend eine Art „Sprungbrett“ im Zielnetz und ermöglicht damit weiteres Vorgehen bis hin zur Steuerung interner Systeme.
Was TWINLOOT SharePoint Teams auszeichnet
Bei TWINLOOT handelt es sich um eine PyArmor-gehärtete Python-Implantatstruktur, die ihre gesamte Command-and-Control-Ausrichtung in vertrauenswürdigen Microsoft-Services abwickeln soll. Die Basis dafür sind mehrere C2-Kanäle, die jeweils eigene Aufgaben übernehmen – von der Aufgabenverteilung bis zum interaktiven Zugriff.
Laut Bericht laufen die Bausteine dabei über ein Zusammenspiel aus SharePoint Online, Microsoft Teams und der Einbindung eines headless laufenden Edge-Browsers des Opfers.
SharePoint-Dead-Drops als Aufgabenkanal
Der erste Kanal von TWINLOOT basiert auf SharePoint Online als „Dead-Drop“-Ablage. Die Implantat-Logik nutzt dabei die Microsoft Graph API, um in einem Rhythmus von etwa 15 Sekunden nach neuen Befehlen zu suchen.
Der zentrale Punkt: Der Datenverkehr zur Graph API wird durch eine headless Instanz des eigenen Edge-Browsers des Opfers angestoßen. Dadurch soll sich die Kommunikation näher an legitime Browser- bzw. Dienstverbindungen annähern.
Der Operator kann über diesen SharePoint-Backchannel anweisen, Befehle auszuführen und Daten zurück ins Ziel des Angreifers zu exfiltrieren.
Teams TURN-Relays für interaktiven Zugriff
Für interaktiven Zugriff und die Weiterleitung in interne Netze setzt TWINLOOT auf einen zweiten Kanal, der TURN-Relay-Infrastrukturen aus Microsoft Teams missbraucht. Technisch wird dies über WebRTC DataChannels realisiert.
Aus Sicht der Bedienperson bedeutet das: Es wird ein SOCKS5-Listener am eigenen System erwartet, typischerweise unter 127.0.0.1:1080. Von dort werden Verbindungen über das Opfer vermittelt („proxied“) – und die Zielverbindungen verlassen dann über die Prozesse auf dem kompromittierten Rechner.
Der Bericht nennt dabei als typische interne Ziele/Ports unter anderem 445 (SMB), 3389 (RDP), 5985 (WinRM) und 1433 (MSSQL). Dadurch wirkt es intern so, als ob der kompromittierte Host selbst normale Lateral-Connections initiieren würde.
So liefert der Angreifer die Python-Komponenten aus
Als initialer Zugang gilt eine Social-Engineering-Attacke über Microsoft Teams. Dabei soll ein Angreifer sich als IT-Support ausgegeben haben und ein Opfer dazu gebracht haben, eine PowerShell-Anweisung auszuführen.
Diese PowerShell-Zeile lädt demnach ein Archiv herunter, das den Python Runtime-Teil sowie ein etwa 39 MB großes kompiliertes Payload-Stück enthält (genannt als bootstrap-fat.pyc). Dieses Element fungiert als Loader für die TWINLOOT-Struktur.
Die Forscher bewerten den Angreifer als mit offensivem Vorgehen und der Architektur von Cloud-Umgebungen vertraut.
Credential-Diebstahl mit Pixel-falschen Sperrbildschirmen
Ein besonders gefährlicher Bestandteil ist die Fähigkeit, Windows-Credentials zu erheben. TWINLOOT nutzt dazu pixelperfekte Fake-Lock-Screens, die über einen Befehl vom Operator („credz_waiting“) ausgelöst werden.
Wichtig ist dabei: Der eingegebene Passwortwert wird laut Bericht nicht gegen eine echte Windows-Authentifizierung geprüft, um zu verifizieren, ob das Passwort korrekt ist. Stattdessen wird dem Opfer unabhängig vom ersten Versuch eine Fehlermeldung angezeigt, typischerweise „Das Passwort ist falsch. Versuchen Sie es erneut“.
Erst nachdem der Operator entsprechende Eingaben erhalten hat, schließt sich der Fake-Lockscreen automatisch. Die erfassten Passwörter werden anschließend verschlüsselt und über den SharePoint-Kanal an den Angreifer hochgeladen.
Vom Passwort zum „Pivot“ ins Netzwerk
Nach dem Diebstahl werden die Credentials über den SOCKS5-Tunnel genutzt, um weiter zu agieren. Der Bericht beschreibt, dass so zum nächsten Host gewechselt wird – etwa über Remote Desktop Protocol (RDP) oder WinRM.
Damit ist TWINLOOT nicht nur ein Datendieb, sondern ein Werkzeug, das den Zugriff auf weitere Systeme systematisch ausbauen kann.
Warum das Tarnen über Microsoft-Dienste funktioniert
TWINLOOT kombiniert mehrere Mechanismen, die in ihrer Gesamtheit den Erkennungsaufwand erhöhen können. Dazu gehört die Nutzung mehrerer C2-Kanäle, die jeweils andere Aspekte der Aktivität abdecken: Aufgaben holen, interaktiven Zugriff ermöglichen und Transportwege so wählen, dass sie dem normalen Dienstverhalten ähneln.
Im Kern läuft die „Tarn“-Idee darauf hinaus, dass der Traffic zur Graph API über einen Browsertransport entsteht, während der interaktive Teil über Relay-Infrastrukturen aus Teams abgewickelt wird.
Ein Trend: TURN-Relays und Browser-Transport bei mehreren Angreifern
Der Fall ist nicht isoliert. Der Bericht ordnet TWINLOOT in einen breiteren Trend ein, bei dem mehrere Gruppen innerhalb eines Zeitraums von ungefähr einem Jahr ähnliche TURN-basierten Missbrauchstechniken einsetzen.
Beispiele, die genannt werden:
- Im Juni 2026 beschrieben Symantec/Carbon Black den Einsatz eines TURN-relierten Mechanismus in einem Go-basierten RAT (Backdoor.Turn) im Kontext der DragonForce-Kampagne.
- Später wurde ein weiterer Rust-basierter RAT (msaRAT) beobachtet, der den gleichen TURN-Relay-Ansatz nutzt, jedoch gegen Twilio statt Teams.
Obwohl das gemeinsame Muster erkennbar ist, unterscheiden sich die Implementierungen. Bei TWINLOOT liegt der Fokus auf WebRTC DataChannels via aiortc, während andere Tools teils alternative Sitzungs-/Signaling-Mechaniken nutzen.
Persistence: Mehrere Wege, um nach Neustarts weiterzulaufen
Damit TWINLOOT auch nach Systemereignissen aktiv bleibt, setzt es je nach Build auf unterschiedliche Persistenzmethoden. Der Bericht nennt vier Ansätze:
- TypeLib COM scriptlet hijack
- Manipulation in Anlehnung an „GhostTask“-artige TaskCache-Strukturen
- Self-Update über ein reobf.json-Manifest
- Ein Registry-basierter Ansatz über ein Mandatory-Profile-Hive-Verfahren
Besonders auffällig ist die vierte Methode. Dafür wird ein Open-Source-Werkzeug namens Swarmer verwendet, um Registry-Exportdateien in Windows-Hive-Dateien umzuwandeln. Ziel ist es, HKCU-bezogene Registry-Konfigurationen unauffälliger zu platzieren, auch wenn keine Administratorrechte vorhanden sind.
Das Implant erzeugt dabei eine verpflichtende Windows-Profil-Hive offline und schreibt sie in %USERPROFILE% \NTUSER.MAN. Sobald Windows das Benutzerprofil lädt, wird diese Datei vor NTUSER.DAT berücksichtigt, wodurch die Persistenz im Benutzerkontext unterstützt wird.
Weitere Funktionen über Diebstahl und Lateral Movement hinaus
Über Credential-Theft und den Netzwerkausbau hinaus nennt der Bericht zusätzliche Fähigkeiten. Dazu gehören unter anderem Reconnaissance, Discovery und Screenshot-Capture. Außerdem gibt es Mechanismen, um bei Ausfällen der primären Konfiguration auf Alternativen auszuweichen.
Ein EtherHiding-ähnlicher Fallback wird erwähnt, falls ein Azure-Blob-Storage-Dead-Drop-Ansatz scheitert. Gleichzeitig deuten die Befunde darauf hin, dass ein Ethereum-bezogener Mechanismus im aktuellen Stand nicht genutzt wird – was für eine fortlaufende Entwicklung des Frameworks sprechen kann.
Wer steckt hinter TWINLOOT SharePoint Teams?
Die Forscher konnten den Verursacher nicht eindeutig identifizieren. Allerdings berichten sie über operative Parallelen zu einem Cluster namens STAC4749, das in der Vergangenheit Teams-vishing-bezogene Kampagnen zur Ausspielung von Chaos-Ransomware orchestriert haben soll.
Die Ähnlichkeiten werden auf einer konzeptionellen Ebene beschrieben: Delivery über Teams, PyArmor-Obfuskation, Reverse-SOCKS5-Proxying und Persistence im HKCU-Umfeld – plus ein zeitlicher Zusammenhang. Gleichzeitig unterscheiden sich die Implementierungsdetails erheblich: STAC4749 nutzt etwa andere Packaging- und Implantatbausteine, während TWINLOOT in der beschriebenen Form stärker auf rohes .pyc-Execution, pure Python und integrierte SOCKS5-Logik setzt.
Fazit: Mehr als ein Einzelfall
TWINLOOT SharePoint Teams verdeutlicht, wie Angreifer Kommunikationswege gezielt in Microsoft-Dienste verlagern können, um schwerer auffindbar zu bleiben. Besonders kritisch sind dabei die Kombination aus SharePoint-basiertem Tasking, Teams-Relay-Missbrauch für interaktiven Zugriff, headless Browser-Transport und die Credential-Erhebung über täuschende Sperrbildschirme.
Für Unternehmen bedeutet das: Neben klassischen Signaturen rücken auch Verfahren in den Fokus, die ungewöhnliche Browser-/Graph-API-Muster, auffällige Teams-Relay-Nutzung und verdächtige Persistenzmechanismen frühzeitig erkennen können – idealerweise kombiniert mit sauberem Microsoft-365-Zugriffsmanagement und konsequentem Training gegen Social Engineering.
Quelle: https://thehackernews.com/2026/08/twinloot-abuses-sharepoint-and-teams-to.html
