Hacking Google with A.I. for $500,000

What it is

brutecat's writeup of an AI-driven Google VRP campaign (invited via bugSWAT Mexico, Oct 2025) that earned $500,000 in ~3 months. The existing summary covers the overall pipeline and the Google Voice bug; what it omits are the specific bypass mechanisms and the FPA v2 token construction that make the technique reproducible. These are the actionable parts.

How it works

Finding live APIs / keys: A domain is a live Google API if it returns a Server: header of ESF, GSE, or scaffolding on HTTPServer2. Keys are filtered to Google-owned GCP projects via a Cloud Marketplace endpoint (GET /v1test/infoSharing/test/test/<projectNumber> on cloudmarketplace.clients6.google.com) — the project number itself leaks in the error message when a key hits an API it lacks.

Discovery-doc access: Google removed /$discovery/rest from most APIs in July 2025, but hidden internal endpoints are exposed by appending ?labels=GOOGLE_INTERNAL (example grew a discovery doc from 253k→329k bytes). Only one label per request, so it's brute-forced across every key × API.

FPA v2 auth (works with API keys, unlike bearer tokens; sent to *.clients6.google.com): token format is <timestamp>_<hash>_<identifierKeys>, where hash = SHA1 of "email:gaiaId timestamp sessionCookie origin" joined by spaces. Identifier keys: e=email, u=obfuscated Gaia ID, a=Workspace domain. Backend ignores unknown letters. The Origin header must match a per-API whitelist (else misleading SESSION_COOKIE_INVALID); *.corp.google.com origins face no restriction and usually front buggy internal APIs.

API-key restriction bypass: Browser keys need a matching Referer (some allow *.google.com); iOS keys need X-Ios-Bundle-Identifier; Android keys need matching X-Android-Package + X-Android-Cert (SHA-1 fingerprint). Only Server/IP restrictions are unbypassable. Referer and Origin can't be mismatched.

The author built a request-lifecycle classifier (10 rejection stages, e.g. MISSING_REQUIRED_VISIBILITY_LABEL on a JSON 404 vs. HTML 404 for a truly-missing method) to build a key×API enablement matrix, then fed the same parsing logic to Claude via MCP.

What to do

Defenders: audit *-pa.clients6.google.com-style front-ends and sandbox/staging hosts (test-*.sandbox.google.com) — a key finding is that staging environments pointed at production data (AdExchange, test-adexchangebuyer-googleapis.sandbox.google.com), and patches applied only to prod hosts were re-reachable via autopush-* sandbox variants (Eldar). Note that ?labels=GOOGLE_INTERNAL bypasses the July-2025 discovery-doc removal.

For the AI-fuzzing method: the system prompt excerpt is worth reading directly — it explicitly excludes existence-enumeration as a finding, forbids type-confusion attempts (strict JSON-gRPC transcoding), and requires operation_id evidence links to defeat hallucinated reports. A "Ralph Wiggum" loop with confirm_testing_complete() validating every endpoint was probed prevented early exit; group-based endpoint classification kept context manageable.

Caveats

Only the first 60,000 of 103,510 characters were fetched. The PLX/plx.corp.google.com internal-analytics bug is cut off mid-response, and any bugs after it are not shown here — this is not a complete list of the findings. Google declined to specify the exact conditions under which the Voice API leaked account-recovery numbers. The number-port/SIM-swap endpoints (InitiateNumberPort) were untested by the author (no Fiber account).