Bug Bounty Starter Guide for Sysadmins Coming from IT Ops (2026)

Career pivot Bug bounty starter · 12 min read · Published May 2026

If you are a sysadmin or IT-ops engineer who has been quietly wondering whether your DNS, HTTP and Linux skills transfer to bug bounty hunting — they do, and more than you think. The skills that pay the rent on a HackerOne or Intigriti program are not exploit-development or kernel rop chains; they are systematic recon, attention to authentication flows, the discipline to write a clean reproducible report, and the patience to follow up with triage teams. This guide is the practical onboarding for a sysadmin who wants to make their first €500 in bounties within 90 days without quitting the day job — what to learn, which programs to pick, the tools that matter, the legal guard-rails, and the report quality that gets paid versus rejected.

Why sysadmin → bug bounty actually works

Bug bounty programs do not pay for exploit-dev wizardry. The 2025 HackerOne report shows that across the top 100 paid programs, more than half of bounties paid were for access control, information disclosure, SSRF, misconfiguration and broken authentication — classes that map directly onto things a sysadmin already debugs daily. You already know what an Origin header is, how an HTTP redirect chain leaks state, why nginx try_files rewrites can swallow path-traversal, and what a stack trace in a production log looks like. The pivot is mostly about systematising what you already know and learning to look for it on someone else’s infrastructure under explicit authorisation.

The mindset shift from defender to attacker

The single biggest change is curiosity direction. As a sysadmin you have spent years pattern-matching weird behaviour and asking “is this broken, do I need to fix it?”. As a hunter you look at the same weirdness and ask “is this exploitable, what is the worst it could do?”. Three concrete shifts:

• Embrace edge cases. Unusual URL encodings, double-decode behaviour, HTTP smuggling — the bugs live where the parser disagrees with itself.
• Map trust boundaries explicitly. Every login form, OAuth callback, SSO assertion, internal API is a boundary. Bugs cluster on the boundary, never in the middle.
• Read the docs adversarially. When a program lists “out of scope” assets, that list is also a map of where unintended behaviour might leak in-scope.

A minimal 2026 tooling stack

You can spend a year shopping for tools, or you can install five free ones in an hour and start.

Skip Metasploit. Skip Cobalt Strike. Skip everything CVE-chasing — bug bounty pays for novel bugs you find, not for running 2-year-old exploits.

Picking your first program

Three criteria, in order:

1. Mature triage. Filter HackerOne and Intigriti for programs with median response time under 72 hours and resolved-to-disclosed ratio above 70 %. Public stats on the program page tell you.
2. Wide scope. Programs that list *.example.com and “any acquired company” give you the surface area to find your first low-hanging fruit. Avoid programs limited to a single static brochure.
3. Pays low / medium. Some programs only reward criticals — bad fit for a beginner. Filter for those paying $100 minimum on Low.

Concrete starter list in 2026: GitLab, Reddit, Shopify, GitHub (Bug Bounty), Twilio, Mozilla, U.S. Department of Defense (Hack the Pentagon). All have public guidance, all pay, all have decent triage.

The five-phase weekly workflow

The discipline that separates submitting from hunting is doing this loop weekly, even when you found nothing last week.

1. Phase 1 — Scope & passive recon (1 hour). Read the program rules carefully. Note in-scope and out-of-scope. Pull subdomains from crt.sh, amass enum -passive -d example.com, GitHub code search. Dedupe into a list.
2. Phase 2 — Active fingerprint (1 hour). httpx the list, nuclei -t exposures,misconfiguration -l alive.txt, screenshot everything with gowitness. Triage the screenshots — old login portals, dev pages, third-party admin panels jump out visually.
3. Phase 3 — Manual deep-dive (3 hours). Pick the 3 most interesting targets. Burp Suite, log in, look for IDOR, missing access controls, weak password reset flows, JWT handling, SSRF in webhooks. This is where bugs live.
4. Phase 4 — Verify, score, write (1 hour). Reproduce 3 times on a clean session. CVSS 3.1 score the issue. Clear PoC: step-by-step commands, screenshots, no superfluous content.
5. Phase 5 — Submit and iterate (30 minutes). Submit through the program platform. Be polite, be precise, respond to triage within 24 hours.

Bug classes a sysadmin spots faster than anyone

• Subdomain takeover. A CNAME pointing at a no-longer-claimed Azure / Heroku / S3 host. You know what dangling DNS records look like — bounty platforms pay for them.
• SSRF via webhook or PDF generator. Webhook URLs that hit http://169.254.169.254 still pay because cloud-metadata exposes IAM creds.
• IDOR on admin endpoints. /api/users/123/edit accessible by user 456. Trivial to test once you have two accounts.
• Default credentials on third-party admin tools. Jenkins, Kibana, Elasticsearch, Grafana on subdomains marketing forgot — sysadmins know which products ship with defaults.
• Path traversal through misconfigured proxies. nginx alias directive without trailing slash is a classic — you have probably fixed it on your own infra, now find it on someone else’s.
• Sensitive info in error pages. Stack traces that leak file paths, DB driver versions, internal IPs. You read these for a living already.

Legal guard-rails (do not skip)

• Never test outside the explicit scope. Stop testing the moment you find a result that touches another customer’s data.
• Do not exfiltrate data. Proof-of-concept is “the GET returns 200 with email field” — not “here are 10 000 emails I exported”.
• Respect “no DoS / no automated scanning” rules. Aggressive nuclei runs against rate-limited endpoints have ended careers.
• Use a clean email and a unique handle per platform. Some programs require KYC for payouts.

The report quality that gets paid

Triagers see fifty submissions per day. A good report stands out because it does not waste their time. Format:

1. One-line summary. “IDOR on /api/orders/{id} allows any authenticated user to read another user’s order details.”
2. Affected asset and scope tag. Match the exact wording from the program scope.
3. Severity. CVSS 3.1 vector + score.
4. Steps to reproduce. Numbered, copy-paste-able. curl commands preferred over Burp screenshots.
5. Impact paragraph. One short paragraph: what an attacker can do, what data is exposed, who is affected. No hyperbole.
6. Suggested fix. Optional but loved — “Add server-side check that session.userId == order.userId before returning the document.”

Skip: marketing language, threats, comparisons to competitors. The triager wants to verify, reward, close.

FAQ