SesameOp: Backdoor nutzt OpenAI-API als Steuerungskanal

Das Detection and Response Team (DART) von Microsoft stieß laut einem Blogbeitrag des Unternehmens auf die Schadsoftware während der Untersuchung eines komplexen Angriffs. Die Besonderheit von SesameOp liegt in der Nutzung legitimer OpenAI-Dienste zur verdeckten Kommunikation, anstatt eine eigene Infrastruktur für die Steuerung aufzubauen. Die Angreifer verfolgten nach Einschätzung von Microsoft das Ziel langfristiger Persistenz zu Spionagezwecken.

Missbrauch legitimer Cloud-Dienste statt eigener Infrastruktur

SesameOp unterscheidet sich laut Microsoft grundlegend von herkömmlichen Backdoors durch die Verwendung der OpenAI Assistants API als Kommunikationskanal. Die Schadsoftware nutzt dabei keine KI-Modelle oder Agenten-SDKs von OpenAI, sondern missbraucht die API ausschließlich als Speicher- und Relay-Mechanismus zum Abrufen und Übermitteln von Befehlen.

Die Forscher entdeckten bei ihrer Untersuchung ein komplexes Arrangement aus internen Web Shells, die Befehle von strategisch platzierten, persistenten Schadprozessen ausführten. Diese Prozesse nutzten mehrere kompromittierte Microsoft Visual Studio Utilities, die mit schädlichen Bibliotheken versehen waren – eine Technik, die als .NET AppDomainManager Injection bekannt ist.

Microsoft und OpenAI haben nach der Entdeckung gemeinsam die Nutzung der API durch die Angreifer untersucht. OpenAI identifizierte und deaktivierte laut Microsoft einen API-Schlüssel sowie einen zugehörigen Account, der vermutlich von den Angreifern verwendet wurde. Die Überprüfung ergab, dass der Account über begrenzte API-Aufrufe hinaus nicht mit OpenAI-Modellen oder -Diensten interagiert hatte. Die OpenAI Assistants API soll im August 2026 eingestellt werden.

Technischer Aufbau der Infektionskette

Die Infektionskette von SesameOp besteht laut der technischen Analyse aus zwei Hauptkomponenten: einem Loader namens Netapi64.dll und einem .NET-basierten Backdoor namens OpenAIAgent.Netapi64. Die DLL ist stark mit Eazfuscator.NET obfuskiert und wird zur Laufzeit über .NET AppDomainManager Injection in die Host-Executable geladen, gesteuert durch eine speziell präparierte .config-Datei.

Der Loader erstellt die Datei C:\Windows\Temp\Netapi64.start als Markierung und erzeugt einen Mutex, um sicherzustellen, dass nur eine Instanz im Speicher läuft. Fehlermeldungen werden in C:\Windows\Temp\Netapi64.Exception geschrieben. Netapi64.dll durchsucht das Verzeichnis C:\Windows\Temp\ nach Dateien mit der Endung .Netapi64, dekodiert diese per XOR und führt sie aus.

Die Hauptfunktionalität der Backdoor liegt in der Komponente OpenAIAgent.Netapi64. Diese liest beim Start die Konfiguration aus dem .NET-Ressourcenbereich TextFile1 und analysiert sie nach dem Schema: OpenAI_API_Key|Dictionary_Key_Name|Proxy. Der erste Teil enthält den OpenAI-API-Schlüssel, der zweite Teil dient als Dictionary-Key-Selektor für ein eingebettetes .NET-Modul, und der dritte Teil spezifiziert optional eine Proxy-Adresse.

Kommunikation über OpenAI Vector Stores und Assistants

Die Backdoor fragt laut Microsoft zunächst die Liste der Vector Stores von OpenAI ab und prüft, ob der Hostname des infizierten Systems bereits vorhanden ist. Falls nicht, erstellt sie einen neuen Vector Store mit dem Base64-kodierten Hostnamen. Anschließend ruft sie die Liste der Assistants ab – bis zu 100 Einträge mit Paginierung – und extrahiert Assistant-ID, Name, Beschreibung und Anweisungen.

Das Beschreibungsfeld eines Assistants kann laut der Analyse drei Werte enthalten: SLEEP, Payload oder Result. Bei SLEEP liest die Backdoor einen Wert aus dem Anweisungsfeld, der Thread-ID und Message-ID enthält, getrennt durch [._.]. Die Backdoor ruft die Nachricht von OpenAI ab und extrahiert einen timeSLEEP-Wert, der für eine Thread-Sleep-Operation verwendet wird.

Wenn die Beschreibung auf Payload gesetzt ist, ruft die Backdoor die Nachricht über Thread-ID und Message-ID ab und löscht anschließend sowohl die Nachricht als auch den Assistant. Die abgerufene Nachricht besteht aus zwei Teilen: einem 32-Byte-AES-Schlüssel, der Base64-dekodiert und mit einem fest kodierten privaten RSA-Schlüssel entschlüsselt wird, sowie den eigentlichen Befehlsdaten, die Base64-dekodiert, AES-entschlüsselt und mit GZIP dekomprimiert werden.

Ausführung und Rückmeldung der Befehle

Nach der Entschlüsselung wird die Nachricht laut Microsoft in ein Dictionary umgewandelt: Sie wird zunächst an Ampersand-Zeichen (&) aufgeteilt, dann jedes Paar am Gleichheitszeichen (=) getrennt, und sowohl Schlüssel als auch Werte werden URL-dekodiert. Das Dictionary und der aus der Konfiguration extrahierte Schlüssel werden an die Methode executeWithJScriptEngine übergeben.

Diese Methode prüft, ob ein eingebettetes .NET-Modul bereits im Application State unter dem Schlüssel „MicroWxx“ vorhanden ist. Falls nicht, wird es Base64-dekodiert, GZIP-dekomprimiert und über Reflection geladen. Das Modul initialisiert eine Microsoft JScript VsaEngine und führt den Befehl mittels Eval.JScriptEvaluate aus.

Das Ergebnis der Befehlsausführung wird komprimiert, verschlüsselt und zurück an OpenAI gesendet. Die Backdoor erstellt einen neuen 32-Byte-AES-Schlüssel, komprimiert das Ergebnis mit GZIP, verschlüsselt es mit AES und kodiert es Base64. Der AES-Schlüssel selbst wird mit einem fest kodierten öffentlichen RSA-Schlüssel verschlüsselt und ebenfalls Base64-kodiert. Beide Teile werden durch ein Leerzeichen getrennt zusammengefügt und als neue Nachricht mit der zuvor abgerufenen Thread-ID an OpenAI gepostet.

Abschließend erstellt die Backdoor einen neuen Assistant mit dem Base64-kodierten Hostnamen als Namen. Das Anweisungsfeld wird auf die Verkettung von Thread-ID und neuer Message-ID gesetzt, getrennt durch [._.], und das Beschreibungsfeld erhält den Wert Result. Dies signalisiert dem Angreifer, dass das Ausführungsergebnis bereitsteht.

Schutzmaßnahmen und Erkennungsmöglichkeiten

Microsoft empfiehlt mehrere Maßnahmen zur Eindämmung der Bedrohung. Organisationen sollten Firewalls und Webserver-Logs regelmäßig überprüfen und sich aller direkt mit dem Internet verbundenen Systeme bewusst sein. Windows Defender Firewall, Intrusion-Prevention-Systeme und Netzwerk-Firewalls sollten genutzt werden, um C2-Kommunikation zu blockieren.

Microsoft Defender Antivirus erkennt die Bedrohung als Trojan:MSIL/Sesameop.A (Loader) und Backdoor:MSIL/Sesameop.A (Backdoor). Microsoft Defender for Endpoint kann die Warnung „Possible dotnet process AppDomainManager injection“ auslösen, die jedoch auch durch andere Bedrohungen ausgelöst werden kann.

Für die Bedrohungssuche stellt Microsoft eine Hunting Query für Microsoft Defender XDR bereit, die Geräte identifiziert, die Verbindungen zu api.openai.com herstellen. Die Query zeigt die Anzahl der Verbindungen pro InitiatingProcessFileName sowie die Anzahl der Tage, an denen die Verbindung beobachtet wurde. Kunden von Microsoft Security Copilot können vorgefertigte Promptbooks wie „Incident investigation“, „Threat actor profile“ oder „Threat Intelligence 360 report“ zur automatisierten Untersuchung verwenden.

Microsoft betont, dass Tamper Protection in Microsoft Defender for Endpoint aktiviert sein sollte und Endpoint Detection and Response im Block-Modus laufen sollte, damit schädliche Artefakte auch dann blockiert werden, wenn Antivirus-Software von Drittanbietern die Bedrohung nicht erkennt. Cloud-basierter Schutz und Echtzeitschutz in Microsoft Defender Antivirus sollten ebenfalls aktiviert sein.