Pentesting Active Directory: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Ein Active-Directory-Pentest ist kein loses Sammeln einzelner Schwachstellen. Entscheidend ist das Verständnis, wie Identitäten, Vertrauensstellungen, Berechtigungen, Protokolle und Betriebsprozesse zusammenwirken. In Windows-Umgebungen entsteht das eigentliche Risiko selten durch eine einzelne kritische Lücke. Meist ist es die Kombination aus schwacher Delegation, überprivilegierten Gruppen, wiederverwendeten Kennwörtern, unklaren ACLs, veralteten Protokollen und unzureichender Segmentierung. Genau daraus entstehen realistische Angriffspfade.

Wer AD testet, bewertet nicht nur Hosts, sondern vor allem Beziehungen: Benutzer zu Gruppen, Gruppen zu Rechten, Computer zu Diensten, Dienste zu Service-Accounts, Trusts zu anderen Domänen und administrative Pfade zu Tier-0-Systemen. Deshalb unterscheidet sich ein AD-Pentest deutlich von reinem Pentesting Netzwerk, klassischem Pentesting Endpoint oder isoliertem Pentesting Web. Die Domäne ist ein Identitäts- und Berechtigungsgraph, kein bloßes Serverinventar.

Ein sauberer Workflow beginnt mit Scope, Freigaben, Kommunikationswegen und klaren Grenzen. Danach folgt die technische Zieldefinition: Soll nur die Widerstandsfähigkeit gegen einen internen Angreifer geprüft werden? Geht es um die Ausnutzbarkeit mit Standardbenutzerrechten? Ist Domain-Admin das Ziel oder die Bewertung von Tier-0-Schutzmaßnahmen? Ohne diese Präzisierung entstehen unbrauchbare Ergebnisse, weil Findings zwar technisch korrekt, aber operativ wertlos sind.

In der Praxis ist es sinnvoll, AD-Pentests entlang realistischer Angreiferperspektiven aufzubauen. Ein externer Einstieg über Phishing oder Webanwendung ist etwas anderes als ein interner Test mit bereits vorhandenem Domänenkonto. Die Methodik muss dazu passen. Grundlagen zu Vorgehensmodellen finden sich auch bei Pentesting Methodik und Pentesting Ablauf, aber in AD zählt besonders die Fähigkeit, aus vielen kleinen Signalen einen belastbaren Angriffspfad abzuleiten.

Typische Fehler in frühen Phasen sind vorschnelles Exploit-Denken, zu aggressive Scans gegen Domain Controller, unvollständige Dokumentation von Credentials und fehlende Trennung zwischen Beobachtung und Ausnutzung. Wer sofort Passwortangriffe startet, ohne Passwort-Policy, Lockout-Verhalten, Monitoring und geschäftskritische Konten zu verstehen, produziert unnötiges Risiko. Ein professioneller Test priorisiert zunächst passive und protokollnahe Enumeration, bevor aktiv eingegriffen wird.

Ein weiterer Kernpunkt: Active Directory ist nie nur AD. DNS, SMB, RPC, LDAP, Kerberos, WinRM, Zertifikatsdienste, GPOs, lokale Administratorrechte, EDR-Ausnahmen und Backup-Infrastruktur greifen ineinander. Deshalb ist AD-Pentesting immer auch ein Test der It Security Sicherheitsarchitektur und der operativen It Security Im Unternehmen. Wer diese Zusammenhänge nicht bewertet, übersieht die Pfade, die Angreifer tatsächlich nutzen.

Vor dem ersten LDAP-Query muss feststehen, welche Domänen, Forests, Trusts, Netze und Systeme im Scope liegen. Gerade in gewachsenen Umgebungen existieren oft Legacy-Domänen, technische Service-Forests, Azure-AD-Connect-Server, PKI-Systeme, Jump Hosts und Management-Netze, die logisch zur Identitätsinfrastruktur gehören, aber organisatorisch getrennt verwaltet werden. Ein unklarer Scope führt fast immer zu zwei Problemen: kritische Pfade bleiben ungetestet oder sensible Systeme werden versehentlich belastet.

Besonders wichtig ist die Einordnung privilegierter Ebenen. Tier-0 umfasst Domain Controller, PKI, ADFS, Entra-Connect-ähnliche Synchronisationssysteme, privilegierte Verwaltungsserver, Backup-Systeme mit AD-Zugriff und oft auch Virtualisierungsplattformen. Wenn ein Test nur auf klassische Domain-Admin-Mitgliedschaften schaut, aber Hypervisor-Admins, Backup-Operatoren oder Identitäts-Sync-Konten ignoriert, wird das tatsächliche Risiko unterschätzt. In vielen Umgebungen ist der Weg zum Domänenkompromiss indirekt.

Zur Vorbereitung gehört auch die Definition sicherer Testgrenzen. Passwort-Spraying gegen produktive Konten, Kerberos-Preauth-Tests, SMB-Authentifizierungen oder RPC-Abfragen können Monitoring auslösen oder bei schlechter Konfiguration Kontensperrungen verursachen. Deshalb müssen Lockout-Schwellen, Servicefenster und Eskalationswege vorab bekannt sein. Das ist nicht nur eine Frage von Pentesting Legal, sondern professioneller Betriebssicherheit.

• Welche Konten dürfen aktiv getestet werden, und welche sind ausgeschlossen, etwa Break-Glass-, SAP-, Backup- oder Produktionsservice-Konten?
• Welche Systeme gelten als besonders sensibel, etwa Domain Controller, PKI, OT-nahe Server oder kritische Management-Hosts?
• Welche Aktionen sind erlaubt: reine Enumeration, Passwortangriffe, Ticket-Anfragen, Remote-Code-Ausführung, Persistenzsimulation oder nur Nachweisbarkeit?

Ein sauberer AD-Pentest dokumentiert außerdem die Ausgangsidentität exakt. Ein Standardbenutzer mit Mailbox, VPN-Zugang und Browser-Session ist ein anderes Startniveau als ein nacktes Domänenkonto ohne Endpunkt. Diese Ausgangslage bestimmt, welche Angriffsvektoren realistisch sind. In vielen Fällen ist die Kombination aus Benutzerkontext, lokaler Maschine und Netzwerkposition entscheidend. Deshalb überschneidet sich AD-Pentesting häufig mit Identity Security Active Directory, Identity Security Kerberos und Identity Security Ntlm.

Auch die Nachweisstrategie muss vorab festgelegt werden. Nicht jede Schwachstelle muss bis zum vollständigen Domänenkompromiss ausgereizt werden. In reifen Umgebungen reicht oft ein kontrollierter Beweis: lesbare LAPS-Passwörter, modifizierbare GPOs, DCSync-fähige Rechte oder ein erreichbarer Pfad in BloodHound. In anderen Fällen ist eine technische Demonstration notwendig, etwa das kontrollierte Auslesen eines Testkontos oder die Übernahme eines freigegebenen Zielsystems. Gute Vorbereitung verhindert unnötige Risiken und verbessert die Aussagekraft des Reports.

Die wichtigste Phase im AD-Pentest ist fast immer die Enumeration. Nicht weil sie spektakulär ist, sondern weil sie die Grundlage für alle späteren Entscheidungen liefert. Gute Enumeration beantwortet nicht nur, welche Hosts existieren, sondern welche Identitäten welche Rechte auf welche Objekte besitzen. LDAP ist dabei das zentrale Protokoll. Über LDAP lassen sich Benutzer, Gruppen, Computer, OUs, GPO-Verknüpfungen, SPNs, Delegationsattribute, ACL-relevante Informationen und Trust-Beziehungen erfassen.

DNS liefert zusätzliche Strukturinformationen: SRV-Records zeigen Domain Controller und Kerberos-Endpunkte, Namenskonventionen verraten Rollen, Subnetze und Standorte. SMB und RPC helfen bei der Einordnung erreichbarer Systeme, Shares, Sessions, lokalen Gruppen und Verwaltungsoberflächen. Gerade die Kombination aus LDAP-Daten und Host-Erreichbarkeit ist entscheidend. Ein theoretischer Pfad ist nur dann operativ relevant, wenn die beteiligten Systeme und Protokolle tatsächlich nutzbar sind.

Ein häufiger Anfängerfehler ist das blinde Vertrauen in Tool-Output. BloodHound, SharpHound, ldapsearch, PowerView oder netexec liefern wertvolle Daten, aber nur dann, wenn die Erhebung vollständig und korrekt interpretiert wird. Fehlende Knoten, unvollständige ACL-Erfassung, nicht aufgelöste SIDs oder veraltete Sessions können zu falschen Schlussfolgerungen führen. Ein professioneller Workflow validiert kritische Pfade manuell: Gruppenmitgliedschaften, effektive Rechte, AdminTo-Beziehungen, lokale Administratorgruppen, GPO-Vererbung und Delegationsattribute werden stichprobenartig geprüft.

Besonders relevant sind folgende Datenpunkte: SPNs für Service-Accounts, Benutzer ohne Kerberos-Preauth, Konten mit unconstrained oder constrained Delegation, Computer mit veralteten Betriebssystemen, Gruppen mit weitreichenden Rechten, ACLs auf OUs und GPOs, privilegierte Sitzungen auf Workstations und Servern sowie Trusts zwischen Domänen. Diese Informationen bilden den Rohstoff für spätere Angriffe wie Kerberoasting, AS-REP Roasting, ACL Abuse oder Lateral Movement.

Enumeration ist außerdem eng mit Netzsicht verbunden. Firewalls, Segmentierung und Namensauflösung bestimmen, welche Pfade praktisch nutzbar sind. Deshalb lohnt sich die Verbindung zu Netzwerksicherheit Analyse, Netzwerksicherheit Segmentierung und Security Monitoring Logs. Ein Pfad, der nur über WinRM erreichbar wäre, ist wertlos, wenn Management-Netze sauber getrennt sind. Umgekehrt wird ein vermeintlich harmloses Recht kritisch, wenn SMB, RPC und Admin-Shares breit offenstehen.

Ein praxistauglicher Ansatz ist, Enumeration in Schichten zu organisieren: zuerst Domänenstruktur und Identitäten, dann privilegierte Beziehungen, danach Host-Kontext und schließlich operative Validierung. So entsteht aus Rohdaten ein belastbares Lagebild statt einer unübersichtlichen Tool-Sammlung.

Beispielhafte Fragestellungen während der Enumeration:
- Welche Benutzer besitzen SPNs und sind damit potenzielle Kerberoasting-Ziele?
- Welche Gruppen haben WriteDACL, GenericAll oder AddMember auf privilegierte Objekte?
- Welche Computer erlauben lokale Administratorzugriffe für breit verteilte Gruppen?
- Wo existieren aktive Sitzungen privilegierter Konten?
- Welche Trusts erlauben Bewegungen über Domänengrenzen hinweg?

Viele AD-Angriffe wirken wie einzelne Techniken, sind aber in Wahrheit direkte Folgen des Authentifizierungsdesigns. Wer Kerberos und NTLM nicht versteht, erkennt weder die Angriffsmöglichkeiten noch die Grenzen sauber. Kerberos basiert auf Tickets, Schlüsseln und Vertrauensbeziehungen zwischen Client, KDC und Dienst. NTLM ist älter, challenge-response-basiert und in modernen Umgebungen oft noch aus Kompatibilitätsgründen vorhanden. Genau diese Koexistenz schafft Angriffsfläche.

Kerberoasting ist nur deshalb möglich, weil Service-Tickets für SPN-gebundene Dienste mit dem Schlüssel des Zielkontos verschlüsselt werden. Ein authentifizierter Benutzer kann ein Ticket für einen Dienst anfordern und offline angreifen. Das ist kein Exploit, sondern legitimes Protokollverhalten. Das Risiko hängt daher nicht primär am Ticket selbst, sondern an schwachen oder wiederverwendeten Kennwörtern von Service-Accounts. Ähnlich funktioniert AS-REP Roasting bei Benutzern ohne Preauthentication: Der KDC liefert Material, das offline geprüft werden kann.

NTLM wird relevant, wenn Relaying, Legacy-Protokolle, SMB-Signing-Lücken, WebDAV, Druckdienste oder unsaubere Serverkonfigurationen ins Spiel kommen. In internen Netzen ist NTLM oft der Brückenschlag zwischen Identität und Remote-Ausführung. Selbst wenn Kerberos bevorzugt wird, bleiben Fallbacks, lokale Konten, IP-basierte Zugriffe oder Dienste ohne SPN-Konfiguration problematisch. Deshalb muss ein AD-Pentest immer prüfen, wo NTLM noch praktisch nutzbar ist.

Ein häufiger Denkfehler ist die Gleichsetzung von erfolgreicher Authentifizierung und ausreichender Berechtigung. In AD sind Rechte granular verteilt. Ein Ticket oder Hash ist nur dann wertvoll, wenn daraus Zugriff auf Shares, Remote Management, LDAP-Objekte, lokale Administratorrechte oder Replikationsrechte entsteht. Gute Angreiferketten verbinden Authentifizierung mit Autorisierung. Genau dort liegen viele Fehlkonfigurationen: ein Service-Account mit schwachem Passwort, der gleichzeitig lokale Adminrechte auf mehreren Servern besitzt, ist wesentlich gefährlicher als ein isoliertes schwaches Konto.

Praktisch bedeutet das: Bei jedem gefundenen Credential-Material muss sofort die Frage folgen, welche Protokolle, Hosts und Rechte damit erreichbar sind. Das betrifft Kerberos-Tickets, NTLM-Hashes, Klartextkennwörter, DPAPI-Artefakte und gespeicherte Secrets gleichermaßen. Die technische Tiefe liegt nicht im Sammeln von Artefakten, sondern in der Bewertung ihrer operativen Verwendbarkeit.

• Kerberoasting ist vor allem ein Passwort- und Rollenproblem von Service-Accounts, nicht nur ein Kerberos-Problem.
• AS-REP Roasting zeigt meist schwache Kontohärtung und fehlende Kontrolle über Legacy-Einstellungen.
• NTLM-Relaying wird erst dann kritisch, wenn Signing, EPA, SMB-Härtung und Dienstkonfigurationen Lücken lassen.

Die Verteidigungsperspektive ist dabei ebenso relevant. Erkenntnisse aus einem AD-Pentest fließen direkt in Identity Security Monitoring, It Security Password Spraying und It Security Account Lockout ein. Ein guter Bericht erklärt nicht nur, dass ein Angriff möglich war, sondern warum die Protokoll- und Betriebsrealität ihn begünstigt hat.

Die meisten kritischen AD-Findings sind keine Zero-Days, sondern Betriebsfehler. Besonders häufig sind übersehene ACLs auf Benutzern, Gruppen, OUs und GPOs. Rechte wie GenericAll, GenericWrite, WriteOwner, WriteDACL, AddMember oder ForceChangePassword wirken auf den ersten Blick technisch abstrakt, sind aber oft direkter als klassische Exploits. Wer eine privilegierte Gruppe erweitern, ein Kennwort zurücksetzen oder eine GPO manipulieren kann, braucht keine Schwachstelle im engeren Sinn mehr.

Delegation ist ein weiteres Minenfeld. Unconstrained Delegation ist in modernen Umgebungen fast immer ein Hochrisiko-Finding, weil Ticket-Material auf kompromittierbaren Systemen landet. Constrained Delegation und Resource-Based Constrained Delegation sind nicht per se unsicher, werden aber häufig falsch verstanden und falsch delegiert. Sobald Schreibrechte auf Computerobjekte, SPNs oder msDS-AllowedToActOnBehalfOfOtherIdentity ins Spiel kommen, entstehen Pfade zur Rechteausweitung, die in vielen Betriebsdokumentationen gar nicht sichtbar sind.

GPOs werden oft unterschätzt. Eine modifizierbare GPO oder eine kontrollierbare Verknüpfung auf einer OU mit Servern oder Admin-Workstations ist praktisch ein Verteiler für Code, Konfiguration oder lokale Rechte. Besonders kritisch sind Startskripte, geplante Tasks, lokale Gruppenrichtlinien-Erweiterungen und Registry-basierte Einstellungen. In vielen Fällen ist eine GPO-Manipulation stabiler und unauffälliger als ein direkter Exploit auf einem einzelnen Host.

Service-Accounts sind ein Dauerproblem. Alte Kennwörter, fehlende Rotation, SPNs auf Benutzerkonten, lokale Adminrechte auf vielen Servern, interaktive Logons und unklare Eigentümerschaft machen sie zu idealen Zielen. Managed Service Accounts reduzieren Teile des Risikos, lösen aber nicht automatisch Berechtigungsprobleme. Entscheidend ist, welche Rechte das Konto tatsächlich besitzt und wo es verwendet wird.

Ein weiterer Klassiker sind falsch verteilte lokale Administratorrechte. Wenn Helpdesk-, Deployment- oder Monitoring-Konten auf vielen Servern lokale Adminrechte besitzen, entsteht ein breiter lateraler Pfad. Das gilt besonders dann, wenn dieselben Konten auf Admin-Workstations, Terminalservern und Applikationsservern genutzt werden. Solche Pfade sind oft wichtiger als einzelne Domain-Admin-Mitgliedschaften, weil sie operative Kontrolle über viele Systeme ermöglichen.

Viele dieser Themen überschneiden sich mit It Security Schwachstellen, It Security Typische Fehler und It Security Secure Configuration. Im AD-Kontext zählt jedoch weniger die abstrakte Kategorie als die konkrete Auswirkung: Kann ein Standardbenutzer daraus einen privilegierten Pfad bauen? Wenn ja, ist das Finding relevant, auch ohne CVE.

Beispiel für eine reale Kette:
1. Standardbenutzer liest per LDAP eine Gruppe mit WriteDACL auf eine Server-OU.
2. Über die OU ist eine GPO mit lokalen Administratorrechten auf Admin-Workstations verknüpft.
3. Die GPO kann angepasst werden, um ein Testkonto lokal zu privilegieren.
4. Auf einer betroffenen Workstation existiert eine aktive Sitzung eines Server-Admins.
5. Daraus entsteht Zugriff auf weitere Systeme und schließlich ein Pfad Richtung Tier 0.

Privilege Escalation in AD ist selten ein einzelner Sprung. Meist entsteht sie aus mehreren kleinen Übergängen: ein lesbares Secret, ein schwacher Service-Account, lokale Administratorrechte, eine privilegierte Session, ein modifizierbares Objekt, ein erreichbarer Management-Dienst. Lateral Movement ist dabei nicht nur Bewegung zwischen Hosts, sondern zwischen Sicherheitskontexten. Das Ziel ist nicht irgendein weiterer Server, sondern ein Kontext mit höherem Vertrauenswert.

Ein klassischer Weg beginnt mit einem Standardbenutzerkonto und Endpunktzugriff. Auf dem Endpunkt lassen sich lokale Gruppen, gespeicherte Credentials, Browser-Artefakte, DPAPI-geschützte Daten, geplante Tasks, Dienste und EDR-Ausnahmen prüfen. Daraus kann lokaler Adminzugriff entstehen. Mit lokalem Admin werden Sessions, Token, LSASS-nahe Artefakte oder Remote-Verwaltungswege relevant. Von dort aus geht es auf Server mit höherem Administrationswert, bis privilegierte Konten oder Replikationsrechte erreichbar sind.

Wichtig ist die Unterscheidung zwischen technischem Zugriff und nachhaltiger Kontrolle. Ein einmaliger Befehl auf einem Server ist weniger wert als ein belastbarer administrativer Pfad. Deshalb werden in professionellen Tests bevorzugt stabile Mechanismen bewertet: lokale Administratorgruppen, WinRM-Berechtigungen, PSRemoting, WMI, Scheduled Tasks, Dienste, Admin-Shares, GPO-gesteuerte Rechte und ACL-basierte Objektkontrolle. Diese Pfade sind reproduzierbar und im Bericht sauber belegbar.

Viele Teams machen den Fehler, Lateral Movement nur hostbasiert zu betrachten. In AD ist objektbasiertes Movement oft mächtiger. Wer ein Gruppenobjekt ändern, ein Computerkonto kontrollieren, ein Kennwort zurücksetzen oder eine Delegation konfigurieren kann, bewegt sich nicht nur seitlich, sondern strukturell. Solche Pfade sind oft langlebiger und schwerer zu erkennen als klassische Remote-Exec-Techniken.

Die Verbindung zu Endpunkten bleibt trotzdem zentral. Ohne Verständnis für Endpoint Security Windows, Endpoint Security Privilege Escalation und Endpoint Security Lateral Movement bleibt AD-Pentesting unvollständig. Viele Domänenkompromisse scheitern nicht an LDAP oder Kerberos, sondern an der Frage, ob auf einem konkreten Host tatsächlich ein verwertbarer Kontext erreichbar ist.

Ein sauberer Workflow priorisiert daher Pfade nach drei Kriterien: Wahrscheinlichkeit, Stabilität und Auswirkung. Ein exotischer Angriff mit hoher Komplexität ist weniger relevant als ein einfacher Pfad über falsch verteilte lokale Adminrechte und privilegierte Sessions. In echten Umgebungen gewinnen fast immer die einfachen, wiederholbaren Wege.

• Zuerst Pfade mit geringem Risiko und hoher Reproduzierbarkeit validieren, etwa lesbare Secrets, lokale Adminrechte oder ACL-Missbrauch.
• Danach privilegierte Sitzungen und Management-Protokolle prüfen, weil sie oft den schnellsten Übergang auf höherwertige Systeme ermöglichen.
• Erst anschließend invasive Schritte wie Passwortangriffe oder tiefere Host-Interaktion ausführen, wenn der Nutzen klar belegt ist.

Der häufigste Fehler ist Aktionismus. Viele Tests verlieren Qualität, weil zu früh auf Exploitation umgeschaltet wird. Ohne vollständige Enumeration werden Angriffswege übersehen, unnötige Risiken erzeugt und falsche Prioritäten gesetzt. Ein Passwort-Spray gegen die falsche Benutzergruppe ist nicht nur laut, sondern oft fachlich schwach, wenn gleichzeitig ACL-Missbrauch oder GPO-Kontrolle möglich gewesen wären.

Ein zweiter Fehler ist die unkritische Übernahme von Tool-Ergebnissen. BloodHound-Pfade, Session-Daten, lokale Admin-Beziehungen oder Delegationsinformationen sind nur so gut wie die Datenerhebung. Wenn EDR, Netzwerkfilter oder Berechtigungsgrenzen die Sammlung einschränken, entstehen Lücken. Wer diese Lücken nicht erkennt, schreibt Berichte mit scheinbarer Präzision, aber geringer Aussagekraft.

Ebenso problematisch ist fehlende Kontextbewertung. Nicht jede modifizierbare Gruppe ist kritisch, nicht jedes SPN-Konto ist relevant und nicht jede NTLM-Möglichkeit ist praktisch ausnutzbar. Entscheidend ist, ob daraus ein realistischer Pfad zu höherwertigen Rechten entsteht. Gute Pentests priorisieren Findings nach Angriffswert, nicht nach Schlagworten.

Ein weiterer Fehler liegt in unsauberem Credential-Handling. Zugangsdaten, Hashes, Tickets und Secrets müssen exakt dokumentiert, getrennt gespeichert und ihrer Herkunft zugeordnet werden. Sonst ist später nicht mehr nachvollziehbar, welcher Pfad tatsächlich funktioniert hat. Das schwächt nicht nur das Reporting, sondern kann auch zu unbeabsichtigter Nutzung falscher Konten führen.

Auch die technische Hygiene zählt. Zu aggressive LDAP-Abfragen, massenhafte SMB-Verbindungen, unkontrollierte SharpHound-Sammlungen oder parallele Remote-Exec-Versuche können Monitoring triggern, Systeme belasten oder Artefakte hinterlassen, die den Test verfälschen. Wer professionell arbeitet, kennt die Unterschiede zwischen Datensammlung, Validierung und Ausnutzung und setzt jede Phase kontrolliert ein.

Schließlich wird oft die Verteidigungsperspektive vernachlässigt. Ein AD-Pentest ist nicht vollständig, wenn nur der Angriffsweg beschrieben wird. Ebenso wichtig ist, welche Logs, Events, Telemetrie und Kontrollen den Pfad hätten erkennen oder stoppen können. Diese Sicht verbindet den Test mit Security Monitoring Detection, It Security Detection Engineering und Pentesting Reporting. Nur so wird aus einem technischen Befund eine belastbare Sicherheitsbewertung.

Ein technisch starker AD-Pentest scheitert oft an schwacher Nachweisführung. Gerade in komplexen Domänen reicht es nicht, einzelne Screenshots oder Tool-Ausgaben zu sammeln. Jeder relevante Befund braucht eine klare Beweiskette: Ausgangskontext, beobachtete Konfiguration, durchgeführte Validierung, Ergebnis und Auswirkung. Nur so lässt sich später nachvollziehen, warum ein Pfad realistisch war und welche Gegenmaßnahmen ihn unterbrechen würden.

Für jeden Angriffspfad sollte dokumentiert werden, mit welchem Konto gestartet wurde, welche Informationen per LDAP oder Host-Enumeration gewonnen wurden, welche Rechte daraus abgeleitet wurden und wie die Validierung erfolgte. Wenn etwa ein Benutzer WriteDACL auf eine Gruppe besitzt, reicht ein Screenshot des ACL-Eintrags nicht aus. Benötigt wird die nachvollziehbare Verbindung zur Auswirkung: Welche Gruppe ist betroffen, welche Systeme oder Rollen hängen daran, und wie wurde die Änderbarkeit kontrolliert nachgewiesen?

Besonders wichtig ist die Trennung zwischen Beobachtung und Ausnutzung. Ein lesbares LAPS-Passwort, ein DCSync-fähiges Recht oder eine modifizierbare GPO sind bereits starke Findings. Nicht immer ist eine vollständige Ausnutzung nötig. In produktiven Umgebungen ist es oft besser, die technische Möglichkeit kontrolliert zu belegen, statt maximalen Zugriff zu demonstrieren. Das erhöht die Sicherheit des Tests und verbessert die Akzeptanz der Ergebnisse.

Auch Befehle und Tool-Versionen gehören in die Dokumentation. Unterschiedliche Versionen von Sammlern, PowerShell-Modulen oder Remote-Exec-Werkzeugen können zu abweichenden Ergebnissen führen. Wer reproduzierbar arbeiten will, dokumentiert die genaue Ausführung, Parameter, Zeitpunkte und Zielsysteme. Das ist besonders relevant, wenn Findings später durch interne Teams nachgestellt oder in Compliance Dokumentation und Compliance Audits überführt werden.

Beispiel für eine saubere Beweiskette:
- Startkonto: user01@corp.local
- Quelle: LDAP-Abfrage auf Gruppen-ACLs
- Beobachtung: user01 besitzt AddMember auf Gruppe "Server-Admins-Test"
- Validierung: kontrolliertes Hinzufügen eines freigegebenen Testkontos
- Auswirkung: Testkonto erhält lokale Adminrechte auf 14 Servern laut Gruppenrichtlinie
- Nachweis: Gruppenmitgliedschaft, GPO-Zuordnung, Host-Validierung auf freigegebenem Zielserver
- Rückbau: Testkonto aus Gruppe entfernt, Zeitstempel dokumentiert

Gute Nachweisführung reduziert Diskussionen. Statt abstrakter Aussagen wie „Privilege Escalation möglich“ entsteht ein klarer, reproduzierbarer Pfad. Genau das trennt belastbare Pentest-Arbeit von bloßer Tool-Bedienung.

Ein AD-Report muss mehr leisten als eine Liste technischer Findings. Entscheidend ist die Darstellung von Angriffspfaden, Abhängigkeiten und Prioritäten. Ein einzelnes schwaches Service-Konto ist möglicherweise nur mittel relevant. Wenn dieses Konto aber lokale Adminrechte auf Management-Servern besitzt und dort privilegierte Sitzungen auftreten, wird daraus ein Hochrisiko-Pfad. Gute Berichte zeigen genau diese Ketten.

Die Priorisierung sollte sich an realer Ausnutzbarkeit orientieren: Startvoraussetzungen, notwendige Zwischenschritte, technische Komplexität, Sichtbarkeit im Monitoring und erreichter Zielwert. Ein Pfad von Standardbenutzer zu Tier 0 über zwei reproduzierbare Schritte ist kritischer als ein theoretischer Angriff mit vielen Annahmen. Ebenso wichtig ist die Trennung zwischen strukturellen Problemen und Einzelfehlern. Eine einzelne falsch gesetzte ACL ist anders zu behandeln als ein generelles Fehlen von Tiering oder ein breites Problem mit Service-Accounts.

Empfehlungen müssen konkret und umsetzbar sein. „Berechtigungen härten“ ist wertlos. Besser ist: Schreibrechte auf bestimmte OUs entfernen, GPO-Besitzverhältnisse bereinigen, Service-Accounts auf gMSA umstellen, lokale Administratorgruppen zentral reduzieren, NTLM auf definierten Pfaden einschränken, privilegierte Sitzungen auf Admin-Workstations begrenzen und Replikationsrechte auf Domain-Ebene überprüfen. Solche Maßnahmen sind technisch anschlussfähig und operativ verständlich.

Ein starker Bericht beschreibt außerdem, welche Kontrollen gefehlt haben. Wurde Kerberoasting nicht erkannt? Gab es keine Warnung bei Gruppenänderungen? Wurden verdächtige LDAP-Abfragen, Ticket-Anfragen oder WinRM-Nutzung nicht korreliert? Diese Erkenntnisse verbinden den Pentest mit Security Monitoring Use Cases, It Security Log Correlation und Defense Playbooks.

Für Management und Technik sollten unterschiedliche Ebenen sauber zusammengeführt werden. Die Management-Sicht braucht Geschäftsrisiko, betroffene Schutzziele und Prioritäten. Die technische Sicht braucht präzise Pfade, Belege, betroffene Objekte und konkrete Remediation-Schritte. In regulierten Umgebungen ist zusätzlich die Verbindung zu It Security Compliance und Compliance Risikoanalyse relevant, weil Identitäts- und Berechtigungsfehler oft direkte Audit-Relevanz haben.

Ein guter AD-Report endet nicht bei „Domain Admin erreicht“. Er zeigt, warum das möglich war, welche Kontrollen versagt haben, welche Maßnahmen den Pfad unterbrechen und welche strukturellen Themen zuerst angegangen werden müssen. Genau daraus entsteht echter Sicherheitsgewinn.

Ein robuster AD-Workflow ist iterativ. Zuerst wird das Umfeld verstanden, dann werden Hypothesen gebildet, anschließend kontrolliert validiert und zuletzt sauber dokumentiert. Diese Reihenfolge verhindert blinde Flecken. In der Praxis hat sich bewährt, jede Phase mit einer klaren Fragestellung zu verbinden: Welche Identitäten existieren? Welche Rechte sind auffällig? Welche Hosts sind relevant? Welche Pfade sind praktisch nutzbar? Welche Nachweise genügen, ohne unnötig invasiv zu werden?

Die erste Iteration konzentriert sich auf Domänenstruktur, Benutzer, Gruppen, Computer, SPNs, Trusts, OUs und GPOs. Die zweite Iteration bewertet privilegierte Beziehungen, ACLs, Delegation, lokale Administratorrechte und Sessions. Die dritte Iteration validiert priorisierte Pfade auf freigegebenen Zielsystemen. Danach folgt die Rückkopplung: Neue Credentials oder Rechte führen zurück in die Enumeration, weil sich das Lagebild mit jedem Kontextwechsel verändert.

Wichtig ist die konsequente Trennung von Datensammlung und Interpretation. Rohdaten allein sind wertlos, wenn daraus keine belastbaren Pfade abgeleitet werden. Umgekehrt sind Hypothesen gefährlich, wenn sie nicht validiert werden. Ein professioneller Test arbeitet deshalb mit einem lebenden Angriffsgraphen: Jede neue Information wird daraufhin geprüft, ob sie bestehende Pfade verkürzt, neue Ziele öffnet oder bisherige Annahmen widerlegt.

Auch die Zusammenarbeit mit Verteidigungsteams kann sinnvoll sein, insbesondere in Purple-Team-nahen Formaten. Wenn bestimmte Erkennungsregeln, Event-IDs oder EDR-Signale mitgeprüft werden sollen, lässt sich der Test gezielt mit Pentesting Purple Team, It Security Blue Team Operations und Defense Incident Response verzahnen. Das ändert nicht die Angriffslogik, erhöht aber den praktischen Nutzen erheblich.

Ein wiederholbarer Workflow zeichnet sich außerdem durch sauberen Rückbau aus. Testkonten aus Gruppen entfernen, geänderte ACLs zurücksetzen, erzeugte Tasks löschen, temporäre Dateien entfernen und Zeitpunkte dokumentieren. Gerade in AD-Umgebungen können kleine Änderungen große Wirkung haben. Rückbau ist daher kein Nebenthema, sondern Teil professioneller Qualität.

Wer AD-Pentests regelmäßig durchführt, erkennt mit der Zeit ein Muster: Nicht die exotischen Techniken dominieren, sondern die wiederkehrenden Betriebsfehler. Deshalb ist ein guter Workflow nicht auf Showeffekte ausgelegt, sondern auf belastbare, reproduzierbare Ergebnisse mit klarer Priorisierung und sauberem Nachweis.