SEKurity GmbH Logo
adPEAS

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.

Alexander Sturz

Gründer & Red Team Lead

12 Min. Lesezeit
Teilen:

Einleitung

In Episode 4 haben wir gesehen, welche Security Checks adPEAS durchführt und welche Schwachstellen dabei aufgedeckt werden können. Aber ein Scan ist nur so gut wie seine Ausgabe. Was nützt der gründlichste Check, wenn die Ergebnisse in einer Textwüste untergehen?

Wer regelmäßig Pentests durchführt, kennt das Problem: Die Rohdaten sind da, aber der Weg vom Scan-Ergebnis zum Kunden-Deliverable kostet oft mehr Zeit als der Scan selbst. adPEAS löst das mit einem durchdachten Output-System, das drei Zielgruppen bedient: den Pentester bei der Live-Analyse, den Report-Schreiber bei der Dokumentation und den Kunden beim Lesen des Ergebnisberichts.

Konkret bietet adPEAS zwei Ausgabe-Modi:

  1. Console Output - Farbcodierte Echtzeit-Ausgabe für die interaktive Arbeit
  2. File Reports - Text und/oder HTML für Dokumentation und Kunden-Deliverables

Beide Modi nutzen intern die gleiche RenderModel-Pipeline, die dafür sorgt, dass die Severity-Klassifizierung konsistent bleibt - egal ob auf der Console oder im HTML-Report. Wie das im Detail funktioniert, schauen wir uns am Ende dieses Posts an.


Teil 1: Console Output

Der Console Output ist das, womit man bei der täglichen Arbeit am meisten interagiert. Während eines Scans scrollt die Ausgabe in Echtzeit durch - und die farbcodierten Symbole sorgen dafür, dass kritische Findings sofort ins Auge springen. Man muss nicht den gesamten Output lesen, ein Blick auf die Farben reicht.

Die Symbole und Farben

adPEAS verwendet fünf farbcodierte Symbole um Findings zu kategorisieren:

SymbolFarbeBedeutungBeispiel
[?]BlauSection Header[?] Analyzing Domain Configuration
[!]RotFinding - Sicherheitsproblem[!] minPwdLength: 3 characters
[+]GelbHint - Prüfen[+] lockoutThreshold: Disabled
[*]GrünNote - Information[*] Found 2 domain controller(s)
[#]Rot auf GelbSecure - Gute Konfiguration[#] AdminSDHolder ACLs are secure

Ein schneller Blick auf die Farben zeigt wo es brennt.


Echte Console-Ausgabe

Wie sieht das nun in der Praxis aus? Hier ein Ausschnitt aus einem adPEAS-Scan:

               _ _____  ______           _____
              | |  __ \|  ____|   /\    / ____|
      ____  __| | |__) | |__     /  \  | (___
     / _  |/ _  |  ___/|  __|   / /\ \  \___ \
    | (_| | (_| | |    | |____ / ____ \ ____) |
     \__,_|\__,_|_|    |______/_/    \_\_____/
                                            Version 2.0.0

    Active Directory Enumeration
    by @61106960

    Legend
        [?] Searching for juicy information
        [!] Found a vulnerability which may be exploitable
        [+] Found some interesting information for further investigation
        [*] Some kind of note
        [#] Some kind of secure configuration

======================================================================
+++++ Establishing LDAP Connection +++++
======================================================================
[*] Successfully connected to domain 'contoso.com' on server 'DC01.contoso.com' as 'CONTOSO\jsmith' via Kerberos (SSPI)
Executing Modules: Domain, Creds, Rights, Delegation, ADCS, Accounts, GPO, Computer, Application, Bloodhound

======================================================================
+++++ Analyzing Domain Configuration +++++
======================================================================

[?] Analyzing password policy...
[!] Found password policy:
[!] minPwdLength:                            3 characters
minPwdAge:                                   1 days
maxPwdAge:                                   42 days
passwordComplexity:                          Enabled
[+] lockoutThreshold:                        Disabled

[?] Analyzing LDAP Signing/Channel Binding via GPO (SYSVOL)...
[+] Found LDAP security configuration in 2 GPO(s):
displayName:                                 Default Domain Policy
[!] LDAPSigning:                             Not Configured
[!] ChannelBinding:                          Not Configured
[#] AnonymousBinding:                        Restricted

Struktur der Ausgabe

Jeder Scan folgt einer festen Struktur. Das macht die Ausgabe vorhersehbar - man weiß immer, wo man gerade ist und was als nächstes kommt. Besonders bei großen Domains mit hunderten Ausgaben hilft diese Struktur, den Überblick zu behalten:

1. Banner & Legende
   +-- Logo, Version, Symbol-Erklärung

2. Connection Info
   +-- Domain, DC, Auth-Methode, Module

3. Module (je nach Auswahl)
   |-- +++++ Analyzing Domain Configuration +++++
   |-- +++++ Analyzing Privileged Accounts +++++
   |-- +++++ Analyzing Delegation Settings +++++
   |-- +++++ Analyzing Access Permissions +++++
   |-- +++++ Analyzing Computer Security +++++
   |-- +++++ Analyzing Group Policy Objects +++++
   |-- +++++ Analyzing Certificate Services +++++
   |-- +++++ Analyzing Application Infrastructure +++++
   |-- +++++ Analyzing Credential Exposure +++++
   +-- +++++ Collecting BloodHound Data +++++

4. Scan Summary
   +-- Duration, Report-Pfade

Verbose-Modus

Manchmal reicht der Standard-Output nicht aus. Wenn ein Check unerwartet leer zurückkommt oder deutlich länger dauert als erwartet, will man wissen was unter der Haube passiert. Mit -Verbose zeigt adPEAS jeden einzelnen Schritt - welche LDAP-Filter abgesetzt werden, wie viele Ergebnisse zurückkommen, und wo Zeit verbraucht wird:

Invoke-adPEAS -Domain "contoso.com" -UseWindowsAuth -Verbose
VERBOSE: [Connect-adPEAS] Starting authentication...
VERBOSE: [Connect-adPEAS] Using Windows Authentication
VERBOSE: [Invoke-LDAPSearch] Filter: (objectClass=domain)
VERBOSE: [Invoke-LDAPSearch] Returned 1 results
VERBOSE: [Get-DomainInformation] Domain DN: DC=contoso,DC=com

Nützlich für:

  • Debugging wenn was nicht funktioniert
  • Verstehen welche LDAP-Abfragen gemacht werden
  • Performance-Analyse

Verbose-Logging in Datei

In der Praxis läuft adPEAS oft im Hintergrund während man an anderen Dingen arbeitet. Wenn dann ein Problem auftritt, ist der Console-Output schon durchgescrollt. -VerboseLogging löst das: Alle Verbose-Meldungen werden mit Zeitstempel in die Text-Output-Datei geschrieben. So kann man auch nachträglich nachvollziehen, was wann passiert ist:

# Verbose-Logging in Datei (aktiviert automatisch auch Console-Verbose)
Invoke-adPEAS -Domain "contoso.com" -UseWindowsAuth -Outputfile .\report -VerboseLogging

Die Textdatei enthält dann zusätzlich zeitgestempelte Einträge:

2026-01-14 18:42:15 [Verbose] [Get-DomainUser] Querying users...
2026-01-14 18:42:16 [Verbose] [Invoke-LDAPSearch] Filter: (objectClass=user)
2026-01-14 18:42:16 [Verbose] [Invoke-LDAPSearch] Returned 1523 results

Hinweis: -VerboseLogging aktiviert automatisch -Verbose für die Console. Der Parameter benötigt -Outputfile mit Text-Format - ohne Output-Datei erscheint eine Warnung, und die Verbose-Meldungen werden nur in der Console angezeigt.


Unter der Haube: Die RenderModel-Pipeline

Für die meisten Anwender ist dieser Abschnitt optional - aber wer verstehen will, warum die Severity-Klassifizierung in Console und HTML-Report immer identisch ist, findet hier die Antwort.

Intern verwendet adPEAS eine Unified RenderModel Pipeline. Check-Module kümmern sich nicht um Formatierung - sie rufen einfach Show-Object auf und die Pipeline erledigt den Rest. Das gleiche AD-Objekt wird automatisch sowohl für die Console als auch für den HTML-Report aufbereitet:

Show-Object $user
    |
    v
Get-RenderModel                      # Baut ein renderer-agnostisches Datenmodell
    |-- Erkennt Objekttyp              (User, Computer, GPO, Cert Template)
    |-- Ordnet Attribute               (Primary vs. Extended)
    |-- Ruft AttributeTransformers     (memberOf, UAC, SPN, etc.)
    |-- Klassifiziert Severity         (Finding/Hint/Note/Secure/Standard)
    |
    +---> Render-ConsoleObject       # ANSI-Farben, Prefixes, Alignment
    +---> Render-HtmlObject          # HTML-Tabellen, Tooltips, CSS-Klassen

Die AttributeTransformers sind spezialisierte Funktionen für komplexe Attribute:

TransformerAttributWas er macht
Convert-MemberOfToRenderValuesmemberOfSID-Auflösung, Gruppen-Klassifizierung
Convert-UACToRenderValuesuserAccountControlFlag-Aufschlüsselung, Severity pro Flag
Convert-SPNToRenderValuesservicePrincipalNameSPN-Formatierung, Kerberoasting-Hinweis
Convert-SIDHistoryToRenderValuessIDHistoryErkennung privilegierter SIDs
Convert-DangerousACEsToRenderValuesDangerousACEsACE-Klassifizierung
Convert-EKUToRenderValuesExtendedKeyUsageOID-zu-Name, PKINIT-Erkennung

Attribute ohne spezialisierten Transformer nutzen Get-AttributeSeverity direkt für einfache Wert-Klassifizierung.


Teil 2: File Reports

Der Console Output ist perfekt für die Live-Analyse, aber für die Dokumentation braucht man etwas Dauerhaftes. adPEAS generiert auf Wunsch zwei Report-Formate: einen Text-Report für die Archivierung und Weiterverarbeitung, und einen HTML-Report als interaktives Dashboard für Präsentationen und Kunden-Deliverables. Beide Formate werden als standalone Dateien ohne externe Dependencies erstellt - eine Datei kopieren und fertig.

Reports generieren

# Alle Formate (Default)
Invoke-adPEAS -Domain "contoso.com" -Outputfile .\report

# Nur HTML
Invoke-adPEAS -Domain "contoso.com" -Outputfile .\report -Format HTML

# Nur Text
Invoke-adPEAS -Domain "contoso.com" -Outputfile .\report -Format Text

# Text ohne Farben (für Editoren)
Invoke-adPEAS -Domain "contoso.com" -Outputfile .\report -Format Text -NoColor

Am Ende zeigt adPEAS die Pfade:

======================================================================
+++++ Scan Summary +++++
======================================================================
[+] Duration: 24.3 seconds
[+] Text report saved to: report.txt
[+] HTML report saved to: report.html
[+] JSON export saved to: report.json

adPEAS erzeugt bei jedem Scan mit -Outputfile automatisch eine JSON-Datei (<basename>.json) neben den Report-Dateien. Diese enthält alle Findings als maschinenlesbare, strukturierte Daten — ideal für Post-Processing, externe Tools oder die Weiterverarbeitung in Scripts.

Inkrementelle Scans mit OutputAppend

In der Praxis will man nicht immer den kompletten Scan auf einmal laufen lassen. Vielleicht möchte man zuerst Domain und Accounts prüfen, dann ADCS separat nachschieben, oder einzelne Module nach einer Konfigurationsänderung nochmal gezielt ausführen. Mit -OutputAppend werden die Ergebnisse mehrerer Durchläufe in einen gemeinsamen Report zusammengeführt:

# Erster Durchlauf - erstellt Report + JSON
Invoke-adPEAS -Module Domain,Accounts -Outputfile .\audit

# Zweiter Durchlauf - Findings werden mit vorherigen zusammengeführt
Invoke-adPEAS -Module ADCS,Rights -Outputfile .\audit -OutputAppend

# Dritter Durchlauf - weitere Module hinzufügen
Invoke-adPEAS -Module Creds,Delegation -Outputfile .\audit -OutputAppend

Wie funktioniert das?

Bei jedem Scan mit -Outputfile erstellt adPEAS neben den Report-Dateien automatisch eine JSON-Datei (audit.json). Bei weiteren Durchläufen mit -OutputAppend werden die neuen Findings mit den vorhandenen aus der JSON-Datei zusammengeführt und der HTML-Report wird mit allen kombinierten Ergebnissen neu generiert. Der Text-Report wird am Ende angehängt.

Durchlauf 1: Domain,Accounts     -> audit.txt, audit.html, audit.json
Durchlauf 2: ADCS,Rights         -> Merge mit JSON -> Report aktualisiert
Durchlauf 3: Creds,Delegation    -> Merge mit JSON -> Report aktualisiert

Ohne -OutputAppend werden bestehende Reports überschrieben (Standard-Verhalten).


Offline Report-Konvertierung

Die JSON-Datei ist nicht nur für inkrementelle Scans nützlich. Sie ist das Austauschformat, mit dem sich Reports jederzeit offline — also ohne aktive LDAP-Verbindung — neu generieren lassen. Das ist besonders praktisch wenn:

  • Eine neuere adPEAS-Version verfügbar ist und man die alten Scan-Daten mit aktualisierten Finding-Definitionen, Scoring oder HTML-Templates neu aufbereiten will
  • Man den Scan auf einem System durchgeführt hat, aber den Report auf einem anderen erstellen möchte

Convert-adPEASReport nimmt eine JSON-Datei als Input und erzeugt daraus frische Reports:

# Alle Formate: HTML + Text + re-exportiertes JSON
Convert-adPEASReport -InputJson ".\audit.json" -OutputPath ".\new_report"

# Nur HTML
Convert-adPEASReport -InputJson ".\audit.json" -OutputPath ".\new_report" -Format HTML

# Nur Text ohne Farben (für Editoren)
Convert-adPEASReport -InputJson ".\audit.json" -OutputPath ".\new_report" -Format Text -NoColor

# JSON re-exportieren (mit aktueller adPEAS-Version als Metadaten)
Convert-adPEASReport -InputJson ".\audit.json" -OutputPath ".\new_report" -Format JSON

# Mit Lizenz für gebrandete Reports
Convert-adPEASReport -InputJson ".\audit.json" -OutputPath ".\new_report" -License ".\license.json"

Wenn die JSON-Datei mit einer älteren adPEAS-Version erstellt wurde, zeigt Convert-adPEASReport das an:

[*] Source: audit.json
[*] Domain: contoso.com, Server: DC01.contoso.com
[*] Original scan: 2026-01-15 14:30 (adPEAS 2.0.0+20260115-1430)
[*] Findings: 47
[+] Regenerating with adPEAS 2.0.1 (updated definitions/scoring)

Wichtig: Die Konvertierung benötigt keine LDAP-Verbindung. Man braucht nur die JSON-Datei und eine adPEAS-Installation.


Report-Vergleich (Diff)

Wer regelmäßig scannt — sei es quartalsweise für Compliance oder nach einer Remediation-Phase — will wissen was sich geändert hat. Compare-adPEASReport vergleicht zwei JSON-Exports und zeigt die Unterschiede strukturiert an:

# Zwei Scans vergleichen
Compare-adPEASReport -Baseline ".\scan_q1.json" -Current ".\scan_q2.json"

# Diff-Report in Datei speichern
Compare-adPEASReport -Baseline ".\scan_jan.json" -Current ".\scan_apr.json" -OutputPath ".\diff_report"

Der Vergleich zeigt:

[?] adPEAS Report Comparison

[*] Baseline: scan_q1.json (2026-01-15 14:30, contoso.com, adPEAS 2.0.0)
[*] Current:  scan_q2.json (2026-04-15 09:00, contoso.com, adPEAS 2.0.1)

[?] Comparison Summary
[!] New findings (added):                   3
[#] Remediated findings (removed):          5
[+] Changed findings:                       2
[*] Unchanged findings:                     39
[*] Total baseline findings:                46
[*] Total current findings:                 44
  • New findings — Neue Schwachstellen seit dem letzten Scan
  • Remediated findings — Behobene Issues (waren in Baseline, sind jetzt weg)
  • Changed findings — Geänderte Severity oder Werte (z.B. Passwort-Policy angepasst)

Bei unterschiedlichen Scan-Scopes (z.B. Baseline hatte ADCS, Current nicht) weist der Vergleich auf fehlende Kategorien hin, damit man keine falschen Schlüsse zieht.

Typischer Workflow:

Quartal 1: Scan -> audit_q1.json
           | Remediation
Quartal 2: Scan -> audit_q2.json
           |
           Compare-adPEASReport -Baseline audit_q1.json -Current audit_q2.json
           |
           Diff-Report -> "5 behoben, 3 neue, 2 geändert"

Der Text-Report

Der Text-Report ist die einfachste Form der Dokumentation - im Grunde der Console Output in einer Datei. Er enthält die gleiche Ausgabe wie die Console, inklusive ANSI-Farbcodes:

  • Lesbar mit cat oder Get-Content im Terminal
  • Mit -NoColor auch in Editoren ohne Escape-Codes lesbar
  • Gleiche Struktur wie Console-Output

Der HTML-Report

Der HTML-Report ist das Highlight des Output-Systems. Während der Text-Report die Rohdaten liefert, verwandelt der HTML-Report die Scan-Ergebnisse in ein interaktives Dashboard mit Suche, Filtern und aufklappbaren Finding-Cards. Ideal wenn man einem Kunden die Ergebnisse präsentiert oder Teile davon in einen Report übernehmen will:

  • adPEAS Logo und Version
  • Lizenz-Hinweis (für kommerzielle Nutzung)
  • Dark/Light Mode Toggle - Sonne/Mond-Schalter

Suchfeld:

  • Freitext-Suche über alle Findings

Severity Filter:

  • All (Anzahl)
  • Finding (Anzahl) - Rot
  • Hint (Anzahl) - Gelb/Orange
  • Note (Anzahl) - Grün
  • Secure (Anzahl) - Blau

Category Filter:

  • All
  • Accounts
  • ADCS
  • Application
  • Computer
  • Creds
  • Delegation
  • Domain
  • GPO
  • Rights

Hauptbereich

Summary Cards:

+----------+ +----------+ +----------+ +----------+
|    12    | |    16    | |    19    | |    16    |
| Findings | |  Hints   | |  Notes   | |  Secure  |
+----------+ +----------+ +----------+ +----------+

Klick auf eine Card filtert nach dieser Severity.

Finding Cards:

Jedes Finding ist eine aufklappbare Card:

+-------------------------------------------------------------+
| [FINDING] Password policy too weak                     [v]  |
+-------------------------------------------------------------+
| Category: Domain                                            |
|                                                             |
| minPwdLength: 7 characters                                  |
| lockoutThreshold: Disabled                                  |
|                                                             |
| Hilfe via Tooltip mit Erklärung                             |
+-------------------------------------------------------------+

HTML-Report Features

Alle Features sind in einer einzigen HTML-Datei enthalten - kein JavaScript von externen CDNs, keine CSS-Frameworks, keine Abhängigkeiten:

FeatureBeschreibung
Dark/Light ModeToggle oben rechts, wird im Browser gespeichert
SucheFreitext über alle Findings
Severity FilterFinding/Hint/Note/Secure einzeln anzeigen
Category FilterNach Modul filtern
Klappbare CardsDetails ein/ausblenden
Help TooltipsErklärungen zu Findings

Farben im HTML-Report

SeverityFarbeCSS-Variable
FindingRot--finding: #d32f2f
HintOrange--hint: #f57c00
NoteGrün--note: #388e3c
SecureBlau--secure: #2196f3

Zusammenfassung

Je nach Situation greift man zu unterschiedlichen Formaten. Hier ein Überblick, was jedes Format kann und wo seine Stärken liegen:

AspektConsoleText-ReportHTML-Report
EchtzeitJaNeinNein
FarbcodiertJaJa (ANSI)Ja (CSS)
Durchsuchbargrep/Select-Stringgrep/Select-StringEingebaut
FilterbarNeinNeinJa
PräsentierbarNeinBedingtJa
Dark ModeTerminalNeinJa

Wann was nutzen?

  • Console - Interaktive Arbeit, Quick-Checks
  • Text-Report - Archivierung, Scripting, Diff
  • HTML-Report - Präsentation, Dokumentation, Kunden-Deliverable

← Episode 4: Security Checks | Episode 6: Offensive Operations — coming soon

Über den Autor

Alexander Sturz

Gründer & Red Team Lead

Active Directory Ninja und Experte für offensive Sicherheit mit Spezialisierung auf Kompromittierung von Unternehmensinfrastrukturen und Post-Exploitation-Techniken.

Verwandte Artikel