Microsoft berichtete am 30. Oktober 2026 von zwei untersuchten Angriffen, bei denen Täter Beschäftigte über Microsoft Teams mit vorgetäuschtem IT-Support zu einem Fernzugriff verleiteten und anschließend Active Directory Certificate Services (AD CS) missbrauchten. Teams diente dabei als Kontaktweg für die Täuschung; der technische Angriff führte über zwei unterschiedliche Zertifikatspfade. Microsofts Bericht beschreibt keine Sicherheitslücke in Teams.

Wie der Teams-Kontakt den Fernzugriff öffnete

Die Angreifer meldeten sich über externe Teams-Nachrichten oder Anrufe als IT- oder Helpdesk-Mitarbeitende aus. Beschäftigte gewährten ihnen interaktiven Fernzugriff, meist über Quick Assist. Anschließend legten die Angreifer Archive ab, entpackten sie in neu angelegte, beschreibbare Ordner und führten dort Skripte mit portablen Umgebungen für Python, Bun oder Java aus.

Damit begann die Suche nach Informationen über den Rechner, das Netzwerk und die Zertifikatsdienste. Dateinamen oder der Fund einer Laufzeitumgebung allein reichen als Hinweis nicht aus. Microsoft empfiehlt, auch Speicherpfad, Prozesskette, Metadaten, den Zusammenhang mit einer Fernsitzung und nachfolgende Aktivitäten zu prüfen.

Zwei Wege durch AD CS

Ein gemeinsamer Teams-Kontakt verzweigt sich in die AD-CS-Pfade ESC1 und PetitPotam/ESC8 mit unterschiedlichen Eindämmungsverläufen.

AD CS verwaltet Zertifikate, die in einer Windows-Domäne auch zur Anmeldung verwendet werden können. In den beiden Fällen missbrauchten die Angreifer unterschiedliche Schwächen dieser Infrastruktur.

Fall 1: ESC1 und eine ausgenommene privilegierte Identität

Bei ESC1 ermöglichte eine fehlerhaft konfigurierte Zertifikatvorlage, dass Antragstellende Identitätsangaben selbst festlegten und Zertifikate für privilegierte Konten erhielten. Die erste Angriffswelle richtete sich gegen drei Nutzerkonten und einen Arbeitsplatzrechner; die Angreifer erlangten Zertifikate für drei privilegierte Konten.

Rund 90 Minuten später zielte eine zweite Welle auf 16 Nutzer und einen weiteren Rechner. Sie führte zu acht zusätzlichen Zertifikaten für privilegierte Konten. Microsoft Defender Attack Disruption blockierte anschließend mehr als 1.000 SMB-Zugriffs- und Anmeldeversuche.

Ein privilegiertes Konto war von der automatischen Eindämmung ausgenommen und blieb nutzbar. Innerhalb von Sekunden nach dem Erhalt eines privilegierten Zertifikats begann ein DCSync-Vorgang. Die Eindämmung begrenzte weitere Replikation, doch über das ausgenommene Konto gelangten die Angreifer später auf einen Dateiserver und übertrugen Daten an ein externes SFTP-Ziel.

Fall 2: PetitPotam und ESC8

Im zweiten Fall veranlasste PetitPotam einen Domänencontroller, sich per NTLM bei einem von den Angreifern kontrollierten System zu authentifizieren. Diese Anmeldung wurde an AD CS Web Enrollment weitergeleitet. Über diesen ESC8-Pfad erlangten die Angreifer ein Zertifikat für das Maschinenkonto des Domänencontrollers und nutzten es für PKINIT, die zertifikatsbasierte Kerberos-Authentifizierung, um ein Ticket-Granting-Ticket (TGT) anzufordern.

Microsoft Defender erzeugte Warnmeldungen zu ESC8. Der Kunde isolierte daraufhin den zugehörigen Arbeitsplatzrechner; anschließend beobachtete Microsoft keine weitere Angriffsprogression.

Welche Signale eine Untersuchung verbinden kann

Microsoft veröffentlichte vier Kategorien von Advanced-Hunting-Abfragen. Sie können bei der Suche nach verdächtigen externen Teams-Kontakten und Hinweisen auf Identitätsvortäuschung helfen, ebenso bei der Ausführung von Bun oder Java aus KB-präfixierten Verzeichnissen. Weitere Abfragen suchen nach Netzwerkverbindungen dieser Laufzeitumgebungen über die Ports 80, 445, 636 oder 88 sowie nach Warnmeldungen zu NTLM-Relays, Certificate Services, PKINIT und Kerberos-Ticketanfragen.

Microsoft empfiehlt, die Abfragen an die jeweilige Umgebung anzupassen und Treffer mit weiteren Vorfallsignalen abzugleichen. Für eine Untersuchung sollten Teams-Kontakt und Fernsitzung mit Prozessaktivitäten auf dem Endgerät, Zertifikatsanfragen und -ausstellungen, Identitätswarnungen und Kerberos-Aktivitäten zusammengeführt werden. Ein einzelner Treffer oder ein Runtime-Dateiname belegt für sich genommen keinen Angriff.

Welche Reaktion Microsoft empfiehlt

Microsoft empfiehlt, unerwartete Supportanfragen über bekannte interne Kanäle zu überprüfen, den externen Teams-Zugriff auf den Geschäftsbedarf abzustimmen und Fernwartung auf genehmigte Abläufe zu begrenzen. Bei AD CS sollten Sicherheitsteams Vorlagen für Authentifizierungszertifikate auf selbst angegebene Identitäten, weit gefasste Antragsrechte und schwache Ausgabekontrollen prüfen. Nicht benötigte Web-Enrollment-Endpunkte sollten entfernt werden; für erforderliche Endpunkte empfiehlt Microsoft HTTPS und Extended Protection for Authentication (EPA). NTLM sollte dort abgeschaltet werden, wo der Betrieb es erlaubt. Die Microsoft-Anleitung zur Absicherung von AD CS gegen NTLM-Relay-Angriffe erläutert diese Schutzmaßnahmen.

Ein Passwortwechsel oder das Neuaufsetzen des zuerst betroffenen Rechners widerruft ein bereits ausgestelltes Zertifikat nicht und macht schon ausgegebene Kerberos-Tickets nicht ungültig. Microsoft empfiehlt deshalb, unerlaubte Zertifikate zu ermitteln und zu widerrufen sowie aktive Tickets gesondert zu überprüfen. Für jedes Konto oder Gerät, das von der automatischen Eindämmung ausgenommen ist, braucht es eine manuelle Ersatzmaßnahme und die Bestätigung, dass sie umgesetzt wurde.