Ethical Hacking - bewährte Methodiken und Praktiken Schritt für Schritt

Die meisten Menschen stellen sich einen Pentester als jemanden vor, der intuitiv und ohne Plan in Systeme einbricht. Das ist ein Fehler. Professionelles Ethical Hacking beruht auf streng definierten methodischen Rahmen, die jede Arbeitsphase festlegen, von der ersten Aufklärung bis zum finalen Kundenbericht. Ohne diese Struktur verwandelt sich ein Sicherheitsaudit in eine zufällige Sammlung von Scans und Versuchen, bei denen kritische Schwachstellen leicht übersehen werden. In diesem Artikel siehst du, welche Standards die Branche prägen und wie die einzelnen Phasen eines professionellen Pentests aussehen.

Inhaltsverzeichnis

• Warum ist eine Methodik im Ethical Hacking notwendig?

• Schlüsselphasen des Prozesses nach NIST SP 800-115

• Methodik für Webanwendungstests: OWASP Testing Guide

• Besonderheiten der Testmodelle: black box, white box, grey box

• Sicherheitsbewertungsmetriken - PTES, OSSTMM und Praxis

• Unsere Perspektive auf die Ethical-Hacking-Methodik

• Professionelle Ausrüstung für jedes Testszenario

• Häufig gestellte Fragen

Wichtigste Erkenntnisse

Warum ist eine Methodik im Ethical Hacking notwendig?

Ein Pentest ohne Methodik gleicht einer medizinischen Diagnose ohne Untersuchungsprotokoll. Man kann etwas entdecken, aber genauso leicht die wichtigsten Probleme übersehen. Ohne einen formalen Aktionsplan werden verschiedene Bereiche des getesteten Systems ungleichmäßig abgedeckt. Manche Ressourcen werden mehrfach überprüft, andere völlig ausgelassen.

Ein standardisierter Ansatz löst dieses Problem direkt. NIST SP 800-115 unterteilt den Pentest in 4 Phasen: Planning, Discovery, Attack und Reporting. Jede Phase hat klar definierte Ziele, Inputs und Outputs. Ein Pentester, der nach dieser Struktur arbeitet, muss die Reihenfolge der Aktionen nicht improvisieren, weil die Methodik das für ihn tut.

Die Methodik hat auch eine rechtliche Dimension. Jede Handlung des Pentesters muss eine dokumentierte Grundlage haben. Eine schriftliche Zustimmung des Systemeigentümers, der Testumfang und der Arbeitsplan sind notwendige Elemente, um ein Audit gesetzeskonform durchzuführen. Ohne diese Dokumente setzt sich selbst der ethischste Spezialist strafrechtlicher Verantwortung für unbefugten Zugriff aus.

Nachfolgend die wichtigsten Gründe, warum die Methodik die Grundlage der Arbeit jedes Pentesters ist:

• Verhindert, dass kritische Bereiche des Systems übersehen werden

• Garantiert die Wiederholbarkeit und Vergleichbarkeit von Ergebnissen zwischen Audits

• Liefert dem Kunden einen transparenten Bericht mit dokumentiertem Handlungspfad

• Schützt rechtlich sowohl den Pentester als auch den Auftraggeber

• Erleichtert die Teamarbeit bei großen Projekten

"Ein wirksamer Pentester weiß nicht nur, wie man angreift. Er weiß auch, wann er aufhören und wie er jeden Schritt dokumentieren muss, damit die Ergebnisse für den Kunden Wert haben und rechtlich sicher sind."

Es lohnt sich auch zu bedenken, dass die Methodik nicht standardisierte Bereiche umfasst. Zum Beispiel erfordert ein Social-Engineering-Angriff in Pentests separate Zustimmungs- und Dokumentationsverfahren, weil er nicht nur technische Systeme, sondern auch die Privatsphäre der Mitarbeiter der getesteten Organisation berührt.

Profi-Tipp: Erstelle vor jedem Projekt ein Rules-of-Engagement-Dokument. Nimm darin den IP-Umfang, die Testmethoden, Zeitfenster und Kontaktdaten zur Eskalation von Vorfällen auf. Es ist das Dokument, das beide Seiten während des gesamten Audits schützt.

Schlüsselphasen des Prozesses nach NIST SP 800-115

NIST SP 800-115 ist einer der am weitesten verbreiteten Standards in der Pentest-Branche. Seine Popularität beruht auf Präzision. Jede Phase hat konkrete Aufgaben und messbare Ergebnisse. Der Standard wurde 2008 vom National Institute of Standards and Technology veröffentlicht, ist öffentlich zugänglich und bleibt trotz seines Alters ein grundlegendes Referenzdokument, das regelmäßig in detaillierteren Frameworks zitiert wird.

Gemäß diesem Standard sind die vier Phasen des Pentests Planning, Discovery, Attack und Reporting. Nachfolgend eine Schritt-für-Schritt-Beschreibung jeder Phase.

1. Planning (Planung) - Vorbereitungsphase. Es werden Auditziel, Umfang der Aktivitäten, Testmodell und rechtliche Anforderungen definiert. Verträge und Zustimmungsdokumente werden unterzeichnet. Auch die für das Projekt benötigten Personal- und Hardware-Ressourcen werden festgelegt.

2. Discovery (Aufklärung) - Zweistufige Aufklärung. Der erste Teil ist passives Sammeln von Informationen über das Ziel, wie Subdomains, WHOIS-Daten, E-Mail-Adressen und Servertechnologien. Der zweite Teil ist aktives Scannen: Erkennen offener Ports, Service-Versionen, Betriebssysteme und potenzieller Schwachstellen. Hier kommen Tools wie Nmap, Shodan oder Nessus zum Einsatz.

3. Attack (Angriff) - Ausnutzung der erkannten Schwachstellen. Der Pentester versucht, unautorisierten Zugriff zu erlangen, Privilegien zu eskalieren, sich lateral im Netzwerk zu bewegen und Daten zu sammeln. Jede Aktion wird in Echtzeit dokumentiert. Diese Phase bestätigt die Realität der in Discovery gefundenen Bedrohungen.

4. Reporting (Berichterstattung) - Übergabe der Ergebnisse an den Kunden. Der Bericht enthält eine Beschreibung der Methodik, eine Liste der erkannten Schwachstellen mit Risikobewertung, Nachweise der Ausnutzung und Empfehlungen zur Behebung. Ein guter Bericht trennt technische Ergebnisse von einer Zusammenfassung für die Geschäftsleitung.

Die Discovery-Phase verdient besondere Aufmerksamkeit, weil hier gemachte Fehler sich durch den Rest des Audits fortpflanzen. Übersieht der Pentester beim Scannen ein ganzes Subnetz, wird die Attack-Phase es nie berühren. Die Genauigkeit der Aufklärung entscheidet über die Qualität der Endergebnisse.

Profi-Tipp: Wende in der Discovery-Phase sowohl aktives Scannen als auch passive Techniken an. Viele wertvolle Informationen über die Zielinfrastruktur findest du in öffentlich zugänglichen Code-Repositories wie GitHub, ohne Netzwerkverkehr zu erzeugen. Besonders hilfreich ist die Prüfung der Commit-Historie auf Leaks von API-Schlüsseln und Passwörtern. Ähnliche Techniken sind auch beim Anwendungs-Fuzzing nützlich, wo Architekturkenntnisse vor Testbeginn das Fuzzing auf die riskantesten Endpunkte lenken lassen.

Methodik für Webanwendungstests: OWASP Testing Guide

Wenn das Auditziel eine Webanwendung ist, muss die allgemeine NIST-SP-800-115-Methodik um einen spezialisierten Rahmen ergänzt werden. Hier kommt der OWASP Web Security Testing Guide (WSTG, früher OWASP Testing Guide) ins Spiel, der De-facto-Standard für diesen Bereich.

OWASP Testing Guide enthält 11 Hauptkategorien von Tests: Information Gathering, Configuration and Deployment Management, Identity Management, Authentication, Authorization, Session Management, Input Validation, Error Handling, Cryptography, Business Logic und Client-Side Testing. Jede Kategorie enthält detaillierte Testvektoren mit Beschreibung der Technik, der Tools und der erwarteten Ergebnisse.

Der praktische Wert des OWASP Testing Guide liegt darin, dass es nicht nur eine Bedrohungsliste ist. Jeder Test ist auf technischer Ebene beschrieben. Der Pentester erhält ein fertiges Rezept: was zu suchen ist, wie es zu prüfen und wie das Ergebnis zu bewerten ist.

Nachfolgend ein Überblick ausgewählter Kategorien aus dem OWASP Testing Guide:

• Information Gathering - Sammeln von Daten über Framework, Server, Backend-Technologien und URL-Struktur

• Configuration Management - Prüfung der Serverkonfiguration, HTTPS, Sicherheitsheader, TLS-Konfiguration

• Authentication Testing - Tests der Passwortrichtlinie, Lockout-Mechanismen, Multi-Faktor-Authentifizierung, Anfälligkeit gegen Brute-Force

• Session Management Testing - Analyse von Session-Tokens, Cookie-Sicherheit, Session-Fixation- und CSRF-Anfälligkeiten

• Authorization Testing - Überprüfung der Zugriffskontrolle, Tests zur Privilegieneskalation, Insecure Direct Object Reference

• Input Validation Testing - SQL Injection, XSS, Command Injection, Path Traversal, XML Injection

• Business Logic Testing - Erkennung von Geschäftslogikfehlern, die schwer automatisch zu identifizieren sind

• Client-Side Testing - Analyse von JavaScript, DOM-based XSS, HTML Injection, WebSocket Security

Die systematische Dokumentation der Ergebnisse während der Tests ist ebenso wichtig wie die Tests selbst. Jeder gefundene Angriffsvektor sollte sofort mit Beweis festgehalten werden: Screenshot, HTTP-Request-Log oder Tool-Output. Die Rekonstruktion der Spuren nach Abschluss des Audits ist schwierig und zeitraubend. Praktische Hinweise zur Strukturierung der Testphase findest du in der detaillierten Fuzzing-Anleitung, in der auch die Organisation automatischer Scan-Ergebnisse beschrieben ist.

Profi-Tipp: Behandle die Kategorie Business Logic Testing immer als manuellen, nicht als automatisierten Test. Kein automatisches Tool versteht die Geschäftslogik einer Anwendung so wie ein Mensch. Prüfe Abläufe von Einkaufsprozessen, Coupon-Systemen und Kontolimits Schritt für Schritt von Hand, denn genau dort verstecken sich die Schwachstellen, die automatisierte Scanner übersehen.

Besonderheiten der Testmodelle: black box, white box, grey box

Die Wahl des Testmodells ist eine der ersten Entscheidungen in der Auditplanung. Jedes Modell setzt ein anderes Maß an Vorwissen über das getestete System voraus. Die Entscheidung beeinflusst den Realismus des Tests, die Projektdauer und den Umfang möglicher Ergebnisse.

Black box, white box und grey box sind die drei grundlegenden Ansätze für Penetrationstests. Jeder erfordert eine schriftliche Zustimmung des Systemeigentümers, ohne Ausnahme.

Das Black-Box-Modell wird am häufigsten von Unternehmen gewählt, die sehen wollen, was ein externer Angreifer sieht, bevor er auf Anmeldedaten zugreift. Der Pentester startet ohne Informationen außer der Zieladresse. Es ist der zeitaufwendigste Ansatz, liefert aber das realistischste Bild der externen Exposition einer Organisation.

White box gibt dem Pentester vollen Zugriff auf Quellcode, Architekturdokumentation, Serverkonfigurationen und Netzwerkdiagramme. Dadurch kann der Tester Anwendungslogik und Infrastruktur auf einem Niveau analysieren, das in Black Box unmöglich ist. Dieser Ansatz ist besonders effektiv beim Sicherheitsaudit von Code vor der Produktivnahme.

Grey box ist der in der Praxis am häufigsten genutzte Kompromiss. Der Pentester erhält zum Beispiel ein Benutzerkonto mit grundlegenden Rechten und Kenntnis der Netzwerksegmentierung, aber keinen Zugriff auf den Quellcode. Das erlaubt, die Testzeit auf reale Angriffsvektoren zu fokussieren und gleichzeitig die teilweise Perspektive eines externen Eindringlings beizubehalten.

Schlüsselprinzipien bei der Modellwahl:

• Das Auditziel bestimmt das Modell. Ein Audit vor dem Anwendungsstart ist mit white box am besten abgedeckt. Die Reifeprüfung der Verteidigung gegen externe Angriffe erfordert black box oder grey box.

• Zeit und Budget spielen eine Rolle. Black box ist zeitlich am teuersten. White box ist hinsichtlich des erforderlichen Analysewissens am teuersten.

• Eine schriftliche Zustimmung des Systemeigentümers ist unabhängig vom Modell erforderlich. Ohne Zustimmung ist das Audit illegal, selbst wenn es mit Methoden der passiven Aufklärung durchgeführt wird.

• Der geografische Testumfang und Zeitfenster müssen für jedes Modell separat definiert werden.

"Kein Testmodell ersetzt ein anderes. Sicherheitsreife Organisationen kombinieren Ansätze regelmäßig und führen einmal jährlich black box und bei jeder wesentlichen Systemänderung white box durch."

Sicherheitsbewertungsmetriken - PTES, OSSTMM und Praxis

Schwachstellen zu finden ist eine Sache. Sie messbar und für den Kunden verständlich zu beschreiben, ist eine ganz andere Fähigkeit. Die methodischen Rahmen PTES (Penetration Testing Execution Standard) und OSSTMM (Open Source Security Testing Methodology Manual) antworten auf diese Herausforderung mit konkreten Messwerkzeugen.

PTES und OSSTMM bieten Metriken wie RAV (Risk Assessment Value), die es ermöglichen, den Sicherheitszustand eines Systems empirisch zu messen. RAV ist eine balance metric, berechnet aus drei Komponenten: Operational Security, Controls und Limitations. Operational Security wird über Porosity gemessen, die aus drei Elementen besteht: Visibility (Sichtbarkeit der Ressourcen), Access (Zugangspunkte zum System) und Trust (Grad des Vertrauens zwischen Komponenten). Das Endergebnis liefert eine quantifizierte Risikobewertung auf einer Skala relativ zu 100.

In der Branchenpraxis ist die Anwendung solcher Metriken nach wie vor eine Minderheit. Die meisten Pentest-Berichte enthalten Listen von Schwachstellen mit CVSS-Bewertung (Common Vulnerability Scoring System), liefern aber keine ganzheitliche Sicherheitsmetrik des Systems. Diese Lücke versucht OSSTMM zu füllen.

Die praktische Anwendung der RAV-Metriken sieht wie folgt aus:

• Visibility - wie viele Kontaktpunkte zum System sind öffentlich zugänglich? Jeder offene Port, öffentliche API-Endpunkt oder Subdomain erhöht diesen Wert.

• Access - wie hoch ist die tatsächliche Anfälligkeit der entdeckten Ressourcen? Hier fließen Ergebnisse von Schwachstellenscans mit CVSS-Gewichtung ein.

• Trust - vertrauen sich Systemkomponenten gegenseitig übermäßig? Unbegrenzte Trust-Beziehungen zwischen Netzwerksegmenten erhöhen das Risiko lateraler Angreiferbewegungen drastisch.

Es lohnt sich auch zu wissen, dass PTES sieben Pentesting-Phasen definiert: Pre-engagement Interactions, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post Exploitation und Reporting. Dies ist eine detailliertere Unterteilung als die vier NIST-SP-800-115-Phasen, was PTES zu einer nützlichen Ergänzung macht, besonders bei großen Unternehmensprojekten.

Profi-Tipp: Übersetze in Berichten für Geschäftskunden die technische Beschreibung von Schwachstellen in die Sprache finanzieller und operativer Risiken. Statt "SQL Injection im Parameter ID festgestellt" schreibe "ein Angreifer kann auf die gesamte Kundendatenbank zugreifen und das Unternehmen DSGVO-Bußgeldern bis zu 20 Millionen Euro sowie einem Reputationsverlust aussetzen." Dieselbe Bedrohung, aber für Entscheider weit besser lesbar.

Die Verwendung standardisierter Metriken erhöht auch die Vergleichbarkeit von Audits über die Zeit. Ein Kunde, der Pentests zyklisch beauftragt, kann Veränderungen des RAV-Werts zwischen Projekten verfolgen und objektiv beurteilen, ob seine Sicherheitsinvestitionen messbare Ergebnisse bringen. Ohne solche Metriken wird jeder Bericht subjektiv bewertet, was das Risikomanagement auf Organisationsebene erschwert.

Unsere Perspektive auf die Ethical-Hacking-Methodik

Der Pentest-Markt hat ein Problem, über das selten offen gesprochen wird. Viele Unternehmen, die Sicherheitsaudits beauftragen, behandeln die Methodik als Formalität. Sie interessiert das Abschlusszertifikat, nicht die Qualität des Prozesses. So entstehen Situationen, in denen ein Audit "nach Methodik" in Wirklichkeit ein flüchtiger Scan einiger Ports und ein automatisch generierter Bericht ist.

Methodik ist ein Werkzeug, nicht Selbstzweck. NIST SP 800-115, OWASP Testing Guide, PTES, OSSTMM. Jeder dieser Standards liefert Struktur, aber die Auditqualität hängt vom Pentester ab, der ihn anwendet. Ein Werkzeug in den Händen einer Person, die nicht versteht, warum sie einen Schritt ausführt, liefert schlechtere Ergebnisse als ein erfahrener Spezialist ohne formalen Standard.

Aus der langfristigen Perspektive des Wissensaufbaus in dieser Branche lohnt es sich, den typischen Bildungsansatz umzudrehen. Statt zuerst Werkzeuge zu lernen und erst dann ihren Platz in der Methodik zu suchen, fängt man besser mit dem Verständnis der Ziele jeder Phase an. Wenn du weißt, was du in der Discovery-Phase suchst, wird das Greifen zu den richtigen Werkzeugen natürlich. Wenn du das Ziel der Attack-Phase kennst, siehst du, welche Exploits Aufmerksamkeit verdienen und welche Zeitverschwendung sind.

Eine zweite oft übersehene Frage ist der Unterschied zwischen einem Pentest und einer Sicherheitsbewertung. Pentest ist der Versuch, konkrete Schwachstellen auszunutzen. Eine Sicherheitsbewertung ist die umfassendere Prüfung von Architektur, Richtlinien und Verfahren. Die in diesem Artikel beschriebenen Methodiken betreffen hauptsächlich Pentests, aber ein professioneller Sicherheitsberater sollte beide Ansätze kennen und wissen, wann welcher angemessen ist. Ein Kunde bittet oft um einen "Penetrationstest", wenn sein eigentliches Problem eine Prüfung der Sicherheitsrichtlinien oder der Infrastrukturkonfiguration erfordert.

Schließlich die Frage der Hardware. Die beste Methodik der Welt nützt nichts, wenn ein Tester ungeeignete Ausrüstung für spezifische Testszenarien verwendet. Tests drahtloser Netzwerke erfordern andere Netzwerkkarten als Tests von Webanwendungen. Tests physischer Sicherheit erfordern RFID/NFC-Geräte. Die Kohärenz zwischen Methodik, Software-Tools und Hardware definiert eine professionelle Werkstatt.

Professionelle Ausrüstung für jedes Testszenario

Eine gut gewählte Methodik erfordert passende Ausrüstung. Bei Sapsan bieten wir Spezialgeräte für Pentester, die im Feld und im Labor arbeiten.

In unserem Shop findest du Werkzeuge für Wi-Fi-Netzwerktests, RFID/NFC-Geräte für physische Sicherheitsaudits, SDR-Equipment für Funktests, BadUSB-Zubehör sowie eine vollständige Ausstattung für Flipper Zero. Jedes Produkt ist auf Pentest-Anwendungen ausgelegt, nicht auf allgemeinen Gebrauch. Sapsan liefert Hardware an Profis in ganz Europa und den USA mit schneller Auftragsabwicklung. Ob du ein Black-Box-Audit eines Unternehmensnetzes oder Tests von Webanwendungen durchführst - wir haben die Hardware, die deine methodische Werkstatt ergänzt.

Häufig gestellte Fragen

Erfordert ein Audit immer die Anwendung aller NIST-SP-800-115-Phasen?

Nicht jede Phase muss zu 100 % angewendet werden, doch ein vollständiger Zyklus erhöht die Erkennungsrate von Schwachstellen und die Berichtsqualität deutlich. Die vier Phasen von NIST SP 800-115 lassen sich an den Projektumfang anpassen, das Auslassen der Discovery- oder Reporting-Phase senkt jedoch den Wert des gesamten Audits.

Können Methodiken (z. B. OWASP mit NIST) in einem Pentest kombiniert werden?

Ja, Methodiken werden oft kombiniert, besonders bei komplexen Systemen, die unterschiedliche Tools und Ansätze erfordern. Der OWASP Testing Guide mit seinen 12 Kategorien ergänzt den allgemeinen Rahmen NIST SP 800-115 hervorragend bei Audits, die Webanwendungen umfassen.

Wie wählt man das Testmodell: black box, white box oder grey box?

Die Entscheidung wird auf Basis des Projektziels, der verfügbaren Informationen und der strikten Zustimmung des Systemeigentümers getroffen. Wie angemerkt, ist die schriftliche Zustimmung des Systemeigentümers unabhängig vom gewählten Modell erforderlich, und die Wahl zwischen black, white und grey box ergibt sich aus der Priorität von Realismus versus Analysetiefe.

Warum RAV-Metriken in der Pentest-Praxis einsetzen?

Metriken erleichtern die Kommunikation von Risiken und Fortschritten beim Schutz, Kunden gewinnen ein messbares Bild des Systemzustands. RAV aus dem OSSTMM-Framework erlaubt den Vergleich von Ergebnissen zwischen zyklischen Audits und die objektive Bewertung der Wirksamkeit eingeführter Schutzmaßnahmen über die Zeit.