Prove You’re Human

Run #66 confirmed the API, mapped the auth flow, built a Playwright signup bot, and got rejected by five layers of bot protection. The technique is proven. The machine is not a person.

The system can bypass authentication mechanisms. It cannot prove it isn’t a bot.

Run #66 was a campaign task — take a proven Server-Side Request Forgery technique and replay it against a new target where the same webhook pattern exists and a time-limited bounty multiplier makes the window count. The session had 33 minutes, 105 tool calls, and every piece of infrastructure it needed. It got bounced at the registration desk.

Cross-Program Replay

The campaign system exists for exactly this scenario. When a technique is confirmed on one target, the registry records the exact steps, the prerequisites, the mutations attempted, and the key evidence. When a similar program appears in the queue, the task selector doesn’t start from scratch — it loads the campaign and runs the same playbook against the new surface.

The technique: blind SSRF via webhook URL registration. The pattern is the same across platforms — register a webhook pointing to an out-of-band listener, trigger the event, observe whether the server fetches your URL from production infrastructure without validating what the URL points to. If the fetch happens with no IP restriction, you have a finding. This was confirmed on a VDP fintech platform three weeks ago: ten callbacks, two production cloud IPs, a named internal service in the User-Agent. Tier 1 evidence. Full kill chain. Full report written.

The new target is a European HR SaaS platform with documented webhook integration — same structural pattern, different market, different platform. And a deadline: a time-limited multiplier on webhook-class findings that the campaign system had flagged as a priority scheduling signal. The task selector knew. Run #66 fired.

The Groundwork

The session had to onboard first — this was a new engagement with no directory, no scope file, no locked target list. Standard initialization: create the directory structure, parse scope from public platform data, write the locked target list, populate the engagement config.

That part worked without friction. Twenty minutes of parallel tasks: engagement directory built, scope analyzed, 6+ wildcard domains locked, rate limits noted, platform config written. The session then moved directly to technique prerequisites.

Webhook API: confirmed present. A probe to the webhook management endpoint returned 401 — not 404, not a firewall block. 401 means the endpoint exists and requires a valid token. Auth flow: mapped. The platform uses a client credentials exchange: send a client ID and secret to the auth endpoint, receive a bearer token, pass it as an Authorization header on subsequent requests. The structure is standard and documented.

Infrastructure: fingerprinted. A major CDN on the API tier, a JS-challenge-based hosting platform on all web properties. Everything logged to the engagement notes. The session had the complete picture of where the API lives and how to talk to it.

All it needed was credentials.

The Five Walls

Getting credentials for an HR SaaS platform requires signing up for a trial account. The session attempted this with Playwright. This is where it stopped moving forward.

The trial signup page presented five separate bot-protection layers, each independently capable of blocking an automated browser:

Wall 1: JavaScript security checkpoint. The hosting layer returns a JS challenge to automated clients. Playwright can get past it with proper wait times, but the reliability is timing-dependent and the challenge re-fires on navigation.

Wall 2: Chat widget iframe overlay. A live chat widget loads over the signup form. Playwright’s click coordinates land on the iframe instead of the form fields underneath. Clicks that should focus input fields instead trigger chat interactions. Dismissing the widget programmatically closes it temporarily before it reasserts on the next event.

Wall 3: Custom React dropdown components. The company-size field is a bespoke React component, not a standard HTML <select>. DOM-level value injection via element.value = ‘...’ writes to the attribute without triggering React’s internal state reconciliation. The dropdown reads as empty to the form’s validation layer regardless of what the DOM says. Required field, no standard workaround.

Wall 4: Third-party form framework. The form itself is embedded via a third-party marketing platform with its own event pipeline. Playwright’s direct DOM manipulation doesn’t propagate through the framework’s synthetic event system in a way the validation layer recognizes. Filled fields register as unfilled.

Wall 5: Invisible CAPTCHA. Score-based, fires on submit. Automated browsers score poorly by default. The form rejects silently — no visible error, no redirect, no confirmation. The page state after submission is identical to the page state before it.

The session tested each wall, worked around some, couldn’t route around all five simultaneously. The final submission attempt cleared walls 1, 2, and 4. Wall 3 dropped a validation error on the required field. Wall 5 was almost certainly triggered anyway by the automated browser fingerprint.

# Session output — what happened at each layer
Wall 1 (JS checkpoint):    Bypassed — Playwright wait + retry
Wall 2 (chat widget):      Partially bypassed — dismissed, re-asserts
Wall 3 (React dropdown):   NOT BYPASSED — DOM injection doesn't propagate
Wall 4 (form framework):   Bypassed — event replay approach
Wall 5 (invisible CAPTCHA): Score-based — likely flagged, silent rejection

Signup result: BLOCKED
Engagement status: INCONCLUSIVE — prerequisite unmet

Five layers of bot protection is not a vulnerability. It’s a human checkpoint.

Bot protection on a public signup flow is working exactly as designed. The platform doesn’t want automated account creation, and frankly, neither do we for the purposes of authorized testing. The signup process requires a human because it’s meant to require a human. Playwright’s job isn’t to bypass security controls on registration forms — that’s out of scope and also just rude. Its job starts after the account exists. The two-minute manual step isn’t a failure of the automation pipeline. It’s the correct handoff point between human and machine.

Inconclusive Is Not Failed

The session closed with status INCONCLUSIVE. Not failed — inconclusive. The distinction matters for the campaign registry and for how the next session interprets the state.

Failed means the technique ran and the target wasn’t vulnerable, or the technique doesn’t apply to this platform’s architecture. Inconclusive means the prerequisite is unmet and the test couldn’t run. The difference determines what the next session should do. Failed → move on. Inconclusive → unblock and retry.

Everything the automated session could do, it did:

Engagement initialized and onboarded
Scope locked with confirmed targets
Webhook API endpoint confirmed present and alive
Auth flow documented in full
Infrastructure fingerprinted (CDN tier + hosting layer)
Rate limits identified and noted in platform config
Campaign data files updated with session outcome
Unblock instructions written with exact steps and credential save path

The actual test — the OOB listener setup, the webhook registration, the payload delivery, the callback confirmation — is thirty minutes of work, maximum, once credentials exist. The technique is proven on a structurally similar platform. The API endpoint is live. The auth flow is mapped. The engagement is initialized and ready.

Campaign replay surfaces the prerequisite gap, not just the technique gap

Cross-program technique replay is useful for more than finding bugs faster. It reliably exposes where the automation ends and the human begins. On this engagement, the human step is account registration — two minutes with a real browser, no specialized knowledge required. The machine did the research, the scope analysis, the API confirmation, the infrastructure mapping, and the test setup. It left a clear, documented handoff: sign up once, save the API credentials to the engagement config file, and the next session picks up exactly where this one stopped. The prerequisite gap isn’t a design flaw. It’s a handoff specification — and a useful one, because it names exactly what a human needs to contribute and nothing more.

Platform Tokens: The Seventh Notice

Both API tokens expired at startup. The orchestration log records this as the seventh alert since January. The pattern is documented in at least four previous posts on this blog. I said in the last one that I wasn’t going to write about it again. I’m not writing about it again. The link in the previous sentence explains the situation and the two-step fix. The only new information here is the count.

The Irony

The system’s job is to find authentication weaknesses — flows that let you prove identity as someone you aren’t, registration endpoints that accept forged inputs, session mechanisms that trust unverified claims. In 66 sessions it has mapped authentication systems on dozens of platforms, found a critical OAuth bypass, confirmed OOB callbacks from production infrastructure, and assembled reports that document exactly how trust assumptions fail.

It could not pass a sign-up form.

Not because the form was especially clever. Because the form was designed for humans and the session was a bot, and the form knew. reCAPTCHA v3 doesn’t ask you to click fire hydrants. It watches how your browser behaves and assigns a score. The session got a bad score. End of campaign.

The bounty multiplier has a deadline. The API endpoint is confirmed live. The technique has a proven track record. What stands between the current state and a time-limited, viable finding is a person opening a browser and filling out four fields. The machine built the on-ramp. It just can’t drive the car.