Bug Bounty Starter Guide for Sysadmins

A bug bounty starter guide for sysadmins begins with the thing nobody told me: your DNS, HTTP and Linux reflexes transfer way better than you would guess. The cheques on HackerOne and Intigriti do not go to kernel ROP wizards. They go to people who do patient recon, who notice when an auth flow smells off, who can write a report a triager actually wants to read. That is sysadmin DNA, honestly. So here is the onboarding I wish someone had handed me: how to land your first 500 euros inside 90 days without quitting your day job, what to learn, which programs to pick, the five tools I actually open, the legal lines you do not cross, and why one report gets paid while the next one dies as informative.

Eleven years keeping other people's servers alive before I cashed my first bounty. And nobody told me the thing that mattered most: your DNS, HTTP and Linux reflexes transfer way better than you'd guess. The cheques on HackerOne and Intigriti don't go to kernel ROP wizards. They go to people who do patient recon, who notice when an auth flow smells off, who can write a report a triager actually wants to read. People who'll chase a stalled ticket for two weeks without getting snippy about it. That's sysadmin DNA, honestly. So here's the onboarding I wish someone had handed me: how to land your first 500 euros inside 90 days without quitting your day job, what to learn, which programs to pick, the five tools I actually open, the legal lines you don't cross, and why one report gets paid while the next one dies as "informative."

Why sysadmin to bug bounty actually works

Here's the thing that flipped my thinking. Pull up the 2025 HackerOne report. Across the top 100 paid programs, over half the money went to access control, information disclosure, SSRF, misconfiguration and broken authentication. None of that is exploit-dev. Every one is something you already chase in a ticket queue, honestly. You know what an Origin header does. You've watched a redirect chain leak state into a query string. And you've seen an nginx try_files rewrite quietly swallow a path-traversal. You read production stack traces in your sleep. The whole pivot is just doing that on purpose, on someone else's box, with their written permission in hand.

The mindset shift from defender to attacker

One thing has to change: which way your curiosity points. For years you've spotted something weird and asked "is this broken, do I fix it before Monday?" The hunter version of you sees the exact same weirdness and asks "can I make this do something it shouldn't, and how bad does that get?" Same instinct. Opposite goal. A few shifts made it click for me, and I'm still not sure I've fully made the second one.

• Go straight for the edge cases. Weird URL encodings, double-decode behaviour, request smuggling. Bugs live where the parser disagrees with itself. The happy path got tested to death years ago.
• Mark every trust boundary. A login form. An OAuth callback. An SSO assertion, an internal API. Each one is a fence, and bugs pile up on the fence, basically never out in the open field.
• Read the rules like an attacker. When a program spells out what's "out of scope," I read it twice. That list quietly tells you where the messy forgotten stuff lives, and sometimes where it spills back into something you are allowed to touch.

A minimal 2026 tooling stack

You can spend a year reading tool comparisons on Reddit. Or install five free things in an hour and go hunt. I did the first one. Don't be me. Here's the whole kit:

Skip Metasploit. Skip Cobalt Strike, skip the whole CVE-firehose mindset. Programs pay for the bug you found. They don't pay for spraying a two-year-old exploit that fifty other people already reported, the one that gets your report closed as a dupe before lunch.

Picking your first program

This is where most beginners pick wrong, then quit two months later. I judge a program on a few things, roughly in this order:

1. Triage that actually answers. On HackerOne and Intigriti, filter for a median response under 72 hours and a resolved-to-disclosed ratio north of 70 %. The numbers sit right there on the program page. A program that ghosts you for six weeks kills your motivation faster than any duplicate ever will.
2. Scope wide enough to breathe. You want the ones listing *.example.com and "any company we acquire." That's where the forgotten low-hanging stuff hides. A program scoped to one static marketing page has nothing for you. Walk away.
3. It pays Low and Medium. Plenty of programs only cough up for criticals, which is a brutal place to start. I filter for at least $100 on a Low so my early, modest finds are still worth the writeup.

Want names to start with in 2026? GitLab, Reddit, Shopify, GitHub's own Bug Bounty, Twilio, Mozilla, the U.S. Department of Defense's Hack the Pentagon. They publish real guidance. They actually pay. Their triage won't leave you hanging for a month.

The five-phase weekly workflow

What separates people who submit from people who just "do security stuff on weekends"? Running this loop every week. Even the weeks you found absolutely nothing. Especially those.

1. Phase 1, Scope and passive recon (1 hour). Read the rules slowly. Write down what's in and what's out. You'll thank yourself later. Then pull subdomains from crt.sh, amass enum -passive -d example.com and GitHub code search, and dedupe the whole pile into one list.
2. Phase 2, Active fingerprint (1 hour). Run the list through httpx, then nuclei -t exposures,misconfiguration -l alive.txt, and screenshot every live host with gowitness. Now flip through the screenshots. Crusty login portals. Half-finished dev pages, third-party admin panels marketing stood up and forgot. They jump out at you in a way reading raw HTML never will.
3. Phase 3, Manual deep-dive (3 hours). Pick your three most interesting targets and basically live in Burp for a while. Log in, then go hunting: IDOR, missing access checks, sloppy password-reset flows, weird JWT handling, SSRF buried in webhooks. This is the part that actually pays. So don't rush it.
4. Phase 4, Verify, score, write (1 hour). Reproduce it three times on a fresh session. If it doesn't fire clean every time, you don't have a bug yet. Score it with CVSS 3.1. Then write a tight PoC: numbered steps, the commands, a screenshot or two. Nothing you don't actually need.
5. Phase 5, Submit and iterate (30 minutes). Send it through the platform, never by email. Be polite, be precise, and when triage pings you back, answer inside a day. Responsiveness gets you remembered. Getting remembered is how the private invites start showing up.

Bug classes a sysadmin spots faster than anyone

• Subdomain takeover. A CNAME still pointing at an Azure / Heroku / S3 host nobody owns anymore. You've spent years cleaning up dangling DNS. Here, that exact eye gets you paid.
• SSRF via a webhook or PDF generator. Get a webhook to fetch http://169.254.169.254 and you're reading cloud metadata, which often hands you IAM creds outright. Still one of the better-paying classes around, last I checked.
• IDOR on admin endpoints. /api/users/123/edit that user 456 can happily open. Spin up two accounts. Thirty seconds to confirm.
• Default creds on third-party admin tools. Jenkins, Kibana, Elasticsearch, Grafana sitting on a subdomain marketing stood up and forgot about. You already know which products ship wide open out of the box. That's your edge, plain and simple.
• Path traversal through a misconfigured proxy. The nginx alias directive with no trailing slash is the timeless one. You've almost certainly fixed it on your own boxes. Now go find someone who didn't.
• Secrets bleeding out of error pages. Stack traces coughing up file paths, DB driver versions, internal IPs. You read these for a living. Most hunters skim right past them.

Legal guard-rails (do not skip)

Re-read the scope before you touch anything. Poke an out-of-scope asset and you're not hunting anymore. You're trespassing on someone's network. The CFAA in the US, the LCEN here in France, the Computer Misuse Act in the UK, none of them care that you "meant well." Good intentions don't hold up as a legal defence.

• Stay inside the explicit scope. Always. And the second a request touches another customer's data, stop, back out, don't go looking for more.
• Don't exfiltrate. Your proof is "this GET returns 200 with an email field in the body," full stop. Never "here are the 10,000 records I dumped to a CSV." That one move turns a payout into a phone call from legal.
• Honour the "no DoS, no automated scanning" lines. I've watched someone point an aggressive nuclei run at a rate-limited endpoint and get banned from the platform over it. Just not worth it.
• Keep a clean email and a unique handle per platform. Several programs run KYC before they'll pay you, and you don't want that getting awkward later.

The report quality that gets paid

This is the bit that genuinely decides whether you get paid. It's also the bit sysadmins are quietly great at. A triager is wading through fifty reports a day. Yours wins by respecting their time, by letting them confirm the bug in two minutes flat. Here's the shape I use:

1. One-line summary. "IDOR on /api/orders/{id} allows any authenticated user to read another user's order details." That's the whole bug, up top, before they even scroll.
2. Affected asset and scope tag. Copy the program's exact wording. Don't make the triager hunt around for which asset you mean.
3. Severity. A CVSS 3.1 vector and score. Show your math. Don't just slap on "critical" and hope nobody checks.
4. Steps to reproduce. Numbered and copy-pasteable. I'll take a clean curl over a pile of Burp screenshots every single time.
5. Impact. One short paragraph. What an attacker does with this, what data leaks, who's on the hook. No drama, no "catastrophic breach."
6. Suggested fix. Optional, but triagers love it: "Add a server-side check that session.userId == order.userId before returning the document." This is where your defender brain quietly pays off.

And cut the rest. No marketing voice. No veiled threats about disclosure, no "your competitor patched this already." The person on the other end wants to verify it, pay you, and close the ticket. So make that easy for them.

Sources and further reading

• OWASP, Top Ten
• OWASP, Cheat Sheet Series

Frequently asked questions