GCP Pentesting
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Before start pentesting a GCP environment, there are a few basics things you need to know about how it works to help you understand what you need to do, how to find misconfigurations and how to exploit them.
Concepts such as organization hierarchy, permissions and other basic concepts are explained in:
GCP - Basic InformationIn order to audit a GCP environment it's very important to know: which services are being used, what is being exposed, who has access to what, and how are internal GCP services an external services connected.
From a Red Team point of view, the first step to compromise a GCP environment is to manage to obtain some credentials. Here you have some ideas on how to do that:
Leaks in github (or similar) - OSINT
Social Engineering (Check the page Workspace Security)
Password reuse (password leaks)
Vulnerabilities in GCP-Hosted Applications
Server Side Request Forgery with access to metadata endpoint
Local File Read
/home/USERNAME/.config/gcloud/*
C:\Users\USERNAME\.config\gcloud\*
3rd parties breached
Internal Employee
Or by compromising an unauthenticated service exposed:
GCP - Unauthenticated Enum & AccessOr if you are doing a review you could just ask for credentials with these roles:
GCP - Permissions for a PentestAfter you have managed to obtain credentials, you need to know to who do those creds belong, and what they have access to, so you need to perform some basic enumeration:
For more information about how to enumerate GCP metadata check the following hacktricks page:
In GCP you can try several options to try to guess who you are:
You can also use the API endpoint /userinfo to get more info about the user:
If you have enough permissions, checking the privileges of each entity inside the GCP account will help you understand what you and other identities can do and how to escalate privileges.
If you don't have enough permissions to enumerate IAM, you can steal brute-force them to figure them out. Check how to do the numeration and brute-forcing in:
GCP - IAM, Principals & Org Policies EnumNow that you have some information about your credentials (and if you are a red team hopefully you haven't been detected). It's time to figure out which services are being used in the environment. In the following section you can check some ways to enumerate some common services.
GCP has an astonishing amount of services, in the following page you will find basic information, enumeration cheatsheets, how to avoid detection, obtain persistence, and other post-exploitation tricks about some of them:
GCP - ServicesNote that you don't need to perform all the work manually, below in this post you can find a section about automatic tools.
Moreover, in this stage you might discovered more services exposed to unauthenticated users, you might be able to exploit them:
GCP - Unauthenticated Enum & AccessThe most common way once you have obtained some cloud credentials or have compromised some service running inside a cloud is to abuse misconfigured privileges the compromised account may have. So, the first thing you should do is to enumerate your privileges.
Moreover, during this enumeration, remember that permissions can be set at the highest level of "Organization" as well.
GCP - Privilege EscalationGCP - Post ExploitationGCP - PersistenceWhile enumerating GCP services you might have found some of them exposing elements to the Internet (VM/Containers ports, databases or queue services, snapshots or buckets...). As pentester/red teamer you should always check if you can find sensitive information / vulnerabilities on them as they might provide you further access into the AWS account.
In this book you should find information about how to find exposed GCP services and how to check them. About how to find vulnerabilities in exposed network services I would recommend you to search for the specific service in:
Compromising principals in one platform might allow an attacker to compromise the other one, check it in:
GCP <--> Workspace PivotingIn the GCloud console, in https://console.cloud.google.com/iam-admin/asset-inventory/dashboard you can see resources and IAMs being used by project.
Here you can see the assets supported by this API: https://cloud.google.com/asset-inventory/docs/supported-asset-types
Check tools that can be used in several clouds here.
gcp_scanner: This is a GCP resource scanner that can help determine what level of access certain credentials posses on GCP.
gcp_enum: Bash script to enumerate a GCP environment using gcloud cli and saving the results in a file.
GCP-IAM-Privilege-Escalation: Scripts to enumerate high IAM privileges and to escalate privileges in GCP abusing them (I couldn’t make run the enumerate script).
BF My GCP Permissions: Script to bruteforce your permissions.
Remember that you can use the parameter --log-http with the gcloud cli to print the requests the tool is performing. If you don't want the logs to redact the token value use gcloud config set log_http_redact_token false
Moreover, to intercept the communication:
In order to use an exfiltrated service account OAuth token from the metadata endpoint you can just do:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
