Detecting Google Cloud Platform OAuth Token Abuse Using Splunk

In a recent post by the Splunk Threat Research team, we addressed permanent and temporary token/credential abuse in AWS and how to mitigate credential exposure. With 94% of Enterprises using a cloud service, and some using at least five different cloud platforms, it’s imperative to stay ahead of threats across multicloud environments. Let’s now turn our attention to Google Cloud Platform (GCP) and how to detect and mitigate OAuth Token Abuse.

Research from Threatpost indicates that GCP features such as Google Cloud Shell can be attacked, which can provide attackers root privileges. There has also been recent research suggesting that GCP Identity Access Management (IAM) permissions can be used to move laterally and escalate privileges. In this blog we will share new threat vectors that abuse Google Cloud platform authentication tokens, as well as how we can detect these threats using Splunk and how to automatically remediate them using Splunk Phantom. 

Let’s take a look at the GCP authentication process, specifically at the use of OAuth tokens.  These access tokens represent an API requests on behalf of users against the services and applications hosted in GCP. We researched and replicated several issues that provide attackers with the ability to abuse them. 

Since these tokens basically authorize a source to execute and perform API requests on targeted platforms, these tokens must be protected and only accessed by a specific application, authorization server, and resource server. These tokens must also be protected when they are at rest state or in transit using encryption. The following is a visual representation of the OAuth token request and flow when tokens are requested from installed applications.

Source Google*

As shown above, users execute a request to obtain a token to Google authentication servers. Next, the users proceed to login and consent. Then, the user receives an authorization code, exchanges a code for the token, and receives a token response. These tokens, which have a limited life depending on the policy, are used for Google API calls.  

Users of GCP and G Suite can add Multi-Factor Authentication (MFA) when acquiring these tokens. The use of these tokens is ultimately restricted by the settings and policies for the Identity Access Management service on Google platforms. 

The GCP OAuth Token Threat Vector

According to recent research by Jenko Hwong from Netskope, there are several issues related to the protection of these tokens, specifically when the tokens are at rest. This means that if an attacker is able to gain access to an endpoint via phishing or physical access, there are several issues with how these tokens are protected:

• Tokens are not encrypted and can be read.
• Tokens can be refreshed once exfiltrated--even from different IP addresses, and
• A switch of account can occur without an MFA prompt. Applicable if multiple accounts with different levels reside in the device, Netskope research shows.

For an actor to employ these abuses, they need to read the local GCP-cached credentials. Local GCP-cached credentials are located at ~/.config/gcloud. The following screenshots show the structure of this folder.

The entire contents of the ~/.config folder can be archived and exfiltrated for subsequent abuse and access of targeted victim’s Google Cloud Services & Applications. We can also view access tokens that are stored in the local sqlite database--specifically access_tokens. 

By querying the local sqlite database we can confirm these tokens are not encrypted and can indeed be exfiltrated to a different host, refreshed, and reused. 

As seen in the above screenshot, the credentials.db file includes scopes of access for the targeted user. With this information we can extend the lifetime of the token by crafting a request that will refresh it.

Reference Netskope OAuth Token Hijacking*
curl -s --data --client_id=3255XXX40559.apps.googleusercontent.com --data client_secret=ZmssLNjJy2XXXhD4CTg2ejr2 --data grant_type=refresh_token --data refresh_token=1//01fYhQRYWoAXmCgYIARAAGAESNwF-L9Ir_U3g3ESX5aHiBWkcvJmUa_-ZrQra47a1WxrImrRoaqXXXXuni1cJkT0mSEs4icYicsI --data scope=”https://www.googleapis.com/auth/cloud-platform
https://www.googleapis.com/auth/accounts.reauth”
"https://www.googleapis.com/OAuth2/v4/token”

Using the curl request above, the attacker can refresh the token and continue accessing the victim's platform long after its original intended expiration time. Moreover, the attacker can access different resources within the scope of authorization of the compromised account. It is important to note that this also applies to any instance where Google SDK is installed. For example, if an attacker is able to compromise a jump box or another type of cloudbased instance used for accessing Google Cloud services, the above actions apply as well. Interestingly enough, even ephemeral environments such as the Google Cloud Shell can be used to extract this information.

Using Splunk to Detect GCP OAuth Token Abuse

Detecting abuse of these tokens can be very difficult, especially in default environments from Google Cloud. For example, there are no expiration limits for sessions or access control based on source IP addresses.  Splunk’s Threat  Research Team has previously addressed the extra step that is usually required in any cloud platform in order to get audit logs and how those logs need to be shipped to Splunk, in this case specifically using GCP. Based on the above conditions, the following items are necessary in order to address GCP OAuth token abuse. 

These two items are needed to detect GCP OAuth token abuse:

• Establish access control lists based on IP address source access
• A log/alert platform needs to be in place in order to perform such detections. Splunk customers need to follow Google best practices for shipping logs to Splunk instances. Customers also need to have Splunk Google Cloud Platform add on. 

Once the above items are in place, we can create a search to detect possible OAuth token hijack or abuse. 

The main fields we need to look for are derived from GCP cloud access audit log. The following fields can be extracted and parsed using Splunk Google Cloud Add-on. It is also important to set up an IP address source access policy as it was done in Netskope recent GCP OAuth token hijacking research via VPC Service Controls. If a token is exfiltrated from a compromised device and access is attempted from an IP address not in the allowed list, a violation will be registered and this can be detected via Splunk search and piped into an alert or further defensive actions via Splunk Phantom. 

The following are the main fields to look for to detect failed attempts to use hijacked:

• type.googleapis.com/google.cloud.audit.AuditLog ← Google Audit logs
• protoPayload.status.details{}.@type ← type of event
• protoPayload.status.details{}.violations{}.callerIp  ← offending IP address
• protoPayload.status.details{}.violations{}.type ← type of violation
• protoPayload.status.message ← response status from violation

Mitigation Measures for GCP OAuth Token Abuse

The following mitigation measures can work against this threat vector:

• Establish access policies such as IP Allow lists in GCP
• Setup cloud auditing logs and monitoring environment that allows detection and investigation
• Limit session time for OAuth tokens
• Enable MFA if you have not done so, MFA however does not prevent reuse/refresh of valid hijacked OAuth tokens 
• Disabling accounts will invalidate all tokens 
• Look proactively for leaked tokens using git-wild-hunt
• Apply behavioral analysis based on access policies and source user behavior. A case where attacker is pivoting from internal asset (i.e Google shell backdoor, compromised endpoint, etc.)

When using Splunk, we can create alerts from detection results and create a notable for Splunk Enterprise Security (ES).  In the following example, after we set up the search and alert based on the above-mentioned fields and we configure the search alert under Splunk ES content management, we will be notified of such occurrences as seen in the screenshot below. 

We can identify in this notable the violating source IP the status type that led to the alert, along with the violation type and the resulting status message. We can also use a Splunk Phantom playbook like the following:

As seen in the above graphics we can investigate the geolocation, owner, DNS resolutions and last HTTPS certificate associated with the offending IP address. 

About Splunk Threat Research Team

The Splunk Threat Research team is devoted to understanding actor behavior and researching known threats to build detections that the entire Splunk community can benefit from. The Splunk Threat Research team does this by building and open sourcing tools that analyze threats and actors like the Splunk Attack Range and using these tools to create attack data sets. From these data sets, new detections are built and shared with the Splunk community under Splunk Security Content. These detections are then consumed by various Splunk products like Enterprise Security, Splunk Security Essentials, and Mission Control to help customers quickly and effectively find known threats.