Beide Vorfälle begannen laut Microsoft identisch: Die Angreifer schrieben und riefen Beschäftigte über Teams an und gaben sich als firmeneigene IT beziehungsweise als Helpdesk aus. Sie arbeiteten dabei aus fremden Tenants heraus, deren Namen an Support-Abteilungen erinnerten, damit der Kontakt vertraut wirkte. Die Nutzer wurden überredet, Quick Assist zu öffnen – das in Windows integrierte Fernwartungswerkzeug – und den Verbindungscode vorzulesen. Damit hatte der Angreifer direkte Kontrolle über die Arbeitsstation.

Anschließend legte der Angreifer ein Archiv im Downloads-Ordner ab, entpackte es in einen neuen Ordner, dessen Name an ein Windows-Update erinnerte, und führte den Inhalt mit einer portablen Python-, Bun- oder Java-Laufzeitumgebung aus. Dateinamen allein taugten kaum als Erkennungsmerkmal: Eine Kopie war umbenannt worden, trug aber weiterhin die Versionsangaben der echten Laufzeitumgebung.

AD CS ist die Windows-Rolle, die jene Zertifikate ausstellt, mit denen sich Nutzer und Computer anmelden. Ein Zertifikat aus einer schlecht konfigurierten Vorlage erlaubt es dem Inhaber, sich als das darin genannte Konto anzumelden. Microsoft weist darauf hin, dass ein solches Zertifikat auch dann weiter funktioniert, wenn das Passwort des Kontos zurückgesetzt oder die zuerst betroffene Maschine neu aufgesetzt wird – keiner der beiden Schritte beendet also den Zugang des Angreifers.

Fall 1: Zertifikate für privilegierte Konten und eine Lücke in der Eindämmung

Im ersten Einbruch fanden die Angreifer eine Zertifikatvorlage mit der als ESC1 bekannten Schwäche. Bei solchen Vorlagen darf der Antragsteller selbst bestimmen, welches Konto das Zertifikat repräsentiert – ein Nutzer mit geringen Rechten kann also ein Zertifikat für ein privilegiertes Konto anfordern.

Die erste Anrufwelle richtete sich gegen drei Nutzer und eine Arbeitsstation und führte zu Zertifikaten für drei hoch privilegierte Konten. Die automatische Angriffsunterbrechung von Microsoft Defender trennte diese Identitäten ab und beendete ihre aktiven Sitzungen. Ein privilegiertes Konto war jedoch von der automatischen Reaktion ausgenommen worden und blieb nutzbar.

Rund 90 Minuten später folgte eine größere Welle gegen 16 Nutzer und eine zweite Arbeitsstation, aus der Zertifikate für acht weitere privilegierte Konten hervorgingen. Mehr als 1.000 spätere Versuche, über SMB auf Dateien zuzugreifen oder sich anzumelden, wurden Microsoft zufolge blockiert.

Innerhalb von Sekunden nach Erhalt eines Zertifikats meldete sich der Angreifer an einem Domänencontroller an und führte DCSync aus, ein Werkzeug zum Kopieren von Passwortdaten aus dem Active Directory. Der Vorgang hatte bereits begonnen, als die Eindämmung griff, was den Umfang der Replikation begrenzte. Wie viele Anmeldedaten der Angreifer erbeutete, teilte Microsoft nicht mit.

Das ausgenommene Konto war die offene Flanke: Der Angreifer nutzte es weiter, erreichte einen Dateiserver und führte eine umbenannte Kopie des Kopierwerkzeugs Rclone aus, um Daten von einer Freigabe auf einen externen SFTP-Server zu verschieben. Auch zum Datenvolumen machte Microsoft keine Angaben. Der Fall zeige, so Microsoft, dass „eine teilweise Identitätseindämmung die Angriffsaktivität zwar verringern, aber dennoch einen gangbaren privilegierten Weg offenlassen kann".

Fall 2: Ein Zertifikat für den Domänencontroller

Der zweite Einbruch begann genauso, nahm aber einen anderen Verlauf, weil die Vorlagenschwäche dort nicht vorhanden war. Stattdessen nutzte der Angreifer die Technik PetitPotam, um einen Domänencontroller zur Authentifizierung gegenüber einer vom Angreifer kontrollierten Maschine zu zwingen. Diese NTLM-Anmeldung wurde an die Web-Enrollment-Seite von AD CS weitergeleitet – ein als ESC8 bekannter Missbrauch, für den kein Passwort nötig ist. Mit der weitergeleiteten Anmeldung forderte der Angreifer ein Zertifikat für den Domänencontroller selbst an. Mit diesem Zertifikat und Kerberos (PKINIT) erlangte er ein Ticket-Granting-Ticket für den Domänencontroller und machte so aus einer einmalig weitergeleiteten Anmeldung eine dauerhafte Identität.

Hier hielt die Reaktion: Defender löste ESC8-Warnungen aus, der Kunde isolierte die Arbeitsstation, und weitere Aktivität folgte Microsoft zufolge nicht. Der Unterschied zwischen beiden Fällen lag in der Eindämmung – im ersten blockierte die automatische Unterbrechung den Großteil des Angriffs, das eine ausgenommene Konto blieb jedoch offen; im zweiten genügte die Isolation einer einzigen Arbeitsstation.

Empfehlungen

Einen Patch gibt es nicht, da keine Softwarelücke beteiligt war. Microsofts Rat betrifft Konfiguration und Reaktion:

  • Unerwartete Support-Anfragen vor Bildschirmfreigabe oder Übergabe der Fernsteuerung über einen bekannten internen Kanal bestätigen lassen.
  • Einschränken, welche externen Teams-Tenants Beschäftigte erreichen können; nur freigegebene Fernwartungswerkzeuge zulassen.
  • Anmeldezertifikatvorlagen prüfen auf solche, bei denen der Antragsteller das Konto benennen darf oder die zu viele Nutzer beantragen können; nicht benötigte Enrollment-Rechte entfernen.
  • HTTPS erzwingen und Extended Protection for Authentication (EPA) auf Web-Enrollment-Endpunkten aktivieren, NTLM dort nach Möglichkeit abschalten. Microsofts KB5005413 beschreibt dies; die Posture-Prüfungen von Defender for Identity markieren für ESC1 und ESC8 anfällige Vorlagen und Endpunkte.
  • Zertifikats-Auditing einschalten. Wurde ein unzulässiges Zertifikat ausgestellt, ist es zu widerrufen – ein Widerruf annulliert jedoch keine bereits ausgestellten Kerberos-Tickets; aktive Tickets sind separat zu prüfen.
  • Jedes von der automatischen Eindämmung ausgenommene Konto als bewusste Entscheidung behandeln und ersatzweise eine manuelle Maßnahme vorsehen.

Einordnung

Microsoft nannte weder eine Tätergruppe noch die Daten der Vorfälle. Neu sind die Methoden nicht: Forscher benannten die Zertifikatsschwächen ESC1 und ESC8 im Jahr 2021, im selben Jahr wurde die Coercion-Technik PetitPotam offengelegt. Den Einstiegsweg über vorgetäuschten Teams-Helpdesk hin zum Fernzugriff hatte Microsoft bereits früher im Jahr 2026 dokumentiert. Neu ist das Zusammentreffen beider Techniken in echten Einbrüchen sowie die Lehre vom ausgenommenen Konto.

Neuere Windows-Versionen sind gegenüber dem ESC8-Schritt weniger exponiert: In Windows Server 2025 hat Microsoft EPA für AD CS standardmäßig aktiviert, in Server 2022 und 2019 muss es manuell eingeschaltet werden.

Microsofts Bericht listet Defender-Warnungen aus Teams, Endpunkt- und Identitätssignalen sowie vier Advanced-Hunting-Abfragen auf, die er als „Ausgangspunkte für eine Untersuchung" und nicht als eigenständigen Beweis bezeichnet. Veröffentlicht wurden zudem drei Dateihashes der Skripte für den Erstzugriff:

  • SHA-256 85b6c424117494d3056e88689dbc94c75e9afdb187a339714043aec0da109f17 (JavaScript-Skript)
  • SHA-256 f326201269f1ee2f803ae435317507263bb6e0dbfdeb70bd1bb5446e2e46f001 (Python-Skript)
  • SHA-256 06c5c14f043aee3bcc5843b5f50909623d5c9a6239a7c1fba9cddad4111469e7 (Python-Skript)