Querying your warehouse straight out the door (BigQuery)
BigQuery holds your analytics crown jewels, and an attacker with read access can run one export job to copy it all to a bucket they control. Here is the exfil, and the fix.
The warehouse does not get breached so much as politely answer the question that empties it.
What it is
BigQuery is GCP’s data warehouse, holding analytics, customer, and often regulated data. An attacker with dataset read and export rights runs queries and an export job that writes results to Cloud Storage, including a bucket in an account they control, then downloads it. No database is breached in the classic sense; the warehouse simply answers. This is T1213 (data from information repositories) with T1537 and T1567.
Why it works
Queries and exports are normal BigQuery operations, so a large pull can blend in unless you watch volume and destinations. Read access to a dataset is read access to all of it.
How to detect it
Look for large or unusual queries, export jobs writing to external or new buckets, and bytes-scanned spikes from an identity that does not normally query, in Cloud Audit Logs and BigQuery job history.
The fix that holds
Least-privilege dataset access, restrict export destinations with a service perimeter (deny external buckets), apply column and row-level security on sensitive data, and alert on large exports. Treat a bulk export as a data breach.
Practice it
We built a BigQuery exfiltration scenario in GraphLattice Range so teams learn to watch query volume and export destinations, not just access.