The Fastest Way to Destroy a GCP Environment

Billing is a necessary evil for all cloud infrastructure. As much as we engineers like to pretend it isn’t there, someone is watching the bill rack up over that build server you forgot in a sandbox. Providers won’t allow you to run your infrastructure without paying for it (which is very reasonable).

What happens right after you stop paying your bill differs slightly across GCP/Azure/AWS. In GCP’s world, the moment you disassociate a project from a billing account, all of the resources in that project start shutting down. It isn’t usually easy to strip away a billing account from a GCP project, except when you use Terraform, which then results in a small project migration accidentally shutting down production. I’m recollecting a particularly unfortunate day for a customer.

The solution is to lock billing accounts to important GCP projects and avoid running terraform apply -auto-approve after importing projects into the state file. But this incident got me thinking - how could attackers weaponize this aspect of GCP?

Cloud Environment Destruction in Ransomware

Microsoft Threat Intelligence reported on an incident in April of this year that involved a ransomware extortion on an on-premises environment accompanied with the destruction of the corresponding hybrid cloud environment. It’s evil genius from the attacker perspective - block any chance of a recovery into the cloud and ensure that your ransom really stings.

The threat actor destroyed the Azure environment in that incident by capturing privileged accounts and then deleting all the things important in the cloud. A mass resource deletion in combination with a ransomware incident on the ground. Ouch.

Take our billing account disassociation accident above and now put it in the hands of a jerk - all of the sudden a single billing account admin user has the power to take down a LOT of environments in GCP at once. You should always limit who has billing account administration roles, but you should really think hard on it if that billing account is attached to projects that make you money.

role: Billing Account Administrator, member: allUsers

The good news - you cannot add just anyone to your billing account. Google Cloud has smartly prevented that misconfiguration from happening. Thank goodness too as otherwise I was about to waste my time and make a billing account enumeration tool to find every poor soul who bound allUsers to roles/billing.admin.

Unfortunately there are still probably folks you gave access to a billing account that you didn’t intend to also give the ability to destroy production. Audit those billing account permissions folks.