Impact

Successful exploitation allows an adversary to maintain long-term access to a GCP environment regardless of security team efforts to rotate credentials. It facilitates significant privilege escalation if the target service account possesses broad IAM permissions. In enterprise environments, this can lead to unauthorized data access, infrastructure manipulation, and cross-project movement within the GCP organization.

Recommendation

• Deploy detection rules to monitor SetIamPolicy operations that add impersonation roles to service accounts.
• Baseline administrative and CI/CD service accounts (such as Terraform or Jenkins) that legitimately perform IAM modifications to reduce false positives.
• Restrict the ability to set IAM policies on service accounts and implement a peer-review or justification-based approval process for IAM changes.
• Review existing IAM bindings for unauthorized principals or external accounts that have been granted impersonation rights.

Recommendation

Review affected products and apply Google's July 2026 security updates.

Attack Chain

1. An attacker gains access to a GCP account with sufficient privileges to modify Logging sinks. This could be through compromised credentials, IAM misconfigurations, or exploiting vulnerabilities in applications with access to GCP resources.
2. The attacker enumerates existing Logging sinks using the gcloud logging sinks list command or the Cloud Logging API to identify a suitable target.
3. The attacker modifies the target Logging sink's destination to a resource under their control, such as a Cloud Storage bucket in a different project or a Pub/Sub topic they subscribe to. They use the gcloud logging sinks update command or the Cloud Logging API.
4. The attacker may also modify the filter associated with the sink to capture a specific subset of logs, focusing on sensitive data or logs related to their activities.
5. Once the sink is updated, logs matching the sink's filter are now routed to the attacker-controlled destination.
6. The attacker accesses the exfiltrated logs from their destination, potentially revealing sensitive information.
7. Alternatively, the attacker modifies the logging sink to disable it entirely, preventing security teams from detecting malicious activity.
8. The attacker covers their tracks by deleting or modifying audit logs related to the sink modification, if possible.

Impact

A successful Logging sink modification can lead to the exfiltration of sensitive data, including personally identifiable information (PII), financial records, or proprietary business data. This can result in financial loss, reputational damage, and legal liabilities. Furthermore, disabling or modifying cloud logs can impair an organization's ability to detect and respond to security incidents, potentially prolonging the duration and increasing the impact of an attack.

Recommendation

• Deploy the Sigma rule "GCP Logging Sink Modification" to your SIEM and tune for your environment. This rule detects modifications to Logging sinks (rule).
• Review the event details for the specific event.action field value google.logging.v*.ConfigServiceV*.UpdateSink to confirm the type of modification made to the logging sink.
• Implement additional monitoring and alerting for changes to logging sink configurations to detect similar unauthorized modifications in the future (content).
• Review and strengthen access controls and permissions related to logging sink configurations to prevent unauthorized modifications, ensuring that only authorized personnel have the necessary permissions (content).
• Reference the MITRE ATT&CK techniques T1537 (Transfer Data to Cloud Account) and T1562.008 (Disable or Modify Cloud Logs) to understand the broader context of this threat (ttps).

Attack Chain

1. The attacker gains unauthorized access to the target's GCP environment, potentially through compromised credentials or a misconfigured IAM role.
2. The attacker enumerates existing storage buckets within the GCP project to identify targets for deletion.
3. The attacker uses the gcloud storage buckets delete command or the GCP console to initiate the deletion of a specific storage bucket.
4. GCP logs the storage.buckets.delete event in the audit logs, capturing details such as the user account, IP address, and timestamp of the deletion.
5. The targeted storage bucket and its contents are permanently removed from the GCP environment.
6. The victim organization experiences data loss and potential service disruption due to the unavailability of the deleted data.
7. The attacker may repeat this process to delete multiple storage buckets, exacerbating the impact and hindering recovery efforts.

Impact

Successful deletion of GCP storage buckets can lead to significant data loss and operational disruption. The impact can range from temporary service outages to permanent data loss, depending on the backup and recovery strategies in place. Industries heavily reliant on cloud storage, such as e-commerce, financial services, and healthcare, are particularly vulnerable. The cost of recovery can be substantial, including expenses related to data restoration, incident response, and reputational damage.

Recommendation

• Deploy the Sigma rule GCP Storage Bucket Deletion to your SIEM to detect unauthorized bucket deletions.
• Review IAM policies and enforce the principle of least privilege to limit the potential impact of compromised credentials.
• Enable versioning on critical storage buckets to facilitate recovery from accidental or malicious deletions (reference: [https://cloud.google.com/storage/docs/key-terms#buckets]).
• Set up alerts for any future deletion actions on storage buckets to ensure immediate awareness and response to similar threats.
• Investigate any alerts generated by the Sigma rule, focusing on the user account, IP address, and timestamp associated with the deletion event.

Attack Chain

1. An attacker gains unauthorized access to a GCP account with sufficient privileges.
2. The attacker enumerates existing Logging sinks within the target GCP project using gcloud logging sinks list or the Cloud Logging API.
3. The attacker identifies a sink to delete, focusing on those critical for security monitoring.
4. The attacker executes a gcloud logging sinks delete [SINK_NAME] command or uses the Cloud Logging API to delete the target sink.
5. GCP audit logs record the google.logging.v*.ConfigServiceV*.DeleteSink event with an event.outcome:success.
6. Log entries that would have been exported to the sink's destination are no longer processed, leading to a gap in security monitoring.
7. The attacker performs other malicious actions within the GCP environment, knowing that their activity is less likely to be detected due to the disabled logging.

Impact

A successful attack involving Logging sink deletion can severely impact an organization's security posture. The deletion of logging sinks prevents security teams from detecting malicious activities within the GCP environment. This can lead to delayed incident response and increased dwell time for attackers. Depending on the scope of the attack, this could affect multiple projects and services, leading to data breaches or service disruptions.

Recommendation

• Deploy the Sigma rule GCP Logging Sink Deletion to your SIEM and tune for your environment to detect sink deletion events.
• Review the audit logs for the specific event.action google.logging.v*.ConfigServiceV*.DeleteSink to identify the user or service account responsible for the deletion.
• Implement additional monitoring and alerting for any future attempts to delete logging sinks, focusing on the specific event action and outcome fields used in the detection query.

Attack Chain

1. An attacker gains unauthorized access to a cloud account or obtains valid credentials via credential stuffing or phishing.
2. The attacker uploads a malicious or compromised image to the cloud environment's image repository or leverages a publicly available, but malicious image.
3. The attacker uses the cloud provider's API or management console to initiate the creation of a new compute instance.
4. During instance creation, the attacker specifies the previously unseen image as the source image for the new instance.
5. The cloud provider provisions the new compute instance using the specified image.
6. The attacker connects to the newly created instance and executes malicious code or uses it for lateral movement within the cloud environment.
7. The attacker exploits resources within the compromised instance to steal sensitive data or compromise other cloud resources.

Impact

Compromised cloud compute instances can lead to data breaches, resource hijacking for cryptocurrency mining, and the deployment of malicious applications. A single compromised instance can serve as a beachhead for lateral movement, potentially impacting a large number of resources within the cloud environment. The use of rogue images bypasses standard image vetting procedures, increasing the likelihood of a successful attack.

Recommendation

• Implement the provided Sigma rule Cloud Instance Created with Unseen Image to detect when a new compute instance is created using an image that has not been previously observed in your environment. Tune the rule to your specific environment and baselines.
• Enable and monitor cloud provider logs related to compute instance creation and image usage to provide the data source for the Sigma rule above (CloudTrail, Azure Activity Log, GCP Cloud Logging).
• Implement strict image vetting procedures, including regular scanning for vulnerabilities and malware, to reduce the risk of deploying compromised images.

Attack Chain

1. The attacker gains unauthorized access to a GCP account through compromised credentials or other means.
2. The attacker enumerates existing logging buckets to identify potential targets for deletion.
3. The attacker attempts to delete a logging bucket using the google.logging.v*.ConfigServiceV*.DeleteBucket API call.
4. The GCP audit logs record the bucket deletion attempt.
5. If successful, the logging bucket enters a pending deletion state for seven days.
6. To fully eliminate logs, the attacker identifies log sinks associated with the deleted bucket.
7. The attacker deletes or modifies these log sinks to prevent further log routing to the affected bucket.
8. The attacker successfully impairs the organization's ability to detect and respond to malicious activity by removing crucial log data.

Impact

A successful logging bucket deletion can severely impact an organization's security posture. It allows attackers to operate with reduced visibility, potentially increasing the dwell time and impact of attacks. Organizations may lose critical audit data, hindering incident response and forensic investigations. The sectors most affected are those heavily reliant on GCP for their infrastructure, including technology, finance, and healthcare. The impact can range from compliance violations to the inability to detect and respond to active threats, leading to data breaches and financial losses.

Recommendation

• Deploy the Sigma rule GCP Logging Bucket Deletion to your SIEM to detect malicious bucket deletion attempts (rule provided below).
• Review IAM permissions and roles to ensure that only authorized personnel have the ability to delete log buckets, reducing the risk of unauthorized deletions.
• Implement additional logging and monitoring for any changes to log sinks and bucket configurations to detect and respond to similar activities promptly.
• Investigate any alerts generated by the GCP Logging Bucket Deletion Sigma rule, focusing on unauthorized user accounts or suspicious source IP addresses.
• Create exceptions for known maintenance periods or specific user accounts responsible for routine bucket deletions as described in the rule's false positives section.

Attack Chain

1. Credential Compromise: An attacker obtains valid credentials through phishing, credential stuffing, or purchasing leaked credentials.
2. Initial Access: The attacker uses the compromised credentials to attempt login to a Google Workspace account associated with a GCP tenant.
3. Single-Factor Authentication: The attacker successfully authenticates using only a username and password because MFA is not enabled or enforced for the target account.
4. GCP Access: Upon successful authentication, the attacker gains access to the Google Cloud Platform (GCP) resources associated with the compromised account.
5. Privilege Escalation (Optional): Depending on the compromised account's permissions, the attacker may attempt to escalate privileges within the GCP environment.
6. Lateral Movement (Optional): The attacker uses the initial access to move laterally within the GCP environment, accessing other resources and accounts.
7. Data Exfiltration / Service Disruption: The attacker exfiltrates sensitive data from GCP storage or disrupts critical services within the GCP environment.
8. Persistence (Optional): The attacker establishes persistence mechanisms to maintain access to the GCP environment, such as creating new accounts or modifying existing roles.

Impact

Successful exploitation of single-factor authentication vulnerabilities can result in significant damage, including data breaches, service disruptions, and financial losses. The impact can range from a few affected accounts to complete compromise of a GCP environment depending on access levels. The Forbes article referenced indicates billions of stolen logins are available, meaning credential compromise is a likely initial vector. Organizations in all sectors are at risk, particularly those with lax MFA enforcement policies.

Recommendation

• Deploy the Sigma rule GCP Successful Single-Factor Authentication to your SIEM and tune for your environment to detect logins without MFA based on Google Workspace logs.
• Investigate any alerts generated by the GCP Successful Single-Factor Authentication rule, prioritizing accounts with elevated privileges or access to sensitive data.
• Enforce multi-factor authentication (MFA) for all Google Workspace accounts, especially those with access to GCP resources, as per Google's recommendations in the references.
• Regularly audit Google Workspace and GCP configurations to ensure that MFA policies are properly configured and enforced.
• Use the drilldown searches included in this brief to investigate users triggering the initial detection.

Attack Chain

1. An attacker gains unauthorized access to a GCP account with sufficient IAM privileges.
2. The attacker enumerates existing service accounts within the targeted GCP project.
3. The attacker identifies a service account critical to business operations.
4. The attacker executes the google.iam.admin.v*.DisableServiceAccount API call to disable the target service account.
5. GCP audit logs record the successful disablement of the service account with event.outcome:success.
6. Applications or VMs relying on the disabled service account experience service disruptions or failures.
7. The attacker may attempt to further exploit the disruption to escalate privileges or conduct lateral movement.

Impact

Disabling a GCP service account can lead to significant disruption of cloud-based applications and services that rely on the account for authentication and authorization. This can result in application downtime, data access failures, and impaired business operations. The severity depends on the criticality of the disabled service account. The impact ranges from temporary service interruptions to complete application failures, potentially affecting customer-facing services and internal business processes.

Recommendation

• Deploy the Sigma rule "GCP Service Account Disabled" to your SIEM to detect this activity in real-time, and tune for your environment.
• Review the GCP audit logs for the specific event event.action:google.iam.admin.v*.DisableServiceAccount to identify the source of the disablement action.
• Implement additional monitoring and alerting for similar disablement actions on service accounts to detect and respond to future incidents promptly.
• Ensure that the principle of least privilege is applied to all service accounts, and enforce MFA for privileged accounts.
• Monitor GCP audit logs for anomalous activity related to IAM roles and permissions.

Attack Chain

1. An attacker gains initial access to a cloud environment through compromised credentials or an insider threat (T1578.005).
2. The attacker enumerates existing cloud security groups to identify potential targets for modification.
3. The attacker modifies security group rules to allow unauthorized access to internal resources or services.
4. The attacker creates new security groups with overly permissive rules, bypassing existing security controls.
5. The attacker deletes existing security groups, disrupting network segmentation and potentially causing service outages.
6. These actions are performed repeatedly within a short time frame (30 minutes), significantly deviating from the user's baseline activity.
7. The attacker exploits the newly opened access to exfiltrate sensitive data or deploy malicious workloads.
8. The ultimate objective is to compromise sensitive resources, disrupt services, or establish a persistent foothold within the cloud environment.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, disruption of critical services, and potential financial losses. A single compromised account can lead to the modification of numerous security groups, impacting multiple applications and services. The impact can range from data breaches and compliance violations to complete service outages. Depending on the scope of the compromised security groups, the blast radius can extend across the entire cloud infrastructure, affecting potentially thousands of users and applications.

Recommendation

• Ensure proper ingestion of AWS CloudTrail, GCP Pubsub Message logs, and Azure Audit logs into a data model like the Change datamodel referenced in the search query.
• Deploy the Sigma rule Cloud Security Group Modifications by User to your SIEM to detect anomalous security group modifications (logsource: AWS CloudTrail).
• Tune the threshold and time window of the Sigma rule based on your environment's baseline activity to reduce false positives. Consider adjusting the upperBound calculation in the search query.
• Investigate any alerts generated by the Sigma rule to determine if the modifications are legitimate or malicious. Prioritize alerts triggered by users with no history of security group administration.
• Implement multi-factor authentication (MFA) for all user accounts to mitigate the risk of compromised credentials.

Attack Chain

1. An attacker gains initial access to a GCP environment through compromised credentials or a vulnerable service.
2. The attacker enumerates existing service accounts to identify targets with desirable permissions.
3. The attacker attempts to create a new key for a chosen service account using the google.iam.admin.v*.CreateServiceAccountKey API.
4. The key creation is successful, granting the attacker access to the service account.
5. The attacker uses the new key to authenticate as the service account.
6. The attacker leverages the service account's permissions to access sensitive data or resources within GCP.
7. The attacker may create additional keys for redundancy and persistence.
8. The attacker maintains long-term access to the compromised GCP environment, potentially causing significant damage.

Impact

Successful exploitation allows an attacker to leverage the service account's permissions, potentially leading to data exfiltration, resource manipulation, or further lateral movement within the GCP environment. While the severity is low, repeated or unusual key creations, particularly for highly privileged service accounts, can indicate a serious compromise. The lack of proper tracking and management of service account keys significantly increases the risk of unauthorized access and persistence.

Recommendation

• Deploy the Sigma rule "GCP Service Account Key Creation" to your SIEM and tune for your environment to detect suspicious key creation activity in GCP.
• Review the audit logs for the specific event.action google.iam.admin.v*.CreateServiceAccountKey to identify the service account involved in the key creation.
• Implement additional monitoring and alerting for unusual service account activities, such as unexpected key creations or permission changes, to enhance detection of similar threats in the future (as described in the "Setup" section).
• Rotate all keys associated with the affected service account if unauthorized access is suspected to mitigate further risk (as mentioned in the "Response and remediation" section).

Attack Chain

1. The attacker gains unauthorized access to a GCP account, potentially through compromised credentials or exploiting a misconfigured IAM role.
2. The attacker enumerates existing service accounts within the GCP project to identify potential targets for disruption.
3. The attacker selects a target service account based on its perceived importance or impact on the target organization's operations.
4. The attacker executes the google.iam.admin.v*.DeleteServiceAccount API call via the gcloud CLI or GCP console.
5. GCP successfully processes the delete request and removes the service account identity.
6. Applications and VMs relying on the deleted service account lose access to authorized GCP services.
7. The target organization experiences disruption in services, leading to potential data loss, operational downtime, or financial repercussions.

Impact

A successful service account deletion can lead to significant disruption within a GCP environment. Depending on the permissions granted to the deleted service account, the impact could range from a minor service outage to a complete shutdown of critical applications. Organizations relying heavily on GCP for their infrastructure are especially vulnerable. If a critical service account is deleted, it can take considerable time to restore functionality, leading to potential financial loss and reputational damage. The number of affected victims depends on the scope of the targeted service account.

Recommendation

• Deploy the Sigma rule GCP Service Account Deletion Detected to your SIEM and tune for your environment to detect malicious deletions.
• Review the audit logs for the specific event.action:google.iam.admin.v*.DeleteServiceAccount to identify the exact time and source of the deletion.
• Investigate the context of the deleted service account, including its permissions and the resources it had access to.

Attack Chain

1. The attacker obtains valid or partially valid credentials through phishing (T1566), credential stuffing, or purchasing them from the dark web.
2. The attacker attempts to log in to a GCP account using the obtained credentials (T1078.004).
3. GCP's login process identifies the need for MFA and issues a login challenge using a configured method.
4. The attacker fails to complete the MFA challenge, indicating they do not possess the correct MFA token or cannot respond correctly (T1621).
5. Multiple failed MFA attempts may occur from the same IP address or user account.
6. If the attacker eventually succeeds in bypassing MFA (e.g., through a vulnerability or social engineering), they gain unauthorized access to the GCP environment.
7. Once inside, the attacker can perform reconnaissance, escalate privileges, and access sensitive data.
8. The attacker exfiltrates data or deploys malicious resources within the GCP environment, causing damage or disruption.

Impact

A successful attack can lead to unauthorized access to sensitive data and resources within the GCP environment. This could result in data breaches, financial loss, reputational damage, and disruption of services. The severity depends on the compromised account's permissions and the attacker's objectives within the GCP environment.

Recommendation

• Deploy the Sigma rule GCP Authentication Failed During MFA Challenge to your SIEM and tune the threshold based on your environment's baseline for failed MFA attempts.
• Investigate any alerts generated by the GCP Authentication Failed During MFA Challenge rule to determine if the failed MFA attempts are legitimate or indicative of malicious activity.
• Monitor login events for unusual patterns, such as multiple failed MFA attempts from the same IP address or user account.
• Ensure all users have strong, unique passwords and are enrolled in MFA.
• Review and enforce Conditional Access policies to restrict access based on location, device, and other factors.
• Install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) to collect the required Google Workspace login events.

Attack Chain

1. An attacker gains initial access to a GCP account, possibly through compromised credentials or exploiting a vulnerability.
2. The attacker authenticates to the GCP environment using valid credentials (T1078).
3. The attacker explores existing IAM roles and permissions to identify potential escalation paths.
4. The attacker crafts a custom IAM role with overly permissive privileges (T1098, T1098.003), granting themselves access to critical resources.
5. The attacker creates the custom IAM role using the google.iam.admin.v*.CreateRole API call.
6. The event is logged as a successful operation (event.outcome:success) in the GCP audit logs.
7. The attacker assigns the newly created custom role to a compromised or attacker-controlled user or service account.
8. The attacker leverages the escalated privileges to access sensitive data, modify configurations, or deploy malicious workloads, achieving persistence or further compromising the environment.

Impact

Successful exploitation can lead to significant damage, including unauthorized access to sensitive data, compromised systems, and potential data exfiltration. The creation of custom roles with excessive permissions can enable adversaries to maintain persistent access to the GCP environment, escalate privileges, and bypass existing security controls. Organizations may experience data breaches, financial losses, and reputational damage.

Recommendation

• Deploy the provided Sigma rules to your SIEM to detect suspicious IAM custom role creation events in GCP (logsource: gcp.audit).
• Review and audit existing IAM roles and permissions regularly to identify and remediate overly permissive configurations.
• Implement the principle of least privilege when assigning permissions to IAM roles, both built-in and custom.
• Monitor GCP audit logs for google.iam.admin.v*.CreateRole events and investigate any unexpected or unauthorized role creation activity.
• Ensure that only authorized personnel have the necessary permissions to create custom IAM roles, and implement controls to prevent unauthorized role creation.
• Establish a baseline of expected role creation activity and investigate any deviations from this baseline.

Attack Chain

1. An attacker gains initial access to a GCP environment, possibly through compromised credentials or a vulnerable application.
2. The attacker enumerates existing IAM roles and permissions to identify potential escalation paths.
3. The attacker attempts to create a new service account using the google.iam.admin.v*.CreateServiceAccount API call.
4. The attacker assigns elevated privileges to the newly created service account, granting it broad access to GCP resources.
5. The attacker uses the service account to perform actions within the GCP environment, such as accessing data or modifying configurations.
6. The attacker leverages the service account for persistence, allowing them to regain access even if their initial access method is revoked.
7. The attacker monitors the service account activity to ensure it maintains its privileges and has not been detected.

Impact

A successful attack can lead to unauthorized access to sensitive data, modification of critical system configurations, or disruption of services. Even though rated as "low" severity, successful exploitation could allow attackers to maintain a persistent presence within the GCP environment, potentially leading to significant data breaches or service outages.

Recommendation

• Deploy the Sigma rule GCP Service Account Created to your SIEM and tune for your environment to detect unexpected service account creation.
• Review IAM policies and permissions regularly to identify and remove any excessive privileges granted to service accounts.
• Implement multi-factor authentication (MFA) for all user accounts, including service accounts where possible, to prevent unauthorized access.
• Monitor GCP audit logs for suspicious activity related to service account creation and usage, using the event.action:google.iam.admin.v*.CreateServiceAccount filter.
• Implement automated workflows to validate and approve service account creation requests to ensure proper authorization and governance.

Attack Chain

1. An attacker gains initial access to a valid user account through credential compromise (e.g., phishing, password spraying).
2. The attacker authenticates to the Google Workspace Admin console using the compromised account.
3. The attacker navigates to the user management section within the Google Workspace Admin console.
4. The attacker locates the target user account for which they intend to disable MFA.
5. The attacker initiates the process to unenroll the target user from strong authentication, triggering the UNENROLL_USER_FROM_STRONG_AUTH command.
6. The system processes the request, disabling MFA for the target user account.
7. The attacker now maintains persistent access to the compromised account without MFA.
8. The attacker leverages the compromised account to perform unauthorized actions, such as accessing sensitive data, modifying configurations, or launching further attacks.

Impact

Successful disabling of MFA can lead to significant security breaches. A single compromised account can provide attackers with persistent access to sensitive data and systems. This can result in data exfiltration, financial losses, reputational damage, and disruption of business operations. The number of affected users depends on the scope of the initial compromise.

Recommendation

• Deploy the Sigma rule Detect GCP MFA Disable via GWS Admin Logs to your SIEM to identify instances of MFA being disabled.
• Investigate any alerts generated by the Sigma rule, focusing on the user and actor.email fields to determine the source and target of the action.
• Implement alerting on other critical admin actions in Google Workspace, beyond just MFA disabling, to give better context around potential account compromise (reference: Google Workspace Admin logs).
• Review and enforce strong MFA policies across your organization to minimize the attack surface (reference: https://support.google.com/cloudidentity/answer/2537800?hl=en).

Attack Chain

1. An attacker gains unauthorized access to a GCP account through compromised credentials or a misconfigured IAM policy.
2. The attacker enumerates existing service accounts to identify potential targets for disruption or privilege escalation.
3. The attacker selects a service account with the intent to disrupt dependent applications or services.
4. The attacker executes the google.iam.admin.v*.DeleteServiceAccountKey API call to delete the key associated with the targeted service account.
5. The GCP audit logs record a successful deletion event (event.outcome: success).
6. Legitimate applications or services that rely on the deleted service account key fail to authenticate, leading to service disruption.
7. The attacker may attempt to further compromise the environment or exfiltrate data, taking advantage of the chaos and confusion caused by the disruption.

Impact

Successful deletion of a service account key can disrupt critical applications and services relying on that key for authentication and authorization. The severity of the impact depends on the importance of the affected service account and the scope of its access. While the specific number of affected organizations is unknown, a successful attack could lead to temporary outages, data unavailability, and reputational damage.

Recommendation

• Deploy the Sigma rule GCP IAM Service Account Key Deletion to your SIEM to detect unauthorized key deletions.
• Investigate any alerts triggered by the GCP IAM Service Account Key Deletion Sigma rule, paying close attention to the actor, affected service account, and context of the deletion event.
• Review IAM policies and service account permissions to minimize the blast radius of compromised service accounts.
• Enforce multi-factor authentication (MFA) for all GCP user accounts to reduce the risk of credential compromise.
• Implement regular service account key rotation policies and monitor for deviations from established baselines.

Attack Chain

1. An attacker gains initial access to a GCP account, potentially through compromised credentials or exploiting a vulnerability.
2. The attacker enumerates existing firewall rules within the VPC or App Engine environment to identify potential targets for deletion.
3. Using compromised credentials or a service account, the attacker initiates the deletion of a specific firewall rule. The gcloud CLI or GCP console could be used.
4. The firewall rule is removed, altering the network access control configuration.
5. The attacker leverages the modified firewall configuration to establish unauthorized connections to internal resources.
6. The attacker moves laterally within the GCP environment, accessing sensitive data or systems previously protected by the deleted firewall rule.
7. The attacker exfiltrates data or performs other malicious activities, taking advantage of the weakened security posture.

Impact

Successful deletion of GCP firewall rules can lead to significant security breaches, including unauthorized access to sensitive data, lateral movement within the cloud environment, and potential data exfiltration. The impact is highly dependent on the scope and purpose of the deleted firewall rule. This activity allows attackers to bypass intended security controls.

Recommendation

• Deploy the Sigma rule GCP Firewall Rule Deletion to your SIEM to detect unauthorized firewall deletions based on data_stream.dataset:gcp.audit and event.action:(*.compute.firewalls.delete or google.appengine.*.Firewall.Delete*Rule).
• Enable GCP audit logging to ensure that all firewall rule deletion events are captured for analysis.
• Review and update access controls and permissions for users and service accounts to minimize the risk of unauthorized firewall rule modifications.
• Implement enhanced monitoring and alerting for firewall rule changes to detect and respond to similar threats more quickly in the future, based on event.action logs.

Attack Chain

1. The attacker gains initial access to a GCP account, potentially through compromised credentials or exploiting a misconfigured service account.
2. The attacker enumerates existing firewall rules and network configurations to identify potential weaknesses.
3. The attacker crafts a new firewall rule designed to allow unauthorized traffic, such as opening specific ports or IP ranges.
4. The attacker uses the gcloud command-line tool or the GCP console to create the new firewall rule, targeting either VPC or App Engine.
5. The newly created firewall rule is activated, effectively modifying the network's security posture.
6. The attacker leverages the permissive firewall rule to establish a command and control (C2) channel or exfiltrate sensitive data.
7. The attacker uses the open port(s) to move laterally within the network.
8. The attacker achieves their objective (data exfiltration, system compromise, etc.)

Impact

Successful exploitation can lead to unauthorized access to sensitive data, compromised systems, and potential data breaches. The low severity acknowledges that legitimate firewall rule changes occur regularly, but highlights the need to monitor and validate these changes to detect malicious activity. If successful, attackers can bypass existing security controls and potentially gain complete control of affected systems and applications.

Recommendation

• Deploy the Sigma rule GCP Firewall Rule Creation to your SIEM to detect suspicious firewall rule creations in your GCP environment. Tune the rule based on your organization's baseline activity and known service accounts.
• Review the audit logs for event.dataset:gcp.audit entries, specifically focusing on the event.action fields: *.compute.firewalls.insert or google.appengine.*.Firewall.Create*Rule to validate the source of firewall rule changes.
• Implement role-based access control (RBAC) to limit the ability to create or modify firewall rules to only authorized personnel, mitigating the risk of compromised accounts creating malicious rules.
• Establish a baseline of expected firewall rules and configurations to quickly identify deviations that could indicate malicious activity, using the provided references about GCP firewalls.

Attack Chain

1. Initial Access: An attacker gains initial access to a cloud account through compromised credentials or exploiting a misconfigured service.
2. Privilege Escalation: The attacker attempts to escalate privileges within the compromised account to gain broader access to cloud resources.
3. Reconnaissance: The attacker begins enumerating cloud resources, including security groups, to identify potential targets and vulnerabilities. This stage involves an increased volume of API calls.
4. Security Group Enumeration: The attacker uses cloud APIs to list existing security groups, their configurations, and associated resources. This is done to map out the network architecture and identify potential weaknesses.
5. Security Group Modification: The attacker attempts to modify security group rules to allow unauthorized access to resources or to create backdoors for persistent access. This could involve opening ports or changing IP address restrictions.
6. Lateral Movement: The attacker leverages the modified security groups to move laterally within the cloud environment, accessing previously restricted resources.
7. Data Exfiltration/Resource Abuse: Once inside, the attacker may exfiltrate sensitive data or abuse cloud resources for malicious purposes, such as cryptocurrency mining or launching denial-of-service attacks.
8. Persistence: The attacker establishes persistent access by creating new accounts or modifying existing ones, ensuring continued access even if the initial vulnerability is patched.

Impact

Compromise of cloud security groups can lead to significant damage. Successful attacks can result in unauthorized access to sensitive data, potential data breaches, and disruption of critical services. The number of victims can range from a single organization to multiple tenants in a shared cloud environment. Sectors at risk include any organization utilizing cloud services, particularly those handling sensitive data such as healthcare, finance, and government.

Recommendation

• Deploy the Sigma rule "Cloud Security Group API Call Volume Anomaly" to your SIEM and tune the threshold based on your environment's baseline activity.
• Enable and monitor cloud provider audit logs (e.g., AWS CloudTrail, Azure Activity Log, Google Cloud Audit Logs) to provide the data source for the Sigma rules.
• Implement multi-factor authentication (MFA) for all cloud accounts to mitigate the risk of credential compromise.

Attack Chain

1. Attacker obtains a valid username and password through phishing, credential stuffing, or purchasing stolen credentials.
2. Attacker attempts to log in to a GCP service or application using the compromised credentials.
3. The GCP environment prompts the user for MFA.
4. Attacker initiates a large number of login attempts within a short timeframe.
5. Each login attempt triggers an MFA request to the legitimate user's device (phone, authenticator app, etc.).
6. The user is bombarded with MFA push notifications or prompts, leading to "MFA fatigue."
7. The user, either accidentally or intentionally, approves one of the MFA requests.
8. Attacker successfully authenticates and gains unauthorized access to the GCP account.

Impact

Successful MFA bypass can lead to complete account takeover, allowing the attacker to access sensitive data, modify configurations, escalate privileges, and potentially deploy malicious workloads within the GCP environment. Depending on the compromised account's permissions, the attacker could gain control over critical infrastructure, leading to data breaches, service disruptions, or financial losses. Previous MFA fatigue attacks have resulted in significant compromises, including access to government and business systems.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect multiple failed MFA requests (see rules).
• Review and tune the threshold and time window in the Sigma rule based on your organization's baseline MFA behavior (see rules).
• Investigate any alerts generated by the Sigma rule to determine the legitimacy of the failed MFA attempts.
• Enforce stricter MFA policies, such as requiring number matching or hardware security keys, to mitigate MFA fatigue attacks.
• Educate users about MFA fatigue attacks and the importance of carefully reviewing MFA requests.
• Consider implementing adaptive authentication measures that analyze login behavior and block suspicious requests.