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 https://admin.google.com/

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: www.ibm.com/security/xforce?schedulerform

More from Cloud Security

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?…

How to Implement Cloud Identity and Access Governance

Creating identity and access governance across cloud environments is crucial for modern organizations. In our previous post, we discussed how important human and non-human identities are for these environments and why their management and the governance of their access can be difficult. In the face of these challenges, our cloud identity and access governance (CIAG) approach offers an orchestration layer between cloud identity and access management (IAM) and enterprise IAM, as the following graphic shows. As we continue our CIAG…

How Do You Plan to Celebrate National Computer Security Day?

In October 2022, the world marked the 19th Cybersecurity Awareness Month. October might be over, but employers can still talk about awareness of digital threats. We all have another chance before then: National Computer Security Day. The History of National Computer Security Day The origins of National Computer Security Day trace back to 1988 and the Washington, D.C. chapter of the Association for Computing Machinery’s Special Interest Group on Security, Audit and Control. As noted by National Today, those in…

Why Are Cloud Misconfigurations Still a Major Issue?

Cloud misconfigurations are by far the biggest threat to cloud security, according to the National Security Agency (NSA). The 2022 IBM Security X-Force Cloud Threat Landscape Report found that cloud vulnerabilities have grown a whopping 28% since last year, with a 200% increase in cloud accounts offered on the dark web in the same timeframe. With vulnerabilities on the rise, the catastrophic impact of cloud breaches has made it clear that proper cloud security is of the utmost importance. And…