Angriffe auf Active Directory erkennen, bevor der Angreifer Domain-Admin ist
Fünf Befunde aus dem Sicherheitsprotokoll, die Ursache dahinter und die Reaktion, die den Angreifer nicht warnt, dazu die Sensoren, die du vorher brauchst.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Kurz gesagt
Ein Angriff auf die Domäne hinterlässt Spuren, lange bevor jemand Domain-Admin ist: Dutzende Diensttickets mit RC4 von einem einzelnen Rechner, eine Replikationsanfrage von einem Konto, das kein Domänencontroller ist, eine NTLM-Anmeldung von einem Arbeitsplatz an zwanzig Servern. Diese Spuren stehen in den Sicherheitsprotokollen der Domänencontroller, aber nur, wenn die erweiterte Überwachungsrichtlinie sie schreibt und jemand sie zusammenführt. Wer sie erkennt, hat Stunden; wer sie erst beim Golden Ticket bemerkt, hat einen Neuaufbau vor sich.
Stand dieser Seite: 04.10.2026
01 Worum es geht
Die Protokolle waren da, aber niemand hat sie gelesen
Die Lage sieht fast immer gleich aus, wenn die Forensiker kommen: Der Angreifer war seit Wochen in der Domäne. Er kam über ein Phishing-Konto ohne Sonderrechte, fragte per LDAP Gruppen und Dienstkonten ab, holte Diensttickets für ein Dutzend Konten mit Dienstprinzipalnamen und knackte offline das Kennwort eines Backup-Dienstkontos aus dem Jahr 2016. Damit bewegte er sich mit NTLM von Server zu Server, bis auf einem ein Domänenadministrator angemeldet war, und zog dessen Hash aus dem Speicher. Per Replikation holte er die Hashes aller Konten und baute sich ein Ticket, das ein Jahrzehnt gilt. Dann kam die Verschlüsselung, und mit ihr Meldepflicht und Stillstand.
Der Preis liegt nicht in der Verschlüsselung allein. Wer den Hash des Kontos krbtgt besitzt, kann sich jederzeit jedes Konto der Domäne ausstellen, auch nach der Wiederherstellung aus einer Sicherung, die den alten Hash enthält. Die Domäne gilt dann als vollständig kompromittiert, und der dokumentierte Weg zurück ist ein Reset des krbtgt-Kontos in zwei Durchgängen und oft der Neuaufbau der Gesamtstruktur. Jeder Schritt der Kette davor wäre billiger gewesen, und jeder hat ein eigenes Ereignis im Protokoll hinterlassen.
Dass diese Ereignisse nicht gelesen wurden, hat drei Ursachen. Die erweiterte Überwachungsrichtlinie schreibt sie nicht, weil die Unterkategorien nie eingeschaltet wurden und das Ereignis 4662 zusätzlich eine Überwachungseinstellung am Domänenobjekt braucht. Die Protokolle liegen auf jedem Domänencontroller einzeln und werden nach Tagen überschrieben. Und das Werkzeug, das die Muster erkennen soll, heißt in vielen Köpfen noch Advanced Threat Analytics, dessen Mainstream-Support am 12. Januar 2021 endete und dessen erweiterter Support im Januar 2026 auslief.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
02 Symptom, Ursache, Lösung
Die Befunde, die im Protokoll tatsächlich auftreten
Fünf Muster decken den größten Teil dessen ab, was bei Angriffen auf Domänen beobachtet wird. Zu jedem steht hier, woran du es erkennst, was dahintersteckt und wie du reagierst, ohne dem Angreifer zu zeigen, dass du ihn siehst.
Symptom
Ein einzelner Arbeitsplatzrechner erzeugt auf dem Domänencontroller innerhalb weniger Sekunden Dutzende Ereignisse 4769 für Dienstkonten mit Dienstprinzipalnamen, und im Feld Ticketverschlüsselungstyp steht 0x17 statt 0x12. Defender for Identity meldet Suspected Kerberos SPN exposure.
Ursache
Das ist Kerberoasting, in MITRE ATT&CK die Technik T1558.003. Jedes Domänenkonto darf Diensttickets für jeden Dienstprinzipalnamen anfordern, und das Ticket ist mit dem Kennwort-Hash des Dienstkontos verschlüsselt. Fordert der Angreifer RC4 an, kann er das Kennwort offline knacken; 0x17 steht für RC4-HMAC, 0x12 für AES256. Microsoft empfiehlt, jeden Ticketverschlüsselungstyp außer 0x11 und 0x12 zu überwachen.
Lösung
Ermittle aus dem Feld Clientadresse den Quellrechner und aus dem Feld Kontoname das verwendete Konto; beide gehören in die Untersuchung, bevor du etwas zurücksetzt. Setz die Kennwörter der angefragten Dienstkonten auf lange Zufallswerte oder stell sie auf gruppenverwaltete Dienstkonten um. Beschränke die erlaubten Verschlüsselungstypen auf AES; Windows Server 2025 stellt für Ticket Granting Tickets kein RC4 mehr aus. Danach gehört eine Regel ins SIEM, die jedes 4769 mit RC4 meldet.
Symptom
Ein Benutzerkonto meldet sich innerhalb kurzer Zeit mit NTLM an vielen Servern an: Ereignis 4624 mit Anmeldetyp 3 und Authentifizierungspaket NTLM auf den Zielservern, Ereignis 4776 auf dem Domänencontroller, Ereignis 8004 mit demselben Quellrechner. Defender for Identity meldet Suspected identity theft (pass-the-hash).
Ursache
Das ist Pass-the-Hash, Technik T1550.002. Der Angreifer hat auf einem übernommenen Rechner den NTLM-Hash eines Kontos aus dem Speicher gelesen, meist eines lokalen Administrators mit überall gleichem Kennwort oder eines Domänenadministrators, der sich dort angemeldet hatte. Diesen Hash verwendet er ohne Kennwort weiter. Defender for Identity erkennt, dass derselbe Hash von einem anderen Rechner aus benutzt wird. Ursache ist fast immer die fehlende Trennung der Ebenen.
Lösung
Isoliere den Quellrechner im Netz, aber schalte ihn nicht aus, damit der Speicher für die Forensik erhalten bleibt. Behandle jedes Konto, das sich dort angemeldet hat, als kompromittiert, und setze Kennwörter koordiniert zurück, nicht einzeln. Danach folgen die strukturellen Maßnahmen: Windows LAPS für lokale Administratorkennwörter, das Tier-Modell mit getrennten Konten für Arbeitsplatz, Server und Domänencontroller, die Gruppe Geschützte Benutzer für privilegierte Konten und die schrittweise Einschränkung von NTLM auf Basis der Ereignisse 8004.
Symptom
Im Sicherheitsprotokoll eines Domänencontrollers steht ein Ereignis 4662, dessen Eigenschaften das erweiterte Recht DS-Replication-Get-Changes-All enthalten, und das anfordernde Konto ist kein Computerkonto eines Domänencontrollers. Defender for Identity meldet Suspected DCSync attack (replication of directory services).
Ursache
Das ist DCSync, Technik T1003.006. Der Angreifer gibt sich gegenüber einem Domänencontroller als Replikationspartner aus und fordert die Kennwort-Hashes aller Konten an, einschließlich krbtgt. Dafür braucht das Konto Replikationsrechte, die Domänen- und Unternehmensadministratoren haben und die gelegentlich fehlerhaft an Dienstkonten delegiert wurden. Legitime Anfragen kommen von Domänencontrollern und vom Dienstkonto der Verzeichnissynchronisierung nach Entra ID; alles andere ist ein Angriff.
Lösung
Ab diesem Befund gilt die Domäne als vollständig kompromittiert, denn der Angreifer besitzt den Hash von krbtgt. Hole Incident-Response-Hilfe, bevor du handelst, und sichere die Protokolle aller Domänencontroller. Der dokumentierte Weg führt über das Zurücksetzen des krbtgt-Kennworts in zwei Durchgängen mit mindestens zehn Stunden Abstand und abgeschlossener Replikation dazwischen, das Zurücksetzen aller privilegierten Konten und der Computerkonten der Domänencontroller und je nach Ausmaß über die Wiederherstellung der Gesamtstruktur. Nimm das Konto der Verzeichnissynchronisierung danach ausdrücklich von der Erkennungsregel für die Ereignis-ID 4662 aus, statt die Regel abzuschalten.
Symptom
Auf einem Server erscheinen Ereignisse 4769 für ein Konto, für das auf keinem Domänencontroller ein vorhergehendes Ereignis 4768 existiert, oder für ein Konto, das es im Verzeichnis nicht gibt, oder die Ticketlaufzeit überschreitet die Richtlinie der Domäne. Defender for Identity meldet Suspected Golden Ticket usage mit dem Zusatz time anomaly, nonexistent account oder encryption downgrade.
Ursache
Das ist ein Golden Ticket, Technik T1558.001. Mit dem Hash von krbtgt stellt der Angreifer selbst Ticket Granting Tickets aus, ohne den Domänencontroller zu fragen. Deshalb fehlt die Anforderung im Protokoll, deshalb sind Laufzeit und Kontoname frei wählbar, und deshalb überlebt das Ticket jede Kennwortänderung außer der von krbtgt selbst. Der Befund zeigt, dass eine vorherige Stufe, meist DCSync, bereits stattgefunden hat.
Lösung
Dieselbe Reaktion wie bei DCSync, und zwar vollständig: zweimaliges Zurücksetzen von krbtgt mit mindestens zehn Stunden Abstand, Zurücksetzen aller privilegierten Konten, forensische Sicherung vor jeder Änderung und die Entscheidung über eine Wiederherstellung der Gesamtstruktur mit Fachleuten. Microsoft erklärt im Leitfaden, dass der zweite Durchgang nötig ist, weil der Kennwortverlauf von krbtgt zwei Einträge hält und der alte Hash sonst weiter gilt, und dass zwischen den Durchgängen mindestens die maximale Ticketlebensdauer von standardmäßig zehn Stunden vergehen und die Replikation abgeschlossen sein muss.
Symptom
Defender for Identity meldet Account Enumeration reconnaissance (LDAP) oder User and Group membership reconnaissance (SAMR) von einem Arbeitsplatzrechner, und auf dem Domänencontroller häufen sich LDAP-Abfragen eines einzelnen Kontos nach Gruppen, Dienstprinzipalnamen und Vertrauensstellungen.
Ursache
Das ist Erkundung, in MITRE ATT&CK unter Discovery mit der Technik T1087.002 für Domänenkonten. Werkzeuge, die den kürzesten Weg zum Domänenadministrator berechnen, fragen in Minuten jede Gruppe, jede Sitzung und jedes Zugriffsrecht ab. Das ist mit jedem Benutzerkonto erlaubt; deshalb fällt es keinem Berechtigungsmodell auf, sondern nur über Menge und Muster der Abfragen. Es ist der früheste Punkt der Kette und der einzige, an dem noch nichts verloren ist.
Lösung
Untersuche Konto und Rechner leise: keine Kennwortänderung, keine Sperre, bevor du weißt, ob der Angreifer schon weiter ist. Prüfe, ob das Konto gephisht wurde oder der Rechner Schadsoftware trägt. Danach senke die Angriffsfläche: Beschränke Remoteaufrufe an SAM über die zugehörige Sicherheitsoption, lege Köderkonten an, die bei jeder Abfrage Alarm auslösen, und räume die Gruppen mit Sonderrechten auf, damit der berechnete Weg zum Domänenadministrator länger wird.
03 Was du mitnimmst
Was du einrichtest, damit die Spuren überhaupt sichtbar werden
Fünf Maßnahmen entscheiden, ob ein Angriff auf die Domäne als Ereignis im Protokoll oder als Erpresserschreiben sichtbar wird. Drei sind Konfiguration, eine ist ein Sensor, die letzte ein Zettel für den Ernstfall.
Die Kette vom Benutzerkonto zur Domäne
- 01 Erkundung per LDAP und SAMR
- 02 Kerberoasting von Dienstkonten
- 03 Pass-the-Hash von Server zu Server
- 04 DCSync zieht alle Hashes
- 05 Golden Ticket bleibt für Jahre
Die erweiterte Überwachungsrichtlinie vollständig schalten
Auf den Domänencontrollern gehören mindestens die Unterkategorien Anmeldeinformationsüberprüfung, Computerkonten-, Sicherheitsgruppen- und Benutzerkontenverwaltung, Verzeichnisdienständerungen, Verzeichnisdienstzugriff und Sicherheitssystemerweiterung auf Erfolg und Fehler. Microsoft nennt diese Liste als Voraussetzung für Defender for Identity: unter anderem 4662, 4726, 4728, 4732, 4741, 4756, 4776, 5136 und 7045.
Das Ereignis 4662 am Domänenobjekt freischalten
Das Ereignis 4662 für Vorgänge an Verzeichnisobjekten entsteht nur, wenn am Domänenobjekt für die Gruppe Jeder eine Überwachungseinstellung mit Erfolg auf untergeordnete Benutzer-, Gruppen-, Computer- und verwaltete Dienstkontoobjekte gesetzt ist. Ohne diesen Eintrag bleibt die Replikationsanfrage eines DCSync-Angriffs unsichtbar, obwohl die Unterkategorie eingeschaltet ist.
NTLM überwachen, bevor du es einschränkst
Die Sicherheitsoptionen zur NTLM-Einschränkung kennen einen Überwachungsmodus, der das Ereignis 8004 erzeugt und zeigt, welches Konto von welchem Rechner auf welchen Server mit NTLM zugreift. Dieses Bild brauchst du zweimal: um Pass-the-Hash zu erkennen und um NTLM später abzuschalten, ohne Anwendungen zu zerstören. Windows Server 2025 hat NTLMv1 entfernt und NTLMv2 als veraltet eingestuft.
Einen Sensor einsetzen, der die Muster kennt
Microsoft Defender for Identity läuft als Sensor auf den Domänencontrollern, liest Netzwerkverkehr und Ereignisse mit und erzeugt Alarme mit Zuordnung zu MITRE ATT&CK, etwa Suspected Kerberos SPN exposure oder Suspected DCSync attack. Der Sensor der Generation 3 ist in Windows Server ab 2019 integriert, setzt die Anbindung an Defender for Endpoint voraus und kann die Überwachungsrichtlinie selbst konfigurieren. Ohne Microsoft-Paket baust du dieselben Erkennungen als Regeln im SIEM.
Köderkonten anlegen und den Ernstfall aufschreiben
Ein Konto mit verlockendem Namen, einem Dienstprinzipalnamen und ohne jede Nutzung ist der billigste Sensor: Jede Ticketanforderung und jede Anmeldung dafür ist ein Alarm, und Defender for Identity kennt dafür eigene Honeytoken-Alarme. Dazu gehört ein Blatt für den Ernstfall: wer entscheidet, wer isoliert, wer Beweise sichert, wer meldet, und die Regel, dass niemand ein einzelnes Kennwort zurücksetzt, bevor das Ausmaß bekannt ist.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Warum die Kette so oft gleich verläuft
Angriffe auf Active Directory folgen einem Muster, weil die Domäne überall gleich gebaut ist. Jedes Konto darf das Verzeichnis lesen, jedes Konto darf Diensttickets anfordern, und jeder Rechner, an dem sich ein Administrator anmeldet, hält dessen Anmeldedaten im Speicher. MITRE ATT&CK fasst die Techniken unter der Taktik Credential Access zusammen: Kerberoasting und AS-REP Roasting als Unterarten von Steal or Forge Kerberos Tickets, DCSync als Unterart von OS Credential Dumping, Pass-the-Hash unter Use Alternate Authentication Material.
Die Kette ist für die Erkennung wertvoll, weil jede Stufe eine andere Spur hinterlässt und weil die Stufen Zeit brauchen. Zwischen der ersten LDAP-Erkundung und dem ersten geknackten Dienstkonto liegen Stunden bis Tage, zwischen dem ersten Serverzugriff mit fremdem Hash und dem Zugriff auf einen Domänenadministrator oft Wochen. Wer die Ereignisse dieser Zeit liest, unterbricht die Kette dort, wo noch nichts verloren ist.
Umgekehrt gilt: Ab dem Ereignis 4662 mit Replikationsrecht ist die Kette am Ende. Alles danach, Golden Ticket, DCShadow, Veränderungen an AdminSDHolder, ist eine Form der Verstetigung. Die Erkennung dieser Spuren zeigt, wie tief der Angreifer sitzt, aber sie rettet die Domäne nicht mehr. Deshalb liegt der Schwerpunkt auf den frühen Stufen, und deshalb ist die wichtigste Maßnahme kein Werkzeug, sondern die Vollständigkeit der Protokolle.
Welche Protokolle du brauchst und woher sie kommen
Die Ereignisse, um die es hier geht, schreibt ein Domänencontroller nicht von sich aus. Die erweiterte Überwachungsrichtlinie muss sie je Unterkategorie einschalten. Microsoft nennt die Liste: Anmeldeinformationsüberprüfung für 4776, Computerkontenverwaltung für 4741 und 4743, Verteilergruppen- und Sicherheitsgruppenverwaltung für 4728 bis 4763, Benutzerkontenverwaltung für 4726, Verzeichnisdienständerungen für 5136, Sicherheitssystemerweiterung für 7045 und Verzeichnisdienstzugriff für 4662. Mit auditpol prüfst du, was gilt; das PowerShell-Modul DefenderForIdentity erzeugt mit New-MDIConfigurationReport einen Bericht über alle Lücken.
Zwei Ereignisse brauchen mehr als die Richtlinie. Das Ereignis 4662 entsteht nur mit einer Überwachungseinstellung am Domänenobjekt für die Gruppe Jeder mit Erfolg auf untergeordnete Benutzer-, Gruppen-, Computer- und verwaltete Dienstkontoobjekte, einschließlich der delegierten verwalteten Dienstkonten, die mit Windows Server 2025 neu sind. Das Ereignis 8004 entsteht nur, wenn die Sicherheitsoptionen zur NTLM-Einschränkung auf Überwachung stehen, und zwar ausschließlich auf Domänencontrollern. Der Sensor der Generation 3 setzt beide Einstellungen automatisch; ohne Sensor setzt du sie per Gruppenrichtlinie.
Das Sicherheitsprotokoll eines Domänencontrollers ist nach Tagen voll, und ein Angreifer mit Adminrechten löscht es. Deshalb gehören die Ereignisse in ein zentrales System mit langer Aufbewahrung. Ob das Microsoft Sentinel, Wazuh oder ein anderes SIEM ist, hängt von Budget und Mannschaft ab; entscheidend ist, dass dort Regeln laufen, die über Rechner hinweg zählen: ein Konto, viele Ziele; eine Quelle, viele Tickets; ein Ticket ohne Anforderung.
Defender for Identity: Sensor, Lernphasen und Grenzen
Microsoft Defender for Identity ist der Nachfolger von Advanced Threat Analytics; wer ATA noch betreibt, hat ein Werkzeug ohne Erkennungsupdates auf seinen Domänencontrollern. Der Sensor der Generation 3 ist in Windows Server ab 2019 integriert, wird über die Anbindung an Defender for Endpoint aktiviert und braucht keine eigene Installation. Mit automatischer Überwachungskonfiguration setzt der Sensor Überwachungsrichtlinie, Objektüberwachung und NTLM-Überwachung selbst und prüft sie alle 24 Stunden.
Die Alarme sind nach den Phasen eines Angriffs gegliedert und tragen die Technik aus MITRE ATT&CK mit: Reconnaissance and discovery, Persistence and privilege escalation, Credential access, Lateral movement. Einige brauchen eine Lernphase; der Alarm zu Brute-Force-Angriffen lernt eine Woche, der zur Verschlüsselungsabsenkung beim Golden Ticket fünf Tage ab Start des Sensors. In dieser Zeit kennt der Sensor den Normalzustand noch nicht.
Zwei Grenzen nennt Microsoft selbst. Defender for Identity ist keine Protokollierungslösung, die jede Operation festhält; es erfasst nur, was es für seine Erkennungen braucht. Und es sieht nur, was den Domänencontroller erreicht: Ein Angreifer, der mit gültigen Anmeldedaten in normalem Tempo arbeitet, erzeugt kein Muster. Die Spuren auf Mitgliedsservern, etwa die Ereignisse 4624 und 4648, und die Spuren auf dem Endgerät kommen aus Defender for Endpoint oder aus dem SIEM. Erst das Zusammenspiel ergibt das Bild, das die Kette unterbricht.
Reagieren, ohne den Angreifer zu warnen
Die häufigste Fehlreaktion ist die schnellste: Ein Administrator sieht ein verdächtiges Konto, setzt das Kennwort zurück und sperrt den Rechner. Damit weiß der Angreifer, dass er gesehen wurde. Die bessere Reihenfolge lautet: beobachten, Ausmaß bestimmen, Beweise sichern, dann koordiniert handeln. Isoliere betroffene Rechner im Netz, aber lass sie laufen, damit der Speicher erhalten bleibt. Sichere die Protokolle aller Domänencontroller, und hol einen Incident-Response-Partner, sobald ein Befund auf Replikationsrechte oder Tickets hinweist.
Ist krbtgt betroffen, beschreibt Microsoft im Leitfaden zur Wiederherstellung der Gesamtstruktur das Verfahren: Das Kennwort wird zweimal zurückgesetzt, weil der Kennwortverlauf des Kontos zwei Einträge umfasst und der alte Hash sonst weiter akzeptiert würde. Zwischen den beiden Durchgängen verlangt Microsoft eine Wartezeit von mindestens zehn Stunden, dem Standardwert für die maximale Lebensdauer von Benutzer- und Diensttickets; ist diese Richtlinie länger eingestellt, muss die Wartezeit entsprechend länger sein, und die Replikation an alle Domänencontroller muss abgeschlossen sein, sonst scheitern legitime Anmeldungen. Danach folgen alle privilegierten Konten, die Computerkonten der Domänencontroller und die Vertrauensstellungen. Diese Schritte gehören in ein geübtes Verfahren, nicht in eine Nachtschicht mit Suchmaschine.
Parallel läuft die Pflicht. Für Einrichtungen nach dem BSI-Gesetz beginnt mit dem Verdacht eines erheblichen Sicherheitsvorfalls die Frist für die frühe Erstmeldung; die Seite zur Meldung eines NIS2-Vorfalls in diesem Bereich beschreibt Fristen und Inhalte. Danach kommen die strukturellen Maßnahmen auf die Liste: das Tier-Modell für privilegierte Konten, AES statt RC4, LDAP-Signierung, die Windows Server 2025 für neue Umgebungen standardmäßig verlangt, SMB-Signierung, die dort für ausgehende Verbindungen Pflicht ist, und der Abschied von NTLM.
Dazu passende Kurse
Wenn die Alarme bei euch bisher niemand liest, bringen Microsoft-Security-Kurse zu Defender for Identity und Sentinel Erkennung und Reaktion in dieselben Hände.
Weil die Spuren auf Servern und Endgeräten genauso zählen wie die auf dem Domänencontroller, findest du bei cmt Security-Kurse zu Windows-Forensik und Angriffserkennung.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
04 Konkrete Kurse
Wo du genau das übst
- Microsoft Defender for Identity - Erkennen von Cyberangriffen
- SC-200 Training: Microsoft Security Operations Analyst (SC-200T00-A)
- Digitale Forensik für Microsoft Windows
- Wazuh Schulung: SIEM aufbauen und Alarme bearbeiten
Weitere Kurse aus diesem Bereich
- SC-300 Training: Microsoft Identity and Access Administrator (SC-300T00-A)
- SC-401 Kurs: Information Security Administrator (SC-401T00)
- SC-5001 – Konfigurieren von SIEM-Sicherheitsoperationen mit Microsoft Sentinel
- Digitale Forensik für Einsteiger - Grundkurs
- SC-500 Schulung: Implement end-to-end security controls for cloud and AI workloads (SC-500T00)
- SC-5002: Azure-Dienste und Workloads mit Microsoft Defender für Cloud absichern, unter Einhaltung regulatorischer Compliance-Kontrollen
- IT-Sicherheit: (Anti-) Hacking für Admins - Angriffe erkennen und Schutzmaßnahmen verstärken
- SELinux Training: Grundlagen und Administration (SEL1)
Preise, Orte und Buchung für alle Kurse des Bereichs findest du im Katalog: Alle IT-Security-Schulungen mit Terminen.
Stimmen aus den Kursen
Was Teilnehmende über die Kurse in diesem Bereich sagen
Dank des äusserst kompetenten Trainers war dies ein sehr informativer und förderlicher Kurs.
Sehr intensiver Lehrgang, hat mich für meine Arbeit ein gutes Stück voran gebracht.
Sehr guter Dozent, spannend erklärt und mit vielen Praxisbeispielen!
05 Fragen
Häufige Fragen
Deine Frage ist nicht dabei? Stell sie uns direkt, wir antworten dir persönlich.
Welche Ereignis-IDs sollten wir als Erstes überwachen?
Warum sehen wir kein Ereignis 4662, obwohl die Richtlinie Verzeichnisdienstzugriff eingeschaltet ist?
Sollen wir bei einem Verdacht sofort alle Kennwörter zurücksetzen?
Wie erkennen wir ein Golden Ticket, wenn es keine Anforderung im Protokoll gibt?
Was ändert Windows Server 2025 für die Erkennung?
Passt thematisch dazu
Fast jeder Befund auf dieser Seite hat dieselbe Vorgeschichte, und die Seite über das Tier-Modell und die Absicherung privilegierter Konten im Verzeichnis beschreibt, wie du sie verhinderst.
Pass-the-Hash läuft fast immer über SMB, und SMB-Signierung und der Abschied von SMB1 nehmen dem Angreifer den bequemsten Weg.
Wenn der Begriff bei euch noch unscharf ist, erklärt der Glossareintrag, was ein SIEM ist und wie es Ereignisse korreliert, bevor es hier um Regeln geht.
Quellen
- Microsoft Learn, Microsoft Defender for Identity classic security alerts (mit MITRE-ATT&CK-Zuordnung)
- Microsoft Learn, Configure Windows event auditing for Microsoft Defender for Identity
- Microsoft Learn, 4769(S, F): A Kerberos service ticket was requested
- Microsoft Learn, AD Forest Recovery: Reset the krbtgt password
- Microsoft Tech Community, End of mainstream support for Advanced Threat Analytics January 2021
- Microsoft Learn, What's new in Windows Server 2025
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem IT-Security-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Die Kette einmal selbst laufen lassen und im Protokoll wiederfinden
Im Kurs zu Microsoft Defender for Identity bei cmt führst du Kerberoasting, Pass-the-Hash und DCSync an einer Übungsdomäne selbst aus, siehst die Ereignisse und Alarme entstehen und übst die Reaktion bis zum zweifachen Reset von krbtgt. Die Trainer haben solche Fälle im Betrieb begleitet.
Verwandte Themen
- SIEM oder XDR: was dein Team wirklich braucht, um Angriffe zu sehen
- EDR oder Antivirus: was auf den Endgeräten heute noch reicht
- Privileged Identity Management in Entra ID einrichten: Adminrechte nur auf Zeit
- Microsoft-365-Konto gehackt: Anzeichen, Sofortmaßnahmen und die Spurensuche