Penetrationstest Ablauf — Sieben Phasen im Detail

Ein professioneller Penetrationstest folgt einer strukturierten Methodik — keine kreative Improvisation, sondern ein dokumentierter Prozess in sieben Phasen. Wer als Auftraggeber den Ablauf versteht, kann besseren Scope formulieren, realistische Zeitpläne erwarten und den finalen Report effektiver auswerten. Dieser Artikel führt durch jede Phase aus Kunden-Perspektive — was passiert, wie lange es dauert, was Sie beisteuern müssen. Er ergänzt unseren Cybersecurity-Guide für den Mittelstand, in dem wir den größeren Rahmen aus NIS2, DSGVO und Compliance darstellen.

Die hier beschriebenen Phasen folgen dem Penetration Testing Execution Standard (PTES), der international etablierten Referenz-Methodik. Sie ist generisch genug für Web-, API-, Infrastruktur- und Mobile-Audits und wird in der Praxis um vertikal-spezifische Checklisten wie OWASP oder die OSSTMM-Kontrollziele ergänzt.

Phase	Was passiert	Typische Dauer
1. Pre-Engagement	Scope, Rules of Conduct, Verträge	5–10 Tage Vorlauf
2. Intelligence Gathering	OSINT, Asset-Discovery, Tech-Stack	1–3 Tage
3. Threat Modeling	Angreifer-Profile, Risiko-Priorisierung	0,5–1 Tag
4. Vulnerability Analysis	Schwachstellen-Identifikation	2–5 Tage
5. Exploitation	Kontrollierte Verifikation der Funde	2–5 Tage
6. Post-Exploitation	Impact-Bewertung, Lateral-Movement-Test	1–3 Tage
7. Reporting	Executive Summary, technische Doku, Empfehlungen	3–5 Tage

Phase 1 — Pre-Engagement

Der wichtigste Teil eines Pentests ist nicht die technische Arbeit, sondern die saubere Vorbereitung. Ein schlecht gescopter Pentest liefert irrelevante Funde, sprengt das Budget oder — schlimmer — verursacht ungewollte Ausfälle, die niemand vereinbart hat. Im Pre-Engagement klären wir mit Ihnen vier Kernfragen.

Was wird getestet? Wir definieren schriftlich, welche Systeme, IP-Bereiche, Anwendungen, URLs, API-Endpoints oder Cloud-Accounts in den Test einbezogen werden. Genauso wichtig ist die Ausschluss-Liste: welche Systeme bleiben außen vor, weil sie kritisch verfügbar sein müssen, von Dritten betrieben werden oder rechtlich nicht im Scope sein können.

Was darf gemacht werden? Die Rules of Conduct legen fest, ob destruktive Tests erlaubt sind, ob Phishing oder Social Engineering Teil des Auftrags sind, ob physischer Zutritt zum Standort getestet wird, und ob Brute-Force gegen Login-Endpoints durchgeführt werden darf. Bei Cloud-Anbietern wie AWS oder Azure ist außerdem der Pre-Approval-Prozess zu beachten.

Wann darf es passieren? Wir vereinbaren konkrete Zeitfenster. Test-Aktivitäten gegen Produktiv-Systeme legen wir wenn möglich in Wartungsfenster außerhalb der Geschäftszeiten. Schwarzwoche, Quartals-Abschluss oder Produkt-Launches sind explizit ausgeschlossene Perioden.

Wer wird im Notfall erreicht? Mindestens zwei Notfall-Kontakte, rund um die Uhr erreichbar, mit Mobil-Nummer und Backup. Falls während des Tests ein unerwartetes Verhalten auftritt — eine Anwendung wird instabil, ein System hängt, eine Drittpartei meldet sich — pausieren wir umgehend und kontaktieren die Notfall-Liste.

Aus unserer Praxis: in mindestens jedem dritten Projekt entdecken wir im Pre-Engagement bereits Probleme, die der Kunde nicht auf dem Schirm hatte — etwa Systeme, die seit Jahren in der Produktiv-Umgebung laufen und auf die niemand mehr Zugriff hat, oder dritte Dienstleister, die mitprüfen müssten. Diese Klärung allein rechtfertigt oft schon das Pre-Engagement-Honorar.

Phase 2 — Intelligence Gathering (OSINT)

In der zweiten Phase sammeln wir öffentlich verfügbare Informationen über das Zielunternehmen. Das Prinzip: was wir mit legalen Mitteln finden, findet auch jeder echte Angreifer. Diese Phase passiert vorwiegend ohne Berührung der Zielsysteme.

Konkrete Aktivitäten umfassen Subdomain-Enumeration über Certificate Transparency Logs (crt.sh), DNS-Aufklärung, WHOIS-Recherche, Suche nach versehentlich öffentlich gestellten Git-Repositories und Dokumenten, Identifikation der eingesetzten Technologien (Server-Header, Wappalyzer-Analysen), Mitarbeiter-Profile auf LinkedIn und Xing für die spätere Phishing-Bewertung, sowie eine Prüfung gegen bekannte Daten-Leaks.

Aus diesem Material entsteht ein Asset-Inventar — und sehr oft die erste Überraschung: Subdomains, von denen die IT-Abteilung nichts wusste, Test-Server, die im Internet erreichbar sind, alte Marketing-Microsites mit veraltetem WordPress, oder vergessene Cloud-Konten ehemaliger Mitarbeiter. In etwa zwei Drittel unserer Engagements findet diese Phase bereits Befunde, die ohne Pentest jahrelang unsichtbar geblieben wären.

Phase 3 — Threat Modeling

Bevor wir mit dem eigentlichen Testen beginnen, priorisieren wir die Angriffsfläche. Nicht jedes System verdient gleich viel Aufmerksamkeit — Ressourcen sind begrenzt, und ein Pentest muss dort tief gehen, wo das Geschäfts-Risiko am größten ist.

Wir betrachten dabei drei Dimensionen: welche realistischen Angreifer-Profile sind relevant (opportunistische Massen-Angreifer, gezielte Wettbewerbs-Spionage, Insider, organisierte Cyberkriminalität), welche Assets würden bei Kompromittierung den größten Schaden anrichten (Kundendaten, geistiges Eigentum, Geschäftskontinuität), und welche Eintritts-Vektoren sind am wahrscheinlichsten gegeben Ihrer technischen Aufstellung.

Das Ergebnis ist eine priorisierte Risiko-Matrix, die für die folgenden Phasen den Fokus setzt. Bei einem typischen Mittelstands-Audit konzentriert sich der Hauptteil der Test-Zeit dann auf zwei bis drei priorisierte Angriffspfade — statt jedem System gleich viel Zeit zu widmen.

Phase 4 — Vulnerability Analysis

Jetzt beginnt die eigentliche Schwachstellen-Identifikation. Wir kombinieren drei Ansätze: automatisierte Scanner für Breite, manuelle Tests für Tiefe, und Code-Review wenn der Quellcode verfügbar ist.

Automatisierte Scans liefern eine erste Übersicht über bekannte CVEs in eingesetzter Software, fehlende Patches und offensichtliche Konfigurations-Schwächen. Wir nutzen je nach Scope eine Auswahl aus Nessus, Qualys, OpenVAS sowie eigene Custom-Checks aus unserer Reepa-Security-Plattform — letztere finden Konfigurations-Probleme, die generische Scanner nicht abdecken.

Manuelle Tests sind der Kern. Hier prüfen wir Geschäftslogik-Lücken, fehlerhafte Zugriffs-Kontrollen zwischen Rollen, Privilege-Escalation-Pfade, Session-Management-Schwächen und Eingabe-Validierung. Diese Klassen finden Scanner nicht — sie erfordern Verständnis für die fachliche Logik der Anwendung.

Code-Review ergänzt bei Grey-Box-Engagements den Black-Box-Test. Wir prüfen kritische Pfade (Authentifizierung, Autorisierung, Verschlüsselung, Datei-Uploads, externe Integrationen) im Quellcode und vergleichen mit dem beobachtbaren Verhalten.

Jeder Befund wird unmittelbar dokumentiert: betroffene Komponente, Reproduktions-Schritte, technische Klassifizierung (CWE-Mapping), erste Risiko-Einschätzung. Diese Dokumentation ist die Basis für den späteren Report — wir schreiben den Report nicht am Ende „aus dem Gedächtnis", sondern protokollieren live.

Phase 5 — Exploitation

Der Begriff klingt dramatisch, die Realität ist kontrolliert und dokumentiert. In der Exploitation-Phase verifizieren wir, dass die identifizierten Schwachstellen tatsächlich ausnutzbar sind — denn theoretische Risiko-Bewertung und reale Ausnutzbarkeit sind zwei verschiedene Dinge.

Konkret heißt das: wenn ein Scanner meldet, eine Anwendung sei „möglicherweise anfällig für SQL-Injection", führen wir einen kontrollierten, nicht-destruktiven Test durch, der die Ausnutzbarkeit nachweist oder ausschließt. Bei nachgewiesener Ausnutzbarkeit beschränken wir uns auf einen Proof-of-Concept — etwa das Lesen einer einzelnen Tabellen-Spalte aus der Datenbank — ohne tatsächliche Daten zu extrahieren oder zu manipulieren.

Dieser Schritt ist wichtig, weil er Theorie von Praxis trennt. Ein Vulnerability-Scan-Report mit 200 „kritischen" Funden ist häufig zu großen Teilen unausnutzbar — etwa weil eine vorgelagerte Web-Application-Firewall den Angriff blockiert oder weil die vermeintlich verwundbare Funktion gar nicht extern erreichbar ist. Die Exploitation-Phase reduziert die Befundsmenge auf das, was tatsächliches Geschäfts-Risiko darstellt.

Alle Aktivitäten werden mit Zeitstempeln und Quell-IP protokolliert. Sollte parallel ein Sicherheitsvorfall in Ihrer Umgebung auftreten, können Sie unsere Aktivitäten von echten Angriffen unterscheiden.

Phase 6 — Post-Exploitation

Wenn der initiale Zugang nachgewiesen ist, bewerten wir, was ein realer Angreifer von diesem Punkt aus erreichen könnte. Diese Phase beantwortet die Frage „Was bedeutet diese Schwachstelle für unser Geschäft?".

Konkret prüfen wir: welche Daten wären zugänglich (personenbezogene Kundendaten? Lohnabrechnungen? Geistiges Eigentum?), welche Folgesysteme wären erreichbar (Lateral-Movement von der Web-Anwendung ins interne Netz?), und welche Persistenz-Möglichkeiten existieren (kann ein Angreifer nach Behebung der initialen Lücke trotzdem im System bleiben?).

Auch in dieser Phase agieren wir kontrolliert. Wir extrahieren keine echten Daten, sondern dokumentieren die Erreichbarkeit. Wir installieren keine Persistenz, sondern weisen die theoretische Möglichkeit nach. Das ist ein wesentlicher Unterschied zur klassischen Red-Team-Übung, die explizit auch Persistenz und Lateral Movement durchführt — siehe dazu unseren Vergleich Red-Team vs Pentest.

Das Resultat dieser Phase ist die realistische Impact-Bewertung pro Befund — nicht „theoretisch könnte das schlimm sein", sondern „bei diesem Befund war folgender Datenzugriff nachweisbar erreichbar".

Phase 7 — Reporting

Der Report ist das Produkt, für das Sie bezahlen. Ein guter Pentest-Report adressiert drei verschiedene Lese-Zielgruppen mit jeweils passender Informationsdichte.

Executive Summary — eine Seite, für Geschäftsführung und Compliance-Officer. Welche Risiken bestehen, wie kritisch sind sie aggregiert, welche Geschäfts-Implikationen ergeben sich, was wird empfohlen. Keine technischen Details, keine Tool-Namen, keine Logs. Stattdessen klare Aussagen wie „acht der zwölf Befunde sind innerhalb von vier Wochen behebbar, die verbleibenden vier erfordern Architektur-Änderungen mit drei bis sechs Monaten Vorlauf".

Detaillierter Befunde-Katalog — pro Schwachstelle eine eigene Seite mit Klassifikation (CWE-Nummer, CVSS-Score), exakter Beschreibung der betroffenen Komponente, Reproduktions-Schritten (so dass Ihr Entwicklungs-Team den Befund verifizieren kann), Impact-Bewertung mit konkretem Geschäfts-Bezug, und priorisierter Remediation-Empfehlung.

Technischer Anhang — für die operative IT. Logs der Test-Aktivitäten, Zeitstempel, Tool-Versionen, eingesetzte Payloads. Diese Sektion erlaubt es, im Nachgang einzelne Befunde nachzuvollziehen oder bei Unklarheiten gezielt nachzuhaken.

Wir liefern den Report verschlüsselt (PGP oder S/MIME) per E-Mail und parallel über eine kennwortgeschützte Download-URL. Auf Wunsch findet eine Präsentation der Ergebnisse in Ihrer IT-Leitungssitzung statt — meist sehr wertvoll, weil sich offene Fragen in einer Diskussion schneller klären als per E-Mail.

Was Sie als Auftraggeber beisteuern

Ein erfolgreicher Pentest ist eine Partnerschaft, kein Auftrag „über die Mauer geworfen". Was wir von Ihnen brauchen, damit das Engagement effizient läuft:

• Eine technische Ansprechperson, erreichbar während der Test-Phase mit kurzer Reaktionszeit
• Bei Grey-Box-Tests: Test-Accounts in allen relevanten Rollen, idealerweise dedizierte Pentest-Accounts mit klarer Kennzeichnung
• Architektur-Dokumentation soweit vorhanden — Datenfluss-Diagramme, Schnittstellen-Übersichten, Berechtigungs-Konzepte
• Information an Ihren Hosting-Provider und ggf. Cloud-Anbieter, dass der Test stattfindet (verhindert automatische Sperrungen)
• Klare Eskalations-Wege für Notfälle und für die finale Befunde-Diskussion

Aus unserer Erfahrung: je besser die Vorbereitung, desto höher die Tiefe und desto wertvoller das Ergebnis. Engagements, in denen die Kunden-Seite chronisch nicht erreichbar ist, liefern messbar dünnere Reports — nicht weil wir weniger könnten, sondern weil offene Fragen nicht zeitnah geklärt werden können.

Nach dem Pentest — wie geht es weiter?

Der Report markiert nicht das Ende, sondern den Anfang. Drei typische Anschluss-Aktivitäten:

Remediation-Begleitung. Wir unterstützen Ihr Team bei der Umsetzung der Empfehlungen — entweder beratend in Code-Reviews oder direkt implementierend. Bei kritischen Architektur-Empfehlungen liefern wir konkrete Migrations-Pläne mit Zwischen-Schritten.

Re-Test. Nach Umsetzung der wichtigsten Maßnahmen prüfen wir gezielt die korrigierten Befunde nach. Im Idealfall stellen wir einen Re-Test-Report aus, der den Verbesserungs-Stand dokumentiert — ein nützliches Dokument für Cyber-Versicherung, Compliance-Audit oder Geschäftspartner-Anfragen.

Kontinuierliche Validierung. Da Schwachstellen ständig neu entstehen — durch Software-Updates, neue Anwendungen, Konfigurations-Änderungen — empfehlen wir den Übergang vom Jahres-Snapshot zur kontinuierlichen Validierung. Unsere Reepa-Security-Plattform übernimmt diese Rolle und liefert monatliche Soll/Ist-Berichte gegen die Pentest-Baseline.

Wer den Pentest als Einmal-Ereignis behandelt, hat ein Dokument für die Schublade. Wer ihn als Ausgangspunkt für kontinuierliche Verbesserung nutzt, hat eine messbar bessere Sicherheits-Position — und kann das gegenüber Versicherern, Behörden und Geschäftspartnern auch nachweisen. Dieses Thema vertiefen wir im Cybersecurity-Pillar sowie im Detail-Artikel zu Pentest-Kosten und Investitions-Modellen.

Häufige Fragen