Dear Readers,
We’ve covered what h1-brain is and how to install it, and we’ve gone through every tool it exposes. Now let’s actually use it. This post is a walkthrough of what it looks like to sit down with h1-brain and Claude, pick a target, and build an attack plan from your own bounty history.
I’m going to keep the program details generic here because I’m not going to name real targets or show real vulnerability data. But the flow is exactly what I do.
Step 1: Pick a target and run hack()#
Maybe it’s a program you’ve worked on before and want to revisit, maybe it’s something new. Either way, you start with hack():
“hack acme-corp”
Claude calls hack("acme-corp"), fetches the live scope, cross-references your database, and hands back the briefing. It takes a few seconds because it hits the HackerOne API for fresh scope data.
Step 2: Read the briefing#
The hack() output has distinct sections and each one tells you something different.
Scope lists every asset. Say ACME has 18 assets in scope, 14 bounty-eligible. Domains, APIs, mobile apps, each with their severity caps and special instructions. Read the instructions, because programs bury important stuff in there. “Do not test during business hours.” “Authentication testing requires a sandbox account.” “.staging.acme.com is out of scope.”* Ignoring these is how you get reports closed as N/A.
Your past findings shows you’ve been rewarded 6 times here. Three XSS, two IDOR, one info disclosure, all on app.acme.com. Total: $8,200. That’s a signal that you’ve been laser-focused on one subdomain and one class of bug.
Weakness frequency shows your global profile. Across all programs you’ve been paid for SSRF 12 times, XSS 18 times, IDOR 9 times, auth bypass 6 times, SQLi 5 times, race conditions 3 times.
Untouched scope reveals that of ACME’s 14 bounty-eligible assets, you’ve only ever tested app.acme.com. The API at api.acme.com, the partner portal at partners.acme.com, the mobile apps, all untouched, zero reports.
Suggested attack vectors tells you that SSRF (rewarded 12x on shopify, uber, yahoo, github) hasn’t been found here, and neither has SQLi (5x on uber, twitter, yahoo) or auth bypass (6x on github, twitter, paypal).
Public disclosed reports shows what other researchers found on ACME and got paid for. Say there are 31 public disclosures — 9 XSS, 6 info disclosure, 4 IDOR, 3 SSRF, and so on. This tells you what weakness types are common here and where other people have had success. Combined with your own suggested vectors, you now have two angles: what worked for you elsewhere, and what worked for others here.
Step 3: Focus#
The untouched scope shows api.acme.com, a REST API with a critical severity cap. The suggested vectors flag SSRF, the public disclosures show 3 SSRF reports on other ACME assets, and you know APIs with server-side fetching are common SSRF targets. So that’s where you start.
Tell Claude:
“I want to focus on api.acme.com. I’ve never tested it. Based on my SSRF track record, what patterns should I look for?”
Claude has the briefing in context. It knows you’ve found SSRF 12 times, it knows what the ACME scope allows, and if you’re on Claude Code with extended thinking it’ll actually reason through the connection before answering. The response isn’t generic SSRF methodology from a cheatsheet, it’s informed by what you’ve actually found before.
Step 4: Mine your history#
“Show me every SSRF I’ve been rewarded for, sorted by bounty”
Claude runs search_reports(weakness="SSRF"):
Found 12 reports ($22,400 total):
- **#1847293** [critical] Blind SSRF via webhook URL parameter
— shopify — Server-Side Request Forgery (SSRF) — $5,000
> The application's webhook registration endpoint accepts user-supplied
> URLs without validating the destination...
- **#1623841** [high] SSRF in PDF export functionality allows internal
network scanning — uber — Server-Side Request Forgery (SSRF) — $3,500
> The /api/v2/export/pdf endpoint accepts a URL parameter for header
> image. This URL is fetched server-side...
- **#1589234** [high] Full-read SSRF via image proxy endpoint
— yahoo — Server-Side Request Forgery (SSRF) — $2,500
> The image proxy at img.yahoo.com/proxy accepts arbitrary URLs...
...When you look at this you start seeing patterns. Three of your SSRFs came from webhook endpoints, two from PDF/export features, two from image proxies, the rest from various URL-fetching parameters. Claude sees this too.
The Shopify webhook SSRF looks relevant here, because ACME’s API probably has webhook functionality too. So you go deeper:
“Show me the full details of report 1847293”
# Report #1847293: Blind SSRF via webhook URL parameter
**Program:** shopify
**Severity:** critical (9.1)
**Weakness:** Server-Side Request Forgery (SSRF) (CWE-918)
**Bounty:** $5,000 USD
**State:** resolved
**Created:** 2024-08-15
## Vulnerability Details
The application's webhook registration endpoint at
`/admin/api/2024-07/webhooks.json` accepts user-supplied URLs
without validating the destination host. By providing an internal
IP address (e.g., `http://169.254.169.254/latest/meta-data/`)
as the webhook target, an attacker can force the server to make
requests to internal infrastructure...
[detailed methodology, payloads, response analysis]
## Attachments (2)
- **ssrf-poc.py** (text/x-python, 4 KB) — id: 89234
- **response-metadata.png** (image/png, 128 KB) — id: 89235Your own methodology, your own payloads, against a similar type of endpoint. You can also check what other researchers did:
“Search disclosed reports for SSRF on acme-corp”
Claude runs search_disclosed_reports(program="acme-corp", weakness="SSRF") and returns the public disclosures. If someone found blind SSRF on webhooks.acme.com via a callback URL parameter, that’s directly relevant to what you’re about to test on the API. You can read the full write-up with get_disclosed_report(id).
And you can pull the PoC from your own report too:
“Get the attachments for that report”
## Attachments for Report #1847293
### ssrf-poc.py (text/x-python, 4 KB)
**Download URL** (expires in ~1 hour):
https://hackerone-us-west-2-production-attachments.s3.us-west-2...
### response-metadata.png (image/png, 128 KB)
**Download URL** (expires in ~1 hour):
https://hackerone-us-west-2-production-attachments.s3.us-west-2...Step 5: Build the plan#
flowchart TD
A["hack() briefing"] --> B["Untouched: api.acme.com"]
A --> C["Suggested: SSRF — 12x elsewhere"]
A --> C2["Public disclosures: 3 SSRF on ACME"]
B --> D["search_reports — weakness=SSRF"]
C --> D
C2 --> D2["search_disclosed_reports — SSRF on acme-corp"]
D --> E["get_report #1847293 — your Shopify webhook SSRF"]
D2 --> E
E --> F["fetch_attachment — PoC script"]
F --> G["Attack plan: test api.acme.com for SSRF\nbased on your past findings + public disclosures"]
style A fill:#ff5c5c,stroke:#ff5c5c,color:#fff
style G fill:#ff5c5c,stroke:#ff5c5c,color:#fff
style B fill:#1a1d27,stroke:#555,color:#fff
style C fill:#1a1d27,stroke:#555,color:#fff
style C2 fill:#1a1d27,stroke:#555,color:#fff
style D fill:#1a1d27,stroke:#555,color:#fff
style D2 fill:#1a1d27,stroke:#555,color:#fff
style E fill:#1a1d27,stroke:#555,color:#fff
style F fill:#1a1d27,stroke:#555,color:#fff
At this point you have ACME’s full scope with api.acme.com as your focus, your 12-report SSRF track record showing recurring patterns in webhooks, exports, and proxies, the public SSRF disclosures on ACME from other researchers, the full write-up of the most relevant past finding, and the PoC script from that report. All of it is loaded into a single Claude session.
This is where you ask Claude to actually plan:
“I’m going to test api.acme.com for SSRF. Based on my Shopify webhook SSRF and the ACME API scope, outline a testing plan. Focus on webhook and callback URL parameters. What endpoints should I look for first?”
Claude knows your Shopify finding targeted /admin/api/webhooks.json, it knows ACME has a REST API with a critical severity cap, and it can reason about where similar functionality might live. The plan it gives you isn’t a generic SSRF testing guide, it’s shaped by what actually worked for you before.
If you’re on Claude Code, this is also where you can pull in local recon data. If you ran ffuf or httpx and saved the output, just tell Claude to read it:
“Read the file at ~/recon/acme/api-endpoints.txt and cross-reference with my SSRF patterns”
Claude reads your recon output, compares it against the webhook/export/proxy patterns from your past SSRFs, and highlights the endpoints that look most interesting.
And if you find something and want to draft the report, Claude has your past write-ups as style references:
“Draft a report for this SSRF in the same format as my Shopify report #1847293”
It’ll match your writing style, your severity justification structure, the way you lay out impact descriptions.
Step 6: Repeat#
flowchart LR
A["sync"] --> B["hack()"]
B --> C["focus"]
C --> D["mine history"]
D --> E["build plan"]
E --> F["hunt"]
F -->|"new target"| B
F -->|"new reports"| A
style A fill:#1a1d27,stroke:#555,color:#fff
style B fill:#ff5c5c,stroke:#ff5c5c,color:#fff
style C fill:#1a1d27,stroke:#555,color:#fff
style D fill:#1a1d27,stroke:#555,color:#fff
style E fill:#1a1d27,stroke:#555,color:#fff
style F fill:#ff5c5c,stroke:#ff5c5c,color:#fff
When you’re done with ACME, run hack() on the next program. The briefing adapts because it always works from your full history. As you submit more reports and resync with fetch_rewarded_reports, the suggestions get better as your weakness frequency updates, your per-program coverage grows, and the untouched asset list shrinks.
Setting up Claude for this workflow#
A few things that make a real difference in how well this works:
Extended thinking. If you’re on Claude Code or the API, turn on extended thinking. It makes Claude deliberate before answering instead of immediately generating text, and for a question like “based on my SSRF history, where should I look on this target?” the difference is noticeable. With thinking enabled, Claude actually cross-references your data instead of pattern-matching on surface-level keywords.
CLAUDE.md. Create a CLAUDE.md file in your working directory with standing instructions:
# h1-brain workflow
- When I give you a program handle, always start with hack()
- When I say "sync", run fetch_rewarded_reports and fetch_programs
- When analyzing a target, always check untouched scope first
- When I ask about a weakness type, search my reports for it before answering
- Reference my past findings by report ID when making suggestionsClaude reads this at the start of every session, so you don’t have to repeat your preferences every time you open a new conversation.
Model choice. Use Opus for h1-brain work. The hack() briefing can be long, and Opus is the model that actually reads the whole thing and reasons over it instead of skimming. For the cost of a few extra seconds per response, you get analysis that’s grounded in what you actually gave it.
A note on what this isn’t#
I wrote a whole post about people claiming AI replaces pentesters, and h1-brain is not that. It doesn’t scan anything, it doesn’t fire payloads, it doesn’t interact with targets at all. What it does is take your own bounty history, the stuff you already found and got paid for, and make it searchable so Claude can cross-reference it against whatever you’re looking at next. The model is still a goldfish with no memory and no intuition, but now it’s a goldfish that has your entire HackerOne track record loaded into its context window, and that turns out to be useful when you’re staring at a new program wondering where to start. The hacking is still entirely on you. h1-brain just makes sure you’re not ignoring things you already know how to find.
That’s the whole series. If you try it, let me know how it goes. I’m @itsecurityguard on X and the repo is at github.com/PatrikFehrenbach/h1-brain.
Until next time 🙂
