Support HackTricks and get benefits!
- If you want to see your company advertised in HackTricks or if you want access to the latest version of the PEASS or download HackTricks in PDF Check the SUBSCRIPTION PLANS!
- Get the official PEASS & HackTricks swag
- Discover The PEASS Family, our collection of exclusive NFTs
- Join the 💬 Discord group or the telegram group or follow me on Twitter 🐦 @carlospolopm.
- Share your hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.
With that permission you can modify the metadata information of an instance and change the authorized keys of a user, or create a new user with sudo permissions. Therefore, you will be able to exec via SSH into any VM instance and steal the GCP Service Account the Instance is running with.
Limitations:
- Note that GCP Service Accounts running in VM instances by default have a very limited scope
- You will need to be able to contact the SSH server to login
For more information about how to exploit this permission check:
{% content-ref url="gcp-local-privilege-escalation-ssh-pivoting.md" %} gcp-local-privilege-escalation-ssh-pivoting.md {% endcontent-ref %}
This permission gives the same privileges as the previous permission but over a specific instances instead to a whole project. The same exploits and limitations as for the previous section applies.
This kind of permission will allow you to grant yourself a role with the previous permissions and escalate privileges abusing them.
If OSLogin is enabled in the instance, with this permission you can just run gcloud compute ssh [INSTANCE]
and connect to the instance. You won't have root privs inside the instance.
If OSLogin is enabled in the instance, with this permission you can just run gcloud compute ssh [INSTANCE]
and connect to the instance. You will have root privs inside the instance.
This method creates a new Compute Engine instance with a specified Service Account, then sends the token belonging to that Service Account to an external server.
The following additional permissions are required for this method:
- compute.disks.create
- compute.instances.create
- compute.instances.setMetadata
- compute.instances.setServiceAccount
- compute.subnetworks.use
- compute.subnetworks.useExternalIp
- iam.serviceAccounts.actAs
The exploit script for this method can be found here.
If you have the osconfig.patchDeployments.create
or **osconfig.patchJobs.exec
** permissions you can create a patch job or deployment. This will enable you to move laterally in the environment and gain code execution on all the compute instances within a project.
If you want to manually exploit this you will need to create either a patch job or deployment for a patch job run:
gcloud compute os-config patch-jobs execute --file=patch.json
To deploy a patch deployment:
gcloud compute os-config patch-deployments create my-update --file=patch.json
Automated tooling such as patchy exists to detect lax permissions and automatically move laterally.
Support HackTricks and get benefits!
- If you want to see your company advertised in HackTricks or if you want access to the latest version of the PEASS or download HackTricks in PDF Check the SUBSCRIPTION PLANS!
- Get the official PEASS & HackTricks swag
- Discover The PEASS Family, our collection of exclusive NFTs
- Join the 💬 Discord group or the telegram group or follow me on Twitter 🐦 @carlospolopm.
- Share your hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.