Active Directory: Sieben Fehler, die fast jedes Red Team findet

Wenn ein Red Team in ein Unternehmensnetz gelangt, führt der Weg zum Ziel fast immer über Active Directory. Nicht, weil die Software fehlerhaft wäre, sondern weil Verzeichnisdienste über Jahre gewachsen sind, Entscheidungen aus der Einführungszeit nie revidiert wurden und Bequemlichkeit im Betrieb Vorrang vor Härtung hatte. Das Ergebnis ist in den meisten Organisationen ähnlich: Vom ersten Benutzerkonto zum Domänenadministrator vergehen Stunden, selten Tage.

Die CISA hat 2023 in der Fallstudie AA23-059A dokumentiert, wie ihr Red Team in einem dreimonatigen Test bei einer als reif eingestuften Organisation Domain-Admin-Rechte erlangte. Die genannten Ursachen sind keine exotischen Schwachstellen: ein krbtgt-Passwort, das über zehn Jahre nicht geändert worden war, lokale Administratorrechte auf Arbeitsplätzen, unconstrained delegation und Zugangsdaten im Klartext. EDR-Alarme wurden ausgelöst, aber niemand reagierte. Diese Liste könnte aus nahezu jedem unserer Berichte stammen.

Dieser Beitrag beschreibt die sieben Fehler, die wir in Active-Directory-Umgebungen am häufigsten vorfinden, erklärt, warum sie für Angreifer so wertvoll sind, und zeigt, wie Sie sie beheben. Er verzichtet bewusst auf operative Angriffsdetails; wer verstehen will, wie Angreifer denken, braucht die Logik, nicht das Werkzeug.

Warum Active Directory das Ziel ist

Active Directory verwaltet Identitäten, Rechte und Richtlinien für fast alle Systeme eines Windows-Netzes. Wer die Domäne kontrolliert, kontrolliert jeden angebundenen Server, jeden Arbeitsplatz, oft auch Backup-Systeme und die Anbindung an die Cloud. Ransomware-Gruppen nutzen Domänenrechte, um Verschlüsselung flächendeckend auszurollen; Spionagegruppen nutzen sie, um dauerhaft unauffällig zu bleiben.

Dabei greifen Angreifer selten Active Directory direkt an. Sie nutzen, wie es konfiguriert und betrieben wird: Welche Konten haben zu viele Rechte, welche Passwörter sind schwach oder alt, welche Protokolle aus den 1990er-Jahren sind noch aktiv, wo liegen Zugangsdaten herum. Der Weg verläuft in kleinen Schritten über Privilege Escalation und Lateral Movement, und jeder dieser Schritte ist nur möglich, weil einer der folgenden sieben Fehler vorliegt.

Die sieben Fehler, die fast jedes Red Team findet

1. Das krbtgt-Passwort wurde nie rotiert

Das krbtgt-Konto signiert alle Kerberos-Tickets der Domäne. Wer den Passwort-Hash dieses Kontos besitzt, kann Tickets für beliebige Benutzer mit beliebigen Rechten ausstellen, ein sogenanntes Golden Ticket, und das so lange, bis das Passwort zweimal geändert wurde. In der CISA-Fallstudie war es über zehn Jahre alt. Das bedeutet: Jeder Angreifer, der in diesem Jahrzehnt einmal Domänenrechte hatte, hätte sie bis heute behalten können. Wir finden krbtgt-Passwörter, die seit der Migration von Windows Server 2008 unverändert sind, in der Mehrheit der mittelständischen Umgebungen.

2. Lokale Administratorrechte und identische lokale Admin-Passwörter

Zwei Fehler, die zusammen wirken. Wenn Mitarbeitende lokale Administratoren auf ihren Arbeitsplätzen sind, kann Schadsoftware nach einem Klick Zugangsdaten aus dem Arbeitsspeicher auslesen. Wenn zusätzlich das eingebaute Administratorkonto auf allen Arbeitsplätzen dasselbe Passwort hat, weil es aus einem Image stammt, öffnet ein einziger kompromittierter Rechner alle anderen. Angriffe wie Pass-the-Hash brauchen dafür nicht einmal das Klartextpasswort. Microsoft stellt mit LAPS seit Jahren ein kostenloses Werkzeug bereit, das lokale Admin-Passwörter automatisch individualisiert und rotiert; es ist erstaunlich selten vollständig ausgerollt.

3. Kerberoasting-anfällige Dienstkonten

Ein Dienstkonto mit registriertem Service Principal Name erlaubt jedem authentifizierten Benutzer, ein Kerberos-Ticket anzufordern, das mit dem Passwort-Hash des Dienstkontos verschlüsselt ist. Dieses Ticket lässt sich offline knacken, ohne dass die Domäne etwas davon bemerkt; die Technik heißt Kerberoasting. Problematisch wird das, wenn Dienstkonten schwache, alte Passwörter haben und gleichzeitig hohe Rechte, etwa weil ein Backup- oder Monitoring-Dienst vor Jahren der Einfachheit halber in die Domänenadministratoren aufgenommen wurde. Wir finden in fast jeder Umgebung mindestens ein Dienstkonto, das beide Bedingungen erfüllt.

4. Unconstrained Delegation

Kerberos-Delegation erlaubt einem Dienst, im Namen eines Benutzers auf andere Dienste zuzugreifen. In der ungebremsten Variante (unconstrained) speichert der Server die Anmeldetickets aller Benutzer, die sich mit ihm verbinden, im Arbeitsspeicher, einschließlich der Tickets von Administratoren. Wer einen solchen Server kompromittiert, erntet die Identitäten aller, die ihn jemals nutzen. Die Einstellung stammt aus der Zeit vor Windows Server 2003 und wird oft bei Migrationen mitgeschleppt. Sie gehört zu den Ursachen, die die CISA in AA23-059A explizit nennt.

5. Zugangsdaten im Klartext in Skripten und Freigaben

Der banalste und zugleich ergiebigste Fund: Passwörter in Anmeldeskripten, in Gruppenrichtlinien-Präferenzen, in Konfigurationsdateien auf Netzlaufwerken, in SharePoint-Seiten der IT-Abteilung oder in Beschreibungsfeldern von Benutzerkonten. Angreifer durchsuchen Freigaben automatisiert nach solchen Mustern, oft in den ersten Stunden nach dem Erstzugriff. Ein einziges Dienstkonto-Passwort in einem alten Installationsskript genügt häufig für den Sprung auf die nächste Rechtestufe.

6. Veraltete Protokolle: NTLM und LLMNR

NTLM ist das Authentifizierungsprotokoll, das Kerberos eigentlich abgelöst hat, in den meisten Netzen aber aus Kompatibilitätsgründen weiterläuft. LLMNR und NBT-NS sind Namensauflösungsprotokolle, die greifen, wenn DNS einen Namen nicht kennt, etwa bei einem Tippfehler im Laufwerkspfad. In Kombination erlauben sie einem Angreifer im selben Netzsegment, Anmeldeversuche abzufangen und weiterzuleiten, ein klassischer Man-in-the-Middle-Ansatz. Beide Protokolle lassen sich über Gruppenrichtlinien deaktivieren; die Angst vor Nebenwirkungen auf Altsysteme verhindert das oft über Jahre.

7. Fehlende Tiering-Trennung

Der strukturelle Fehler hinter den meisten anderen: Dieselben Administratorkonten werden für Domänencontroller, Server und Arbeitsplätze verwendet. Ein Domänenadministrator meldet sich an einem normalen Arbeitsplatz an, um ein Problem zu lösen, und hinterlässt dort seine Zugangsdaten im Speicher. Das Tiering-Modell trennt Verwaltungsebenen strikt: Konten für Domänencontroller (Tier 0) dürfen sich nie an Servern (Tier 1) oder Arbeitsplätzen (Tier 2) anmelden. Ohne diese Trennung führt jeder kompromittierte Arbeitsplatz potenziell direkt zum Domain Admin. Mit ihr muss der Angreifer eine Grenze überwinden, die sich überwachen lässt.

Gegenmaßnahmen im Überblick

Die Reihenfolge ist bewusst gewählt. krbtgt-Rotation und Delegation sind in wenigen Stunden erledigt und beseitigen die gefährlichsten Dauerzugänge. LAPS und die Bereinigung von Klartext-Zugangsdaten folgen innerhalb weniger Wochen. Tiering ist ein Projekt über Monate, aber das einzige, das die Angriffsfläche strukturell verkleinert.

Erkennung als zweite Verteidigungslinie

Nicht jeder Fehler lässt sich sofort beheben. Für die Übergangszeit ist Erkennung entscheidend. Die CISA-Fallstudie macht deutlich, dass die betroffene Organisation technisch in der Lage gewesen wäre, das Red Team zu bemerken: Die EDR-Lösung hatte Alarme erzeugt. Sie wurden nicht bearbeitet. Jeder der sieben Fehler erzeugt beim Ausnutzen Spuren: ungewöhnliche Kerberos-Ticketanfragen, Anmeldungen privilegierter Konten auf untypischen Systemen, massenhafte Zugriffe auf Freigaben, LLMNR-Antworten von unbekannten Hosts.

Ob Ihr SOC diese Spuren sieht, lässt sich nur praktisch prüfen. In einem Purple Teaming führen wir die relevanten Techniken kontrolliert aus und stimmen mit Ihrem Blue Team Erkennungsregeln ab, Technik für Technik. Wie das abläuft, beschreibt der Beitrag Purple Teaming und Detection Engineering. Ergänzend bieten Honeytoken-Konten einen günstigen Frühwarnmechanismus: ein unbenutztes Dienstkonto mit verlockendem Namen, dessen Anforderung eines Tickets sofort Alarm auslöst.

Wie wir Active Directory prüfen

Im Rahmen unserer Leistung Active Directory & Cloud gehen wir in zwei Modi vor. Im Assessment analysieren wir die Konfiguration mit Lesezugriff und bewerten Angriffspfade, ohne sie zu beschreiten. Im Assumed Breach starten wir mit einem normalen Benutzerkonto und versuchen, den Weg zum Domänenadministrator tatsächlich zu gehen, dokumentiert mit Zeitstempeln, die Ihr SOC mit seinen Alarmen abgleichen kann. Der zweite Modus beantwortet die Frage, die für die Geschäftsführung zählt: Wie lange dauert es, und bemerkt es jemand? Beide Formate enden mit einem priorisierten Maßnahmenplan und auf Wunsch einem Retest nach der Umsetzung.

Fazit

Die sieben Fehler sind keine Geheimnisse. Sie stehen in jedem Härtungsleitfaden und in der öffentlich zugänglichen CISA-Fallstudie. Dass wir sie trotzdem in fast jeder Umgebung finden, liegt nicht an fehlendem Wissen, sondern an fehlender Priorität und der Angst vor Nebenwirkungen. Die Behebung ist bei fünf der sieben Punkte in Wochen möglich und kostet vor allem Arbeitszeit. Wenn Sie wissen möchten, wo Ihre Domäne steht und wie schnell ein Angreifer sie übernehmen könnte, ist ein Assumed Breach der direkteste Weg zu einer belastbaren Antwort. Informationen zu Umfang und Ablauf finden Sie unter Active Directory & Cloud.

Quellen

• CISA, Cybersecurity Advisory AA23-059A (2023): „CISA Red Team Shares Key Findings to Improve Monitoring and Hardening of Networks“, cisa.gov.
• MITRE ATT&CK Enterprise: Techniken T1558.001 (Golden Ticket), T1558.003 (Kerberoasting), T1550.002 (Pass the Hash), T1557.001 (LLMNR/NBT-NS Poisoning), attack.mitre.org.
• Mandiant, M-Trends 2026: mediane Dwell Time 14 Tage.

Häufige Fragen zum Thema