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

Charles Henderson’s Cybersecurity Awareness Month Content Roundup

In some parts of the world during October, we have Halloween, which conjures the specter of imagined monsters lurking in the dark. Simultaneously, October is Cybersecurity Awareness Month, which evokes the specter of threats lurking behind our screens. Bombarded with horror stories about data breaches, ransomware, and malware, everyone’s suddenly in the latest cybersecurity trends and data, and the intricacies of their organization’s incident response plan. What does all this fear and uncertainty stem from? It’s the unknowns. Who might…

How IBM Secured the 2022 US Open

Throughout the US Open Tennis Championship, the infrastructure for USOpen.org and the mobile apps can see upwards of 3 million security events. While the vast majority of events are not serious, security analysts must quickly determine which are concerning to take immediate action. However, with such a large volume and variety of data, security analysts need to know where to focus their attention. As the host of the digital platforms and official digital innovation partner for the US Open Tennis…