Diese Seite fasst die wichtigsten Werkzeuge für Reconnaissance / Angriffsflächen-Mapping und Web-Schwachstellen-Testing zusammen. Zu jedem Befehl gibt es eine eigene Erklärung: was er tut, wann man ihn einsetzt und worauf zu achten ist.

ℹ️ Hinweis: Alle Beispiele verwenden Dokumentations-Adressen (192.0.2.0/24, target.example). Sämtliche Aktivitäten nur im schriftlich freigegebenen Scope durchführen. Aktive Scans, Brute-Force und Fuzzing können Dienste stören und sind ohne Erlaubnis strafbar (§ 202a–202c StGB).

Einstufung der Befehle:

CORE – Standard, geringe Last, gefahrlos im Scope.
ADVANCED – tiefergehend, erfordert Verständnis der Optionen.
AGGRESSIV – hohe Last / auffällig / potenziell störend – nur mit Bedacht und klarer Freigabe.

Teil 1 – Recon & Attack Surface Mapping

Nmap + Masscan – Netzwerk- und Port-Discovery

Nmap ist das Standardwerkzeug zur Host- und Portanalyse. Masscan ergänzt es, wenn große Adressbereiche in kurzer Zeit abgesucht werden sollen – Masscan findet schnell offene Ports, Nmap liefert danach die Details.

Host-Discovery (CORE)

nmap -sn 192.0.2.0/24

Ein reiner Ping-Scan ohne Portscan (-sn = „no port scan"). Nmap prüft nur, welche Hosts im Netz überhaupt antworten. Ideal als erster Schritt, um aus einem Adressbereich die lebenden Ziele herauszufiltern, bevor man aufwändiger enumeriert. Erzeugt wenig Last und fällt kaum auf.

Schneller Top-Ports-Scan (CORE)

nmap -sS --top-ports 1000 --open 192.0.2.10

SYN-Scan (-sS, „halboffen", schnell und ressourcenschonend) auf die 1000 statistisch häufigsten TCP-Ports. --open zeigt nur tatsächlich offene Ports an und hält die Ausgabe übersichtlich. Guter Standard-Einstieg pro Host. Der SYN-Scan benötigt Root-Rechte.

Versionserkennung (ADVANCED)

nmap -sV --version-all 192.0.2.10

-sV ermittelt die konkrete Software und Version hinter jedem offenen Port. --version-all fährt die Erkennungsintensität voll hoch, probiert also alle Prüf-Signaturen aus. Genauer, aber langsamer und gesprächiger im Netz. Sinnvoll, wenn du für gefundene Dienste gezielt nach bekannten Schwachstellen suchen willst.

Default-Skripte + OS-Erkennung (ADVANCED)

nmap -sC -sV -O 192.0.2.10

Kombiniert drei Dinge: -sC führt die Standard-NSE-Skripte aus (übliche, sichere Prüfungen), -sV macht die Versionserkennung und -O versucht, das Betriebssystem zu bestimmen. Ein kompakter „Rundumschlag" für einen Einzelhost. -O braucht Root und liefert bei gefilterten Zielen nicht immer eindeutige Ergebnisse.

Alle TCP-Ports (AGGRESSIV)

nmap -p- --open -T4 192.0.2.10

-p- scannt alle 65535 TCP-Ports statt nur der häufigen – wichtig, weil interessante Dienste oft auf ungewöhnlichen Ports laufen. -T4 beschleunigt das Timing spürbar. Deutlich lauter und lastintensiver; auf empfindlichen Zielen lieber -T3 oder ohne Zeitdruck fahren.

Häufige UDP-Dienste (ADVANCED)

nmap -sU --top-ports 100 192.0.2.10

Prüft die 100 häufigsten UDP-Ports (-sU). UDP wird gern vergessen, dabei stecken dort DNS, SNMP, NTP, TFTP u.v.m. – oft mit lohnenden Fehlkonfigurationen. UDP-Scans sind langsam, weil offene und gefilterte Ports schwer zu unterscheiden sind; deshalb hier bewusst auf die Top-100 begrenzt.

HTTP-Titel und Header (CORE)

nmap -p80,443 --script http-title,http-headers 192.0.2.10

Startet gezielt zwei NSE-Skripte gegen die Webports: http-title liest den Seitentitel, http-headers zeigt die HTTP-Antwortheader. Schneller Weg, um zu sehen, welche Web-Anwendung läuft und welche Server-/Security-Header gesetzt sind – gutes Bindeglied zur späteren Web-Analyse.

Masscan – schnelle Portsuche (AGGRESSIV)

sudo masscan 192.0.2.10 -p1-65535 --rate 500

Masscan durchsucht alle Ports mit sehr hoher Geschwindigkeit. --rate 500 begrenzt die Paketrate bewusst auf 500 Pakete/Sekunde, um das Ziel und das eigene Netz nicht zu überlasten – der Standardwert wäre um Größenordnungen aggressiver. Immer mit gedrosselter Rate arbeiten und die Ergebnisse anschließend mit Nmap verifizieren.

Masscan über ein Subnetz (AGGRESSIV)

sudo masscan 192.0.2.0/28 -p80,443,8080,8443 --rate 300

Sucht in einem kleinen freigegebenen Subnetz gezielt nach den typischen Web-Ports. So findest du schnell alle exponierten Weboberflächen im Bereich, ohne jeden Host einzeln anzufassen. Die niedrige Rate hält das Verfahren netzschonend.

Chain: Masscan-Ergebnisse an Nmap übergeben (CHAIN)

awk '/open/{print $4}' masscan.lst | sort -u > hosts.txt && nmap -sV -iL hosts.txt

Ein typischer Workflow: awk zieht die Host-Adressen der offenen Ports aus der Masscan-Ausgabe, sort -u entfernt Duplikate, und das Ergebnis wird per -iL als Zielliste an Nmap gefüttert. So kombinierst du Masscans Tempo mit Nmaps genauer Versionserkennung.

tshark – Traffic- und Protokollanalyse

tshark ist die Kommandozeilen-Variante von Wireshark. Sie eignet sich gut für Automatisierung, für Arbeit auf Servern ohne GUI und um Mitschnitte reproduzierbar auszuwerten.

Interfaces auflisten (CORE)

tshark -D

Listet alle Capture-Schnittstellen auf, die tshark sieht, jeweils mit Nummer und Name. Immer der erste Schritt, damit du beim Mitschneiden das richtige Interface (z. B. eth0) erwischst.

Gezielt einen Host mitschneiden (CORE)

sudo tshark -i eth0 -f "host 192.0.2.10" -w target.pcapng

Schneidet nur Verkehr von und zu einem bestimmten Host mit. -f ist ein Capture-Filter (BPF-Syntax), der schon beim Aufzeichnen filtert – das hält die Datei klein und relevant. -w schreibt den Mitschnitt in eine Datei zur späteren Analyse. Auf den Scope beschränken, um keinen fremden Verkehr aufzuzeichnen.

HTTP-Pakete anzeigen (CORE)

tshark -r target.pcapng -Y http

Liest eine gespeicherte Datei (-r) und zeigt per Display-Filter (-Y) nur HTTP-Pakete. Anders als der Capture-Filter wirkt der Display-Filter erst bei der Auswertung, du kannst also dieselbe Datei mehrfach unter verschiedenen Blickwinkeln ansehen.

DNS isolieren (CORE)

tshark -r target.pcapng -Y dns

Filtert DNS-Anfragen und -Antworten heraus. Nützlich, um aufgelöste Namen, verdächtige Domains oder ungewöhnliche Nameserver-Kommunikation zu erkennen.

TLS-Metadaten prüfen (ADVANCED)

tshark -r target.pcapng -Y tls

Zeigt TLS-Pakete inklusive Handshake-Details. Auch ohne Entschlüsselung sind Metadaten wertvoll: angebotene Cipher, Zertifikatsnamen (SNI/CN), TLS-Version – daraus lassen sich Fehlkonfigurationen und veraltete Verfahren ablesen.

Eine TCP-Verbindung verfolgen (ADVANCED)

tshark -r target.pcapng -Y "tcp.stream eq 0"

Jede TCP-Verbindung bekommt eine fortlaufende Stream-Nummer. Mit tcp.stream eq 0 isolierst du genau eine Konversation vom Verbindungsaufbau bis zum Abbau. Praktisch, um einen einzelnen Request/Response-Ablauf sauber nachzuvollziehen.

TCP-Resets finden (ADVANCED)

tshark -r target.pcapng -Y "tcp.flags.reset==1"

Filtert alle Pakete mit gesetztem RST-Flag. Gehäufte Resets deuten auf abgewiesene Verbindungen, Firewalls, abgestürzte Dienste oder Portscans hin – ein guter Indikator für Probleme oder Abwehrmaßnahmen.

TCP-Konversationsübersicht (AGGRESSIV)

tshark -r target.pcapng -z conv,tcp -q

-z conv,tcp erzeugt eine Statistik aller TCP-Konversationen (wer mit wem, wie viele Pakete/Bytes), -q unterdrückt die normale Paketausgabe zugunsten der Zusammenfassung. Guter Überblick, welche Verbindungen dominieren.

Protokollhierarchie (AGGRESSIV)

tshark -r target.pcapng -z io,phs -q

Baut eine Baumübersicht aller im Mitschnitt vorkommenden Protokolle mit Paketzahlen. Schneller Weg, um zu sehen, welche Protokolle überhaupt im Spiel sind, bevor man ins Detail geht.

Chain: Felder für die Auswertung exportieren (CHAIN)

tshark -r target.pcapng -T fields -e ip.src -e ip.dst -e tcp.dstport > evidence.tsv

-T fields gibt statt ganzer Pakete nur ausgewählte Felder aus – hier Quell-IP, Ziel-IP und Zielport. Das Ergebnis ist eine tabellarische TSV-Datei, die sich gut für Reports, Korrelationen oder die Weiterverarbeitung in anderen Tools eignet.

Shodan – externe Exposition & OSINT

Shodan indexiert im Internet erreichbare Dienste. Damit erkennst du aus der Außensicht (ganz ohne eigenen aktiven Scan), was von einem Ziel öffentlich sichtbar ist. Benötigt ein Konto und einen API-Key.

Host abfragen (CORE)

shodan host 192.0.2.10

Zeigt alle von Shodan indexierten, internetseitig erreichbaren Dienste einer IP – offene Ports, Banner, erkannte Software, Standort. Rein passiv: du fragst Shodans Datenbank ab, ohne das Ziel selbst zu berühren.

Domain-Infos (CORE)

shodan domain target.example

Liefert die zu einer Domain gespeicherten DNS-Informationen und Subdomains. Guter erster OSINT-Schritt, um die Struktur einer Domain zu verstehen.

Nach Hostname suchen (CORE)

shodan search "hostname:target.example"

Durchsucht Shodans Index nach Einträgen, deren Hostname zur Domain passt. So findest du zugehörige, exponierte Systeme, die dir sonst vielleicht entgehen.

Nach Zertifikatsname suchen (ADVANCED)

shodan search "ssl.cert.subject.cn:target.example"

Sucht Dienste, deren TLS-Zertifikat auf die Ziel-Domain ausgestellt ist. Sehr wirksam, um verbundene Infrastruktur aufzudecken – auch dann, wenn der Hostname im DNS nicht offensichtlich ist.

HTTPS nach Organisation filtern (ADVANCED)

shodan search "org:\"Example Org\" port:443"

Grenzt die Suche auf eine Organisation und Port 443 ein. Nützlich, um die HTTPS-Angriffsfläche einer bestimmten Organisation zu überblicken. Der Org-Name muss exakt passen und in Anführungszeichen stehen.

Indexierte HTTP-Titel (CORE)

shodan search "hostname:target.example http.title:*"

Sucht Einträge, bei denen ein HTTP-Titel indexiert ist. Über die Titel bekommst du schnell einen Eindruck, welche Anwendungen (Login-Portale, Admin-Panels, Standardseiten) im Umfeld der Domain laufen.

Treffer zählen (CORE)

shodan count "hostname:target.example"

Gibt nur die Anzahl passender Treffer zurück, ohne Ergebnisse abzurufen. Praktisch, um die Größe der externen Angriffsfläche einzuschätzen, und schont dein Shodan-Query-Kontingent.

Ergebnisse herunterladen (AGGRESSIV)

shodan download shodan.json.gz "hostname:target.example"

Lädt den kompletten Treffersatz als komprimierte JSON-Datei für die Offline-Auswertung herunter. Achtung: verbraucht je nach Trefferzahl deutlich Query-Credits, deshalb vorher mit count die Menge prüfen.

Felder extrahieren (ADVANCED)

shodan parse --fields ip_str,port,org,hostnames shodan.json.gz

Zieht aus der heruntergeladenen Datei nur die relevanten Felder heraus. So machst du aus dem umfangreichen JSON eine kompakte, gut lesbare Übersicht der wichtigsten Informationen.

Chain: kompakte Host/Port-Liste bauen (CHAIN)

shodan search "hostname:target.example" --fields ip_str,port | sort -u > shodan-hosts.txt

Erzeugt direkt aus der Suche eine deduplizierte Liste aus IP und Port. Diese Liste kannst du anschließend als Eingabe für die eigene (freigegebene) aktive Verifikation verwenden.

Recon-ng – automatisierter OSINT-Workspace

Recon-ng ist ein modulares OSINT-Framework mit eigener Konsole und Datenbank. Es sammelt Informationen aus vielen Quellen und legt sie strukturiert in einem Workspace ab.

Konsole starten (CORE)

recon-ng

Startet die interaktive Recon-ng-Konsole. Von hier aus verwaltest du Workspaces, Module und die gesammelten Daten.

Workspace anlegen (CORE)

workspaces create hexsec-target

Legt einen isolierten Arbeitsbereich für ein Engagement an. Jeder Workspace hat seine eigene Datenbank – so hältst du die Ergebnisse verschiedener Ziele sauber getrennt.

Module suchen (CORE)

marketplace search domains-hosts

Durchsucht den Marketplace nach Modulen, die aus einer Domain zugehörige Hosts ermitteln. So findest du das passende Werkzeug für die jeweilige Aufgabe.

Modul installieren (ADVANCED)

marketplace install recon/domains-hosts/hackertarget

Installiert ein ausgewähltes Recon-Modul. Manche Module benötigen zusätzlich einen API-Key (in Recon-ng über keys add hinterlegt); rein passive Module wie dieses funktionieren meist ohne.

Modul laden (CORE)

modules load recon/domains-hosts/hackertarget

Lädt das installierte Modul in den aktuellen Workspace, damit du es konfigurieren und ausführen kannst.

Quelle setzen (CORE)

options set SOURCE target.example

Legt die freigegebene Ausgangs-Domain fest, gegen die das Modul arbeiten soll. Immer sicherstellen, dass die Quelle im Scope liegt.

Modul ausführen (CORE)

run

Führt das geladene Modul mit den gesetzten Optionen aus. Die Ergebnisse landen automatisch in der Workspace-Datenbank.

Gesammelte Hosts ansehen (ADVANCED)

show hosts

Zeigt die im Workspace gesammelten Hosts tabellarisch an. So behältst du den Überblick über das, was die Module bislang zusammengetragen haben.

Daten direkt abfragen (AGGRESSIV)

db query SELECT host,ip_address FROM hosts;

Recon-ng speichert alles in einer SQLite-Datenbank, die du direkt per SQL abfragen kannst. Damit filterst und exportierst du genau die Felder, die du brauchst – flexibler als die vorgefertigten show-Ansichten.

Chain: Ausgabe protokollieren (CHAIN)

spool start recon-output.txt

Schreibt die gesamte Konsolenausgabe zusätzlich in eine Datei. Ideal zur Dokumentation und um später Ergebnisse mit anderen Tools zu korrelieren.

Subdomain-Enumeration

Subdomains sind ein zentraler Teil der Angriffsfläche – oft laufen dort vergessene, veraltete oder schlechter gepflegte Systeme. Die Kombination mehrerer Werkzeuge liefert die vollständigste Abdeckung.

ℹ️ Hinweis: Aktualisiert: Im Original standen hier Sublist3r und die alte Amass-Syntax. Sublist3r wird kaum noch gepflegt; als moderner, aktiv gepflegter Standard hat sich subfinder (ProjectDiscovery) etabliert. Die Amass-Befehle sind auf die aktuelle v4-Syntax angepasst. Wenn du beim Original bleiben willst, sag Bescheid.

subfinder – passiv (CORE, ersetzt Sublist3r)

subfinder -d target.example -o subfinder.txt

subfinder sammelt Subdomains rein passiv aus zahlreichen öffentlichen Quellen (Zertifikatstransparenz, Suchmaschinen, DNS-Datenbanken). -d gibt die Ziel-Domain an, -o speichert das Ergebnis. Schnell, gefahrlos und ohne aktive Anfragen ans Ziel – der ideale erste Schritt.

subfinder – mit allen Quellen (ADVANCED)

subfinder -d target.example -all -o subfinder-all.txt

-all aktiviert auch die langsameren bzw. API-Key-pflichtigen Quellen für maximale Abdeckung. Ergibt mehr Treffer, dauert länger; für einige Quellen müssen in der subfinder-Konfiguration API-Keys hinterlegt sein.

Amass – passiv (CORE)

amass enum -passive -d target.example -o amass-passive.txt

Amass ist das gründlichste Enumerationswerkzeug. Im passiven Modus (-passive) fragt es nur externe Datenquellen ab, ohne das Ziel aktiv zu berühren. Gute Ergänzung zu subfinder, weil Amass teils andere Quellen nutzt.

Amass – aktive Validierung (ADVANCED)

amass enum -active -d target.example -o amass-active.txt

Im aktiven Modus verifiziert Amass gefundene Namen durch eigene DNS-Auflösungen und ähnliche Prüfungen. Genauer, aber nicht mehr rein passiv – das Ziel bzw. dessen DNS bekommt Anfragen zu sehen. Nur im Scope einsetzen.

Amass – Brute-Force (AGGRESSIV)

amass enum -brute -d target.example -o amass-brute.txt

Ergänzt die Enumeration um DNS-Brute-Force: Amass probiert Namen aus Wortlisten gegen das Ziel-DNS. Findet auch Subdomains, die in keiner öffentlichen Quelle stehen, erzeugt aber viele DNS-Anfragen und ist damit auffällig.

Amass – Infrastruktur-Intelligence (ADVANCED)

amass intel -d target.example

Der intel-Modus sammelt übergeordnete Infrastruktur-Informationen zur Domain (z. B. zugehörige Netzblöcke/ASNs). Nützlich, um über die reine Subdomain-Liste hinaus das größere Bild der Ziel-Infrastruktur zu verstehen.

Merge & Deduplizieren (CORE)

cat amass*.txt subfinder*.txt | sort -u > subdomains-all.txt

Führt die Ergebnisse beider Werkzeuge zusammen und entfernt Duplikate. So entsteht eine einzige, saubere Gesamtliste als Basis für den nächsten Schritt.

Chain: Subdomains auflösen (CHAIN)

while read h; do dig +short "$h"; done < subdomains-all.txt > resolved.txt

Löst jede Subdomain der Liste per dig in ihre IP auf. Damit trennst du „lebende", tatsächlich auflösbare Namen von reinen Karteileichen und hast die aktiven Ziele für die weitere Analyse.

WhatWeb – Technologie-Fingerprinting

WhatWeb erkennt, welche Technologien eine Website einsetzt – CMS, Frameworks, Server, JavaScript-Bibliotheken. Dieses Wissen steuert die spätere, gezielte Suche nach passenden Schwachstellen.

Standard-Scan (CORE)

whatweb https://target.example

Identifiziert die Web-Technologien mit dem Standardprofil. Ein schneller, unauffälliger Überblick, der als Grundlage für alles Weitere dient.

Höchste Aggressionsstufe (AGGRESSIV)

whatweb -a 3 https://target.example

-a 3 setzt die Erkennung auf die höchste reguläre Stufe: WhatWeb sendet zusätzliche, gezielte Anfragen, um mehr zu erkennen. Genauer, aber mehr Requests und damit auffälliger. (Stufe 4 wäre „heavy" und noch aggressiver.)

Verbose-Ausgabe (CORE)

whatweb -v https://target.example

Zeigt ausführlich, welche Plugins angeschlagen haben und aufgrund welcher Merkmale. Hilfreich, um die Erkennungen nachzuvollziehen statt nur die Kurzfassung zu sehen.

Ganze URL-Liste (CORE)

whatweb -i urls.txt

Verarbeitet alle URLs aus einer Datei nacheinander. Praktisch, um nach der Subdomain-Enumeration den kompletten Bestand in einem Rutsch zu fingerprinten.

Ergebnisse als JSON (CORE)

whatweb --log-json=whatweb.json https://target.example

Speichert die Erkennungen maschinenlesbar als JSON. Ideal zur Weiterverarbeitung, Filterung (z. B. mit jq) und Korrelation mit anderen Ergebnissen.

Kompaktes Log (CORE)

whatweb --log-brief=whatweb.txt -i urls.txt

Erzeugt eine knappe, einzeilige Zusammenfassung pro Ziel. Gut lesbar und leicht mit anderen Listen abzugleichen.

Eigener User-Agent (CORE)

whatweb --user-agent "Mozilla/5.0" https://target.example

Setzt einen normalen Browser-User-Agent. Manche Seiten liefern je nach User-Agent anderen Inhalt oder blockieren den Standard-Scanner – so testest du unter realistischeren Bedingungen.

Authentifizierter Endpunkt (ADVANCED)

whatweb --header "Authorization: Bearer $TOKEN" https://target.example

Sendet einen Authorization-Header mit, um einen eingeloggten Anwendungsbereich zu fingerprinten. Nützlich, wenn hinter der Authentifizierung andere Technologien sichtbar werden. Token nur mit gültiger Freigabe verwenden.

Über einen Proxy (AGGRESSIV)

whatweb --proxy 127.0.0.1:8080 -a 3 https://target.example

Leitet das Fingerprinting durch einen abfangenden Proxy (z. B. Burp). So kannst du die einzelnen Requests/Responses genau mitlesen und die Erkennung nachvollziehen.

Chain: Ergebnisse aufbereiten (CHAIN)

whatweb -i urls.txt --log-json=stack.json && jq -r ".[]" stack.json > stack.txt

Fingerprintet alle Ziele, schreibt JSON und wandelt es mit jq in eine weiterverwertbare Textform um – als Basis für die nächste Analysephase.

EyeWitness – visuelle Erfassung der Angriffsfläche

EyeWitness erstellt automatisch Screenshots vieler Webseiten und fasst sie in einem Report zusammen. Bei großen Ziellisten spart das enorm Zeit: Du siehst auf einen Blick, was sich hinter jeder URL verbirgt.

Liste screenshotten (CORE)

eyewitness --web -f urls.txt --no-prompt

Macht von jeder URL einen Screenshot und baut daraus einen HTML-Report. --no-prompt unterdrückt Rückfragen, damit es unbeaufsichtigt durchläuft. Der schnellste Weg, aus hunderten URLs die interessanten herauszufinden.

Einzelnes Ziel (CORE)

eyewitness --web --single https://target.example --no-prompt

Erfasst genau ein Webziel. Praktisch für einen schnellen Blick auf ein einzelnes System.

Parallel verarbeiten (ADVANCED)

eyewitness --web -f urls.txt --threads 6 --no-prompt

--threads 6 verarbeitet mehrere Seiten gleichzeitig und beschleunigt große Listen deutlich. Die Threadzahl nicht übertreiben, um Ziel und eigenes System nicht zu überlasten.

Timeout erhöhen (CORE)

eyewitness --web -f urls.txt --timeout 12 --no-prompt

Gibt langsamen Anwendungen mehr Zeit zum Laden, bevor der Screenshot gemacht wird. Verhindert leere oder halbe Bilder bei trägen Seiten.

Verzögerung einbauen (CORE)

eyewitness --web -f urls.txt --delay 2 --no-prompt

Fügt eine Pause zwischen den Zugriffen ein. Schont das Ziel und wirkt weniger wie ein aggressiver automatisierter Zugriff.

Eigenes Ausgabeverzeichnis (CORE)

eyewitness --web -f urls.txt -d eyewitness-report --no-prompt

Legt Screenshots und HTML-Report in einem benannten Ordner ab. Hilft, die Ergebnisse verschiedener Ziele oder Läufe sauber zu trennen.

Browser-User-Agent (CORE)

eyewitness --web -f urls.txt --user-agent "Mozilla/5.0" --no-prompt

Erfasst die Seiten mit einem browserähnlichen User-Agent, damit Seiten, die Scanner aussperren oder anders ausliefern, korrekt dargestellt werden.

Deduplizieren und mehr Threads (AGGRESSIV)

sort -u urls.txt > urls-clean.txt && eyewitness --web -f urls-clean.txt --threads 8 --no-prompt

Entfernt zuerst doppelte URLs und verarbeitet dann die bereinigte, größere Liste mit mehr Parallelität. So vermeidest du doppelte Arbeit bei umfangreichen Ziellisten.

Screenshots zählen (CORE)

find eyewitness-report -type f -name "*.png" | wc -l

Zählt die erzeugten Screenshot-Dateien. Schnelle Kontrolle, wie viele Ziele tatsächlich erfasst wurden.

Chain: interessante Seiten priorisieren (CHAIN)

grep -Ril "login\|admin\|dashboard" eyewitness-report/ > high-value-pages.txt

Durchsucht die Report-Dateien nach vielversprechenden Begriffen wie Login, Admin oder Dashboard. So filterst du aus vielen Screenshots gezielt die lohnenden Ziele heraus.

Metadaten & Personen-OSINT

Öffentlich erreichbare Dokumente und Mitarbeiternamen sind wertvolle OSINT-Quellen: In Dokument-Metadaten stecken oft Benutzernamen, Software und interne Pfade; Namenslisten helfen bei der Einschätzung möglicher Konten.

ℹ️ Hinweis: Aktualisiert: metagoofil und InSpy werden beide kaum noch gepflegt. Für Metadaten aus öffentlichen Dokumenten ist der bewährte Klassiker exiftool (in Verbindung mit gezieltem Herunterladen) zuverlässiger; für Dokumentensuche/Metadaten hat sich ergänzend die Nutzung von Suchmaschinen-Dorks plus exiftool etabliert. Die metagoofil-Befehle sind der Vollständigkeit halber beschrieben, aber mit diesem Vorbehalt zu sehen.

metagoofil – PDFs sammeln (CORE)

metagoofil -d target.example -t pdf -l 25 -n 10 -o docs

Sucht über Suchmaschinen nach öffentlich verfügbaren PDFs der Domain und lädt eine begrenzte Menge herunter. -l begrenzt die Suchergebnisse, -n die Downloads, -o setzt das Zielverzeichnis. Hinweis: Das Tool ist alt und funktioniert je nach Suchmaschinen-Blocking nicht mehr zuverlässig.

metagoofil – mehrere Formate (ADVANCED)

metagoofil -d target.example -t pdf,doc,docx -l 50 -n 20 -o docs

Erweitert die Suche auf mehrere Dokumenttypen. Mehr Formate bedeuten mehr potenzielle Metadaten-Fundstellen (Autoren, Software, Pfade).

exiftool – Metadaten auslesen (CORE, empfohlen)

exiftool -r docs/ | grep -Ei "Author|Creator|Producer|Company|Software"

Liest rekursiv die Metadaten aller gesammelten Dokumente aus und filtert die aufschlussreichen Felder heraus. Genau hier liegen die spannenden Informationen: verwendete Software, Firmennamen und vor allem Benutzernamen der Autoren – oft direkt die internen Login-Namen.

Dokumente inventarisieren (CORE)

find docs -type f -maxdepth 2 | sort > downloaded-files.txt

Erstellt eine Übersicht der lokal gesammelten Dokumente. Hilft, den Bestand zu dokumentieren und den Überblick zu behalten.

Namen für Korrelation extrahieren (CHAIN)

exiftool -T -Author docs/*.pdf | sort -u > people.txt

Zieht die Autorennamen tabellarisch aus den PDFs und dedupliziert sie. Die Namensliste lässt sich anschließend mit den Metadaten und Login-Namenskonventionen abgleichen. (Ersetzt die frühere InSpy-Kette.)

Gobuster – Verzeichnisse, DNS & VHosts

Gobuster findet durch systematisches Ausprobieren von Wortlisten versteckte Web-Inhalte, Subdomains und virtuelle Hosts. Es ist schnell und vielseitig – ein Kernwerkzeug der Content-Discovery.

Verzeichnisse suchen (CORE)

gobuster dir -u https://target.example -w /usr/share/wordlists/dirb/common.txt

Der dir-Modus probiert Pfade aus einer Wortliste (-w) gegen die Ziel-URL. So findest du Verzeichnisse und Dateien, die nicht verlinkt sind. common.txt ist eine kleine Standardliste – guter, schneller Einstieg.

Mit Dateiendungen (CORE)

gobuster dir -u https://target.example -w /usr/share/wordlists/dirb/common.txt -x php,html,txt

-x hängt an jeden Wortlisteneintrag die genannten Endungen an. So findest du nicht nur /admin, sondern auch /admin.php usw. – deutlich mehr Treffer bei relevanten Dateien.

Größere Wortliste + Speichern (ADVANCED)

gobuster dir -u https://target.example -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt -o gobuster.txt

Nutzt eine umfangreichere, praxisbewährte SecLists-Wortliste und speichert die Treffer mit -o. Mehr Abdeckung, dafür längere Laufzeit. SecLists ist auf Kali über das Paket seclists verfügbar.

Auf sinnvolle Statuscodes filtern (ADVANCED)

gobuster dir -u https://target.example -w /usr/share/seclists/Discovery/Web-Content/raft-medium-words.txt -s 200,204,301,302,307,401,403

-s beschränkt die Anzeige auf aussagekräftige HTTP-Statuscodes. Reduziert Rauschen und hebt die wirklich interessanten Antworten (existierende oder geschützte Ressourcen) hervor.

Authentifizierter Bereich (CORE)

gobuster dir -u https://target.example -w /usr/share/wordlists/dirb/common.txt -H "Authorization: Bearer $TOKEN"

Mit -H sendest du einen Auth-Header mit und durchsuchst so einen eingeloggten Bereich. Wichtig, weil hinter der Anmeldung häufig ganz andere (und lohnendere) Inhalte liegen. Nur mit Freigabe.

Mit Session-Cookie (CORE)

gobuster dir -u https://target.example -w /usr/share/wordlists/dirb/common.txt -c "session=$SESSION"

Wie oben, aber über einen Session-Cookie statt eines Tokens. Passt für klassische Cookie-basierte Anwendungen.

DNS-Enumeration (CORE)

gobuster dns -d target.example -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt

Der dns-Modus rät Subdomains per Wortliste und prüft sie gegen das DNS. Eine schnelle, aktive Ergänzung zur passiven Enumeration mit subfinder/Amass.

Virtuelle Hosts (AGGRESSIV)

gobuster vhost -u https://target.example -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt --append-domain

Der vhost-Modus sucht virtuelle Hosts, die sich dieselbe IP teilen, aber je nach Host-Header andere Inhalte liefern. --append-domain hängt die Basis-Domain an die Wortlisteneinträge an. Deckt „versteckte" Anwendungen auf, die per DNS allein nicht sichtbar sind.

Chain: Pfade extrahieren (CHAIN)

awk "{print \$1}" gobuster.txt | sort -u > discovered-paths.txt

Zieht die gefundenen Pfade aus der Gobuster-Ausgabe für die gezielte Nachprüfung. So entsteht eine fokussierte Liste für die manuelle Analyse.

Content-Discovery – dirsearch & Alternativen

Ergänzend zu Gobuster gibt es weitere Werkzeuge für die Inhaltssuche, die etwas andere Stärken haben – etwa rekursives Vorgehen oder komfortablere Ausgabe.

ℹ️ Hinweis: Aktualisiert: DirBuster (die alte GUI) gilt als überholt. Als moderner, sehr schneller Rust-Ersatz mit eingebauter Rekursion hat sich feroxbuster etabliert; dirsearch selbst wird weiter gepflegt und bleibt drin.

dirsearch – Basis (CORE)

dirsearch -u https://target.example

Führt eine Standard-Verzeichnis- und Dateisuche mit sinnvollen Voreinstellungen durch. dirsearch bringt eine eigene, gute Standardwortliste mit und liefert übersichtliche Ergebnisse – ein bequemer Einstieg.

dirsearch – Endungen (CORE)

dirsearch -u https://target.example -e php,html,js,json

-e gibt die zu prüfenden Dateiendungen vor. So findest du gezielt Skript-, Markup- und Datendateien passend zum erkannten Technologie-Stack.

dirsearch – größere Wortliste (ADVANCED)

dirsearch -u https://target.example -w /usr/share/seclists/Discovery/Web-Content/raft-medium-words.txt

Verwendet eine umfangreichere Wortliste für tiefere Abdeckung. Mehr Treffer möglich, längere Laufzeit – ein guter zweiter Durchgang nach dem schnellen Basis-Scan.

dirsearch – rekursiv (ADVANCED)

dirsearch -u https://target.example -r

-r aktiviert rekursive Suche: In gefundenen Verzeichnissen wird weitergesucht. Findet tief verschachtelte Strukturen, erzeugt aber deutlich mehr Anfragen.

dirsearch – Rekursionstiefe (AGGRESSIV)

dirsearch -u https://target.example -r --max-recursion-depth 3

Begrenzt die Rekursion auf eine definierte Tiefe. So bekommst du einen kontrollierten Tiefen-Scan, ohne dass sich das Tool endlos in die Verzeichnisstruktur gräbt.

dirsearch – authentifiziert (CORE)

dirsearch -u https://target.example -H "Authorization: Bearer $TOKEN"

Durchsucht mit gültigem Auth-Header die geschützten Bereiche der Anwendung. Nur mit Freigabe verwenden.

dirsearch – mit Cookie (CORE)

dirsearch -u https://target.example --cookie "session=$SESSION"

Nutzt eine bestehende Session per Cookie, um im eingeloggten Zustand zu suchen. Passend für Cookie-basierte Anwendungen.

feroxbuster – schnelle rekursive Suche (ADVANCED, ersetzt DirBuster)

feroxbuster -u https://target.example -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt

feroxbuster ist ein sehr schneller, in Rust geschriebener Content-Discovery-Scanner mit standardmäßig rekursivem Vorgehen. Es ersetzt die betagte DirBuster-GUI durch ein modernes CLI-Tool und eignet sich gut für gründliche, dennoch zügige Durchläufe.

Chain: Treffer in Review-Liste (CHAIN)

dirsearch -u https://target.example -o dirsearch.txt && grep -E "200|301|302|401|403" dirsearch.txt > review.txt

Speichert die Ergebnisse und filtert sie auf die relevanten Statuscodes für die manuelle Nachprüfung. So entsteht eine fokussierte Warteschlange fürs Review.

Fuzzing & eigene Wortlisten

Fuzzing bedeutet, systematisch viele Eingaben an definierten Stellen einer Anfrage durchzuprobieren – Pfade, Parameter, Header. Eigene, zielspezifische Wortlisten erhöhen die Trefferquote deutlich.

ℹ️ Hinweis: Aktualisiert: wfuzz wird nicht mehr aktiv gepflegt; die Maintainer selbst verweisen auf ffuf. Alle Fuzzing-Beispiele sind daher auf ffuf umgestellt. CeWL (Wortlisten-Generator) bleibt, weil weiterhin nützlich und gepflegt.

ffuf – Pfade fuzzen (CORE, ersetzt wfuzz)

ffuf -w /usr/share/wordlists/dirb/common.txt -u https://target.example/FUZZ -mc 200,204,301,302,401,403

ffuf ersetzt das Schlüsselwort FUZZ in der URL nacheinander durch jeden Wortlisteneintrag. -mc („match codes") zeigt nur die interessanten Statuscodes. Extrem schnell und der aktuelle Standard für Web-Fuzzing.

ffuf – GET-Parameternamen finden (CORE)

ffuf -w params.txt -u "https://target.example/?FUZZ=test" -fs 0

Hier wird der Parametername gefuzzt, um unbekannte GET-Parameter aufzuspüren. -fs 0 („filter size") blendet leere Antworten aus. Eine geänderte Antwortgröße verrät, dass ein Parameter tatsächlich verarbeitet wird.

ffuf – POST-Parameter (ADVANCED)

ffuf -w values.txt -X POST -d "q=FUZZ" -u https://target.example/search -fc 404

Fuzzt den Wert eines POST-Parameters. -X POST setzt die Methode, -d den Body, -fc 404 filtert 404-Antworten heraus. Passend für Suchfelder und Formulare im freigegebenen Scope.

ffuf – Header fuzzen (ADVANCED)

ffuf -w headers.txt -H "X-Fuzz: FUZZ" -u https://target.example/ -fc 404

Testet, wie die Anwendung auf unterschiedliche Header-Werte reagiert. Manche Anwendungen werten benutzerdefinierte Header aus – das kann versteckte Funktionen oder Schwachstellen offenlegen.

ffuf – auf Statuscodes matchen (CORE)

ffuf -w words.txt -mc 200,204,301,302,401,403 -u https://target.example/FUZZ

Zeigt gezielt die aussagekräftigen Statuscodes an. Der schnellste Weg, aus vielen Anfragen die relevanten Antworten herauszufiltern.

ffuf – nach Antwortgröße filtern (CORE)

ffuf -w words.txt -u https://target.example/FUZZ -fs 0

Filtert Antworten anhand ihrer Größe. Nützlich, wenn ein Ziel auf alles mit „200" antwortet: Dann unterscheidet nicht der Statuscode, sondern die Antwortgröße echte Treffer von Standard-Antworten.

ffuf – zwei Positionen fuzzen (AGGRESSIV)

ffuf -w users.txt:U -w ids.txt:I -u https://target.example/user/U/I

ffuf kann mehrere Positionen gleichzeitig fuzzen, indem man jeder Wortliste ein eigenes Schlüsselwort zuweist (:U, :I). So testest du Kombinationen aus zwei Werten in einer Anfrage – deutlich mehr Requests, entsprechend vorsichtig einsetzen.

CeWL – Ziel-Wortliste bauen (CORE)

cewl https://target.example -d 2 -m 5 -w cewl.txt

CeWL crawlt die Website und baut aus den vorkommenden Wörtern eine zielspezifische Wortliste. -d 2 = Crawltiefe, -m 5 = Mindestwortlänge. Solche maßgeschneiderten Listen enthalten Fachbegriffe und Namen des Ziels und schlagen generische Listen oft bei Passwörtern und Pfaden.

CeWL – tiefer crawlen + E-Mails (AGGRESSIV)

cewl https://target.example -d 3 -m 4 -e --email_file emails.txt -w deep-cewl.txt

Crawlt tiefer und sammelt mit -e zusätzlich E-Mail-Adressen in eine eigene Datei. Die Adressen sind wertvolles OSINT (Namensschema, Kontakte), der tiefere Crawl erzeugt aber mehr Last.

Chain: eigene Wortliste direkt fuzzen (CHAIN)

cewl https://target.example -d 3 -w cewl.txt && ffuf -w cewl.txt -u https://target.example/FUZZ -fc 404

Baut erst die zielspezifische Wortliste und speist sie direkt in die Content-Discovery ein. Ein eleganter, geschlossener Ablauf: Vokabular des Ziels sammeln und sofort damit suchen.

AutoRecon – automatisierter Recon-Workflow

AutoRecon orchestriert viele der bisher genannten Werkzeuge zu einem geführten Ablauf: Es scannt, erkennt Dienste und startet passende Folgescans automatisch. Ideal, um pro Ziel reproduzierbar eine solide Grundaufnahme zu bekommen.

ℹ️ Hinweis: Aktualisiert: Sn1per aus dem Original wird kaum noch gepflegt und ist teils unzuverlässig; ich habe die Sn1per-Karten entfernt und AutoRecon als das gepflegte, in Kursen bewährte Werkzeug in den Mittelpunkt gestellt. Sag Bescheid, falls Sn1per drinbleiben soll.

Ein Ziel (CORE)

autorecon 192.0.2.10

Startet AutoRecon gegen einen einzelnen freigegebenen Host. Das Tool führt zunächst Portscans durch und startet dann je erkanntem Dienst automatisch passende, überwiegend „sichere" Enumerationsschritte. Ergebnis ist eine sauber strukturierte Verzeichnisablage pro Host.

Mehrere Ziele (CORE)

autorecon -t targets.txt

Liest mehrere Ziele aus einer Datei und arbeitet sie nacheinander/parallel ab. Praktisch, um eine ganze freigegebene Zielliste in einem Rutsch grundzuenumerieren.

Eigenes Ausgabeverzeichnis (CORE)

autorecon 192.0.2.10 -o autorecon-results

Schreibt alle Ergebnisse in ein benanntes Engagement-Verzeichnis. Hält verschiedene Aufträge getrennt und erleichtert die spätere Auswertung und Doku.

Flache Struktur für einen Host (CORE)

autorecon 192.0.2.10 --single-target

Verwendet eine flachere Ordnerstruktur, wenn ohnehin nur ein Host untersucht wird. Übersichtlicher, wenn keine Trennung mehrerer Ziele nötig ist.

Alle TCP-Ports (AGGRESSIV)

autorecon 192.0.2.10 -p T:1-65535

Überschreibt die Port-Abdeckung und lässt AutoRecon alle TCP-Ports berücksichtigen. Deutlich gründlicher, aber auch spürbar länger und lastintensiver.

Rekursive Web-Discovery (AGGRESSIV)

autorecon 192.0.2.10 --dirbuster.threads 15

Steuert die Web-Content-Discovery-Phase, hier die Anzahl paralleler Threads. Beschleunigt die Verzeichnissuche, erhöht aber die Last auf dem Ziel – Threadzahl mit Bedacht wählen.

VHost-Enumeration ergänzen (ADVANCED)

autorecon 192.0.2.10 --global.domain target.example

Übergibt AutoRecon die zugehörige Domain, damit auch virtuelle Hosts in die Diensterkennung einbezogen werden. Sinnvoll, wenn hinter einer IP mehrere Anwendungen per Host-Header liegen.

Nur sichere NSE-Skripte (ADVANCED)

autorecon 192.0.2.10 --nmap-append "--script safe"

Hängt an die von AutoRecon gesteuerten Nmap-Scans zusätzliche Optionen an – hier die als „safe" kategorisierten NSE-Skripte. So erweiterst du die Prüfungen, ohne aggressive/intrusive Skripte zu riskieren.

Teil 2 – Web-Schwachstellen-Hunting & Fuzzing

Proxys – Burp, OWASP ZAP & curl

Ein abfangender Proxy ist das Herzstück des manuellen Web-Testings: Er sitzt zwischen Browser/Tool und Ziel, macht jede Anfrage sicht- und veränderbar. Mit curl -x lässt sich beliebiger Verkehr gezielt durch den Proxy leiten, um ihn dort zu analysieren oder zu wiederholen.

Anfrage durch Burp leiten (CORE)

curl -x http://127.0.0.1:8080 https://target.example/

-x schickt die Anfrage über den lokalen Proxy (Burp lauscht standardmäßig auf 8080). Die Anfrage taucht dann in Burp auf und kann dort inspiziert, an Repeater geschickt oder verändert werden. Grundlage für fast alles Weitere.

Zertifikatswarnung ignorieren (CORE)

curl -k -x http://127.0.0.1:8080 https://target.example/api/status

-k akzeptiert ungültige/selbstsignierte Zertifikate. Beim Proxying über Burp ist das Burp-CA-Zertifikat im Spiel; -k verhindert, dass curl deswegen abbricht. Nur in Test-/Laborkontexten verwenden.

Authentifizierte API-Anfrage (ADVANCED)

curl -x http://127.0.0.1:8080 -H "Authorization: Bearer $TOKEN" https://target.example/api/me

Leitet eine eingeloggte API-Anfrage durch den Proxy, sodass du das authentifizierte Verhalten in Burp untersuchen kannst. Nützlich, um Token-Handling und geschützte Endpunkte zu analysieren.

Session durch den Proxy wiederholen (ADVANCED)

curl -x http://127.0.0.1:8080 -b "session=$SESSION" https://target.example/dashboard

-b setzt einen Cookie. So spielst du eine bestehende, freigegebene Session durch den Proxy nach und beobachtest, was der eingeloggte Zugriff auslöst.

POST für Repeater-Analyse (CORE)

curl -x http://127.0.0.1:8080 -X POST -d "q=test" https://target.example/search

Sendet eine POST-Anfrage über den Proxy. In Burp kannst du sie dann festhalten, im Repeater immer wieder variieren und die Reaktionen der Anwendung vergleichen.

Custom-Header testen (CORE)

curl -x http://127.0.0.1:8080 -H "X-Test: value" https://target.example/

Schickt einen selbst gewählten Header mit. So prüfst du über den Proxy, ob und wie die Anwendung auf zusätzliche/ungewöhnliche Header reagiert.

OWASP ZAP starten (CORE)

zaproxy

Startet OWASP ZAP, die freie Alternative zu Burp. ZAP bietet ebenfalls Proxy, Scanner und viele Analysefunktionen und eignet sich gut, wenn ein quelloffenes Werkzeug gewünscht ist.

ZAP – Quick-Scan per CLI (CORE)

zaproxy -cmd -quickurl https://target.example -quickout zap-report.html

Führt einen automatisierten Schnell-Scan der freigegebenen URL rein über die Kommandozeile aus und schreibt einen HTML-Report. Guter Einstieg für einen automatisierten Erst-Überblick ohne GUI.

ZAP – Daemon-Modus (ADVANCED)

zaproxy -daemon -port 8090

Startet ZAP headless als Dienst auf Port 8090. In diesem Modus lässt sich ZAP über seine API steuern und in Automatisierungen einbinden – etwa als Proxy in Skripten.

Anfrage durch ZAP leiten (CORE)

curl -x http://127.0.0.1:8090 https://target.example/

Wie beim Burp-Beispiel, nur über den ZAP-Daemon-Port. So fließt der Verkehr durch ZAP und wird dort erfasst und analysierbar.

Chain: Scan + Triage (CHAIN)

zaproxy -cmd -quickurl https://target.example -quickout zap.html && grep -i "high\|medium" zap.html > findings.txt

Scannt, exportiert und filtert anschließend die höher eingestuften Funde heraus. So bekommst du aus dem Report schnell eine priorisierte Liste der wichtigsten Themen.

Nikto + Skipfish – Webserver-Enumeration

Nikto und Skipfish sind klassische, schnelle Webserver-Scanner. Sie prüfen automatisiert auf bekannte Probleme, veraltete Komponenten, gefährliche Dateien und Fehlkonfigurationen – gute Werkzeuge für einen breiten ersten Überblick.

Basis-Scan (CORE)

nikto -h https://target.example

Führt die Standard-Webserver-Prüfungen durch: bekannte verwundbare Dateien, veraltete Software, problematische Header und typische Fehlkonfigurationen. Schnell und breit, dafür recht „laut" und gut sichtbar in Server-Logs.

HTTPS erzwingen (CORE)

nikto -h target.example -ssl

Erzwingt eine HTTPS-Verbindung beim Scannen. Nützlich, wenn der Host sowohl HTTP als auch HTTPS anbietet und du gezielt die TLS-Seite prüfen willst.

Nicht-Standard-Port (CORE)

nikto -h https://target.example -port 8443

Prüft einen Webdienst auf einem abweichenden Port. Anwendungen laufen oft auf 8080/8443 o. ä. – so erreichst du auch diese.

Prüfklassen fokussieren (ADVANCED)

nikto -h https://target.example -Tuning 123

-Tuning schränkt die Prüfungen auf bestimmte Kategorien ein (hier 1/2/3 – u. a. interessante Dateien und Fehlkonfigurationen). Macht den Scan kürzer und gezielter statt „alles auf einmal".

Verbose-Ausgabe (CORE)

nikto -h https://target.example -Display V

Zeigt detaillierte Test- und Fundinformationen. Hilft nachzuvollziehen, was genau geprüft wurde und warum ein Fund gemeldet wird.

Über Proxy laufen lassen (ADVANCED)

nikto -h https://target.example -useproxy http://127.0.0.1:8080

Leitet Niktos Anfragen durch Burp/ZAP. So kannst du die Scanner-Requests mitlesen, interessante Funde direkt aufgreifen und im Proxy weiterverfolgen.

JSON speichern (CORE)

nikto -h https://target.example -output nikto.json -Format json

Schreibt die Ergebnisse maschinenlesbar als JSON – gut für Weiterverarbeitung, Filterung und Reporting.

Breiter Scan mit Zeitlimit (AGGRESSIV)

nikto -h https://target.example -Tuning x -maxtime 20m

-Tuning x aktiviert einen sehr breiten Prüfumfang, -maxtime deckelt die Laufzeit auf 20 Minuten. So bekommst du viel Abdeckung, ohne dass der Scan unbegrenzt läuft.

Skipfish – Crawl & Audit (AGGRESSIV)

skipfish -o skipfish-report https://target.example

Skipfish crawlt die Anwendung aktiv und erstellt eine interaktive Karte samt Audit-Report. Sehr gründlich und schnell, dabei aber ausgesprochen aggressiv – nur mit klarer Freigabe und nicht gegen empfindliche Produktionssysteme.

Vulnerability-Scanner – Nessus + Acunetix

Kommerzielle Schwachstellenscanner automatisieren die Suche nach bekannten Verwundbarkeiten in großem Umfang. Nessus ist ein Netzwerk-/System-Scanner, Acunetix auf Webanwendungen spezialisiert. Beide lassen sich per API in Abläufe einbinden.

Nessus-Dienst starten (CORE)

sudo systemctl start nessusd

Startet den Nessus-Dienst. Nach der Installation des Pakets läuft Nessus als lokaler Dienst und ist anschließend über die Weboberfläche unter https://127.0.0.1:8834 erreichbar.

Nessus-Status prüfen (CORE)

sudo systemctl status nessusd --no-pager

Zeigt, ob der lokale Scanner läuft. --no-pager gibt die Statusausgabe direkt aus, ohne in einen Pager zu wechseln – praktisch in Skripten und schnellen Checks.

Nessus-Einstellungen anzeigen (ADVANCED)

/opt/nessus/sbin/nessuscli fix --show

nessuscli ist das Kommandozeilen-Verwaltungswerkzeug von Nessus. fix --show listet die aktuell gesetzten Konfigurationswerte auf – hilfreich zur Diagnose und um die aktive Konfiguration zu prüfen.

Nessus – Plugins/Update (CORE, ergänzt)

sudo /opt/nessus/sbin/nessuscli update --all

Aktualisiert die Nessus-Plugins (die eigentlichen Schwachstellen-Checks). Da täglich neue Plugins erscheinen, gehört ein Update vor größeren Scans zur Routine, damit auch aktuelle Schwachstellen erkannt werden.

Nessus – Benutzer anlegen (CORE, ergänzt)

sudo /opt/nessus/sbin/nessuscli adduser

Legt interaktiv einen Nessus-Benutzer an. Beim ersten Einrichten brauchst du einen Login für die Weboberfläche; hierüber lässt er sich auch per CLI erstellen oder zurücksetzen.

Scans über die API auflisten (ADVANCED)

curl -ks -H "X-ApiKeys: accessKey=$NESSUS_ACCESS; secretKey=$NESSUS_SECRET" https://127.0.0.1:8834/scans | jq .

Fragt über die lokale Nessus-REST-API die vorhandenen Scans ab. -k akzeptiert das lokale Zertifikat, -s unterdrückt den Fortschrittsbalken, jq macht die JSON-Antwort lesbar. Die API-Keys erzeugst du in den Nessus-Einstellungen. So lässt sich Nessus in eigene Automatisierungen einbinden.

Scan-Ordner auflisten (CORE)

curl -ks -H "X-ApiKeys: accessKey=$NESSUS_ACCESS; secretKey=$NESSUS_SECRET" https://127.0.0.1:8834/folders | jq .

Listet die Scan-Ordner auf. Ordner helfen, mehrere Engagements sauber zu organisieren – gerade wenn du Nessus regelmäßig für unterschiedliche Aufträge nutzt.

Acunetix – Ziele auflisten (ADVANCED)

curl -ks -H "X-Auth: $ACUNETIX_API_KEY" "$ACUNETIX_URL/api/v1/targets" | jq .

Ruft über die Acunetix-API die konfigurierten Scan-Ziele ab. Setzt eine lizenzierte Acunetix-Installation voraus; X-Auth trägt den API-Key, die Basis-URL steckt in $ACUNETIX_URL.

Acunetix – Ziel anlegen (CORE)

curl -ks -X POST -H "X-Auth: $ACUNETIX_API_KEY" -H "Content-Type: application/json" "$ACUNETIX_URL/api/v1/targets" -d '{"address":"https://target.example","description":"scoped"}'

Legt per API ein neues, freigegebenes Scan-Ziel an. So automatisierst du das Einpflegen von Zielen, statt sie einzeln in der Oberfläche zu erfassen. Nur Ziele im Scope eintragen.

Acunetix – Scans ansehen (CORE)

curl -ks -H "X-Auth: $ACUNETIX_API_KEY" "$ACUNETIX_URL/api/v1/scans" | jq .

Zeigt die vorhandenen Scan-Aufträge. Guter Überblick über laufende und abgeschlossene Scans für die lokale Auswertung.

Acunetix – Funde extrahieren (CHAIN)

curl -ks -H "X-Auth: $ACUNETIX_API_KEY" "$ACUNETIX_URL/api/v1/vulnerabilities?l=100" | jq -r ".vulnerabilities[]?.vt_name" | sort -u

Holt eine größere Fundseite und extrahiert die eindeutigen Schwachstellennamen. Ergibt eine kompakte Übersicht der gefundenen Schwachstellentypen zur weiteren Korrelation.

Web-Application-Auditing – Arachni

Arachni ist ein leistungsfähiges, quelloffenes Framework zum automatisierten Auditieren von Webanwendungen. Es crawlt die Anwendung und prüft auf ein breites Spektrum an Schwachstellen; Ergebnisse lassen sich in Reports exportieren.

ℹ️ Hinweis: Aktualisiert: Das ursprünglich mit aufgeführte w3af ist seit Jahren praktisch unmaintained und läuft auf aktuellen Systemen oft nicht mehr sauber. Ich habe es weggelassen und den Abschnitt auf Arachni konzentriert. Auch Arachni selbst wird nur noch eingeschränkt gepflegt – als moderne Ergänzung für gezielte Checks bietet sich nuclei an (siehe Extra-Abschnitt unten).

Basis-Audit (CORE)

arachni https://target.example

Führt ein Standard-Audit gegen die freigegebene Anwendung durch: Arachni crawlt die Seiten und testet automatisch auf gängige Schwachstellenklassen. Guter Rundum-Einstieg, allerdings mit spürbarer Last auf dem Ziel.

Audit-Session speichern (CORE)

arachni https://target.example --report-save-path=target.afr

Speichert die vollständige Audit-Session in einer .afr-Datei. Aus dieser Datei lassen sich später verschiedene Reportformate erzeugen, ohne den Scan zu wiederholen.

Subdomains einbeziehen (ADVANCED)

arachni https://target.example --scope-include-subdomains

Bezieht in den Scope fallende Subdomains in das Audit ein. Sinnvoll, wenn die Anwendung über mehrere Subdomains verteilt ist – nur einsetzen, wenn diese ausdrücklich freigegeben sind.

Concurrency erhöhen (AGGRESSIV)

arachni https://target.example --http-request-concurrency=10

Erhöht die Zahl paralleler HTTP-Anfragen auf einen kontrollierten Wert. Beschleunigt das Audit, steigert aber die Last – behutsam wählen, um das Ziel nicht zu beeinträchtigen.

Report erzeugen (CORE)

arachni_reporter target.afr --reporter=html:outfile=arachni-report.zip

Erzeugt aus der gespeicherten Session einen HTML-Report (als ZIP). arachni_reporter ist das separate Reporting-Werkzeug; so trennst du das Scannen vom Erstellen der Auswertung sauber.

Nur XSS prüfen (CORE)

arachni https://target.example --checks=xss*

Begrenzt die Prüfungen auf XSS-Checks. Zielgerichtete, schnellere Läufe, wenn du bewusst nur eine Schwachstellenklasse untersuchen willst.

Ausgewählte Checks (AGGRESSIV)

arachni https://target.example --checks=xss,sqli,path_traversal

Prüft gezielt mehrere ausgewählte Schwachstellenklassen. Guter Kompromiss zwischen einem vollständigen Audit und einem eng fokussierten Einzelcheck.

Chain: Audit + JSON-Export (CHAIN)

arachni https://target.example --report-save-path=target.afr && arachni_reporter target.afr --reporter=json:outfile=arachni.json

Auditiert und exportiert das Ergebnis als JSON. Das maschinenlesbare Format eignet sich gut, um Funde mit anderen Werkzeugen zu korrelieren.

Extra: nuclei – vorlagenbasierte Checks (ADVANCED, moderne Ergänzung)

nuclei -u https://target.example -severity medium,high,critical

nuclei prüft anhand einer riesigen, gepflegten Sammlung von YAML-Templates gezielt auf bekannte Schwachstellen und Fehlkonfigurationen. -severity filtert auf die wichtigen Funde. Schnell, präzise und aktuell – ein sehr guter moderner Baustein neben oder statt der älteren Auditing-Frameworks.

XSS-Testing – XSStrike & XSSer

Cross-Site-Scripting (XSS) gehört zu den häufigsten Web-Schwachstellen. Diese Werkzeuge analysieren Parameter gezielt auf XSS, generieren Payloads und prüfen, ob sie reflektiert bzw. ausgeführt werden.

XSStrike – GET-Parameter (CORE)

xsstrike -u "https://target.example/search?q=test"

XSStrike analysiert einen reflektierten GET-Parameter intelligent auf XSS: Es prüft den Kontext der Reflexion und baut passende Payloads, statt nur stur eine Liste durchzuprobieren. Dadurch weniger Fehlalarme und gezieltere Treffer.

XSStrike – POST-Parameter (CORE)

xsstrike -u https://target.example/search --data "q=test"

Testet einen über POST übermittelten Parameter. --data gibt die POST-Daten an. Passend für Suchfelder und Formulare, die per POST arbeiten.

XSStrike – crawlen (ADVANCED)

xsstrike -u https://target.example --crawl

Lässt XSStrike die Anwendung crawlen und die dabei gefundenen Parameter automatisch testen. Praktisch, um nicht jeden Endpunkt einzeln angeben zu müssen.

XSStrike – Crawltiefe (AGGRESSIV)

xsstrike -u https://target.example --crawl -l 2

Erhöht die Crawltiefe für einen gründlicheren Durchlauf im freigegebenen Scope. Mehr Abdeckung, aber deutlich mehr Anfragen.

XSStrike – Fuzzing (AGGRESSIV)

xsstrike -u "https://target.example/search?q=test" --fuzzer

Aktiviert den Fuzzing-Modus gegen den gewählten Parameter: XSStrike probiert viele Payload-Varianten durch, um Filter zu testen. Kraftvoll, aber auffällig – bewusst einsetzen.

XSStrike – nur Server-XSS (CORE)

xsstrike -u "https://target.example/search?q=test" --skip-dom

--skip-dom überspringt die DOM-XSS-Analyse und konzentriert sich auf reflektiertes/serverseitiges XSS. Schneller, wenn du gezielt nur diese Variante untersuchst.

XSStrike – authentifiziert (ADVANCED)

xsstrike -u https://target.example/search --data "q=test" --headers "Authorization: Bearer $TOKEN"

Testet einen geschützten POST-Endpunkt mit mitgesendetem Auth-Header. Nur mit gültiger Freigabe verwenden.

XSSer – Basis (CORE)

xsser -u "https://target.example/search?q=test"

XSSer ist ein weiteres XSS-Framework mit eigenem Payload-Satz und Automatikmodus. Als zweites Werkzeug neben XSStrike nützlich, um Funde gegenzuprüfen oder anders gelagerte Fälle zu finden.

XSSer – GET-Parameter fokussieren (ADVANCED)

xsser -u "https://target.example/search?q=XSS" -g "q=XSS"

Mit -g markierst du gezielt den zu testenden GET-Parameter und die Einfügestelle (XSS). So konzentriert sich der Test auf genau diesen Punkt.

XSSer – Automatikmodus (AGGRESSIV)

xsser -u "https://target.example/search?q=XSS" --auto

Fährt das automatisierte Testprofil mit einer breiten Palette an Payloads und Mutationen. Bequem, aber laut – erzeugt viele Anfragen und ist in Logs gut sichtbar.

Chain: XSSer-Funde sichern (CHAIN)

xsser -u "https://target.example/search?q=XSS" --auto > xsser.txt 2>&1 && grep -i "xss" xsser.txt > xss-validation.txt

Speichert den kompletten Lauf und filtert die XSS-relevanten Zeilen heraus. Ergibt eine fokussierte Liste für die anschließende manuelle Verifikation – denn automatisch gemeldete XSS immer von Hand bestätigen.

SQL-Injection – sqlmap

sqlmap ist das führende Werkzeug zum Aufspüren und Ausnutzen von SQL-Injection. Es erkennt automatisch verwundbare Parameter, bestimmt die Datenbank und kann – im Rahmen der Freigabe – Daten auslesen. Aufgrund seiner Mächtigkeit besonders verantwortungsvoll einzusetzen.

GET-Parameter testen (CORE)

sqlmap -u "https://target.example/item?id=1" -p id

Testet gezielt den Parameter id (-p) einer GET-URL auf SQL-Injection. Die gezielte Angabe eines Parameters ist präziser und schonender, als alle Parameter automatisch durchzuprobieren.

POST-Parameter (CORE)

sqlmap -u https://target.example/search --data="q=test&id=1" -p id

Testet einen per POST übermittelten Parameter. --data enthält den Body, -p id wählt den zu prüfenden Parameter aus.

Rohen Request nutzen (CORE)

sqlmap -r request.txt -p id

-r liest eine komplette, z. B. aus Burp gespeicherte Roh-Anfrage aus einer Datei. Das ist der zuverlässigste Weg, weil sämtliche Header, Cookies und der genaue Body original erhalten bleiben – ideal für komplexe oder authentifizierte Requests.

Session bewahren (CORE)

sqlmap -r request.txt --cookie="session=$SESSION"

Übergibt einen Session-Cookie, damit sqlmap im eingeloggten Zustand testet. Wichtig, wenn die verwundbare Stelle erst nach der Anmeldung erreichbar ist.

Authentifizierte API (ADVANCED)

sqlmap -r request.txt --headers="Authorization: Bearer $TOKEN"

Testet eine geschützte API-Anfrage mit Auth-Header. So lassen sich auch Endpunkte hinter Token-Authentifizierung prüfen.

Coverage erhöhen (ADVANCED)

sqlmap -r request.txt --level=3 --risk=1

--level steuert, wie viele Stellen/Techniken getestet werden, --risk wie „riskant" die Testanfragen sein dürfen. level=3, risk=1 erweitert die Abdeckung, ohne destruktive Payloads einzusetzen – ein guter, sicherer Mittelweg.

Tiefer Detektionslauf (AGGRESSIV)

sqlmap -r request.txt --level=5 --risk=2 --threads=4

Maximiert die Erkennung (viele Stellen, aggressivere Tests) und parallelisiert mit vier Threads. Findet auch schwer erkennbare Injektionen, ist aber langsam und belastend – nur mit klarer Freigabe. --risk=3 würde potenziell verändernde Anfragen zulassen und ist daher hier bewusst nicht gewählt.

Nicht-interaktiv (AGGRESSIV)

sqlmap -r request.txt --technique=BEUSTQ --batch

--technique legt die zu prüfenden SQLi-Techniken fest (Boolean, Error, Union, Stacked, Time, inline Query), --batch beantwortet alle Rückfragen automatisch mit sinnvollen Vorgaben. Praktisch für Automatisierung – aber du gibst damit die manuelle Kontrolle über einzelne Entscheidungen ab.

DBMS fingerprinten (ADVANCED)

sqlmap -r request.txt --banner --current-db

Nach bestätigter Injektion liest dies gezielt zwei harmlose, aber aussagekräftige Informationen aus: die DBMS-Version (--banner) und den Namen der aktuellen Datenbank (--current-db). Gut, um den Fund zu belegen, ohne gleich große Datenmengen zu extrahieren.

Chain: Nachweis protokollieren (CHAIN)

sqlmap -r request.txt --batch -v 2 | tee sqlmap.txt

Führt den Test nicht-interaktiv mit erhöhter Ausführlichkeit aus und schreibt die Ausgabe zugleich auf den Bildschirm und in eine Datei (tee). So hast du einen nachvollziehbaren Beleg des Ablaufs für den Report.

ℹ️ Hinweis: Die im Original zusätzlich gezeigten Tools sqlninja, sqlsus und sqlmate sind alt bzw. sehr speziell (sqlninja nur MS-SQL, sqlsus nur MySQL, beide kaum gepflegt; sqlmate ein wenig verbreiteter sqlmap-Klon). In der Praxis deckt sqlmap ihre Anwendungsfälle heute ab. Ich habe sie daher weggelassen – sag Bescheid, wenn du einen dieser Spezialfälle im Kurs zeigen möchtest.

CMS-Testing – WPScan, JoomScan & Droopescan

Content-Management-Systeme wie WordPress, Joomla und Drupal haben eigene, spezialisierte Scanner. Diese kennen die typischen Schwachstellen, Plugin-/Theme-Strukturen und Versionsmerkmale des jeweiligen CMS.

WPScan – Basis (CORE)

wpscan --url https://target.example

Führt einen grundlegenden WordPress-Sicherheitsscan durch: Version, erkennbare Plugins/Themes und offensichtliche Probleme. WordPress ist extrem verbreitet, daher ein sehr häufiger und lohnender Prüffall.

WPScan – Plugins (CORE)

wpscan --url https://target.example --enumerate p

Zählt die erkannten Plugins auf. Plugins sind bei WordPress die häufigste Schwachstellenquelle, daher besonders relevant.

WPScan – verwundbare Plugins (CORE)

wpscan --url https://target.example --enumerate vp

Beschränkt die Plugin-Enumeration auf solche mit bekannten Schwachstellen (vp = „vulnerable plugins"). Liefert direkt die sicherheitsrelevanten Treffer. Für vollständige Verwundbarkeitsdaten ist ein API-Token nötig (siehe unten).

WPScan – Themes (CORE)

wpscan --url https://target.example --enumerate t

Zählt installierte Themes auf. Auch Themes können verwundbar sein oder Informationen preisgeben.

WPScan – verwundbare Themes (CORE)

wpscan --url https://target.example --enumerate vt

Fokussiert auf Themes mit bekannten Schwachstellen (vt). Analog zu vp, nur für Themes.

WPScan – aggressive Erkennung (AGGRESSIV)

wpscan --url https://target.example --detection-mode aggressive

Erhöht die Erkennungsgründlichkeit: WPScan prüft Komponenten direkter statt nur passiv. Findet mehr, sendet aber deutlich mehr Anfragen und ist auffälliger.

WPScan – kombinierte Enumeration (AGGRESSIV)

wpscan --url https://target.example --enumerate vp,vt,cb,dbe

Kombiniert mehrere Enumerationsziele: verwundbare Plugins/Themes sowie Hinweise auf Config-Backups (cb) und exponierte Datenbank-Exporte (dbe). Ein gründlicher, aber lauter Rundum-Check.

WPScan – mit API-Token (ADVANCED)

wpscan --url https://target.example --api-token "$WPSCAN_TOKEN"

Bindet aktuelle Verwundbarkeitsdaten aus der WPScan-Datenbank ein. Ohne Token erkennt WPScan zwar Versionen, kann sie aber nicht zuverlässig konkreten CVEs zuordnen – der (kostenlose) Token macht die Ergebnisse erst richtig aussagekräftig.

WPScan – Proxy + JSON (ADVANCED)

wpscan --url https://target.example --proxy http://127.0.0.1:8080 --format json -o wpscan.json

Leitet den Scan durch Burp und exportiert die Funde als JSON. Kombiniert Nachvollziehbarkeit im Proxy mit maschinenlesbarer Ausgabe fürs Reporting.

JoomScan – Basis (CORE)

joomscan -u https://target.example

Führt grundlegende Joomla-Schwachstellenprüfungen durch: Version, bekannte Schwachstellen und typische Fehlkonfigurationen. Das Joomla-Pendant zum WPScan-Basisscan.

JoomScan – Komponenten (ADVANCED)

joomscan -u https://target.example -ec

-ec enumeriert die installierten Joomla-Komponenten. Wie bei WordPress-Plugins sind Drittkomponenten auch bei Joomla eine häufige Schwachstellenquelle.

JoomScan – mit Cookie (CORE)

joomscan -u https://target.example --cookie "session=$SESSION"

Scannt mit einem freigegebenen Anwendungs-Cookie, um auch eingeloggte Bereiche einzubeziehen.

Droopescan – Drupal (CORE)

droopescan scan drupal -u https://target.example

Droopescan ist auf Drupal spezialisiert (kann aber auch andere CMS). Es erkennt Version und Module und deckt so die Drupal-spezifische Angriffsfläche ab.

Droopescan – WordPress gegenprüfen (CORE)

droopescan scan wordpress -u https://target.example

Nutzt Droopescan als zweite Meinung für WordPress. Ein zweiter, unabhängiger Scanner bestätigt Funde und findet gelegentlich, was der erste übersieht.

Chain: zwei Scanner kombinieren (CHAIN)

joomscan -u https://target.example -ec > joomla.txt && droopescan scan joomla -u https://target.example > droope.txt

Prüft dasselbe Joomla-Ziel mit zwei unabhängigen Scannern und legt die Ergebnisse getrennt ab. Das Gegenprüfen mit einem zweiten Werkzeug erhöht die Verlässlichkeit der Funde.

Zusammenfassung der Aktualisierungen

Die folgenden Werkzeuge aus den Original-PDFs wurden durch aktuell gepflegte Alternativen ersetzt oder ergänzt. Falls du eines davon bewusst im Original behalten möchtest, lässt sich der jeweilige Abschnitt leicht zurückändern.

Original	Ersetzt/ergänzt durch	Grund
Sublist3r	subfinder	Sublist3r kaum noch gepflegt; subfinder ist der aktuelle Standard
wfuzz	ffuf	wfuzz unmaintained; Maintainer verweisen selbst auf ffuf
DirBuster (GUI)	feroxbuster	DirBuster veraltet; feroxbuster schnell und rekursiv
metagoofil / InSpy	exiftool (+ Dorks)	beide OSINT-Tools veraltet; exiftool zuverlässig für Metadaten
w3af	Arachni / nuclei	w3af unmaintained, läuft oft nicht mehr
Sn1per	AutoRecon	Sn1per unzuverlässig; AutoRecon gepflegt und kursbewährt
sqlninja / sqlsus / sqlmate	sqlmap	Spezial-/Alttools; sqlmap deckt die Fälle heute ab

Bounty Hunter Tools

Teil 1 – Recon & Attack Surface Mapping

Nmap + Masscan – Netzwerk- und Port-Discovery

Host-Discovery (CORE)

Schneller Top-Ports-Scan (CORE)

Versionserkennung (ADVANCED)

Default-Skripte + OS-Erkennung (ADVANCED)

Alle TCP-Ports (AGGRESSIV)

Häufige UDP-Dienste (ADVANCED)

HTTP-Titel und Header (CORE)

Masscan – schnelle Portsuche (AGGRESSIV)

Masscan über ein Subnetz (AGGRESSIV)

Chain: Masscan-Ergebnisse an Nmap übergeben (CHAIN)

tshark – Traffic- und Protokollanalyse

Interfaces auflisten (CORE)

Gezielt einen Host mitschneiden (CORE)

HTTP-Pakete anzeigen (CORE)

DNS isolieren (CORE)

TLS-Metadaten prüfen (ADVANCED)

Eine TCP-Verbindung verfolgen (ADVANCED)

TCP-Resets finden (ADVANCED)

TCP-Konversationsübersicht (AGGRESSIV)

Protokollhierarchie (AGGRESSIV)

Chain: Felder für die Auswertung exportieren (CHAIN)

Shodan – externe Exposition & OSINT

Host abfragen (CORE)

Domain-Infos (CORE)

Nach Hostname suchen (CORE)

Nach Zertifikatsname suchen (ADVANCED)

HTTPS nach Organisation filtern (ADVANCED)

Indexierte HTTP-Titel (CORE)

Treffer zählen (CORE)

Ergebnisse herunterladen (AGGRESSIV)

Felder extrahieren (ADVANCED)

Chain: kompakte Host/Port-Liste bauen (CHAIN)

Recon-ng – automatisierter OSINT-Workspace

Konsole starten (CORE)

Workspace anlegen (CORE)

Module suchen (CORE)

Modul installieren (ADVANCED)

Modul laden (CORE)

Quelle setzen (CORE)

Modul ausführen (CORE)

Gesammelte Hosts ansehen (ADVANCED)

Daten direkt abfragen (AGGRESSIV)

Chain: Ausgabe protokollieren (CHAIN)

Subdomain-Enumeration

subfinder – passiv (CORE, ersetzt Sublist3r)

subfinder – mit allen Quellen (ADVANCED)

Amass – passiv (CORE)

Amass – aktive Validierung (ADVANCED)

Amass – Brute-Force (AGGRESSIV)

Amass – Infrastruktur-Intelligence (ADVANCED)

Merge & Deduplizieren (CORE)

Chain: Subdomains auflösen (CHAIN)

WhatWeb – Technologie-Fingerprinting

Standard-Scan (CORE)

Höchste Aggressionsstufe (AGGRESSIV)

Verbose-Ausgabe (CORE)

Ganze URL-Liste (CORE)

Ergebnisse als JSON (CORE)

Kompaktes Log (CORE)

Eigener User-Agent (CORE)

Authentifizierter Endpunkt (ADVANCED)

Über einen Proxy (AGGRESSIV)

Chain: Ergebnisse aufbereiten (CHAIN)

EyeWitness – visuelle Erfassung der Angriffsfläche

Liste screenshotten (CORE)

Einzelnes Ziel (CORE)

Parallel verarbeiten (ADVANCED)

Timeout erhöhen (CORE)

Verzögerung einbauen (CORE)

Eigenes Ausgabeverzeichnis (CORE)

Browser-User-Agent (CORE)

Deduplizieren und mehr Threads (AGGRESSIV)

Screenshots zählen (CORE)

Chain: interessante Seiten priorisieren (CHAIN)

Metadaten & Personen-OSINT

metagoofil – PDFs sammeln (CORE)

metagoofil – mehrere Formate (ADVANCED)