When you look at the details surrounding attacks in the cloud, how easy is it for you to quickly determine what happened and how to prevent a similar attack in your own environment? Applying the MITRE Att&ck Cloud Matrix is a great resource to classify and understand cloud-based attacks.
In this post, we will revisit a previous blog post to demonstrate how MITRE’s new Cloud Matrix can be applied to help us analyze the threat and prevent it from happening in your environment. We’ll recount the scenario, which exposes data in a storage bucket hosted by the Google Cloud Platform (GCP). Then we will examine some mitigations provided by MITRE, and look at how we could implement these in GCP.
Summary of the Scenario
The original scenario was an attack in which I escalated my privileges to remove a security perimeter established around a storage bucket that was storing sensitive data. The security perimeter only allowed people to access the bucket if they were coming from the correct IP address range. Below is a diagram, along with the steps taken to complete the attack.
The attack followed these basic steps:
- A service account credential was accidentally exposed, which had OSLogin permissions (allows someone to SSH to virtual machines).
- Using the exposed credential, I SSHd into a publicly exposed virtual machine.
The virtual machine was running with the default service account for Google Compute Engine (which has too many permissions), and the scope associated was, “Allow full access to all Cloud APIs.”
- Using the default service account, I listed the other service accounts in that project.
- I located a service account that had admin permissions and activated that service account from the virtual machine. At that point, I had administrative privileges at the Organization level.
- Using the admin service account, I removed a VPC Security Perimeter.
- After removing the VPC Security Control Perimeter, I accessed the data in the storage bucket that was previously protected.
The attack’s impact was the exposure of sensitive data.
Breaking Down the Att&ck
Below are the tactics, techniques, and mitigations found in MITRE’s Cloud Matrix matched with parts of the attack. The numbers match with the attack steps in the section above. The text in italics under the MITRE mitigation column was taken directly from MITRE’s Cloud Matrix.
Along with MITRE’s Techniques and Mitigations, I’ve added some specific mitigative steps to take for GCP.
Step 1
Description: A valid credential was found in source control that was publicly exposed.
- Tactics: Initial Access
- Techniques: Valid Accounts
- Mitigations: Application Developer Guidance
Scan your source code for credentials, and then update any credentials found. This is not specific to GCP. However, the GCP service account credential is an RSA key, so you will need to be sure that your scans include private RSA keys.
Step 2
Description: A SSH connection was established from outside the organization to a virtual machine hosted by GCP using the exposed credential.
- Tactics: Initial Access
- Techniques: Exploit Public-Facing Application
- Mitigations: Network Segmentation
Only allow SSH authentication from allow listed IP addresses. This can be configured in GCP firewall rules.
Step 3 + 4
Description: The credentials of the publicly exposed virtual machine were used to assume another identity that has administrative privileges in GCP.
- Tactics: Privilege Escalation
- Techniques: Valid Accounts
- Mitigations: Privileged Account Management
T