Kerberos, ACLs,ADCSund was dahinter steckt.

Wir prüfen auf AS-REP-Roastable-Accounts ohne Kerberos-Vorauthentisierung und auf kerberoastbare Dienstkonten: Jedes Konto mit einem Service Principal Name gibt jedem Domänennutzer ein Ticket heraus, das offline gegen Wortlisten gerechnet werden kann. Entscheidend ist nicht die Zahl der geknackten Passwörter, sondern welche Rechte an den Konten hängen. Dazu kommen die drei Delegierungsvarianten: unconstrained Delegation auf Nicht-Domain-Controllern, constrained Delegation mit Protocol Transition und Resource-Based Constrained Delegation, die sich über ein einziges Schreibrecht auf ein Computerobjekt nachträglich einrichten lässt. Aus den Beziehungen entsteht ein BloodHound-Graph, in dem wir den kürzesten Weg vom Standardnutzer zu Tier-0 zeigen – als nachvollzogene Kette, nicht als Theorie.

Active Directory Certificate Services ist der unterschätzteste Teil jeder AD-Umgebung – wegen einer Eigenschaft, die keine andere Schwachstelle hat: Ein ausgestelltes Zertifikat überlebt das Zurücksetzen des Passworts. Wir prüfen die bekannten Fehlkonfigurationen vollständig: Vorlagen, bei denen der Antragsteller den Subject Alternative Name selbst wählt (ESC1), Vorlagen mit „Any Purpose“-EKU oder ganz ohne EKU (ESC2) und Enrollment-Agent-Vorlagen (ESC3), zu weite Berechtigungen auf Vorlagen und PKI-Objekten (ESC4, ESC5), das Flag EDITF_ATTRIBUTESUBJECTALTNAME2 (ESC6), missbrauchbare CA-Rollen (ESC7), Relay auf Web-Enrollment (ESC8) und RPC-Endpunkt (ESC11), den mit Shell-Zugriff auf der CA nutzbaren HSM-Schlüssel (ESC12), schwache Zertifikatszuordnung (ESC9, ESC10, ESC14), Ausstellungs- und Anwendungsrichtlinien (ESC13, ESC15), eine CA, die die SID-Sicherheitserweiterung global abschaltet und damit jedes ausgestellte Zertifikat auf die schwache Zuordnung zurückfallen lässt (ESC16), und Vorlagen für Serverauthentisierung, bei denen der Antragsteller den Namen selbst setzt und so einen Server wie WSUS übernimmt (ESC17). Häufig genügt eine einzige Vorlage, damit jeder authentisierte Nutzer die Domäne übernimmt.

Wir bewerten das Tier-Modell: Wer darf Tier-0-Objekte verwalten, welche Gruppenrichtlinien hängen an der Domain-Controller-OU, welche Berechtigungskette führt aus Tier 2 dorthin? Gemeint sind die Rechte, die in keiner Gruppenmitgliedschaft auftauchen: GenericAll und WriteDACL auf privilegierten Gruppen, WriteOwner auf Administratorkonten, ForceChangePassword, Schreibrechte auf Computerobjekte, delegierte Organisationseinheiten. Dazu analysieren wir DCSync-Rechte außerhalb der Domain Controller, AdminSDHolder-Anomalien, SID-History aus alten Migrationen, die Nutzung der Gruppe „Geschützte Benutzer“ und die Leserechte auf gMSA-Passwörter und LAPS-Attribute: Wer ein LAPS-Passwort lesen darf, ist lokaler Administrator – ganz gleich, in welcher Gruppe er steht.

Bevor ein Pfad interessant wird, prüfen wir, was die Domäne grundsätzlich erlaubt: Funktionsebenen und Vertrauensstellungen mit Richtung, Transitivität und SID-Filterung – ein vertrauter Forest ist Teil Ihrer Angriffsfläche, auch wenn ihn jemand anderes betreibt –, die Passwortrichtlinie samt Fine-Grained Password Policies, das Machine Account Quota und Reste von „Pre-Windows 2000 Compatible Access“. Ob LDAP-Signing, Channel Binding und SMB-Signing erzwungen werden, entscheidet darüber, ob ein abgefangener Authentisierungsversuch weitergereicht wird oder ins Leere läuft. Dazu kommen Härtungslücken aus Gruppenrichtlinien – WDigest, AlwaysInstallElevated, Point-and-Print ohne Signaturpflicht –, der Patch-Stand der Domain Controller mit Blick auf Zerologon und PrintNightmare sowie Systeme ohne Sicherheitsupdates in der Domäne.

Wir durchsuchen SYSVOL nach Gruppenrichtlinien mit cpassword und nach Anmeldeskripten mit hinterlegten Konten, das Verzeichnis selbst nach Beschreibungsfeldern, in denen ein Passwort als Notiz steht. Wir bestimmen die tatsächliche LAPS-Abdeckung – nicht, ob LAPS ausgerollt ist, sondern welche Computerobjekte kein verwaltetes Administratorpasswort haben – und wer BitLocker-Wiederherstellungsschlüssel lesen darf. Schließlich prüfen wir die Dienste mit historisch weitreichenden Rechten im Verzeichnis: Exchange mit seinen gewachsenen Berechtigungen, SCCM mit Site-Servern, Netzwerkzugriffskonten und Client-Push sowie SCOM, dessen Verwaltungsserver Code auf Clients verteilt.

adPEAS ist ein PowerShell-Werkzeug, mit dem ein Teil der AD-Pentesting-Welt den ersten Enumerationslauf fährt. Geschrieben und gepflegt wird es bei SEKurity, von Alexander Sturz, einem der drei Geschäftsführer. Es deckt neun Prüfkategorien ab, von Domänenkonfiguration, Berechtigungen und Delegierung über ADCS und Gruppenrichtlinien bis zu Exchange, SCCM und SCOM, sammelt Daten für BloodHound CE und bringt einen Kerberos-Stack mit, der AS-REQ/AS-REP, TGS, PKINIT und Pass-the-Ticket vollständig in PowerShell implementiert. Ein OPSEC-Modus lässt die aktiven Tests aus. Für Ihren Test heißt das: Wer ein solches Werkzeug schreibt – in reinem PowerShell, ohne Fremdabhängigkeiten, lauffähig in jeder Windows-Umgebung und über jede Anmeldeart hinweg, vom Passwort bis zum Zertifikat –, kennt die Protokolle darunter und nicht nur die Ausgabe eines Scanners.

• adPEAS auf GitHub

  Quellcode, Dokumentation und Issue-Tracker – jede Angabe oben lässt sich dort nachlesen. Bei ADCS prüft das Werkzeug die Vorlagen- und Enrollment-Pfade: ESC1 bis ESC5, ESC8, ESC9, ESC13 bis ESC15 und ESC10 über die Gruppenrichtlinien-Prüfung.

• blog.sekurity.de: adPEAS v2 im Detail

  Die technische Serie zur zweiten Version: Architektur, Authentisierung, der Kerberos-Stack und die Datensammlung, Schritt für Schritt erklärt. Wer wissen will, wie tief das Verständnis hinter einem Befund reicht, liest dort nach.

Der Ablauf ist bei jedem AD-Test derselbe; was sich unterscheidet, ist der Umfang. Vorab halten wir schriftlich fest, welche Domänen in Scope sind, mit welchem Konto wir starten und welche Änderungen wir am Verzeichnis vornehmen dürfen. Kritische Findings melden wir sofort: Ein offener Weg vom Standardnutzer zum Domain-Admin ist kein Berichtspunkt, sondern ein Anruf.

1. 01

   Scoping & Freigabe

   Wir legen gemeinsam fest, welche Domänen, Forests und Vertrauensstellungen geprüft werden, ob ADCS und das Tier-0-Containment dazugehören und wer im Eskalationsfall erreichbar ist. Das Ergebnis ist eine schriftliche Testfreigabe samt Liste der erlaubten Aktionen und ihres Rückbaus.

2. 02

   Ausgangsposition

   Der Regelfall ist ein unprivilegiertes Domänenkonto, eigens für den Test angelegt, dazu ein Netzzugang über einen verwalteten Client, einen Jump-Host oder VPN. Auf Wunsch beginnen wir ohne Zugangsdaten und zeigen, was ein Angreifer im Netz erreicht, bevor er ein Konto hat.

3. 03

   Enumeration

   Zuerst wird nur gelesen: Domänenkonfiguration, Trusts, Richtlinien, Konten und Gruppen, Berechtigungen, Delegierungen, Zertifikatsvorlagen, Gruppenrichtlinien, LAPS-Abdeckung. Daraus entsteht der Graph der möglichen Pfade; ausgenutzt oder verändert wird nichts.

4. 04

   Verifikation der Pfade

   Die Pfade aus dem Graphen werden manuell und kontrolliert nachvollzogen: Tickets offline gerechnet, DCSync über die Berechtigung belegt, Zertifikate gegen eine abgestimmte Vorlage beantragt. Jede aktive Handlung wird mit Zeitstempel protokolliert – Ihr SOC kann sie zuordnen.

5. 05

   Bericht & Abschlussgespräch

   Sie erhalten einen Bericht mit Management Summary und technischem Teil, je Finding mit Reproduktion, Nachweis, Bewertung und Empfehlung. Anschließend priorisieren wir gemeinsam; ein Nachtest wird im Angebot separat ausgewiesen.

Auch auf dieser Seite stehen bewusst keine Tagessätze, Personentage oder Preisspannen: Ein AD-Test richtet sich nach der Umgebung, die Sie betreiben, und die lässt sich von außen nicht abschätzen. Statt einer Zahl, die für die eine Hälfte der Anfragen zu hoch und für die andere zu niedrig wäre, legen wir offen, was den Aufwand treibt.

• Domänen, Forests und Trusts

  Eine einzelne Domäne ist ein anderes Projekt als ein gewachsener Forest mit Ressourcendomänen und Vertrauensstellungen zu Konzerngesellschaften oder Dienstleistern. Jede Vertrauensstellung ist ein eigener Prüfpunkt: Über sie wandern Rechte in ungewollte Richtungen.

• Zahl der Benutzer- und Computerobjekte

  Die Objektzahl bestimmt die Größe des Berechtigungsgraphen und damit den Aufwand der manuellen Verifikation. Ein paar hundert Konten lassen sich vollständig nachvollziehen; bei zehntausenden Konten und hunderten Gruppenrichtlinien liegt die Arbeit im Aussortieren der nur theoretischen Pfade.

• ADCS in Scope oder nicht

  Eine AD-integrierte PKI ist eine eigene Prüffläche: Jede Zertifizierungsstelle, jede Vorlage und jeder Enrollment-Endpunkt wird einzeln bewertet. Haben Sie keine, entfällt der Abschnitt; bei mehreren CAs mit gewachsenen Vorlagen ist er der größte Einzelposten.

• Tier-0-Containment

  Ob wir nur Pfade suchen oder zusätzlich Ihr Administrationsmodell bewerten, ist eine Umfangsentscheidung. Die zweite Variante prüft Kontentrennung, privilegierte Arbeitsplätze, Anmeldebeschränkungen und die Frage, ob ein kompromittierter Client an Tier-0-Anmeldedaten kommt.

• On-Prem oder hybrid mit Entra ID

  Mit Entra ID hängt an Ihrer Domäne eine zweite Identitätswelt: Synchronisationsserver und Synchronisationskonten, das Anmeldeverfahren – Password Hash Sync, Pass-through-Authentifizierung oder Föderation –, Seamless SSO und die Frage, ob ein lokaler Administrator in der Cloud Rechte erbt.

Wie Sie zu einer belastbaren Zahl kommen.

In einem Scoping-Gespräch klären wir die fünf Punkte oben; dafür genügen meist die Zahl der Domänen, eine grobe Objektzahl und die Auskunft, ob ADCS und Entra ID dazugehören. Daraus erhalten Sie ein schriftliches Angebot mit festem Umfang, festem Preis und verbindlichem Zeitfenster – kostenfrei und unverbindlich.

Wir arbeiten nicht nach einer Hausmethode, die niemand außer uns kennt. Die Prüfung folgt öffentlich dokumentierten Referenzen: dem Katalog der Angriffstechniken, dem Zugriffsmodell des Herstellers und dem Leitfaden, an dem sich deutsche Prüfer orientieren.

• MITRE ATT&CK Enterprise

  Der Katalog dokumentierter Angreifertechniken, auf den wir jedes Finding abbilden – für Active Directory unter anderem Kerberoasting, DCSync und Delegierungsmissbrauch. So kann Ihr SOC seine Erkennung gegen genau die Techniken prüfen, die bei Ihnen funktioniert haben.

• Microsoft: Enterprise Access Model

  Das Referenzmodell des Herstellers für privilegierten Zugriff, Nachfolger des klassischen Tier-Modells. Es definiert, was Tier 0 umfasst, und liefert den Maßstab, gegen den wir Kontentrennung und Containment bewerten – statt gegen unsere eigene Meinung.

• BSI: Praxis-Leitfaden IS-Penetrationstest

  Der Leitfaden des Bundesamts für Sicherheit in der Informationstechnik, samt Klassifizierung nach Informationsbasis und Aggressivität. Die übliche Referenz, wenn ein deutscher Prüfer oder eine Behörde wissen will, wonach getestet wurde.