Bug bounty pour sysadmins : guide de démarrage

Un guide de démarrage bug bounty pour sysadmins commence par ce que personne ne m'a dit : tes réflexes DNS, HTTP et Linux se transfèrent bien mieux que tu ne l'imagines. Les chèques sur HackerOne et Intigriti ne vont pas aux magiciens du ROP kernel. Ils vont aux gens qui font de la recon patiente, qui sentent quand un flux d'auth ne tourne pas rond, qui savent écrire un report qu'un triager a vraiment envie de lire. Ça, c'est de l'ADN de sysadmin. Voilà l'onboarding que j'aurais aimé qu'on me file : décrocher tes premiers 500 euros en 90 jours sans quitter ton boulot, quoi apprendre, quels programmes choisir, les cinq outils que j'ouvre, et pourquoi un report est payé quand le suivant crève en informative.

Onze ans à garder en vie les serveurs des autres avant de toucher mon premier bounty. Et personne ne m'avait dit ce qui comptait le plus : tes réflexes DNS, HTTP et Linux se transfèrent bien mieux que tu ne l'imagines. Les chèques sur HackerOne et Intigriti ne vont pas aux magiciens du ROP kernel. Ils vont aux gens qui font de la recon patiente, qui sentent quand un flux d'auth ne tourne pas rond, qui savent écrire un report qu'un triager a vraiment envie de lire. Aux gens capables de relancer un ticket bloqué pendant deux semaines sans s'agacer. Ça, c'est de l'ADN de sysadmin, franchement. Voilà donc l'onboarding que j'aurais aimé qu'on me file : comment décrocher tes premiers 500 euros en 90 jours sans quitter ton boulot, quoi apprendre, quels programmes choisir, les cinq outils que j'ouvre vraiment, les lignes légales à ne jamais franchir, et pourquoi un report est payé pendant que le suivant crève en informative.

Pourquoi sysadmin vers bug bounty marche vraiment

Voilà ce qui a fait basculer ma vision des choses. Ouvre le rapport HackerOne 2025. Sur les 100 programmes les mieux payés, plus de la moitié de l'argent est allée à l'access control, à l'information disclosure, au SSRF, à la misconfiguration et au broken authentication. Rien là-dedans n'est de l'exploit-dev. Chacune de ces choses, tu la traques déjà dans une file de tickets, franchement. Tu sais à quoi sert un header Origin. Tu as déjà vu une chaîne de redirections fuiter de l'état dans une query string. Et tu as déjà vu une réécriture nginx try_files avaler discrètement un path-traversal. Tu lis des stack traces de prod les yeux fermés. Tout le pivot, c'est juste faire ça volontairement, sur la machine de quelqu'un d'autre, avec sa permission écrite en poche.

Le changement de mindset : du défenseur à l'attaquant

Une chose doit changer : le sens dans lequel pointe ta curiosité. Pendant des années, tu as repéré un truc bizarre et tu t'es demandé est-ce que c'est cassé, je le répare avant lundi ? La version hunter de toi voit exactement la même bizarrerie et se demande est-ce que je peux lui faire faire un truc qu'il ne devrait pas, et ça devient grave à quel point ? Même instinct. But opposé. Quelques bascules m'ont fait tilt, et je ne suis toujours pas sûr d'avoir pleinement fait la deuxième.

• Vise direct les edge cases. Encodages d'URL bizarres, comportements de double-decode, request smuggling. Les bugs vivent là où le parser n'est pas d'accord avec lui-même. Le happy path a été testé à mort il y a des années.
• Marque chaque trust boundary. Un formulaire de login. Un callback OAuth. Une assertion SSO, une API interne. Chacun est une clôture, et les bugs s'entassent sur la clôture, quasiment jamais en plein milieu du champ.
• Lis les règles comme un attaquant. Quand un programme détaille ce qui est out of scope, je le lis deux fois. Cette liste te dit en douce où traîne le bazar oublié, et parfois où il déborde vers quelque chose que tu as le droit de toucher.

Un stack d'outils minimal pour 2026

Tu peux passer un an à lire des comparatifs d'outils sur Reddit. Ou installer cinq trucs gratuits en une heure et partir à la chasse. J'ai fait le premier. Ne sois pas comme moi. Voilà tout le kit :

Laisse tomber Metasploit. Laisse tomber Cobalt Strike, laisse tomber tout l'état d'esprit CVE à la lance à incendie. Les programmes paient pour le bug que toi tu as trouvé. Ils ne paient pas pour balancer un exploit vieux de deux ans que cinquante autres personnes ont déjà reporté, celui qui fait fermer ton report en dupe avant midi.

Choisir ton premier programme

C'est là que la plupart des débutants choisissent mal, puis abandonnent deux mois plus tard. Je juge un programme sur quelques points, en gros dans cet ordre :

1. Un triage qui répond vraiment. Sur HackerOne et Intigriti, filtre sur un temps de réponse médian sous les 72 heures et un ratio resolved-to-disclosed au-dessus de 70 %. Les chiffres sont là, juste sur la page du programme. Un programme qui te ghost pendant six semaines tue ta motivation plus vite que n'importe quel duplicate.
2. Un scope assez large pour respirer. Tu veux ceux qui listent *.example.com et toute société qu'on rachète. C'est là que se planque le low-hanging fruit oublié. Un programme scopé sur une seule page marketing statique n'a rien pour toi. Passe ton chemin.
3. Il paie en Low et en Medium. Plein de programmes ne crachent au bassinet que pour les criticals, ce qui est un point de départ brutal. Je filtre pour avoir au moins 100 $ sur un Low, comme ça mes premières trouvailles, modestes, valent quand même le writeup.

Tu veux des noms pour commencer en 2026 ? GitLab, Reddit, Shopify, le Bug Bounty de GitHub lui-même, Twilio, Mozilla, le Hack the Pentagon du Department of Defense américain. Ils publient de vraies consignes. Ils paient pour de vrai. Leur triage ne te laissera pas poireauter un mois.

Le workflow hebdo en cinq phases

Qu'est-ce qui sépare les gens qui soumettent de ceux qui font des trucs de sécu le week-end ? Faire tourner cette boucle chaque semaine. Même les semaines où tu n'as absolument rien trouvé. Surtout celles-là.

1. Phase 1, Scope et recon passive (1 heure). Lis les règles lentement. Note ce qui est dedans et ce qui est dehors. Tu te remercieras plus tard. Ensuite, sors les sous-domaines depuis crt.sh, amass enum -passive -d example.com et la recherche de code GitHub, puis dédoublonne tout le tas en une seule liste.
2. Phase 2, Fingerprint actif (1 heure). Passe la liste dans httpx, puis nuclei -t exposures,misconfiguration -l alive.txt, et screenshot chaque hôte vivant avec gowitness. Maintenant, feuillette les captures. Des portails de login défraîchis. Des pages de dev à moitié finies, des panneaux d'admin tiers que le marketing a montés puis oubliés. Ils te sautent aux yeux d'une façon que lire du HTML brut ne fera jamais.
3. Phase 3, Deep-dive manuel (3 heures). Choisis tes trois cibles les plus intéressantes et installe-toi dans Burp un bon moment, en gros. Connecte-toi, puis pars à la chasse : IDOR, contrôles d'accès manquants, flux de password-reset bâclés, gestion JWT bizarre, SSRF enfoui dans des webhooks. C'est la partie qui paie vraiment. Alors ne la bâcle pas.
4. Phase 4, Vérifier, scorer, écrire (1 heure). Reproduis le truc trois fois sur une session fraîche. Si ça ne part pas proprement à chaque fois, tu n'as pas encore de bug. Score-le avec le CVSS 3.1. Puis écris un PoC serré : étapes numérotées, les commandes, une capture ou deux. Rien dont tu n'aies pas réellement besoin.
5. Phase 5, Soumettre et itérer (30 minutes). Envoie-le via la plateforme, jamais par email. Sois poli, sois précis, et quand le triage te recontacte, réponds dans la journée. La réactivité, ça te fait remarquer. Se faire remarquer, c'est comme ça que les invitations privées commencent à arriver.

Les classes de bugs qu'un sysadmin repère plus vite que personne

• Subdomain takeover. Un CNAME qui pointe encore vers un hôte Azure / Heroku / S3 que plus personne ne possède. Tu as passé des années à nettoyer du DNS qui pendouille. Ici, exactement cet œil-là te fait payer.
• SSRF via un webhook ou un générateur de PDF. Fais en sorte qu'un webhook aille chercher http://169.254.169.254 et te voilà en train de lire les métadonnées cloud, qui te filent souvent des creds IAM tout cuits. Toujours une des classes les mieux payées du moment, aux dernières nouvelles.
• IDOR sur des endpoints admin. Un /api/users/123/edit que l'utilisateur 456 peut ouvrir tranquillement. Monte deux comptes. Trente secondes pour confirmer.
• Creds par défaut sur des outils d'admin tiers. Jenkins, Kibana, Elasticsearch, Grafana posés sur un sous-domaine que le marketing a monté puis oublié. Tu sais déjà quels produits sortent grand ouverts par défaut. C'est ton avantage, tout simplement.
• Path traversal à travers un proxy mal configuré. La directive alias de nginx sans slash final est l'indémodable. Tu l'as quasi certainement déjà corrigée sur tes propres machines. Maintenant, va trouver quelqu'un qui ne l'a pas fait.
• Des secrets qui fuient par les pages d'erreur. Des stack traces qui recrachent des chemins de fichiers, des versions de driver DB, des IP internes. Tu lis ça pour gagner ta vie. La plupart des hunters passent dessus sans s'arrêter.

Les garde-fous légaux (à ne pas zapper)

Relis le scope avant de toucher quoi que ce soit. Titille un asset hors scope et tu ne fais plus du hunting. Tu t'introduis sur le réseau de quelqu'un. Le CFAA aux US, la LCEN ici en France, le Computer Misuse Act au UK : aucun de ces textes ne se soucie que tu partais d'une bonne intention. Les bonnes intentions ne tiennent pas comme défense juridique.

• Reste dans le scope explicite. Toujours. Et à la seconde où une requête touche les données d'un autre client, arrête, fais marche arrière, ne va pas en chercher plus.
• N'exfiltre pas. Ta preuve, c'est ce GET renvoie un 200 avec un champ email dans le body, point. Jamais voilà les 10 000 enregistrements que j'ai dumpés dans un CSV. Ce geste-là transforme un payout en coup de fil du service juridique.
• Respecte les lignes no DoS, no automated scanning. J'ai vu quelqu'un pointer un run nuclei agressif sur un endpoint rate-limité et se faire bannir de la plateforme pour ça. Ça ne vaut tout simplement pas le coup.
• Garde un email propre et un handle unique par plateforme. Plusieurs programmes font du KYC avant de te payer, et tu ne veux pas que ça devienne gênant plus tard.

La qualité de report qui se fait payer

C'est le passage qui décide vraiment si tu es payé ou non. C'est aussi celui où les sysadmins sont, discrètement, excellents. Un triager se tape cinquante reports par jour. Le tien gagne en respectant son temps, en lui laissant confirmer le bug en deux minutes chrono. Voilà la forme que j'utilise :

1. Un résumé en une ligne. IDOR sur /api/orders/{id} qui permet à n'importe quel utilisateur authentifié de lire les détails de commande d'un autre utilisateur. Tout le bug, tout en haut, avant même qu'il scrolle.
2. Asset affecté et tag de scope. Recopie la formulation exacte du programme. Ne force pas le triager à chercher de quel asset tu parles.
3. Sévérité. Un vecteur et un score CVSS 3.1. Montre ton calcul. Ne colle pas juste critical en espérant que personne ne vérifie.
4. Étapes de repro. Numérotées et copiables-collables. Je prendrai un curl propre plutôt qu'une pile de captures Burp, à chaque fois.
5. Impact. Un court paragraphe. Ce qu'un attaquant fait avec, quelles données fuient, qui est en cause. Pas de drame, pas de breach catastrophique.
6. Correctif suggéré. Optionnel, mais les triagers adorent : Ajouter un contrôle côté serveur que session.userId == order.userId avant de renvoyer le document. C'est là que ton cerveau de défenseur paie en douce.

Et coupe le reste. Pas de voix marketing. Pas de menaces voilées sur la disclosure, pas de ton concurrent a déjà patché ça. La personne en face veut le vérifier, te payer et fermer le ticket. Alors facilite-lui ça.

Sources et ressources complémentaires

• OWASP, Top Ten
• OWASP, Cheat Sheet Series

Questions fréquentes