adPEAS v2 Episode 9: Tips & Tricks - Die versteckten Werkzeuge in adPEAS
Versteckte Produktivitäts-Booster in adPEAS v2: Show-Object, KnownSPN-Discovery, gefährliche ACL-Analyse, EPA-Testing, Account-Activity-Filter, Zertifikatsanalyse und mehr.
Einleitung
In den bisherigen Episoden ging es um den automatischen Scan, die Security Checks, die Reports und die offensiven Operationen. Aber adPEAS hat noch eine Seite, die man gerne übersehen kann: Die vielen kleinen Helfer, die im täglichen Pentest-Alltag enorm Zeit sparen.
Dieser Post zeigt Funktionen und Parameter, deren Benutzung man nicht direkt sieht, die aber für die manuelle Analyse Gold wert sind. Keine davon braucht externe Tools — alles ist in adPEAS enthalten.
Voraussetzung: Eine aktive adPEAS-Session:
Import-Module .\adPEAS.ps1
Connect-adPEAS -Domain "contoso.com" -UseWindowsAuthReconnaissance & Enumeration
AD-Objekte auf einen Blick verstehen mit Show-Object
Wer einen User oder Computer mit Get-DomainUser abfragt, wird von Attributen erschlagen - dutzende Properties, die meisten davon uninteressant. Show-Object filtert das Rauschen raus und zeigt dir farbkodiert nur die sicherheitsrelevanten Attribute:
Get-DomainUser -Identity f.sinatra | Show-ObjectdisplayName: Frank Sinatra
sAMAccountName: f.sinatra
userPrincipalName: f.sinatra@contoso.com
distinguishedName: CN=Frank Sinatra,OU=Users,OU=Domain User,DC=contoso,DC=com
objectSid: S-1-5-21-1234567890-1234567890-1234567890-1157
[+] memberOf: TerminalServerUsers
LAPSReader
ClientAdmins
ServerAdmins
Server-Operatoren
description: User Help Desk
[+] msDS-KeyCredentialLink: DeviceID: 617b9d6fa7b5204c8fa049bebf9da5eb | Created: 2026-02-19 11:20
[+] userAccountControl: NORMAL_ACCOUNT
DONT_EXPIRE_PASSWORD
[+] pwdLastSet: 04/12/2022 11:39:08
lastLogonTimestamp: 02/19/2026 10:34:36
[+] admincount: 1Die [+]-Markierungen (gelb) heben Attribute hervor, die für einen Pentester sofort relevant sind: Gruppenmitgliedschaften, Shadow Credentials, UAC-Flags wie DONT_EXPIRE_PASSWORD, veraltete Passwörter, und admincount: 1 als Indikator für privilegierte Accounts.
Funktioniert identisch für Computer:
Get-DomainComputer -Identity DC01 | Show-ObjectStatt sich durch rohes LDAP-Output zu wühlen, hat man in Sekunden den Überblick - welche Attribute sind gesetzt, welche davon sind interessant, und wo lohnt sich ein genauerer Blick.
High-Value Targets finden mit einem Parameter
Jeder Pentest beginnt mit der Frage: Wo sind die interessanten Systeme? Normalerweise heisst das: LDAP-Filter bauen, SPNs parsen, Output filtern. Oder man benutzt einfach -KnownSPN:
# Alle SQL-Server im AD
Get-DomainComputer -KnownSPN MSSQL
# Alle Exchange-Server
Get-DomainComputer -KnownSPN Exchange
# Alle ADCS Certificate Authorities
Get-DomainComputer -KnownSPN CADas Schöne daran: adPEAS kennt die SPN-Patterns für jeden Service-Typ. MSSQL matcht MSSQLSvc/*, Exchange matcht exchangeMDB/*, exchangeRFR/* und exchangeAB/*, CA matcht certsvc/*. Man muss die SPN-Syntax nicht kennen - einfach den Service-Namen angeben.
Die unterstützten Service-Typen:
| Parameter | SPN-Pattern | Typisches Ziel |
|---|---|---|
MSSQL | MSSQLSvc/* | SQL Server |
Exchange | exchangeMDB/*, exchangeRFR/*, exchangeAB/* | Exchange Server |
SCCM | SMS Site Server/*, CmRcService/* | SCCM/MECM |
WSUS | wsusService/*, WSUS/* | Windows Update Services |
ADFS | adfssrv/* | Federation Services |
CA | certsvc/* | Certificate Authorities |
SCOM | MSOMHSvc/*, MSOMSdkSvc/* | System Center Operations Manager |
Backup | wbengine/*, veeam* | Backup-Server |
HyperV | Microsoft Virtual Console Service/*, vmms/* | Hyper-V Hosts |
RDP | TERMSRV/* | Remote Desktop |
WinRM | WSMAN/* | WinRM/PSRemoting |
HTTP | HTTP/* | Web-Services |
FTP | FTP/* | FTP-Server |
GPO-Wirkungsbereich aufdecken
GPOs sind einer der möglichen Angriffsvektoren in AD. Aber zu wissen welche GPOs existieren ist nur die halbe Miete — man muss wissen, wo sie wirken:
# Welche GPOs wirken auf die Finance-OU?
Get-DomainGPO -AppliedToOU "OU=Finance,DC=contoso,DC=com"Das beantwortet die Frage: Wenn ich ein GPO editieren kann, welche Systeme sind betroffen? Oder umgekehrt: Welche GPOs beeinflussen einen bestimmten Bereich der AD-Struktur?
ADCS Templates auf einen Blick
ADCS-Schwachstellen (ESC1-ESC15) sind seit 2021 einer der beliebtesten Privilege-Escalation-Pfade. adPEAS macht das Suchen nach verwundbaren Templates einfach:
# ESC1: Templates die beliebige Subject Names erlauben + Client Auth haben
Get-CertificateTemplate -EnrolleeSuppliesSubject -ClientAuthentication
# Templates ohne Manager-Approval (schnellere Ausnutzung)
Get-CertificateTemplate -NoManagerApprovalDie Filter sind kombinierbar. -EnrolleeSuppliesSubject -ClientAuthentication findet Templates die beide Bedingungen erfüllen — genau das was für ESC1 benötigt wird. Ohne adPEAS müsste man die msPKI-Certificate-Name-Flag und pKIExtendedKeyUsage Attribute manuell parsen.
Access Control Analysis
Dangerous ACLs finden
ACL-Analyse ist normalerweise mühsam. Get-ObjectACL nimmt den Schmerz:
# Alle gefährlichen Berechtigungen auf privilegierte Objekte
Get-DomainUser -AdminCount | Get-ObjectACL -DangerousOnly-DangerousOnly filtert auf die ACEs die tatsächlich für Angriffe relevant sind: GenericAll, GenericWrite, WriteDacl, WriteOwner und kritische ExtendedRights. Alles andere — die hunderten “Read Property” und “List Contents” ACEs die jede Analyse zumüllen — wird ignoriert.
Das funktioniert auch mit Computern, Gruppen und GPOs:
# Wer kann GPOs editieren?
Get-DomainGPO | Get-ObjectACL -DangerousOnly
# Wer hat Rechte auf den Domain Root?
Get-ObjectACL -Identity "DC=contoso,DC=com" -DangerousOnlyIdentitäten klassifizieren
Wer ist eigentlich privilegiert? Die Frage klingt einfach, ist es aber nicht. Domain Admins — klar. Aber was ist mit Account Operators? Server Operators? DnsAdmins? Exchange Windows Permissions?
$result = Test-IsPrivileged -Identity "S-1-5-21-3623811015-12345-512"
$result.IsPrivileged # $true
$result.Category # "Privileged"
$result.Reason # "Privileged group (RID suffix -512)"Test-IsPrivileged klassifiziert SIDs in fünf Kategorien: Privileged, Operator, BroadGroup, ExchangeService und Standard. Dabei prüft die Funktion nicht nur die SID selbst gegen bekannte privilegierte SIDs und RID-Suffixe, sondern löst auch rekursiv alle Gruppenmitgliedschaften auf — mit einem einzigen LDAP-Query über LDAP_MATCHING_RULE_IN_CHAIN. Ein User der in einer Gruppe ist, die in einer Gruppe ist, die in Domain Admins ist, wird also korrekt als Privileged erkannt. Zusätzlich prüft die Funktion das sIDHistory-Attribut auf privilegierte SIDs — ein Klassiker für SID History Injection.
Kerberos Toolbox
Fünf Auth-Methoden, eine Funktion
Invoke-KerberosAuth ist das Schweizer Taschenmesser für Kerberos-Authentifizierung. Fünf verschiedene Methoden, eine einheitliche API:
# Passwort-basiert (AES256)
Invoke-KerberosAuth -UserName "admin" -Domain "contoso.com" -Password "P@ssw0rd"
# Overpass-the-Hash (NT-Hash → RC4 TGT)
Invoke-KerberosAuth -UserName "admin" -Domain "contoso.com" -NTHash "A1B2C3D4E5F6..."
# Pass-the-Key (AES256)
Invoke-KerberosAuth -UserName "admin" -Domain "contoso.com" -AES256Key "4a3b2c1d5e6f..."
# Pass-the-Key (AES128)
Invoke-KerberosAuth -UserName "admin" -Domain "contoso.com" -AES128Key "4a3b2c1d..."
# PKINIT (Zertifikat-basiert)
Invoke-KerberosAuth -UserName "admin" -Domain "contoso.com" -Certificate "user.pfx"Zwei besonders nützliche Parameter:
-OutputKirbi "tgt.kirbi"— Speichert das TGT direkt als .kirbi-Datei. Kein manuelles Base64-Dekodieren, kein Byte-Array-Handling. Einfach Dateiname angeben.
Network & Lateral Movement
Admin-Zugriff testen — parallel
Nach der Enumeration die nächste Frage: Auf welchen Systemen habe ich Admin-Rechte? Das manuell zu testen dauert ewig, besonders in großen Umgebungen. Test-RemoteAdminAccess löst das mit paralleler Ausführung:
# Alle Server testen - 32 gleichzeitig (Default)
Get-DomainComputer -OperatingSystem "*Server*" | Select-Object -ExpandProperty dNSHostName | Test-RemoteAdminAccessDie Funktion testet standardmäßig über SMB (ADMIN$-Share). Wenn SMB blockiert ist, fällt sie automatisch auf WMI zurück. Mit -Method kann man die Methode erzwingen:
# Nur SMB (kein WMI-Fallback)
Test-RemoteAdminAccess -ComputerName "SERVER01" -Method SMB -NoFallback
# Nur WMI (wenn ADMIN$ geblockt ist)
Test-RemoteAdminAccess -ComputerName "SERVER01" -Method WMIWichtig für die Praxis: -Timeout setzt ein Timeout pro Ziel. Das verhindert, dass der ganze Scan hängt, weil ein einzelner Host nicht antwortet. Standardmäßig sind das wenige Sekunden — bei langsamen VPN-Verbindungen kann man den Wert erhöhen.
Die Funktion erkennt auch automatisch, ob Kerberos-Tickets (PTT) vorhanden sind, und passt das Verhalten entsprechend an.
NTLM Impersonation — runas /netonly als Funktion
Manchmal braucht man NTLM-Authentifizierung statt Kerberos. Zum Beispiel wenn man Credentials hat, aber die bestehenden Kerberos-Tickets im Cache behalten will. Invoke-NTLMImpersonation macht genau das — wie runas /netonly, aber programmatisch:
# NTLM-Token erstellen
$token = Invoke-NTLMImpersonation -Credential (Get-Credential)
# Alle Netzwerk-Operationen nutzen jetzt die neuen Credentials
# SMB, LDAP, etc. — alles über NTLM
# ... Arbeit erledigen ...
# Zurück zur ursprünglichen Identität
Invoke-RevertToSelf -TokenHandle $tokenDer Clou: Bestehende Kerberos-Tickets bleiben im Cache erhalten. Man wechselt nur die NTLM-Identität für Netzwerk-Operationen.
EPA-Status prüfen - NTLM Relay Protection testen
NTLM Relay ist nach wie vor einer der wirkungsvollsten Angriffsvektoren im AD-Umfeld. Die Gegenmaßnahme: Extended Protection for Authentication (EPA). Aber wie prüft man, ob EPA auf Exchange oder ADCS tatsächlich aktiv ist? Normalerweise: NTLM Type2 Challenge manuell provozieren, Channel Binding Token analysieren, Ergebnis interpretieren. Oder man benutzt -TestEPA:
# Exchange: EPA-Status pro Endpoint prüfen
Invoke-HTTPRequest -ScanExchange -Uri "mail.contoso.com" -TestEPA
# ADCS: EPA-Status der Web Enrollment prüfen (ESC8-Relevanz!)
Invoke-HTTPRequest -ScanADCS -Uri "ca.contoso.com" -TestEPA
# ADCS mit CA-Name: auch CES-Endpoints testen
Invoke-HTTPRequest -ScanADCS -Uri "ca.contoso.com" -CAName "Contoso-CA" -TestEPAWas dabei passiert: adPEAS führt einen NTLM-Handshake ohne Channel Binding Token durch. Wenn der Server die Authentifizierung ablehnt, ist EPA aktiv - NTLM Relay wird blockiert. Akzeptiert der Server den Handshake, ist EPA deaktiviert und das Endpoint ist anfällig für Relay-Angriffe.
Besonders relevant bei Exchange: IIS erlaubt unterschiedliche EPA-Einstellungen pro Virtual Directory. OWA kann EPA haben, EWS aber nicht. adPEAS testet deshalb jeden Endpoint einzeln:
$scan = Invoke-HTTPRequest -ScanExchange -Uri "mail.contoso.com" -TestEPA
# EPA-Status pro Endpoint abfragen
$scan.Endpoints.OWA.EPAEnabled # $true oder $false
$scan.Endpoints.EWS.EPAEnabled # Kann anders sein!
$scan.Endpoints.Autodiscover.EPAEnabledAls Bonus extrahiert adPEAS aus der NTLM Type2 Challenge nützliche Informationen über den Zielserver - ohne sich authentifizieren zu müssen:
$scan.NTLMInfo.NbComputerName # NetBIOS-Name: "EX01"
$scan.NTLMInfo.NbDomainName # NetBIOS-Domain: "CONTOSO"
$scan.NTLMInfo.DnsComputerName # FQDN: "ex01.contoso.com"
$scan.NTLMInfo.DnsDomainName # Domain: "contoso.com"
$scan.NTLMInfo.DnsTreeName # Forest: "contoso.com"
$scan.NTLMInfo.ServerTimestamp # Serverzeit (hilfreich für Clock-Skew-Analyse)Für ADCS ist -TestEPA besonders interessant im Kontext von ESC8 (NTLM Relay to ADCS Web Enrollment). Wenn /certsrv/ NTLM ohne EPA anbietet, kann ein Angreifer über Coercion-Methoden (PetitPotam, PrinterBug) die Authentifizierung eines Domain Controllers an die CA weiterleiten und ein Zertifikat im Namen des DCs anfordern.
Hilfs-Utilities
Account-Analyse mit Test-AccountActivity
Test-AccountActivity ist ein Pipeline-basierter Filter für AD-Accounts — wie Where-Object, aber mit eingebauter AD-Logik:
# Accounts die seit mehr als 90 Tagen inaktiv sind
Get-DomainUser | Test-AccountActivity -IsInactive
# Passwort älter als 3 Jahre
Get-DomainUser | Test-AccountActivity -PasswordAgeDays 1095
# Noch nie eingeloggt
Get-DomainUser | Test-AccountActivity -NeverLoggedIn
# Passwort stammt aus 2018 oder früher
Get-DomainUser | Test-AccountActivity -PasswordChangedBeforeYear 2019Das Besondere: Alle Filter sind kombinierbar. Damit lassen sich sehr gezielte Abfragen bauen:
# Die "Ticking Time Bombs": Aktive Accounts + Passwort läuft nie ab + Passwort älter als 10 Jahre
Get-DomainUser | Test-AccountActivity -IsActive -PasswordNeverExpires -PasswordAgeDays 3650
# Enabled + nie eingeloggt (vergessene Accounts — perfekt für Übernahme)
Get-DomainUser | Test-AccountActivity -IsEnabled -NeverLoggedIn
# Inaktive Computer (kein Login seit 6 Monaten — veraltete Patches?)
Get-DomainComputer | Test-AccountActivity -IsInactive -InactiveDays 180Ein Detail das die Funktion von manuellem Filtern unterscheidet: Sie differenziert zwischen “inaktiv” und “nie eingeloggt”. Ein Account ohne lastLogonTimestamp ist nicht “inaktiv” (= war mal aktiv, ist es nicht mehr), sondern “nie benutzt”. Das sind unterschiedliche Findings mit unterschiedlicher Bedeutung.
Mit -IncludeDetails kann man sich die berechneten Werte als Property anhängen lassen:
Get-DomainUser | Test-AccountActivity -IsInactive -IncludeDetails |
Select-Object sAMAccountName,
@{N='DaysInactive'; E={$_.ActivityDetails.DaysSinceActivity}},
@{N='PwdYear'; E={$_.ActivityDetails.PasswordYear}},
@{N='NeverExpires'; E={$_.ActivityDetails.HasPasswordNeverExpires}}Die vollständige Liste der Filter:
| Filter | Beschreibung |
|---|---|
-IsActive / -IsInactive | Basierend auf lastLogonTimestamp |
-InactiveDays 180 | Custom Schwellwert (Default: 90 Tage) |
-NeverLoggedIn / -HasLoggedIn | Noch nie eingeloggt vs. mindestens einmal |
-PasswordAgeDays 1825 | Passwort älter als N Tage |
-PasswordChangedBeforeYear 2020 | Passwort vor Jahr X geändert |
-PasswordChangedInYear 2021 | Passwort genau in Jahr X geändert |
-PasswordChangedAfterYear 2023 | Passwort nach Jahr X geändert |
-PasswordNeverSet | Passwort wurde nie gesetzt |
-IsEnabled / -IsDisabled | Account-Status |
-PasswordNeverExpires | DONT_EXPIRE_PASSWORD Flag |
-PasswordNotRequired | PASSWD_NOTREQD Flag |
Zertifikate analysieren mit Get-CertificateInfo
Du hast ein PFX aus einem ADCS-Angriff, aus Shadow Credentials oder von einer Dateifreigabe - und willst wissen, was drinsteckt? Get-CertificateInfo zeigt dir alles Wichtige, ohne das Zertifikat in den Windows Certificate Store importieren zu müssen:
Get-CertificateInfo -Certificate ".\admin.pfx" -CertificatePassword "pass"[?] Certificate Information
[+] General:
Subject: CN=Administrator
Issuer: CN=Contoso-CA, DC=contoso, DC=com
Serial Number: 1A00000005...
Thumbprint: 3F2B1C...
[+] Validity:
Not Before: 2026-02-19 10:50:21
Not After: 2027-02-19 10:50:21
Status: Valid (expires in 365 days)
[+] Key Information:
Has Private Key: True
Key Algorithm: RSA (2048 bit)
[+] Extended Key Usage:
[1] Client Authentication (1.3.6.1.5.5.7.3.2)
[2] Smartcard Logon (1.3.6.1.4.1.311.20.2.2)
[+] PKINIT Assessment:
PKINIT Capable: True
PKINIT EKUs: Client Authentication, Smartcard Logon
Identities:
[1] UPN: Administrator@contoso.com
Usage:
Connect-adPEAS -Domain contoso.com -Certificate '.\admin.pfx' -CertificatePassword 'pass'Besonders praktisch: Das PKINIT Assessment zeigt dir sofort ob und wie du das Zertifikat für eine Kerberos-Authentifizierung verwenden kannst - inklusive fertigem Connect-adPEAS-Befehl zum Copy-Paste.
Funktioniert mit allen gängigen Formaten:
# PFX/P12 mit Passwort
Get-CertificateInfo -Certificate ".\admin.pfx" -CertificatePassword "pass"
# PFX ohne Passwort (z.B. von Request-ADCSCertificate -NoPassword)
Get-CertificateInfo -Certificate ".\admin.pfx"
# CER/DER (nur öffentlicher Schlüssel)
Get-CertificateInfo -Certificate ".\server.cer"
# Für Scripting: -PassThru liefert ein Objekt
$info = Get-CertificateInfo -Certificate ".\admin.pfx" -PassThru
$info.PKINITCapable # True/False
$info.Identities # @("UPN:Administrator@contoso.com")
$info.HasPrivateKey # TrueTab-Completion — Schneller navigieren
In großen AD-Umgebungen ist Tab-Completion ein Produktivitäts-Boost. adPEAS bietet zwei Modi:
Lazy Loading (Default): Der Cache wird automatisch beim ersten TAB-Druck aufgebaut - pro Objekt-Typ und nur bei Bedarf. Wer Get-DomainUser -Identity adm<TAB> drückt, triggert den User-Cache. Computers, Groups und GPOs werden erst geladen wenn sie tatsächlich gebraucht werden. Kein Overhead beim Connect, keine unnötige Last.
Eager Loading: Wer alle Objekt-Typen vorab laden will, nutzt -BuildCompletionCache beim Connect:
Connect-adPEAS -Domain "contoso.com" -UseWindowsAuth -BuildCompletionCacheIn beiden Fällen funktioniert Tab-Completion identisch für alle Get-Domain* und Set-Domain* Funktionen:
Get-DomainUser -Identity adm<TAB> # → "administrator", "admin.smith", ...
Get-DomainComputer -Identity DC<TAB> # → "DC01", "DC02", ...
Get-DomainGroup -Identity Domain<TAB> # → "Domain Admins", "Domain Users", ...
Get-DomainGPO -Identity Def<TAB> # → "Default Domain Policy", ...In einer Umgebung mit 5.000 Users, 500 Computern und 200 Gruppen spart das pro Abfrage einige Sekunden. Über einen ganzen Pentest-Tag hinweg summiert sich das.
Der Cache bleibt solange bestehen wie die PowerShell-Session läuft und kann mit Build-CompletionCache jederzeit manuell aktualisiert werden.
Session-Status prüfen
Mitten im Pentest die Frage: Bin ich noch verbunden? Welche Auth-Methode? Welcher DC?
Get-adPEASSessionZeigt den aktuellen Session-Status: Domain, Server, Authentifizierungsmethode und ob Kerberos-Tickets vorhanden sind. Besonders nützlich nach einer längeren Pause oder wenn plötzlich Abfragen fehlschlagen.
Reports offline regenerieren und vergleichen
Zwei Funktionen die kein aktives AD brauchen — nur eine JSON-Datei aus einem früheren Scan:
Report-Konvertierung: Wenn eine neue adPEAS-Version rauskommt, muss man nicht nochmal scannen. Convert-adPEASReport nimmt die JSON-Datei und generiert frische Reports mit aktualisierten Templates und Scoring:
# Alle Formate neu generieren (HTML + Text + JSON)
Convert-adPEASReport -InputJson ".\audit.json" -OutputPath ".\new_report"
# Nur HTML für den Kunden
Convert-adPEASReport -InputJson ".\audit.json" -OutputPath ".\new_report" -Format HTMLReport-Vergleich: Nach einer Remediation-Phase will man wissen, was sich geändert hat. Compare-adPEASReport vergleicht zwei JSON-Exports:
# Baseline vs. Current
Compare-adPEASReport -Baseline ".\scan_q1.json" -Current ".\scan_q2.json"Der Output zeigt neue, behobene und geänderte Findings — gruppiert nach Check-Kategorie. Besonders nützlich für quartalsweise Compliance-Audits oder die Validierung von Remediation-Maßnahmen.
Details zu beiden Funktionen in Episode 5: Output & Reports.
Attribut-Suche mit Search-Value
Du hast 500 User aus Get-DomainUser und suchst einen bestimmten String — aber du weißt nicht, in welchem Attribut er steckt? Search-Value durchsucht alle Properties jedes Pipeline-Objekts:
# In welchem Attribut steckt "admin"?
Get-DomainUser | Search-Value "admin" administrator
sAMAccountName: administrator
description: Built-in account for administering the computer/domain
f.sinatra
description: User Help Desk Admin
memberOf: ClientAdmins
memberOf: ServerAdminsFür jedes matchende Objekt zeigt Search-Value den Account-Namen und die Properties, in denen der Suchbegriff gefunden wurde. Das spart die manuelle Pipeline mit ForEach-Object und Where-Object.
Die Suche funktioniert mit allen Get-Domain* Funktionen:
# Computer mit "SQL" in irgendeinem Attribut
Get-DomainComputer | Search-Value "SQL"
# Gruppen mit "Exchange" im Namen oder der Beschreibung
Get-DomainGroup | Search-Value "Exchange" -Property name,description
# Regex-Suche: User deren Passwort in 2019 gesetzt wurde
Get-DomainUser | Search-Value "^01/..../../2019" -Regex -Property pwdLastSet
# Exakter Match
Get-DomainUser | Search-Value "DONT_EXPIRE_PASSWORD" -Exact -Property userAccountControlDie drei Suchmodi:
| Modus | Syntax | Verhalten |
|---|---|---|
| Wildcard (Default) | Search-Value "admin" | *admin* — matcht überall im Wert |
| Exact | Search-Value "admin" -Exact | Exakter String-Vergleich |
| Regex | Search-Value "^adm\d+" -Regex | Regulärer Ausdruck |
Mit -Property kann die Suche auf bestimmte Attribute eingeschränkt werden. Ohne den Parameter werden alle Attribute durchsucht.
Vorherige Episode: Episode 8 - PAC Deep-Dive & Ticket Forging
Über den Autor
Verwandte Artikel
adPEAS v2 Blog-Serie: Active Directory Sicherheitsanalyse mit adPEAS
Einführung in adPEAS v2 — eine komplette Neuentwicklung des PowerShell-basierten Active Directory Analyse-Tools mit nativem Kerberos-Support, null Abhängigkeiten und über 40 Security-Checks.
adPEAS v2 Episode 2: Unter der Haube - Anatomie eines Scans
Was passiert, wenn adPEAS ein Active Directory scannt? Von Authentifizierung und LDAP-Abfragen bis hin zu kontextabhängigen Severity-Bewertungen und Caching — ein Blick unter die Haube.
adPEAS v2 Episode 5: Output & Reports - Vom Scan zum Bericht
Wie adPEAS v2 Scan-Ergebnisse in verwertbare Ausgabe verwandelt: farbcodierte Console, interaktive HTML-Reports, inkrementelles Scannen, Offline-Konvertierung und Report-Diff.