Detection of Inbound SSO persistence techniques in GCP
Single Sign On (SSO) is a powerful capability that allows organizations to use their own identity provider (IdP) to access 3rd party applications, like the cloud provider console.
SSO makes user lifecycle management easier, and also saves the burden of having multiple accounts for the end users.
SSO adds a net positive to the overall security of an organization, reducing the management overhead of IT systems. But, powerful features need to be used with caution, and closely monitored, identity federation is no exception. Recently threat actors who have compromised admin accounts of identity providers have then configured their own malicious IdP to act as a trusted source of identity. By abusing the identity provider Just In Time user provisioning feature, attackers were able to impersonate other users in the IdP.
How can these techniques be applied to Cloud Identity in GCP?
Cloud Identity does not support Just In Time user provisioning, and therefore a SAML SSO authentication workflow returning a claim with an identifier different from the initial request will not be successful. For more information read Cloud Identity documentation.
While it would not allow to impersonate legitimate users easily, adding external identity providers is still a valuable persistence tactic and it is important to be aware of how it could be implemented in GCP.
There are three main ways to consume external identities in a GCP organization:
- Enable an SSO profile for all or a subset of users
- Create an identity pool for workload identity federation
- Create an identity pool for workforce identity federation
Let’s see how to monitor for each of these.
Enable SSO profile in Cloud Identity
Reconfigure an existing SSO for the whole organization is going to be noticed immediately as it would prevent all legitimate users from authenticating. A more sneaky approach is to create an SSO profile with the new external IdP and useit for a subset of users, members of a specific organization unit. See SSO profiles documentation here. Once the SSO profile is created and assigned to an Organization Unit, the external IdP will be used to authenticate those users to Google Cloud.
The key logging entries to monitor for are create a new SSO profile, or update an existing SSO profile:
logName: "organizations/[organization ID]/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.methodName: "google.admin.AdminService.inboundSsoProfileUpdated"logName: "organizations/[organization ID]/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.methodName: "google.admin.AdminService.inboundSsoProfileCreated"These logs are available in GCP Log Explorer if you have enabled Google Workspace logs sharing, by querying at the Organization node level.
Identity pools for workforce identity federation
Workforce identity federation lets you use an external identity provider (IdP) to authenticate and authorize a group of users, using IAM, so that the users can access Google Cloud services using syncless, attribute-based single sign on. See documentation here.
Workforce Identity pools are not mapped into Cloud Identity users, and are recommended for granting non-privileged IAM roles, with very specific scope. It is not probably an attacker’s first choice for persistency, but — given the opportunity — a compromised workforce identity pool is still a valuable asset.
The key events to monitor are the creation of workforce identity pool and their update, the respective logs can be isolated searching for the following:
logName="organizations/[OrganizationId]/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.methodName="google.iam.admin.v1.WorkforcePools.CreateWorkforcePool"logName="organizations/[OrganizatrionId]/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.methodName="google.iam.admin.v1.WorkforcePools.UpdateWorkforcePool"These actions are implemented at organization level, and therefore logs should be queried at the organization node.
Identity pools for workload identity federation
With Workload Identity Federation you can use Identity and Access Management (IAM) to grant external identities IAM roles. This approach eliminates the need to create and manage Service Account keys, workloads can use their native identity, for example the service account from another cloud provider, to impersonate a GCP Service Account. External identities are managed in GCP by creating Identity Pools. See documentation here.
An attacker with the right privileges can create — or more likely update — identity pools to add their own OIDC provider and then obtain GCP service account tokens.
The following logs entries report the creation or the update of a workload identity federation:
logName="projects/[ProjectID]/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.methodName="google.iam.v1.WorkloadIdentityPools.CreateWorkloadIdentityPoolProvider"logName="projects/[ProjectID]/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.methodName="google.iam.v1.WorkloadIdentityPools.UpdateWorkloadIdentityPoolProvider"These logs are ingested at project level, where the Identity pool resource is created. To monitor for these events across your whole organization you will need to aggregate the logs with an org-level log sink.
Wrapping up
Configuring SSO, or identity pools, require privileged access, for example the role of Super Admin. It is vital to protect those user accounts with hardware security keys for multi factor authentication, and follow the security best practices.
Then, you should monitor for all these events in your organization, the good news is that they are easy to spot in the defaults GCP logs, and they are very infrequent so your SOC should not be overwhelmed by alerts.
You can monitor these techniques for example by redirecting these logs to a simple Cloud Function, or forward them to your SIEM of choice. Also, if you have Security Command Center Premium, make sure to be notified if the Event Threat Detection rule “CHANGE_SSO_SETTINGS” is triggered.
