[HackerNotes Ep. 178] Hacking Google with AI: $670K in Bounties with Brutecat

Hacker TL;DR

• First-party auth (FPAv2) is the key to most Google APIs: if an API has a client6.google.com alias, ~90% of the time FPA works. The full FPA spec was extracted from a leaked TypeScript source map on a random Google site

• Abstract everything AI-unworthy. Brutecat's system pre-computes auth, key restrictions, visibility labels, and origin whitelists. The AI only thinks about the request body; everything else is handled by background tooling

• 3,600 Google API keys were collected from 60,000+ APKs, IPAs, and a Chrome debugger extension crawling every Google domain, then filtered through a Cloud Marketplace endpoint to keep only google.com-scoped keys

• Error normalization and operation IDs cut noise from 90% to near-zero. Common errors are converted to standardized explanations, and every vulnerability report must reference an operation ID or it's automatically rejected

Today's Sponsor: Check out Zero Trust Cloud Access from ThreatLocker https://www.criticalthinkingpodcast.io/tl-ztca

Who's Brutecat

Arvin Shivram (aka @brutecat) is one of the top Google VRP researchers in the world. He's behind some of the most impactful Google privacy bugs: leaking the email of any YouTube user for a $10,633 bounty, and a brute-force chain that recovered the phone number tied to any Google account. His Decoding Google series, turning Google's API black box into a white box, established him as a go-to source for Google internals. He's been hacking Google for years through Brutecat Security, building up an encyclopedic knowledge of its internal architecture, and now AI-powered API hacking.

bugSWAT Mexico: The Spark

The entire project started at bugSWAT Mexico. While other researchers were hunting bugs, Brutecat was doing something different: he was reading source code. Googlers at the event were willing to show source from google3, and he spent the whole event studying internal architecture. He was already a heavy Claude user (even back in 2024, building tools like req2proto with it), and one idea consumed him entirely:

The barrier wasn't technical complexity: it was scale. Access control testing on Google's Discovery Documents is tedious manual work. There are thousands of APIs, each with dozens of endpoints. No human has time for that.

He was already sketching it on the flight home. About a week later, he had a working MVP.

Building bugz AI: MVP in a Week

The first version was a web UI that parsed Discovery Documents client-side and rendered every method with a "Play" button. It handled Google's First Party Auth v2, which, it turns out, was partially documented in a leaked TypeScript source map on some random Google site that had source maps enabled in production. The leaked code revealed extra fields required for the authorization header computation that weren't in any public blog post.

Pro Tip: Source maps in production are a goldmine. Every time you find a Google site with source maps enabled, you might be looking at internal specifications for auth, APIs, or internal tooling.

The UI let Brutecat click any method, authenticate with a single click via FPA, and send requests entirely from the browser. But this was just the interface. The real challenge was keys.

The Key Collection: 3,600 API Keys

API keys are the single most important resource for scanning Google. Without keys, you're limited. With enough keys, you can access almost everything.

Brutecat partnered with Michael Dalton (another researcher) for a massive key collection effort:

1. APKs: Scraped all 60,000+ APKs Google ever published, extracted keys from every one

2. IPAs: Decrypted iOS apps and pulled keys from those too

3. Chrome Debugger API: Built a Chrome extension that hooked into Chrome's debugger API and automatically captured keys from every request across every Google domain

4. Web crawling: Visited every *.google.com domain, exercised as much functionality as possible to trigger API calls

But raw keys weren't enough. Many of the collected keys were customer keys tied to non-Google projects. To filter those out, Brutecat used a Cloud Marketplace endpoint that accepts a project number and returns the owning domain. The project number can be leaked from key validation errors: when a key isn't enabled for a specific API, the error message reveals the project number.

The result: ~3,600 verified Google-owned API keys.

And there's another avenue worth scanning for: zhandlers. Google's internal debug handlers, accessible on *.google.com. Some zhandlers (like /flagz) leak API keys directly. Others act as "LFI as a service": you can read any file from the server, including process classes that contain keys. Brutecat was coy about whether his own collection drew from this, but the capability is real: Google even accidentally bundled the zhandlers in a leaked binary that could be run locally, giving him full access to examine every handler.

Pro Tip: Scan for zhandlers on all Google API domains. They pop up randomly and contain a wealth of information: keys, internal endpoints, and even reflected XSS (Brutecat found one on www.google.com itself, though Googlers-only).

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!

Auth Layers: The Onion

Google's API auth isn't one check, it's a multi-layer verification stack:

1. API key present? Is the key valid at all?

2. API key enabled for this API? Is the key's project authorized for this specific API?

3. Key restriction check: Does the key have the right referrer header (web), Android header, or iOS header? You need to brute force the correct value for each key

4. Origin whitelist (FPA): First-party auth requires a whitelisted origin. A "session cookie invalid" error is actually a fake error: it means the origin isn't whitelisted. Brute force a list of Google domains until one works

5. Visibility label: Even if auth passes, your key needs the correct visibility label for the endpoint. Missing label returns "method not found" (another misleading error)

6. Endpoint-level restrictions: Some keys have specific methods blocked

All of this happens before your request is processed. As Brutecat puts it:

Google APIs whose origin whitelist is restricted to corp origins are huge red flags. Those APIs were meant to be internal-only, but you can supply a corp origin yourself from outside Google's network and walk right in. Brutecat found a ton of bugs this way. The whitelist is often loose enough that the origin doesn't even need to be a .google.com domain: even withgoogle.com is accepted, despite FPA's session cookies making no sense there.

The AI Implementation

Brutecat's AI system evolved significantly from his initial approach.

Initial approach (MCP-based, scrapped)

He started with AI SDK + MCP tools: probe_api, report_vulnerability, complete_testing. But the probe request bodies were bloated: they included the full method ID, host, version, and path. Too much room for the AI to hallucinate.

New approach (CLI-based)

The AI no longer constructs requests from scratch. Instead, Brutecat provides simplified tool calls:

{
  "body": { /* request body */ },
  "include_creds": "113728935872649341310",
  "method_id": "updateDataFetcherConfiguration",
  "path": "/v1/updateDataFetcherConfiguration",
}

Auth, key selection, origin whitelisting, and visibility labels are all handled by the background tooling. The AI only thinks about what matters: the request body.

Pro Tip: Don't use AI for things you can do without AI. Key collection, auth handling, origin brute-forcing, and correlation should be pre-computed. Reserve the AI budget for the intellectually hard part: constructing request bodies that probe for access control issues.

Response deduplication via hash

Different API keys produce different responses. Sending every key for every request would be wasteful. Brutecat's system groups responses by response_hash: the AI sees unique responses with a hash reference, not every single key's output.

Error normalization

Google APIs return misleading errors. "Method not found" doesn't mean the method doesn't exist: it means your key lacks the visibility label. Brutecat converted common errors to standardized types with explanations so the AI doesn't have to decode Google's error obfuscation:

{
  "standardErrorType": "INVALID_ARGUMENT_NO_DETAILS",
  "standardErrorExplanation": "The request was rejected by the application due to invalid arguments, but no details were provided. Check your request parameters."
}

Endpoint coverage via group-based sorting

Sending one massive Discovery Document as context causes the AI to focus on one area and ignore the rest. Brutecat's solution: group-based sorting. Endpoints are grouped by CRUD operations, and each group gets a full pentest session. Summary notes from each session are passed to the next, maintaining cross-group context.

Operation IDs for validation

Every tool call gets a unique ID. When the AI reports a vulnerability, it must reference the operation IDs that produced it. Reports without operation IDs are automatically rejected. This alone cut the false positive rate from ~90% to near-zero.

Pwning Google: $670K in Bugs

In ~3-4 months of running bugz AI across Google's entire API surface, Brutecat accumulated $670,000 in bounties. Here are the highlights:

Google Voice ATO

An endpoint with no auth: just an unobfuscated Gaia ID in the URL. It returned the phone number, Google Voice number, email, and PIN for any Google account. There was also an endpoint to assign a phone number to any account, which would immediately appear in the victim's Google Account settings. The only thing preventing exploitation was the API key, and Brutecat had it.

eldar.corp.google.com

Eldar is Google's internal tool for bug triage, access requests, and investigations. The frontend was behind the corporate network, but the backend API was fully exposed. The origin whitelist was a wildcard for *.google.com. Brutecat's AI actually generated an Eldar report during testing, which emailed him at his private Gmail with links to Google-internal resources: a hilarious proof-of-existence straight from Google's internal tooling.

YouTube Unlisted Videos Leak ($12,000)

Every YouTube Partner has a hidden Content ID management account. When a YouTuber uploads a video (even as unlisted), it gets registered as a Content ID asset with the naming convention auto-generated-asset-{VIDEO_ID}. By searching all assets for this pattern, you can leak every unlisted video from YouTube Partner channels, including unreleased trailers, private POCs, and scheduled premieres.

Impact highlight: This has Polymarket implications. If Google uploads a Gemini model announcement as an unlisted premiere, you could leak the release date and bet on it.

PLX Tables ($12,000)

PLX is Google's internal dashboard system: every Googler uses it daily. The datahub.client6.google.com API had a suggest endpoint that leaked internal table names, including sensitive ones like "need to know employee data." The real trick: a staging environment allowed setting IAM policies without restrictions. Brutecat added himself as a table admin, taking over internal PLX tables (some petabytes in size). He couldn't query them directly, but a month later, another researcher found an endpoint on the same integration that could read the tables.

AdExchange ATO

AdExchange (Google's ad management platform) had a staging environment (test-dash.adxbuyer.googleapis.com) that pointed to the production database with no access controls. Brutecat enumerated all ad accounts and could access any account's data. The staging-bypass trick came up repeatedly, including doubling bounties by finding the same bugs on an autopush environment.

App Engine Request Log Leak

The App Engine dashboard loading endpoint was completely unauthenticated. Supplying any project ID returned all stats including request paths: if anyone had a password reset link in their logs, it would show up. Even the Bug Hunter site (where Googlers submit reports) was exposed.

Vertex Assistant ($30,000)

This was a feature not yet rolled out. The AI found it via GraphQL introspection, but the UI didn't exist yet. By setting JavaScript breakpoints and enabling feature flags in the console, Brutecat activated the hidden feature and demonstrated the vulnerability to Google's product team. Google paid for it because it was about to be released.

GraphQL & Cloud Console

The Cloud Console uses GraphQL behind the scenes, and the staging endpoint had no signature validation, allowing full introspection. This opened an entirely new attack surface: APIs reachable through Cloud Console's GraphQL proxy that weren't accessible via Google APIs directly.

Brutecat worked with Michael Dalton to adapt bugz AI to scan this GraphQL surface. The challenge: some queries map to RPCs, some don't, and you have to figure out which is which. The introspection data included comments that helped map the surface.

GraphQL staging endpoints without signature validation are a goldmine. Introspect everything, then use that knowledge to probe production.

Resources

• Brutecat's earlier research: Decoding Google: Converting a Black Box to a White Box

• Brutecat Security: Follow @brutecat for more research

That's it for this week, keep hacking