[HackerNotes Ep. 192] Masterclass: Building a POC Creation Skill

Hacker TL;DR

• Host your POCs as a curl -s ... | python3 one-liner or a single HTML file, so the triager reproduces with one command instead of shuttling files into a VM.

• Treat the POC as two things at once: a codified narrative of your report, and a unit test that prints a clear vulnerable / not vulnerable verdict for remediation retests.

• Make the script portable and observable: zero dependencies (not even requests), cert validation off, a proxy prompt, and an X-POC-Actor header so every request is tagged attacker or victim.

• Do the boring setup in code: embed credentials, register accounts and create objects on the fly, print the IDs, and host artifacts (run logs, screenshots) proving a successful execution.

Sponsored by ThreatLocker – Privileged Access Management. Fitting, since auth bypass and privilege escalation are the whole theme here: least privilege plus PAM are exactly what keeps a full auth bypass from turning into game over. Worth a look.

Why Bother? The Three Goals

Bug bounty queues are clogged, triagers are overwhelmed, and everyone up and down the chain (hackers, programs, platforms) is stressed. Rather than being jaded about "the other side," a high-quality POC is one of the best ways to push the whole community forward. A report where you click one thing and the full vulnerability demonstrates itself cleanly gets processed faster. That's the whole game.

Justin frames the skill around three goals:

1. Give the triager the easiest, most seamless triage experience possible. They already have the report open and a VM to run things in, so don't make them transfer files and reconstruct state by hand.

2. Give the team an easy triage and remediation-retest experience. They have to hand the bug to devs (who often work without a proxy) and later confirm their fix works. A re-runnable POC lets them do both. Yes, this can eat into retest payouts, but Justin's take is that overall throughput is worth more than grabbing at a $50 retest right now.

3. Give yourself an easy way to visualize and validate what your hackbot reports. If you're running a bot, your life is triage: you open the queue, read the finding, drop the POC script into your terminal, watch the output, and click report. A weak POC is also the single best motivator to improve: nothing sharpens your skill like being annoyed at your own unreadable output.

Codify the Report, Then Unit-Test It

The mental model behind the whole skill is a combination of two ideas.

First, codify the report. The POC should be a holistic, self-narrating experience. It sets the scene (this app does XYZ, here's who we are) and walks through the logic: the attacker (low-privilege user) can't reach the data via this route, then can reach it via that route. Use attacker and victim as your labels, not user1/user2. It removes all ambiguity about session ownership, and you show it with the actual HTTP requests. Done right, you barely need the written report; the POC itself explains why the finding is a vulnerability.

Second, think of it as a unit test for that specific vulnerability. A unit test validates that a piece of behavior holds up across changes to the codebase. Your POC does the same for the bug: it runs the flow and emits a verdict. Accessed the data? State: vulnerable. Got a 401 after a fix landed? Error handling catches it and prints State: not vulnerable. That single line tells the team instantly whether their remediation actually worked.

Pro Tip: Put the automated POC URL at the very top of your Steps to Reproduce. Burying "…or just run this script" at the bottom, after fifteen minutes of manual steps, is how you make a triager rip their hair out.

We do subs at $25, $10, and $5, premium subscribers get access to:

– Hackalongs: live bug bounty hacking on real programs, VODs available
– Live data streams, exploits, tools, scripts & un-redacted bug reports

You can also find some hacker swag here.

Need a Pentest? We just launched CTBB Pentests!

Hack full time? Check out the Full-Time Hunter’s Guild!

The Python POC: Nuts and Bolts

Justin gives his AI exactly two formats to work within: a curl-to-Python script for server-side chains, or an HTML file for client-side exploits. Anything more exotic (a server-side chain that needs to cache a value the client can't reach because of CORS) is a manual exception; the primary flow stays curl -s <url>.py | python3.

And the AI should be iterating on the POC as it writes the report (build it, run it, modify it) and always running it exactly the way the triager will, i.e. curling the hosted URL and piping to Python. That guarantees it's validated through the real reproduction path.

Rules for the script itself:

• Hosted, not attached. The triager should curl | python3, not download-and-transfer. Provide both a Unix and a Windows reproduction command, because stock PowerShell doesn't always alias curl cleanly. You can safely assume Python is installed; if it isn't, that's on them.

• Completely self-contained. No local path references, and no external dependencies, not even requests. Every dependency is another point of failure; the standard library should be considered to include everything you need. It must run on any machine with Python.

• Cert validation off, because of the next point.

• Make it proxyable. You must give the triager a way to route requests through Caido or Burp. If the HTTP_PROXY variable isn't set, prompt them for a proxy address. This matters: some hunters (you tricky little devils) print() fake requests instead of actually sending them, so triagers now want to see real traffic in a tool they're comfortable with rather than re-reading your code.

• Tag every request with X-POC-Actor. Set it to attacker or victim so the triager knows whose session made each request without cracking open the JWT to check the email. Denote in the POC that this header exists; a one-line hint saves a lot of confusion.

• Embed credentials. For an authenticated bug, drop the session/username/password in a constant at the top of the script. Don't be precious about "leaking" your creds in a report: nobody cares, and it makes reproduction instant. Some triagers prefer to use their own accounts (who knows what janky state yours are in), so a clean registration flow (spin up guest accounts on the fly if there's no CAPTCHA) is even better.

• Discover and create everything in-script. Need an org with a team under it? Have the script spin up the user, create the org, create the team, print the IDs, and label them (this is the vulnerable team). Then the attacker accesses that team. Narrate how you obtain each ID in the codified output so nobody has to go hunting for object IDs.

The HTML POC: Client-Side Exploits

The HTML path is usually simpler. The big rules:

• The page narrates itself. As the exploit proceeds, the page explains what's happening, the same "codify the report" principle.

• Sensible defaults + credentials. Prefill input fields with sensible values, and provide login credentials so the IDs line up and there are no mismatches (you often can't fetch the IDs you need client-side).

• auto_run=1. Justin always adds an auto-run parameter, plus the ability to pass any required IDs as query parameters. The point is to demonstrate how few clicks the exploit needs. "Visit the attacker's page and it fires" is a materially stronger finding than "visit the page and click a button", so be explicit about the real interaction requirements.

Both Formats: Narrate, Control, Clean Up, Prove It

Whichever format you use, the POC should read as a narrative of the report: set up the required state, issue a control request (showing the benign/blocked case), fire the exploit and dump the data that proves the result, then clean up after itself so the account is left in the same state it started.

The final piece Justin emphasizes hardest: host artifacts of a successful run. When the AI builds a Python POC, it captures the run output into a .txt file, hosts it on the POC server, and links it right below the reproduction command, so the triager sees what a successful output looks like before they even run it. For client-side exploits, pop it in a headless browser, take screenshots at the key moments, and host those too. This proves the vulnerability worked at least once and tells the triager exactly what to look for.

Closing Thoughts

That's the framework: two formats, hosted and self-contained, that codify your report and act as a re-runnable unit test, with embedded creds, proxy support, actor headers, on-the-fly setup, and hosted proof of a successful run. It's the kind of thing AI makes quick work of, and it's the difference between a triager sighing at your queue entry and one clicking reproduce with a smile. There's more depth (and the skill itself) waiting in the Discord, where people better at this than any of us are constantly dropping tips.

That's it for the week, keep hacking!