IBM Security X-Force Red took a deeper look at the Google Cloud Platform (GCP) and found a potential method an attacker could use to persist in GCP via the Google Cloud Shell.

Google Cloud Shell is a service that provides a web-based shell where GCP administrative activities can be performed. A web-based shell is a nice feature because it allows developers and administrators to manage GCP resources without having to install or keep any software locally on their system. From a technical perspective, Google notes that Cloud Shell is an ephemeral Debian Linux Virtual Machine (VM). What users interact with when they use Cloud Shell is actually a Docker container. To use Cloud Shell, you simply log in to the Google Cloud console and click the terminal icon, which starts up a Cloud Shell instance, as can be seen below.

Reading the previous paragraph, you probably saw the word “ephemeral” and wondered how you can persist in an ephemeral environment. The container spun up by Google Cloud Shell is ephemeral, but your home directory (/home) can hold up to 5GB of data and is persistent.

There is previous research showing how to use the .bashrc file to persist in Cloud Shell. That is in this Medium post made by Juan Berner in 2018. Persisting through the .bashrc file is one method to persist, but there is another option.

During our research, we discovered that the Google Cloud Shell has a unique capability at startup to read from a file in the home folder called .customize_environment. This file is not created by default, but once it is added it will run every time the Cloud Shell is started.

From an administrative perspective, this is a great convenience. If there are tools an admin frequently uses, but are not installed by default, they can write a script within the .customize_environment file to install any desired software, change the system’s configuration and more.

If you are a hacker, however, this feature may catch your attention for other reasons.

Bad guys, penetration testers and red teams typically have a similar goal after they initially breach an environment. That goal is to stay inside a compromised network, which means they need to have at least one method to maintain their access. In cybersecurity, we refer to this as persistence.

The .customize_environment file is a solid persistence option after initial access is gained to GCP. There is a lot of capability with this method. A command and control implant could be downloaded and run every time the Cloud Shell is started, or run a script run that steals tokens and posts them to the attacker’s server and so on. Outbound filtering on the Cloud Shell seemed extremely limited during testing. Below we checked for open TCP ports we could connect to outbound, and none were blocked.

Open outbound access means that a reverse shell is possible. In the example below we keep it simple and run a Netcat reverse shell using the following code in the .customize_environment file. This provides us remote access to the compromised Cloud Shell.

The next time Cloud Shell is started up we get a reverse shell.

You can see in the process list that .customize_environment is automatically called with Bash at startup and is still running the reverse shell.

There are downsides to this persistence method, however. For it to be effective, the victim must use Cloud Shell. If they are an infrequent user or don’t use Cloud Shell, this will not be a reliable or effective persistence method.

Another downside is that the first time an action is performed in Cloud Shell that requires authentication, it pops up an authorization window in the user’s browser that must be accepted before the command runs. If an unexpected pop-up comes up, a target could get suspicious and burn the persistence method.

A workaround to limit detection would be monitoring the user’s activity and waiting until they have made an API call before trying to perform activity that requires authentication. Lastly, if a user does not use Cloud Shell regularly the Home directory will be deleted after 120 days of inactivity.

Authorization popup from command using Curl to attempt to access the Metadata server

A key advantage of this persistence method is that the ability to detect or block it is very limited. Google does not currently provide for logging, firewall rules or etc. to apply to Cloud Shell.

The only way to effectively block this persistence method is to disable Cloud Shell for all users. Below are step-by-step instructions a Google admin user can use to disable Cloud Shell:

1. Login to the Google Admin console at

2. Select Additional Google services on the left menu bar.

3. Now select Google Cloud Platform from the menu in the middle of the screen.

4. Click on Cloud Shell settings to open the Cloud Shell options menu.

5. Uncheck the box Allow access to Cloud Shell.

6. Lastly, click the SAVE button to save the configuration.

The Google Cloud Shell is now disabled for the organization.

In the end, using the .customize_environment file for persistence is a method that under the right conditions is a solid persistence option with limited detection capabilities.

If you’d like to schedule a consult with IBM Security X-Force visit:

More from Cloud Security

The Importance of Modern-Day Data Security Platforms

Data is the backbone of businesses and companies everywhere. Data can range from intellectual property to critical business plans to personal health information or even money itself. At the end of the day, businesses are looking to grow revenue, innovate, and operationalize but to do that, they must ensure that they leverage their data first because of how important and valuable it is to their organization. No matter the industry, the need to protect sensitive and personal data should be…

Cybersecurity in the Next-Generation Space Age, Pt. 4: New Space Future Development and Challenges

View Part 1, Introduction to New Space, Part 2, Cybersecurity Threats in New Space, and Part 3, Securing the New Space, in this series. After the previous three parts of this series, we ascertain that the technological evolution of New Space ventures expanded the threats that targeted the space system components. These threats could be countered by various cybersecurity measures. However, the New Space has brought about a significant shift in the industry. This wave of innovation is reshaping the future…

Backdoor Deployment and Ransomware: Top Threats Identified in X-Force Threat Intelligence Index 2023

Deployment of backdoors was the number one action on objective taken by threat actors last year, according to the 2023 IBM Security X-Force Threat Intelligence Index — a comprehensive analysis of our research data collected throughout the year. Backdoor access is now among the hottest commodities on the dark web and can sell for thousands of dollars, compared to credit card data — which can go for as low as $10. On the dark web — a veritable eBay for…

How Posture Management Prevents Catastrophic Cloud Breaches

We've all heard about catastrophic cloud breaches. But for every cyberattack reported in the news, many more may never reach the public eye. Perhaps worst of all, a large number of the offending vulnerabilities might have been avoided entirely through proper cloud configuration. Many big cloud security catastrophes often result from what appear to be tiny lapses. For example, the famous 2019 Capital One breach was traced to a misconfigured application firewall. Could a proper configuration have prevented that breach?…