Penetrationstest-Bericht - Definition & Erklärung

Ein Penetrationstest-Bericht ist das finale Lieferobjekt eines Penetrationstests - und oft das wichtigste. Er muss zwei völlig verschiedene Zielgruppen bedienen: die Geschäftsführung (Executive Summary, Risikobewertung) und das technische Team (reproduzierbare Befunde, Proof-of-Concept).

Aufbau eines professionellen Pentest-Berichts

1. Deckblatt und Metadaten

PENETRATIONSTEST-BERICHT

Auftraggeber:   Mustermann GmbH, Hauptstraße 1, 12345 Berlin
Auftragnehmer:  AWARE7 GmbH, Gelsenkirchen
Testtyp:        Web Application Penetration Test
Scope:          https://app.mustermann.de (Produktionssystem)
Testmethodik:   Black Box / Gray Box (gemischt)
Testzeitraum:   2026-02-10 bis 2026-02-14
Bericht-Datum:  2026-02-20
Version:        1.0 (Final)
Klassifizierung: VERTRAULICH - Nur für Auftraggeber

Erstellt von:   Max Mustermann, OSCP, OSCE3
Geprüft von:    Anna Schmidt, Lead Penetration Tester

2. Executive Summary (für die Geschäftsführung)

Das Executive Summary sollte KEINE technischen Details enthalten.
Es beantwortet: "Was haben wir gefunden? Was bedeutet das? Was tun?"

Struktur:
  ┌────────────────────────────────────────┐
  │ GESAMTRISIKO: KRITISCH                 │
  │ Kritische Befunde: 2                   │
  │ Hohe Befunde:      5                   │
  │ Mittlere Befunde:  8                   │
  │ Niedrige Befunde: 12                   │
  └────────────────────────────────────────┘

  "Während des Penetrationstests konnten wir als externer Angreifer
  ohne vorherige Kenntnisse vollständigen Datenbankzugriff auf die
  Kundendatenbank mit 50.000 Einträgen erlangen. Zwei kritische
  Schwachstellen ermöglichten dies innerhalb von 4 Stunden.

  Wir empfehlen die sofortige Behebung der kritischen und hohen
  Befunde (Befund 1-7) vor Weiterentwicklung neuer Features."

Gefunden Befunde (Zusammenfassung):
  Risk Level | Anzahl | Beispiel
  KRITISCH   | 2      | SQL Injection im Login-Formular
  HOCH       | 5      | IDOR auf /api/users/{id}
  MITTEL     | 8      | Fehlende Rate Limiting
  NIEDRIG    | 12     | Missing Security Headers

3. Technischer Teil - Befundkarten

Jeder Befund wird als eigenständige Befundkarte dokumentiert:

══════════════════════════════════════════════
BEFUND #01: SQL Injection im Benutzerformular
══════════════════════════════════════════════

Schweregrad:      KRITISCH (CVSS v3.1: 9.8)
CVSS Vector:      AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE:              CWE-89: Improper Neutralization of SQL Commands
CVE:              N/A (custom application)
Status:           Offen / In Behebung / Behoben

Betroffene URL:   POST https://app.mustermann.de/api/v1/users/login
Betroffener       Parameter: `username`
Parameter:

BESCHREIBUNG:
  Der Parameter `username` im Login-Formular wird ohne Validierung
  oder Parametrisierung direkt in eine SQL-Abfrage eingefügt.
  Dies ermöglicht es einem Angreifer, beliebige SQL-Befehle
  im Kontext der Datenbankverbindung auszuführen.

PROOF OF CONCEPT:
  1. POST-Request an Login-Endpoint:
     username=admin'--&password=anything

  2. Manipulierte SQL-Abfrage:
     SELECT * FROM users WHERE username='admin'--' AND password='...'
     → Kommentar (--) entfernt Passwort-Prüfung

  3. Anmeldesuccess als admin ohne Passwort bestätigt.

  4. Datenbankexfiltration (sqlmap):
     sqlmap -u "https://app.mustermann.de/api/v1/users/login" \
       --data="username=test&password=test" \
       --dbs --dump

  5. Extrahierte Daten (Auszug):
     Database: production_db
     Table: customers (52.347 rows)
     [email, name, address, iban, ...]

RISIKOBEWERTUNG:
  Ohne Authentifizierung vollständiger Datenbankzugriff.
  DSGVO-Meldepflicht bei Ausnutzung (Art. 33 DSGVO).
  Reputationsschaden bei Öffentlichwerden.

EMPFEHLUNG:
  SOFORTMASSNAHME (bis 24h):
    → Prepared Statements / Parameterized Queries implementieren
    → KORREKT: cursor.execute("SELECT * FROM users WHERE username=%s", (username,))
    → FALSCH:  cursor.execute("SELECT * FROM users WHERE username='" + username + "'")

  MITTELFRISTIG (bis 7 Tage):
    → WAF aktivieren (virtueller Patch)
    → Datenbankzugriff auf least-privilege beschränken
    → SQL-Injection in Code Review und SAST-Tools einbeziehen

4. Angriffsszenarien / Attack Chains

Neben Einzel-Befunden dokumentiert ein guter Bericht
die reale Angriffskette - wie ein echter Angreifer vorgeht:

Attack Chain #1: Von der SQL Injection zur vollständigen Übernahme

  Schritt 1: SQL Injection (Befund #01)
    → Dump aller Nutzerdaten inkl. Passwort-Hashes (bcrypt)

  Schritt 2: Passwort-Cracking
    → 12% der Hashes geknackt (schwache Passwörter)
    → Admin-Account kompromittiert

  Schritt 3: Admin-Panel Zugriff
    → Backup-Download möglich (Befund #05 - unsichere Admin-Funktion)

  Schritt 4: Backup enthält DB-Credentials
    → Datenbankzugriff direkt möglich

  Ergebnis: Vollständige Datenbankexfiltration in <2 Stunden
  Betroffene Daten: 52.347 Kundendatensätze (DSGVO-relevant!)

5. Maßnahmenplan

Priorisierter Maßnahmenplan:

Prio | Befund | Aufwand | Verantwortlich | Frist
─────────────────────────────────────────────────
  1  | SQL Injection        | 2h    | Dev-Team      | 24h
  2  | IDOR /api/users      | 4h    | Dev-Team      | 48h
  3  | XXE in XML-Upload    | 2h    | Dev-Team      | 48h
  4  | Fehlende MFA-Admin   | 4h    | IT-Ops        | 7 Tage
  5  | Veraltetes jQuery    | 1h    | Dev-Team      | 7 Tage
  ...
 20  | Missing HSTS Header  | 30min | IT-Ops        | 30 Tage

6. Anhang und Methodik

Anhang A: Testmethodik
  → Verwendete Tools: Burp Suite Professional, sqlmap, Nmap, ffuf
  → Standards: OWASP Testing Guide v4.2, PTES
  → Testbeginn/ende mit Zeitstempeln

Anhang B: Scope
  → In-Scope: app.mustermann.de, api.mustermann.de
  → Out-of-Scope: mustermann.de (Hauptwebsite), interne Systeme

Anhang C: Tool-Output (Rohdaten)
  → Nmap-Scan-Output
  → Nikto-Report
  → OWASP ZAP Baseline-Report

Anhang D: Kommunikationsprotokoll
  → Wer wurde informiert?
  → Kritische Findings: sofortige Eskalation an CTO (02.02.2026, 14:32)

Was einen guten Bericht ausmacht

Guter Bericht:                    Schlechter Bericht:
  ✓ Executive Summary verständlich   ✗ Nur technischer Kauderwelsch
  ✓ Reproduzierbare PoC-Schritte     ✗ "Found SQLi" ohne Details
  ✓ Business Impact beschrieben      ✗ Nur CVSS ohne Kontext
  ✓ Priorisierte Maßnahmen           ✗ Unsortierte Befundliste
  ✓ Screenshots / Tool-Output        ✗ Keine Nachweise
  ✓ Angriffsketten dokumentiert      ✗ Isolierte Einzelbefunde
  ✓ Retest-Ergebnisse (wenn möglich) ✗ Kein Follow-up vorgesehen
  ✓ 2-4 Wochen nach Test geliefert   ✗ Monatelange Wartezeit

Retest - Befunde verifizieren

Nach Behebung der Befunde:
  → Dedizierter Retest der behobenen Schwachstellen
  → Neues Bericht-Kapitel: "Behobene Befunde"
  → Status-Update: "Offen" → "Behoben" / "Teilweise behoben"

Status-Optionen:
  Behoben (Closed):             Schwachstelle nicht mehr vorhanden
  Teilweise behoben (Partial):  Hauptproblem behoben, Rest noch offen
  Akzeptiert (Accepted Risk):   Bewusste Entscheidung kein Fix
  Offen (Open):                 Noch keine Behebung