So waehlst du dein erstes Bug-Bounty-Ziel: Das 3-Filter-System

TL;DR

Die meisten Einsteiger geben Bug Bounty nicht auf, weil ihnen die Faehigkeiten fehlen. Sie hoeren auf, weil sie das falsche Ziel waehlen. Die Zielauswahl ist eine erlernbare Faehigkeit, und sie ist wichtiger, als jeden Payload zu kennen. Pruefe jedes Programm anhand von drei Filtern, bevor du auch nur eine Stunde investierst:

1. Scope-Groesse. Waehle ein Ziel, das du in unter 30 Minuten vollstaendig kartieren kannst.
2. Technologie-Stack. Jage die Technologien, die du bereits verstehst.
3. Hunter-Dichte. Waehle Programme, auf denen du gegen fuenf Hunter konkurrierst, nicht gegen fuenftausend.

Arbeite anschliessend eine 2-stuendige Recon-Checkliste ab, bewerte das Ziel auf einer Skala bis 30 und bleib vier Wochen an einem Ziel dran. So erreichst du das tiefe Verstaendnis, in dem die echten Bugs leben.

Die Zielauswahl ist die Faehigkeit, die niemand lehrt

Hier ist die Wahrheit, die dir niemand sagt. Die meisten Einsteiger geben Bug Bounty nicht auf, weil sie nicht klug genug sind. Sie hoeren auf, weil sie ein Programm mit riesigem Scope oeffnen, wochenlang automatisierte Scanner laufen lassen, nichts finden und annehmen, dass sie fuer dieses Feld nicht gut genug sind.

Die Zielauswahl ist eine Faehigkeit. Sie ist wichtiger, als jeden XSS-Payload zu kennen. Sie ist wichtiger, als zwanzig Tools installiert zu haben. Wenn du ein Ziel waehlst, das zu deinem aktuellen Level passt, findest du Bugs. Wenn du ein Ziel waehlst, das zu gross, zu komplex oder zu ueberlaufen ist, brennst du aus.

Ich habe das auf die harte Tour gelernt. Frueh in meiner Laufbahn jagte ich alles, an dem eine Bounty hing. Ich verschwendete Monate an Zielen, die zu gross, zu komplex oder zu ueberlaufen waren. Sobald ich anfing, Ziele vor dem Testen zu filtern, aenderten sich meine Ergebnisse sofort. Diese Disziplin hat mich zu 250+ Hall-of-Fame-Eintraegen von Organisationen wie WHO, UNESCO, BBC, Boeing, Cambridge, Sheffield, Deutsche Boerse, BASF, Michelin und Philips gebracht.

Dieser Leitfaden verwandelt diese Disziplin in ein einfaches, wiederholbares System. Das 3-Filter-System ist nicht kompliziert und erfordert keine fortgeschrittenen Tools. Es erfordert nur Ehrlichkeit darueber, wo du als Hunter gerade stehst. Pruefe jedes potenzielle Ziel anhand dieser drei Checks. Scheitert ein Ziel an einem Check, lass es fallen und suche ein anderes.

1. Filter 1: Scope-Groesse (kannst du ihn in 30 Minuten kartieren?)

Waehle fuer deine ersten zehn Bugs einen Scope, der auf einen Bildschirm passt. Vermeide am Anfang Wildcard-Scopes wie *.target.com. Suche nach fokussierten Scopes wie api.target.com, dashboard.target.com oder konkreten Endpoints und Subdomains, die in der Policy aufgefuehrt sind.

Warum die Scope-Groesse ueber deine Chancen entscheidet

Ein Wildcard-Scope ist eine Falle fuer Einsteiger. Du verbringst zwei Wochen damit, Tausende Subdomains zu kartieren. Du findest einen alten Server, freust dich, und lernst dann, dass jemand ihn vor zwei Tagen per Automatisierung gemeldet hat. Du hast gerade achtzig Stunden investiert, um zu erfahren, dass ein anderer Hunter schneller ist als du.

Grosse Scopes erzeugen ausserdem Entscheidungsmuedigkeit. Wenn du zehntausend Subdomains hast, entwickelst du nie ein tiefes Verstaendnis fuer eine einzelne Anwendung. Du springst von Asset zu Asset. Aber Logic-Bugs leben im tiefen Verstaendnis. IDORs, Race Conditions und Preismanipulation werden von Testern gefunden, die den Business-Flow besser verstehen als die Entwickler selbst.

Betrachte es so. Wenn dich jemand bitten wuerde, einen Fehler in einem einzigen Kapitel eines Buchs zu finden, koenntest du das in einer Stunde. Wenn er dich bitten wuerde, irgendwo in einer ganzen Bibliothek einen Fehler zu finden, wuerdest du tagelang umherirren und ihn wahrscheinlich verfehlen. Genau das passiert, wenn Einsteiger Wildcard-Scopes jagen. Der Bug ist da, aber du suchst an zu vielen Stellen gleichzeitig.

Ein fokussierter Scope zwingt dich, jedes Feature zu verstehen. Du lernst, wie sich Benutzer registrieren, wie Bestellungen ablaufen, wie Zahlungen verarbeitet werden und wie Dateien geteilt werden. Genau dort verstecken sich die echten Bugs. Wenn du jeden Endpoint auswendig kennst, faengst du an, die merkwuerdigen Verhaltensweisen zu bemerken: einen Parameter, der sein Verhalten aendert, wenn du ihn modifizierst, einen Endpoint, der Berechtigungen nicht richtig prueft. Diese Momente entstehen nur, wenn du die Anwendung tief kennst.

Wie das in der Praxis aussieht

Ein Sicherheitsforscher teilte seine Erfahrung nach acht Monaten Misserfolg auf Reddit. Er war Webentwickler mit solidem technischem Wissen. Jedes Mal, wenn er mit dem Hunting begann, listete er alle Subdomains eines grossen Ziels auf und klickte sie dann wahllos durch. Er nutzte Tools zur Subdomain-Enumeration, Crawler und Archiv-URL-Fetcher. Nachdem er Endpoints gefunden hatte, wusste er nicht, was er als Naechstes tun sollte. Er schrieb, es fuehle sich an, als muesste er ein ganzes Jahr aufwenden, um nur einen winzigen Bug zu finden. Er jagte riesige Scopes auf beliebten Programmen ohne Plan, und die Groesse des Ziels ueberforderte ihn vollkommen. Den Thread kannst du hier lesen: Bug bounty is insanely hard. Am I doing something wrong?

Ein anderer Hunter schrieb ueber den Fehler, der seinen Fortschritt monatelang ausbremste. Er jagte riesige Programme mit breiten Scopes, wechselte alle paar Tage das Ziel und verpflichtete sich nie darauf, eine Anwendung tief zu verstehen. Sobald er sich auf kleinere, handhabbare Scopes konzentrierte, aenderten sich seine Ergebnisse sofort: The Bug Hunting Mistake That Slowed My Progress.

Scopes, die fuer Einsteiger ideal sind

• api.target.com oder mobile.target.com mit wenigen Subdomains und Assets
• Konkrete Endpoints wie /api/v1/users oder /api/v1/orders
• Einzelne Anwendungen mit klaren Benutzerrollen
• Online-Shops mit Warenkorb- und Checkout-Flows

Die Regel: Wenn du nicht innerhalb von dreissig Minuten jeden Endpoint im Scope lesen kannst, ist das Ziel zu gross. Ueberspring es.

2. Filter 2: Technologie-Stack (jage, was du verstehst)

Waehle Ziele, bei denen du die Logik und das Protokoll verstehst. Wenn du noch nie mit GraphQL gearbeitet hast, waehle kein Ziel, dessen gesamte API GraphQL-nativ ist. Wenn du Mobile-Anwendungen nicht verstehst, lass Mobile-Scopes vorerst aus. Du kannst diese Technologien spaeter lernen, aber dort beginnst du nicht. Jage, was du kennst.

Warum ein Tech-Mismatch die Motivation toetet

Wenn du ein Ziel waehlst, das auf einer Technologie aufbaut, die du nicht verstehst, verbringst du deine erste Woche damit, Syntax zu lernen, statt Bugs zu finden. Du verbringst deine zweite Woche im Ringen mit Konzepten. Bis zur dritten Woche bist du frustriert und bereit aufzugeben.

Einsteiger jagen oft hohe Bounties auf schweren Zielen. Eine maximale Auszahlung von 50.000 US-Dollar bedeutet nichts, wenn die Anwendung auf einem Stack laeuft, den du nicht testen kannst. Facebook, Google und Apple haben erstklassige Sicherheit und werden seit ueber einem Jahrzehnt von den besten Huntern getestet. Als Einsteiger wirst du wahrscheinlich hundert Stunden investieren und nichts finden.

Vergleiche das mit einem Hunter, der REST-APIs und Standard-Webformulare verstand und einen Preismanipulations-Bug auf einer simplen PHP-Seite fand. Die Checkout-API war ein einfacher POST-Request. Keine Microservices, keine komplexe Architektur, nur ein Preisparameter, der von der Client-Seite gesendet wurde. Er aenderte den Preis von fuenfhundert Dollar auf zwei Dollar, und der Server akzeptierte ihn. Dieser Bug erforderte null Exploit-Code und keine speziellen Payloads. Er erforderte nur das Verstaendnis eines simplen POST-Requests und die Frage, warum der Preis vom Client kam. Das ist eine klassische Business-Logic-Schwachstelle, und es ist genau die Art Bug, die du finden kannst, wenn dein Kopf frei ist, nach Logikfehlern zu suchen, statt mit den Grundlagen zu kaempfen.

Echter Fall: die GraphQL-Huerde

Ein Einsteiger teilte oeffentlich die Geschichte seiner ersten Bounty. Er fand eine JavaScript-Datei mit einem GraphQL-API-Key auf einem Ziel mit riesigem Scope und entdeckte per Directory-Fuzzing einen /graphql-Endpoint. Doch es gab ein Problem: Er wusste nichts ueber GraphQL. Er verbrachte mehrere Tage mit Recherche, Lernen und dem Sammeln von Tools, nur um das Schema zu verstehen. Er nutzte die PortSwigger Academy, um die Grundlagen zu lernen, und die InQL-Burp-Extension, um das Schema zu visualisieren. Am Ende verdiente er eine Bounty von 700 US-Dollar, aber die technologische Luecke haette ihn beinahe zum Aufgeben gebracht, bevor er ueberhaupt anfing. Haette er ein Standard-REST-API-Ziel gewaehlt, haette er sofort mit dem Testen beginnen koennen. Die ganze Geschichte: How I Got My First Bounty.

Einsteigerfreundliche Stacks

• Standard-REST-APIs mit klaren GET- und POST-Endpoints (siehe unseren Leitfaden zum API-Security-Testing)
• Klassische Web-Apps mit Benutzerrollen wie Admin, User und Guest
• E-Commerce-Flows mit Warenkorb-, Checkout- und Zahlungsschritten
• Plattformen mit Team- oder Einladungsfunktionen

Stacks, die du als Einsteiger meiden solltest

• Starke WebSocket-Abhaengigkeit. Ohne eigenes Tooling schwer zu testen.
• GraphQL mit komplexer Autorisierung. Steile Lernkurve.
• Internet-of-Things- oder Hardware-Scopes. Erfordern physische Geraete.
• Blockchain- oder Smart-Contract-Scopes. Ein voellig anderes Skillset.

Wenn du noch an den Grundlagen baust, verbringe zuerst Zeit in einem Home Lab und der PortSwigger Web Security Academy. Beide lassen dich die obigen Stacks ohne jedes rechtliche Risiko ueben.

3. Filter 3: Hunter-Dichte (meide die Menge)

Finde Programme, auf denen die Konkurrenz gering ist, der Scope aber real ist. Vermeide den Ansturm auf beliebte Programme. Suche nach Vulnerability Disclosure Programs mit kurzen Hall-of-Fame-Listen und neueren Programmen, die noch nicht leergeraeumt wurden.

Warum Dichte ein verborgener Multiplikator ist

Hohe Hunter-Dichte bedeutet geringe Chancen. Wenn fuenftausend Hunter auf dasselbe Ziel schauen, sinkt deine Chance, einen neuen Bug zu finden, auf nahezu null. Die einfachen Bugs wurden am ersten Tag gefunden. Die mittelschweren Bugs wurden in der ersten Woche gefunden. Was uebrig bleibt, erfordert tiefes Fachwissen oder sehr spezifische Bedingungen.

Beliebte Programme auf grossen Plattformen sind wie ueberfuellte Angelstellen. Alle werfen ihre Angeln aus, und die grossen Faenge sind selten. Auf den am staerksten gesaettigten Programmen wird ein grosser Teil der eingehenden Reports als Duplikat geschlossen, was bedeutet, dass dir selbst ein gueltiger Fund nichts einbringen kann.

Verborgene Programme sind deine Geheimwaffe. Einige der besten Ziele fuer Einsteiger stehen nicht auf den Startseiten von HackerOne oder Bugcrowd. Es sind Responsible-Disclosure-Programme, die auf der Sicherheitsseite eines Unternehmens vergraben sind, oder selbst gehostet ueber eine security.txt-Datei auf der Unternehmenswebsite. Diese Programme zahlen vielleicht kein Geld, aber sie bieten Hall-of-Fame-Eintraege, Swag, Reputation und Erfahrung. Am wichtigsten: Sie haben sehr wenig Konkurrenz. Ein Unternehmen, das ein VDP ueber seine eigene Website betreibt, hat vielleicht nur fuenf oder zehn Hunter, die jemals an es gemeldet haben. Vergleiche das mit einem Flaggschiff-Programm mit fuenftausend Huntern. Wo wuerdest du lieber deine zwei Wochen verbringen?

Echter Fall: zwoelf Namen in der Hall of Fame

Ein Hunter verdiente seine erste Bounty von 1.000 US-Dollar, indem er die Menge komplett mied. Statt zu einem beliebten Programm zu springen, waehlte er ein ausgereiftes oeffentliches Programm und ging nach fast zwei Monaten erneut seine Notizen durch und pruefte erneut robots.txt. Er fand einen disallowten Pfad, der auf ein Admin-Panel zeigte, das einen 403 zurueckgab, was die Existenz der Ressource bestaetigte, und fand dann einen Weg, die Beschraenkung zu umgehen. Das entscheidende Detail ist, dass er ein fokussiertes Ziel mit geringer Konkurrenz waehlte, was ihm erlaubte, Zeit auf Details wie robots.txt zu verwenden, ohne sich Sorgen zu machen, dass fuenfhundert andere Hunter sie bereits geprueft hatten: My First Bug Bounty: How I Earned $1,000.

Ein anderer Forscher fand ein Fintech-VDP mit genau zwoelf Namen in der Hall of Fame und einem Scope von nur zwei APIs. Weil die Konkurrenz so gering war, testete er zwei Wochen lang jedes Feature tief und fand drei gueltige Bugs in Nebenfunktionen, die andere Hunter uebersprungen hatten. Auf einem Programm mit fuenfhundert aktiven Huntern waeren diese Bugs in der ersten Woche weg gewesen.

Wie du die Hunter-Dichte misst

1. Pruefe die Hall-of-Fame-Seite. Wenn sie 200+ Namen hat, ist das Programm gesaettigt. Zehn bis fuenfzig Namen bedeuten, dass du Spielraum hast.
2. Schau auf das Alter des Programms. Ein Programm, das vor sechs Monaten gestartet wurde und dreihundert geloeste Reports hat, ist wahrscheinlich leergeraeumt. Ein Programm, das vor drei Wochen mit fuenf Reports startete, ist frisch.
3. Pruefe die letzte Aktivitaet. Wenn der letzte geloeste Report von gestern ist, arbeiten Hunter aktiv daran. Wenn der letzte Report drei Wochen alt ist, sind die Hunter weitergezogen, aber die Bugs koennten noch da sein.

Verborgene Programme mit Google-Dorks finden

Google Dorking nutzt fortgeschrittene Suchoperatoren, um Programme mit geringer Konkurrenz aufzuspueren:

site:com inurl:responsible-disclosure
site:de inurl:security.txt
inurl:.well-known/security.txt "contact"
site:io "report a vulnerability"

Wenn du eine security.txt-Datei findest (standardisiert als RFC 9116), lies sie sorgfaeltig. Wenn sie einen Kontakt und eine Acknowledgments-Seite auffuehrt, hast du ein Ziel mit praktisch keiner Konkurrenz gefunden.

4. Arbeite eine 2-stuendige Recon-Checkliste ab, bevor du testest

Sobald ein Ziel alle drei Filter passiert, fang nicht an, Payloads abzufeuern. Verbringe zwei Stunden mit strukturierter Reconnaissance. Wenn du diese Fragen nicht in 120 Minuten beantworten kannst, ist das Ziel zu komplex oder deine Notizen brauchen Arbeit.

Stunde 1: kartiere die Angriffsflaeche

Dein Ziel in der ersten Stunde ist es, die gesamte Angriffsflaeche zu verstehen, noch nicht Bugs zu finden.

• Registriere zwei Konten. Du brauchst zwei Konten, um auf IDORs und andere Zugriffskontroll-Probleme zu testen.
• Identifiziere alle Benutzerrollen. Guest, User, Admin, Vendor. Kann eine zu einer anderen eskalieren?
• Liste jedes Feature auf. Login, Passwort-Reset, Profil-Update, Datei-Upload, Sharing, Checkout.
• Finde die API-Dokumentation. Suche nach Swagger- oder Postman-Collections oder lies die JavaScript-Aufrufe des Frontends.

Stunde 2: suche nach niedrig haengenden Fruechten

• Passwort-Reset-Flow. Ist der Token vorhersehbar? Kannst du ihn per Brute Force knacken?
• Datei-Upload. Gibt es eine Filterung nach Dateiendung? Kannst du HTML oder JavaScript hochladen?
• Profil-Update. Kannst du deine E-Mail auf die E-Mail eines bestehenden Benutzers aendern?
• Sharing- oder Einladungs-Flows. Kannst du dich selbst zu der Ressource eines anderen Benutzers einladen?
• Checkout- oder Zahlungs-Flow. Wird der finale Preis vom Client gesendet?

Wenn du diese Checkliste abschliesst und nichts findest, gib nicht auf. Du hast nur die Oberflaeche getestet. Aber wenn du auch nur ein merkwuerdiges Verhalten findest, etwa ein 200 OK bei einer modifizierten ID oder ein fehlendes Rate Limit, hast du eine Spur. Verfolge diese Spur. Neu beim Recon-Tooling? Beginne mit unserem Nmap-Tutorial und den wichtigsten Linux-Befehlen.

5. Bewerte jedes Ziel mit der Target-Scorecard

Nutze diese Scorecard fuer jedes Ziel, bevor du auch nur eine Stunde investierst. Sie dauert fuenf Minuten und bewahrt dich vor Wochen verschwendeter Muehe.

Bewertungshilfe:

• 25 bis 30: Prime-Ziel. Bleib vier Wochen dran.
• 18 bis 24: Akzeptabel. Gut zum Lernen, aber daempfe deine Erwartungen.
• Unter 18: Lass es fallen. Finde etwas Besseres. Deine Zeit ist zu wertvoll.

Halte diese Scorecard in deinen Notizen fest und arbeite sie vor jedem neuen Ziel durch.

6. Bleib vier Wochen an einem Ziel dran

Sobald ein Ziel die Filter passiert und die Scorecard besteht, bleib vier Wochen dran. Fuege kein zweites Ziel hinzu, bevor du nicht vier volle Wochen am ersten verbracht hast.

Die meisten Einsteiger sind Ziel-Touristen. Sie jagen drei Tage ein Programm, finden nichts und wechseln zum naechsten. Sie entwickeln nie das tiefe Verstaendnis, das fuer Logikfehler noetig ist. Und Logic-Bugs zeigen sich nicht an Tag drei. Sie zeigen sich an Tag zehn, wenn dir auffaellt, dass sich der Endpoint zum Loeschen des Kontos anders verhaelt, wenn du ihn zweimal sendest. Sie zeigen sich an Tag zwanzig, wenn du erkennst, dass die Mobile-API einen Parameter hat, den die Web-App nie nutzt. Sie zeigen sich an Tag dreissig, wenn du den Business-Flow besser verstehst als der Entwickler.

Diese Disziplin ist unbequem. Sie fuehlt sich langsam an. Aber so baust du die Mustererkennung auf, die das Hunting spaeter muehelos erscheinen laesst. Wenn du in vier Wochen keinen Bug findest, gehe deine Notizen durch, bevor du weiterziehst. Hast du ein Feature uebersehen? Hast du einen Flow uebersprungen? Erst dann ziehe einen Wechsel in Betracht.

7. Wo Bug Bounty in deine umfassendere Karriere passt

Bug Bounty ist einer der schnellsten Wege, Offensive-Security-Faehigkeiten oeffentlich zu beweisen, aber es ist selten die ganze Geschichte. Dieselbe Disziplin bei der Zielauswahl (Fokus, Tiefe und Geduld) ist genau das, wonach Arbeitgeber bei Penetrationstestern und Red Teamern suchen. Wenn du eine Karriere aufbaust, kombiniere dein Hunting mit strukturiertem Lernen: einem klaren Cybersicherheits-Karrierepfad, den richtigen Einsteiger-Zertifizierungen und dem Nachweis, dass du sicher arbeiten kannst, den du in einem Cybersicherheits-Home-Lab aufbaust. Quereinstieg ohne formalen Hintergrund? Sieh dir an, wie Menschen ohne Abschluss einsteigen.

Lies jede Woche offengelegte Reports, um deine Mustererkennung zu trainieren. Die PortSwigger Web Security Academy und die Projektseiten von OWASP sind kostenlos, autoritativ und decken sich direkt mit den Bugs, die du jagen wirst.

Fazit: kippe die Chancen zu deinen Gunsten

Bug Bounty ist keine Lotterie. Es geht darum, die Chancen zu deinen Gunsten zu kippen.

Du musst nicht Google hacken, um ein echter Hacker zu sein. Du musst ein Ziel finden, das zu deinen aktuellen Faehigkeiten passt, es tief verstehen und dort jagen, wo andere nicht hinschauen. Das 3-Filter-System verwandelt zufaelliges Raten in einen Prozess. Die Scope-Groesse haelt dich fokussiert. Der Technologie-Stack haelt dich effektiv. Die Hunter-Dichte haelt dich konkurrenzfaehig.

Dein erster Hall-of-Fame-Eintrag versteckt sich in einer fokussierten API, auf einem Programm mit zwoelf anderen Huntern, in einem Business-Logic-Flow, an dessen Test niemand sonst gedacht hat. Nutze die Filter. Nutze die Scorecard. Bleib vier Wochen dran. Geh ihn finden.