TwinLoot verwandelt Microsoft 365 in eine Kommandozentrale für Angriffe auf Unternehmensnetzwerke

Ein Python-Framework in der Microsoft-Cloud

Forscher des Ontinue Cyber Defense Center haben TwinLoot entdeckt – ein modulares, in Python geschriebenes Malware-Framework, das das Living-off-the-Land-Prinzip in die Cloud verlagert. Das System nutzt nicht nur bereits unter Windows vorhandene Werkzeuge, sondern baut seine Command-and-Control-Infrastruktur mithilfe legitimer Dienste von Microsoft Azure und Microsoft 365 auf.

Die Kampagne war im Juli noch aktiv, als die Malware-Module geborgen wurden. Die Aktivität wurde am 18. August 2026 erkannt.

TwinLoot verwendet SharePoint Online und die Microsoft Graph API zum Austausch von Befehlen und Daten, Microsoft Teams für interaktiven Zugriff und Microsoft Edge, um die vom kompromittierten Gerät erzeugte Kommunikation glaubwürdiger erscheinen zu lassen. Der Datenverkehr kann sich dadurch unter die normalen Aktivitäten von Benutzern und Unternehmensanwendungen mischen.

Die Python-Module waren mit PyArmor 9.2.5 geschützt. Nach der Entschlüsselung der eingebetteten Konfiguration zeigte sich eine Architektur mit mehreren Betriebskanälen, die darauf ausgelegt ist, die Sichtbarkeit des Angreifers zu reduzieren und die Kontrolle auch nach der initialen Kompromittierung aufrechtzuerhalten.

SharePoint, Graph und Teams werden zur C2-Infrastruktur

Die Command-and-Control-Komponente nutzt SharePoint Online als Austauschpunkt nach dem Dead-Drop-Modell: Der Angreifer legt Befehle oder Daten in einem Cloud-Speicher ab, und die Malware ruft sie über legitime Microsoft-APIs ab.

Die Microsoft Graph API fungiert als Anwendungskanal. Statt eine Verbindung zu einem verdächtigen Server oder einer Domain mit schlechtem Ruf aufzubauen, interagiert TwinLoot mit einer Infrastruktur, die in Unternehmensnetzwerken weit verbreitet ist.

Das Framework bindet außerdem die TURN-Relay-Infrastruktur von Microsoft Teams ein. Diese Technologie, die normalerweise interaktive Kommunikation ermöglicht, wird dazu missbraucht, eine operative Verbindung zum infizierten System aufrechtzuerhalten. Dadurch entsteht ein Kanal, der insbesondere dann wie gewöhnlicher Teams-Datenverkehr wirken kann, wenn Identitäten, Endpunkte und Cloud-Aktivitäten nicht miteinander korreliert werden.

Microsoft Edge trägt dazu bei, Graph-API-Anfragen weiter zu tarnen. Der auf dem Opfergerät vorhandene Browser wird für den Transport der Kommunikation genutzt. Browser-Automatisierung und der mögliche Einsatz von Headless-Komponenten erschweren zusätzlich die Unterscheidung zwischen bösartigen Aktivitäten und denen einer Unternehmensanwendung.

Nach Einschätzung der Forscher ist TwinLoot das erste von ihnen beobachtete Framework, das einen Microsoft-365-Dead-Drop, den Missbrauch des Teams-TURN-Relays und den Transport über einen Browser in einer einzigen Architektur vereint.

Die Funktionen: Zugangsdaten, Befehle und Pivoting im internen Netzwerk

TwinLoot enthält ein Modul zum Diebstahl von Windows-Anmeldedaten. Die Malware zeigt einen gefälschten Sperrbildschirm an, der dem legitimen Bildschirm des Betriebssystems nachempfunden ist, und fordert den Benutzer zur Eingabe seines Passworts auf.

Die Erfassung erfolgt auch dann, wenn der Versuch fehlschlägt. Bei einem falschen Passwort sieht das Opfer eine Meldung, die wie ein gewöhnlicher Authentifizierungsfehler wirkt, und kann es erneut versuchen. Ist die nächste Eingabe erfolgreich, bleibt das ungewöhnliche Verhalten möglicherweise unbemerkt.

Auf diese Weise können Passwörter erfasst werden, ohne zwangsläufig leicht erkennbare Hinweise für den Benutzer zu erzeugen. Unerwartete Authentifizierungsaufforderungen oder Sperrbildschirme außerhalb des normalen Arbeitsablaufs sollten daher überprüft werden, insbesondere wenn sie wiederholt auftreten.

Das Framework ermöglicht außerdem die Ausführung beliebiger Befehle auf dem kompromittierten System. Der Angreifer kann dadurch Informationen sammeln, das Verhalten des Endpunkts verändern und weitere Aktivitäten vorbereiten.

Die für die laterale Bewegung wichtigste Komponente ist ein interaktiver SOCKS5-Proxy. Er leitet den Datenverkehr über den infizierten Prozess und kann den Zugriff auf interne Netzwerkressourcen ermöglichen, die nicht direkt aus dem Internet erreichbar sind. Ein einzelner kompromittierter Computer wird so zu einem Pivot-Punkt für Aufklärung, den Zugriff auf weitere Systeme und die Interaktion mit Unternehmensdiensten.

Persistenz ohne Administratorrechte

TwinLoot setzt außerdem eine von den Forschern als „Corrupting the Hive Mind“ bezeichnete Persistenztechnik ein. Dabei wird mithilfe legitimer Windows-APIs offline ein Hive für ein verpflichtendes Benutzerprofil, ein sogenannter Mandatory Profile Hive, erstellt.

Die Technik erfordert keine Administratorrechte und verändert die Registry während der Installation nicht direkt. Daher werden möglicherweise keine Ereignisse erzeugt, die üblicherweise mit einer Registry-Änderung oder einer Rechteausweitung verbunden sind.

Dies schränkt die Aussagekraft bestimmter herkömmlicher Erkennungsregeln ein. Eine Organisation, die ausschließlich nach geänderten Registry-Schlüsseln, administrativen Prozessen oder Aktivitäten mit erhöhten Rechten sucht, könnte die Persistenz übersehen.

Ontinue beschreibt dieses Verhalten als die erste in realen Aktivitäten beobachtete bösartige Nutzung dieser Methode. Die Persistenz nutzt native Funktionen des Betriebssystems und hinterlässt im Vergleich zu Techniken mit offensichtlichen Konfigurationsänderungen eine geringere operative Spur.

Sorgfältige Vorbereitung, aber weiterhin unklare Zuordnung

Die beobachtete Architektur deutet auf eine siebenwöchige Vorbereitungsphase hin. Vor dem operativen Einsatz sollen zwei abgelaufene Domains, eine dedizierte Azure-AD-Anwendung und eine SharePoint-Website für die Funktion als Dead-Drop eingerichtet worden sein.

In das Python-Framework wurde außerdem ein Tool integriert, das ursprünglich auf einer Technologiekonferenz vorgestellt worden war. Die Domains waren mehrere Wochen vor der übrigen Infrastruktur vorbereitet worden.

Die Operation wurde keiner bestimmten Gruppe zugeordnet. Der hohe Integrationsgrad von Offensive Security, Python, Cloud-Identitäten und Microsoft-Diensten lässt auf einen professionellen Akteur oder einen Entwickler mit fortgeschrittenen Kenntnissen des Azure- und Microsoft-365-Ökosystems schließen.

Versionen der beteiligten Microsoft-Produkte sowie IP-Adressen, verwendete Domains, Hashes oder andere konkrete Indikatoren wurden nicht veröffentlicht. Ebenso liegen keine CVE-Kennungen, kein CVSS-Score und kein Eintrag im KEV-Katalog der CISA vor. Daher können weder ein Aufnahmedatum noch eine KEV-Frist zur Umsetzung von Gegenmaßnahmen angegeben werden.

So lässt sich TwinLoot erkennen, ohne sich nur auf Indikatoren zu verlassen

Datenverkehr zu Microsoft 365 ist nicht automatisch vertrauenswürdig. Die Abwehr muss sich auf Abweichungen vom erwarteten Verhalten von Benutzern, Geräten, Anwendungen und Diensten konzentrieren.

Organisationen sollten für SharePoint, Teams und die Graph API Baselines erstellen und dabei Volumen, Häufigkeit, Zeiten, Ziele und Zugriffsarten berücksichtigen. Ungewöhnliche Sequenzen von Graph-Aufrufen verdienen eine Untersuchung – insbesondere, wenn sie mit einem Konto oder Gerät verbunden sind, das solche Aufrufe normalerweise nicht ausführt.

Auch OAuth-Anwendungen und Azure-AD-Einwilligungen müssen überprüft werden. Unerwartete Anwendungen, übermäßig weitreichende Berechtigungen oder neue Integrationen mit SharePoint und Graph können auf die Vorbereitung des C2-Kanals hindeuten.

Die Telemetrie von SharePoint und Teams sollte mit der der Endpunkte korreliert werden. Websites, Dateien, Relay-Sitzungen und ungewöhnliche Kommunikationsflüsse sind vor allem dann aussagekräftig, wenn sie mit einer ungewöhnlichen Nutzung von Edge, Browser-Automatisierung, Python-Skripten oder mit PyArmor geschützten Modulen zusammentreffen.

Erkennungsregeln sollten außerdem wiederholte Authentifizierungsaufforderungen, unerwartete Sperrbildschirme sowie fehlgeschlagene Zugriffsversuche berücksichtigen, auf die eine erfolgreiche Authentifizierung folgt. Bei TwinLoot kann die vom Benutzer eingegebene fehlerhafte Eingabe bereits erfasst worden sein.

Schließlich sollte nach Anzeichen für einen SOCKS5-Proxy, unerwarteten interaktiven Verbindungen und Zugriffen auf interne Ressourcen von Endpunkten gesucht werden, die normalerweise keine Administrations- oder Pivoting-Aktivitäten ausführen. Die Korrelation von Identität, Cloud und Endpunkt ist entscheidend: Eine getrennte Analyse dieser drei Ebenen lässt dem Angreifer große Handlungsspielräume.