{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","favicon":"https://feed.craftedsignal.io/favicon-32x32.png","feed_url":"https://feed.craftedsignal.io/products/google-cloud-platform/feed.json","home_page_url":"https://feed.craftedsignal.io/","icon":"https://feed.craftedsignal.io/apple-touch-icon.png","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Cloud Platform"],"_cs_severities":["medium"],"_cs_tags":["persistence","privilege-escalation","cloud-security","gcp"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eAdversaries with sufficient GCP administrative privileges can establish durable, key-less persistence by granting themselves or an attacker-controlled principal specific IAM roles on a target service account. The roles \u003ccode\u003eroles/iam.serviceAccountTokenCreator\u003c/code\u003e, \u003ccode\u003eroles/iam.serviceAccountUser\u003c/code\u003e, and \u003ccode\u003eroles/iam.serviceAccountOpenIdTokenCreator\u003c/code\u003e allow a principal to mint OAuth2 access tokens, generate OpenID Connect identity tokens, or attach (actAs) the target service account to new cloud resources. Because these roles leverage GCP's native IAM trust relationship rather than long-lived static service account keys, the resulting access is unaffected by traditional credential rotation or password reset procedures. This technique is commonly used to pivot from a compromised low-privileged identity to a higher-privileged service account with broader project or organization-level permissions. Defenders should monitor for unexpected \u003ccode\u003eSetIamPolicy\u003c/code\u003e operations, particularly when the principal performing the grant has not historically performed such actions.\u003c/p\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy detection rules to monitor \u003ccode\u003eSetIamPolicy\u003c/code\u003e operations that add impersonation roles to service accounts.\u003c/li\u003e\n\u003cli\u003eBaseline administrative and CI/CD service accounts (such as Terraform or Jenkins) that legitimately perform IAM modifications to reduce false positives.\u003c/li\u003e\n\u003cli\u003eRestrict the ability to set IAM policies on service accounts and implement a peer-review or justification-based approval process for IAM changes.\u003c/li\u003e\n\u003cli\u003eReview existing IAM bindings for unauthorized principals or external accounts that have been granted impersonation rights.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-08-11T23:43:05Z","date_published":"2026-08-11T23:43:05Z","id":"https://feed.craftedsignal.io/briefs/2026-08-gcp-sa-impersonation/","summary":"Adversaries can gain unauthorized access to Google Cloud Platform environments by granting themselves service account impersonation roles, enabling long-term persistence and privilege escalation that survives credential rotation.","title":"GCP Service Account Impersonation Role Grant Detection","url":"https://feed.craftedsignal.io/briefs/2026-08-gcp-sa-impersonation/"},{"_cs_actors":[],"_cs_cpes":["cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:*"],"_cs_cves":[{"cvss":9.6,"id":"CVE-2026-15899"},{"cvss":9.6,"id":"CVE-2026-15901"},{"cvss":8.8,"id":"CVE-2026-16423"},{"cvss":8.8,"id":"CVE-2026-15904"},{"cvss":8.8,"id":"CVE-2026-15902"}],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["golang.org/x/crypto/ssh (\u003c 0.52.0)","golang.org/x/crypto/ssh \u003c 0.52.0","golang.org/x/crypto/ssh/agent \u003c 0.52.0","golang.org/x/image (\u003c 0.41.0)","Chrome","Brave","Opera","Vivaldi","Microsoft Edge","Google Chrome","Brave Browser","Mozilla Firefox","Splunk Enterprise","Splunk Enterprise Security","Splunk Cloud","Opera Browser","Vivaldi Browser","Edge","Firefox","Chromium","Google Workspace","Google Drive","Google Docs","Google Sheets","Google Forms","Google Apps Script","Google Workspace Marketplace","Google Workspace Drive","GCP","Google Kubernetes Engine","GKE","GCP Audit Logs","Kubernetes API","Kubernetes","Google Cloud Platform","Google Kubernetes Engine (GKE)","Google Cloud Platform (GCP) Audit Logs","Android (\u003c= 2026-07-06)","Dialogflow CX \u003c= 2026-06-30","Cloud Run \u003c= 2026-06-30","Chrome (\u003c 150.0.7871.114)","Chrome (\u003c 150.0.7871.115)","Google Chrome (for Windows and macOS \u003c 150.0.7871.115)","Google Chrome (for Linux \u003c 150.0.7871.114)","Google Cloud Platform (BigQuery)","Google Cloud Platform (Dataform)","Google Cloud Platform (Colab Enterprise)","Helm","CoreDNS","kube-dns","Google Cloud Platform IAM Custom Roles","Service Account","Android (4.2.2 through December 2023 patch)","OPPO A5 (CPH1931/CPH1943, Android 9, last patched ~2022)","Cloud Run","Google Cloud Platform (GCP)","kube-controller-manager","Google OAuth","Apps Script","Kubernetes API (TokenRequest)","Kubernetes API Server","Kubernetes Kubelet API","CertificateSigningRequest (CSR)","GCP Fleet integration","Kubernetes Engine","Google Ads Sync Accounts (MMC)","google.golang.org/grpc (\u003c 1.82.1)","Chrome (\u003c 150.0.7871.181)","Chrome (\u003c 150.0.7871.182)","Cloudflare Workers","Twilio TURN","Google Chrome (\u003c 150.0.7871.186)","Google Chrome (\u003c 150.0.7871.187)","Chrome for Desktop (\u003c 150.0.7871.186/.187 for Windows/Mac, \u003c 150.0.7871.186 for Linux)","Chrome (\u003c 151.0.7922.72)"],"_cs_severities":["high"],"_cs_tags":["roundup"],"_cs_type":"advisory","_cs_vendors":["Google","Red Hat","Brave Software","Opera","Vivaldi Technologies","Microsoft","Mozilla","Splunk","Opera Software","Elastic","Kubernetes","OPPO","Cloudflare","Twilio"],"content_html":"\u003cp\u003eAggregated Google security advisories for July 2026. CVEs from this cycle are folded\ninto the list below as they are published.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cp\u003eReview affected products and apply Google's July 2026 security updates.\u003c/p\u003e\n","date_modified":"2026-07-31T15:31:32Z","date_published":"2026-07-03T10:41:13Z","id":"https://feed.craftedsignal.io/briefs/2026-07-google-security-updates/","summary":"Roundup of Google security advisories published in July 2026.","title":"Google Security Updates — July 2026","url":"https://feed.craftedsignal.io/briefs/2026-07-google-security-updates/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Cloud Platform"],"_cs_severities":["low"],"_cs_tags":["gcp","cloud","exfiltration","defense_evasion"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis detection identifies modifications to Logging sinks within Google Cloud Platform (GCP). Logging sinks are a mechanism to export copies of log entries to destinations like Cloud Storage buckets, BigQuery datasets, or Pub/Sub topics. An attacker might modify a sink's configuration to redirect logs to a destination under their control for exfiltration, or to disable logging entirely to evade detection. This activity is identified by monitoring GCP audit logs for \u003ccode\u003eUpdateSink\u003c/code\u003e events. The rule is triggered by successful sink modifications. This matters because it can lead to data breaches or hide malicious activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn 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.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing Logging sinks using the \u003ccode\u003egcloud logging sinks list\u003c/code\u003e command or the Cloud Logging API to identify a suitable target.\u003c/li\u003e\n\u003cli\u003eThe 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 \u003ccode\u003egcloud logging sinks update\u003c/code\u003e command or the Cloud Logging API.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eOnce the sink is updated, logs matching the sink's filter are now routed to the attacker-controlled destination.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses the exfiltrated logs from their destination, potentially revealing sensitive information.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker modifies the logging sink to disable it entirely, preventing security teams from detecting malicious activity.\u003c/li\u003e\n\u003cli\u003eThe attacker covers their tracks by deleting or modifying audit logs related to the sink modification, if possible.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;GCP Logging Sink Modification\u0026quot; to your SIEM and tune for your environment. This rule detects modifications to Logging sinks (rule).\u003c/li\u003e\n\u003cli\u003eReview the event details for the specific \u003ccode\u003eevent.action\u003c/code\u003e field value \u003ccode\u003egoogle.logging.v*.ConfigServiceV*.UpdateSink\u003c/code\u003e to confirm the type of modification made to the logging sink.\u003c/li\u003e\n\u003cli\u003eImplement additional monitoring and alerting for changes to logging sink configurations to detect similar unauthorized modifications in the future (content).\u003c/li\u003e\n\u003cli\u003eReview 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).\u003c/li\u003e\n\u003cli\u003eReference the MITRE ATT\u0026amp;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).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-30T12:00:00Z","date_published":"2024-01-30T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-30-gcp-logging-sink-modification/","summary":"Modification of a Google Cloud Platform (GCP) Logging sink is detected, potentially indicating an adversary's attempt to exfiltrate logs to an unauthorized destination or impair defenses by disabling or modifying cloud logs.","title":"GCP Logging Sink Modification for Exfiltration or Defense Evasion","url":"https://feed.craftedsignal.io/briefs/2024-01-30-gcp-logging-sink-modification/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Cloud Platform","Google Cloud Storage"],"_cs_severities":["medium"],"_cs_tags":["cloud","gcp","impact"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis threat brief focuses on the malicious deletion of Google Cloud Platform (GCP) storage buckets. Threat actors may target these buckets to disrupt business operations by removing critical data. The detection rule monitors GCP audit logs for bucket deletion events. This activity can lead to significant data loss and service disruption, impacting an organization's ability to function normally. The alert is triggered by the \u003ccode\u003estorage.buckets.delete\u003c/code\u003e event action within the GCP audit logs. Successful exploitation of this technique could result in prolonged downtime and financial losses.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains unauthorized access to the target's GCP environment, potentially through compromised credentials or a misconfigured IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing storage buckets within the GCP project to identify targets for deletion.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003egcloud storage buckets delete\u003c/code\u003e command or the GCP console to initiate the deletion of a specific storage bucket.\u003c/li\u003e\n\u003cli\u003eGCP logs the \u003ccode\u003estorage.buckets.delete\u003c/code\u003e event in the audit logs, capturing details such as the user account, IP address, and timestamp of the deletion.\u003c/li\u003e\n\u003cli\u003eThe targeted storage bucket and its contents are permanently removed from the GCP environment.\u003c/li\u003e\n\u003cli\u003eThe victim organization experiences data loss and potential service disruption due to the unavailability of the deleted data.\u003c/li\u003e\n\u003cli\u003eThe attacker may repeat this process to delete multiple storage buckets, exacerbating the impact and hindering recovery efforts.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGCP Storage Bucket Deletion\u003c/code\u003e to your SIEM to detect unauthorized bucket deletions.\u003c/li\u003e\n\u003cli\u003eReview IAM policies and enforce the principle of least privilege to limit the potential impact of compromised credentials.\u003c/li\u003e\n\u003cli\u003eEnable versioning on critical storage buckets to facilitate recovery from accidental or malicious deletions (reference: [https://cloud.google.com/storage/docs/key-terms#buckets]).\u003c/li\u003e\n\u003cli\u003eSet up alerts for any future deletion actions on storage buckets to ensure immediate awareness and response to similar threats.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the user account, IP address, and timestamp associated with the deletion event.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-29T12:00:00Z","date_published":"2024-01-29T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-gcp-bucket-delete/","summary":"An adversary may delete a Google Cloud Platform (GCP) storage bucket to disrupt business operations, detected via GCP audit logs.","title":"GCP Storage Bucket Deletion for Impact","url":"https://feed.craftedsignal.io/briefs/2024-01-gcp-bucket-delete/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Cloud Platform","Google Cloud Logging"],"_cs_severities":["medium"],"_cs_tags":["gcp","logging","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis threat brief focuses on the detection of a specific defense evasion technique in Google Cloud Platform (GCP): the deletion of Logging sinks. GCP Logging sinks are configured to export log entries to various destinations for analysis and storage. Attackers might delete these sinks to disrupt logging and monitoring, effectively evading detection. The behavior is detected by monitoring GCP audit logs for successful sink deletion events. The deletion action is performed using the Google Cloud Logging API. This activity is of concern to defenders because it directly impacts their ability to identify and respond to malicious activity within their GCP environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to a GCP account with sufficient privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing Logging sinks within the target GCP project using \u003ccode\u003egcloud logging sinks list\u003c/code\u003e or the Cloud Logging API.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a sink to delete, focusing on those critical for security monitoring.\u003c/li\u003e\n\u003cli\u003eThe attacker executes a \u003ccode\u003egcloud logging sinks delete [SINK_NAME]\u003c/code\u003e command or uses the Cloud Logging API to delete the target sink.\u003c/li\u003e\n\u003cli\u003eGCP audit logs record the \u003ccode\u003egoogle.logging.v*.ConfigServiceV*.DeleteSink\u003c/code\u003e event with an \u003ccode\u003eevent.outcome:success\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eLog entries that would have been exported to the sink's destination are no longer processed, leading to a gap in security monitoring.\u003c/li\u003e\n\u003cli\u003eThe attacker performs other malicious actions within the GCP environment, knowing that their activity is less likely to be detected due to the disabled logging.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGCP Logging Sink Deletion\u003c/code\u003e to your SIEM and tune for your environment to detect sink deletion events.\u003c/li\u003e\n\u003cli\u003eReview the audit logs for the specific event.action \u003ccode\u003egoogle.logging.v*.ConfigServiceV*.DeleteSink\u003c/code\u003e to identify the user or service account responsible for the deletion.\u003c/li\u003e\n\u003cli\u003eImplement 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-26T12:00:00Z","date_published":"2024-01-26T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-26-gcp-logging-sink-deletion/","summary":"Detection of Google Cloud Platform (GCP) Logging sink deletion, a technique used by adversaries to impair defenses and evade detection by preventing log entries from being exported to designated destinations.","title":"GCP Logging Sink Deletion for Defense Evasion","url":"https://feed.craftedsignal.io/briefs/2024-01-26-gcp-logging-sink-deletion/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Amazon Web Services","Azure","Google Cloud Platform"],"_cs_severities":["medium"],"_cs_tags":["cloud","compute-instance","image-compromise"],"_cs_type":"advisory","_cs_vendors":["Amazon","Microsoft","Google"],"content_html":"\u003cp\u003eThis alert focuses on detecting the creation of cloud compute instances using previously unseen images within a cloud environment. The use of a new or unknown image could signal various malicious activities, including unauthorized deployment of resources, use of compromised images containing malware, or attempts to bypass security controls. While the provided content does not specify a threat actor, a successful attack involving a rogue image can lead to significant data breaches, resource hijacking, and operational disruption. It is crucial for defenders to identify and investigate such instances promptly to prevent further damage. The scope of this alert is applicable to any cloud environment that supports compute instance creation from images.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to a cloud account or obtains valid credentials via credential stuffing or phishing.\u003c/li\u003e\n\u003cli\u003eThe attacker uploads a malicious or compromised image to the cloud environment's image repository or leverages a publicly available, but malicious image.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the cloud provider's API or management console to initiate the creation of a new compute instance.\u003c/li\u003e\n\u003cli\u003eDuring instance creation, the attacker specifies the previously unseen image as the source image for the new instance.\u003c/li\u003e\n\u003cli\u003eThe cloud provider provisions the new compute instance using the specified image.\u003c/li\u003e\n\u003cli\u003eThe attacker connects to the newly created instance and executes malicious code or uses it for lateral movement within the cloud environment.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits resources within the compromised instance to steal sensitive data or compromise other cloud resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement the provided Sigma rule \u003ccode\u003eCloud Instance Created with Unseen Image\u003c/code\u003e 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.\u003c/li\u003e\n\u003cli\u003eEnable 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).\u003c/li\u003e\n\u003cli\u003eImplement strict image vetting procedures, including regular scanning for vulnerabilities and malware, to reduce the risk of deploying compromised images.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-25T12:00:00Z","date_published":"2024-01-25T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-25-cloud-instance-unseen-image/","summary":"A cloud compute instance was created with a previously unseen image, potentially indicating malicious activity such as unauthorized deployment or image compromise.","title":"Cloud Compute Instance Created with Previously Unseen Image","url":"https://feed.craftedsignal.io/briefs/2024-01-25-cloud-instance-unseen-image/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Cloud Platform"],"_cs_severities":["medium"],"_cs_tags":["gcp","cloud","defense_evasion"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis threat brief focuses on the deletion of logging buckets within Google Cloud Platform (GCP). Log buckets are central to storing and organizing log data within GCP. An attacker may intentionally delete these buckets to disrupt incident response, forensics investigations, and overall security monitoring. The deletion of a bucket results in a pending state for seven days, during which logs continue to be routed to the bucket. To completely stop log routing, associated log sinks must also be deleted or modified. This activity matters to defenders as it represents a direct attempt to blind security teams by removing valuable audit data, increasing the dwell time of malicious activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains unauthorized access to a GCP account through compromised credentials or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing logging buckets to identify potential targets for deletion.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to delete a logging bucket using the \u003ccode\u003egoogle.logging.v*.ConfigServiceV*.DeleteBucket\u003c/code\u003e API call.\u003c/li\u003e\n\u003cli\u003eThe GCP audit logs record the bucket deletion attempt.\u003c/li\u003e\n\u003cli\u003eIf successful, the logging bucket enters a pending deletion state for seven days.\u003c/li\u003e\n\u003cli\u003eTo fully eliminate logs, the attacker identifies log sinks associated with the deleted bucket.\u003c/li\u003e\n\u003cli\u003eThe attacker deletes or modifies these log sinks to prevent further log routing to the affected bucket.\u003c/li\u003e\n\u003cli\u003eThe attacker successfully impairs the organization's ability to detect and respond to malicious activity by removing crucial log data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGCP Logging Bucket Deletion\u003c/code\u003e to your SIEM to detect malicious bucket deletion attempts (rule provided below).\u003c/li\u003e\n\u003cli\u003eReview IAM permissions and roles to ensure that only authorized personnel have the ability to delete log buckets, reducing the risk of unauthorized deletions.\u003c/li\u003e\n\u003cli\u003eImplement additional logging and monitoring for any changes to log sinks and bucket configurations to detect and respond to similar activities promptly.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the \u003ccode\u003eGCP Logging Bucket Deletion\u003c/code\u003e Sigma rule, focusing on unauthorized user accounts or suspicious source IP addresses.\u003c/li\u003e\n\u003cli\u003eCreate exceptions for known maintenance periods or specific user accounts responsible for routine bucket deletions as described in the rule's false positives section.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-11T10:00:00Z","date_published":"2024-01-11T10:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-11-gcp-logging-bucket-deletion/","summary":"Detection of a Google Cloud Platform (GCP) logging bucket deletion, which can be used by adversaries to impair defenses and evade detection by removing or modifying cloud logs.","title":"GCP Logging Bucket Deletion for Defense Evasion","url":"https://feed.craftedsignal.io/briefs/2024-01-11-gcp-logging-bucket-deletion/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Cloud Platform","Google Workspace"],"_cs_severities":["high"],"_cs_tags":["gcp","cloud","authentication","account-takeover"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis analytic detects successful single-factor authentication attempts against Google Cloud Platform (GCP) accounts where multi-factor authentication (MFA) is not enabled. This detection is based on Google Workspace login event data and identifies instances where MFA is not utilized during account login. The lack of MFA can stem from misconfigurations, policy violations, or successful credential compromise. The successful exploitation of this gap by an attacker can provide initial access to GCP resources, potentially leading to data breaches, service disruptions, or further lateral movement within the cloud environment. This activity should be investigated promptly to ensure appropriate security policies are enforced and potentially compromised accounts are remediated.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Compromise:\u003c/strong\u003e An attacker obtains valid credentials through phishing, credential stuffing, or purchasing leaked credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker uses the compromised credentials to attempt login to a Google Workspace account associated with a GCP tenant.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSingle-Factor Authentication:\u003c/strong\u003e The attacker successfully authenticates using only a username and password because MFA is not enabled or enforced for the target account.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eGCP Access:\u003c/strong\u003e Upon successful authentication, the attacker gains access to the Google Cloud Platform (GCP) resources associated with the compromised account.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (Optional):\u003c/strong\u003e Depending on the compromised account's permissions, the attacker may attempt to escalate privileges within the GCP environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement (Optional):\u003c/strong\u003e The attacker uses the initial access to move laterally within the GCP environment, accessing other resources and accounts.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration / Service Disruption:\u003c/strong\u003e The attacker exfiltrates sensitive data from GCP storage or disrupts critical services within the GCP environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence (Optional):\u003c/strong\u003e The attacker establishes persistence mechanisms to maintain access to the GCP environment, such as creating new accounts or modifying existing roles.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGCP Successful Single-Factor Authentication\u003c/code\u003e to your SIEM and tune for your environment to detect logins without MFA based on Google Workspace logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the \u003ccode\u003eGCP Successful Single-Factor Authentication\u003c/code\u003e rule, prioritizing accounts with elevated privileges or access to sensitive data.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) for all Google Workspace accounts, especially those with access to GCP resources, as per Google's recommendations in the references.\u003c/li\u003e\n\u003cli\u003eRegularly audit Google Workspace and GCP configurations to ensure that MFA policies are properly configured and enforced.\u003c/li\u003e\n\u003cli\u003eUse the drilldown searches included in this brief to investigate users triggering the initial detection.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T12:00:00Z","date_published":"2024-01-09T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-09-gcp-single-factor-auth/","summary":"Detection of successful single-factor authentication against Google Cloud Platform (GCP) for an account without Multi-Factor Authentication (MFA) enabled, potentially leading to account compromise and unauthorized access to GCP resources.","title":"GCP Account Compromise via Single-Factor Authentication","url":"https://feed.craftedsignal.io/briefs/2024-01-09-gcp-single-factor-auth/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Cloud Platform"],"_cs_severities":["medium"],"_cs_tags":["gcp","cloud","iam","impact"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis alert identifies when a service account is disabled within Google Cloud Platform (GCP). Service accounts are non-human accounts utilized by applications and virtual machines for authorized API calls. An attacker compromising an account with sufficient privileges may disable a service account to disrupt services, impacting business operations. The rule focuses on detecting successful disablement actions in GCP audit logs, specifically targeting the \u003ccode\u003egoogle.iam.admin.v*.DisableServiceAccount\u003c/code\u003e event. This detection enables security teams to promptly investigate and respond to potentially malicious activity. The alert logic covers all Google Cloud Platform environments.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to a GCP account with sufficient IAM privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing service accounts within the targeted GCP project.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a service account critical to business operations.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003egoogle.iam.admin.v*.DisableServiceAccount\u003c/code\u003e API call to disable the target service account.\u003c/li\u003e\n\u003cli\u003eGCP audit logs record the successful disablement of the service account with \u003ccode\u003eevent.outcome:success\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eApplications or VMs relying on the disabled service account experience service disruptions or failures.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to further exploit the disruption to escalate privileges or conduct lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eDisabling 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;GCP Service Account Disabled\u0026quot; to your SIEM to detect this activity in real-time, and tune for your environment.\u003c/li\u003e\n\u003cli\u003eReview the GCP audit logs for the specific event \u003ccode\u003eevent.action:google.iam.admin.v*.DisableServiceAccount\u003c/code\u003e to identify the source of the disablement action.\u003c/li\u003e\n\u003cli\u003eImplement additional monitoring and alerting for similar disablement actions on service accounts to detect and respond to future incidents promptly.\u003c/li\u003e\n\u003cli\u003eEnsure that the principle of least privilege is applied to all service accounts, and enforce MFA for privileged accounts.\u003c/li\u003e\n\u003cli\u003eMonitor GCP audit logs for anomalous activity related to IAM roles and permissions.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-04T12:00:00Z","date_published":"2024-01-04T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-04-gcp-service-account-disabled/","summary":"Detection of a Google Cloud Platform (GCP) service account being disabled, potentially indicating malicious activity aimed at disrupting business operations by an adversary.","title":"GCP Service Account Disabled","url":"https://feed.craftedsignal.io/briefs/2024-01-04-gcp-service-account-disabled/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["AWS","Google Cloud Platform","Microsoft Azure"],"_cs_severities":["high"],"_cs_tags":["cloud","security_group","anomaly","aws"],"_cs_type":"advisory","_cs_vendors":["Amazon","Google","Microsoft"],"content_html":"\u003cp\u003eThis detection identifies anomalous modifications to cloud security groups by users within a 30-minute timeframe. It focuses on actions such as modifications, deletions, and creations of security groups, analyzing cloud infrastructure logs to detect deviations from normal behavior. The analytic calculates the standard deviation of security group changes per user, employing a 3-sigma rule to identify outliers. This activity is significant because unauthorized or malicious alterations to security groups can expose sensitive resources or disrupt critical services. The original Splunk ES content was published in 2026-04-17T11:58:53Z. This may indicate a compromised account, insider threat, or privilege escalation attempts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a cloud environment through compromised credentials or an insider threat (T1578.005).\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing cloud security groups to identify potential targets for modification.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies security group rules to allow unauthorized access to internal resources or services.\u003c/li\u003e\n\u003cli\u003eThe attacker creates new security groups with overly permissive rules, bypassing existing security controls.\u003c/li\u003e\n\u003cli\u003eThe attacker deletes existing security groups, disrupting network segmentation and potentially causing service outages.\u003c/li\u003e\n\u003cli\u003eThese actions are performed repeatedly within a short time frame (30 minutes), significantly deviating from the user's baseline activity.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits the newly opened access to exfiltrate sensitive data or deploy malicious workloads.\u003c/li\u003e\n\u003cli\u003eThe ultimate objective is to compromise sensitive resources, disrupt services, or establish a persistent foothold within the cloud environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnsure 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.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eCloud Security Group Modifications by User\u003c/code\u003e to your SIEM to detect anomalous security group modifications (logsource: AWS CloudTrail).\u003c/li\u003e\n\u003cli\u003eTune the threshold and time window of the Sigma rule based on your environment's baseline activity to reduce false positives. Consider adjusting the \u003ccode\u003eupperBound\u003c/code\u003e calculation in the search query.\u003c/li\u003e\n\u003cli\u003eInvestigate 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.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts to mitigate the risk of compromised credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-03-cloud-security-group-modifications/","summary":"This analytic identifies unusual modifications to cloud security groups by users, such as modifications, deletions, or creations, analyzed over 30-minute intervals, potentially indicating compromised accounts or insider threats leading to resource exposure or service disruption.","title":"Unusual Cloud Security Group Modifications by User","url":"https://feed.craftedsignal.io/briefs/2024-01-03-cloud-security-group-modifications/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Cloud Platform"],"_cs_severities":["low"],"_cs_tags":["cloud","gcp","persistence","account-manipulation"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis rule detects the creation of new keys for service accounts within Google Cloud Platform (GCP). Service accounts are non-human accounts used by applications and virtual machines to make authorized API calls. While legitimate key creation is a common administrative task, malicious actors may create new keys to gain unauthorized access and persist within a GCP environment. Successful exploitation allows an attacker to leverage the permissions associated with the service account, potentially leading to data exfiltration, resource manipulation, or further lateral movement. The detection focuses on monitoring GCP audit logs for key creation events.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a GCP environment through compromised credentials or a vulnerable service.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing service accounts to identify targets with desirable permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create a new key for a chosen service account using the \u003ccode\u003egoogle.iam.admin.v*.CreateServiceAccountKey\u003c/code\u003e API.\u003c/li\u003e\n\u003cli\u003eThe key creation is successful, granting the attacker access to the service account.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the new key to authenticate as the service account.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the service account's permissions to access sensitive data or resources within GCP.\u003c/li\u003e\n\u003cli\u003eThe attacker may create additional keys for redundancy and persistence.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains long-term access to the compromised GCP environment, potentially causing significant damage.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;GCP Service Account Key Creation\u0026quot; to your SIEM and tune for your environment to detect suspicious key creation activity in GCP.\u003c/li\u003e\n\u003cli\u003eReview the audit logs for the specific event.action \u003ccode\u003egoogle.iam.admin.v*.CreateServiceAccountKey\u003c/code\u003e to identify the service account involved in the key creation.\u003c/li\u003e\n\u003cli\u003eImplement 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 \u0026quot;Setup\u0026quot; section).\u003c/li\u003e\n\u003cli\u003eRotate all keys associated with the affected service account if unauthorized access is suspected to mitigate further risk (as mentioned in the \u0026quot;Response and remediation\u0026quot; section).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-03-gcp-service-account-key-creation/","summary":"An adversary may create a new key for a service account in Google Cloud Platform (GCP) to abuse the permissions assigned to that account and evade detection, potentially leading to persistent access.","title":"GCP Service Account Key Creation for Persistence","url":"https://feed.craftedsignal.io/briefs/2024-01-03-gcp-service-account-key-creation/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Cloud Platform"],"_cs_severities":["medium"],"_cs_tags":["gcp","iam","impact"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis alert detects the deletion of service accounts within Google Cloud Platform (GCP). Service accounts are non-human identities used by applications and virtual machines to interact with GCP services. An attacker may delete these accounts to disrupt legitimate applications, severing their access to critical resources and services. Monitoring for this activity is essential because while legitimate administrative actions can lead to service account deletion, unauthorized or malicious deletions can have significant operational impact. This detection focuses on successful \u003ccode\u003egoogle.iam.admin.v*.DeleteServiceAccount\u003c/code\u003e events within GCP audit logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains unauthorized access to a GCP account, potentially through compromised credentials or exploiting a misconfigured IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing service accounts within the GCP project to identify potential targets for disruption.\u003c/li\u003e\n\u003cli\u003eThe attacker selects a target service account based on its perceived importance or impact on the target organization's operations.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003egoogle.iam.admin.v*.DeleteServiceAccount\u003c/code\u003e API call via the gcloud CLI or GCP console.\u003c/li\u003e\n\u003cli\u003eGCP successfully processes the delete request and removes the service account identity.\u003c/li\u003e\n\u003cli\u003eApplications and VMs relying on the deleted service account lose access to authorized GCP services.\u003c/li\u003e\n\u003cli\u003eThe target organization experiences disruption in services, leading to potential data loss, operational downtime, or financial repercussions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGCP Service Account Deletion Detected\u003c/code\u003e to your SIEM and tune for your environment to detect malicious deletions.\u003c/li\u003e\n\u003cli\u003eReview the audit logs for the specific \u003ccode\u003eevent.action:google.iam.admin.v*.DeleteServiceAccount\u003c/code\u003e to identify the exact time and source of the deletion.\u003c/li\u003e\n\u003cli\u003eInvestigate the context of the deleted service account, including its permissions and the resources it had access to.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-03-gcp-service-account-deletion/","summary":"Detection of Google Cloud Platform (GCP) service account deletion, which adversaries may perform to disrupt business operations.","title":"GCP Service Account Deletion","url":"https://feed.craftedsignal.io/briefs/2024-01-03-gcp-service-account-deletion/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Cloud Platform","Google Workspace"],"_cs_severities":["medium"],"_cs_tags":["gcp","cloud","mfa","credential-access"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis analytic identifies failed authentication attempts during Multi-Factor Authentication (MFA) challenges within a Google Cloud Platform (GCP) environment. It leverages Google Workspace login failure events to detect instances where MFA methods were challenged but not successfully completed. The detection is based on Google Workspace login failure events where MFA methods were challenged. This activity could signify an adversary attempting to gain unauthorized access to an account using compromised credentials, even with MFA enabled. Successful exploitation could lead to data breaches, resource hijacking, or other malicious activities within the targeted GCP environment. The Splunk Add-on for Google Workspace (app ID 5556) is required for data ingestion.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker obtains valid or partially valid credentials through phishing (T1566), credential stuffing, or purchasing them from the dark web.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to log in to a GCP account using the obtained credentials (T1078.004).\u003c/li\u003e\n\u003cli\u003eGCP's login process identifies the need for MFA and issues a login challenge using a configured method.\u003c/li\u003e\n\u003cli\u003eThe attacker fails to complete the MFA challenge, indicating they do not possess the correct MFA token or cannot respond correctly (T1621).\u003c/li\u003e\n\u003cli\u003eMultiple failed MFA attempts may occur from the same IP address or user account.\u003c/li\u003e\n\u003cli\u003eIf the attacker eventually succeeds in bypassing MFA (e.g., through a vulnerability or social engineering), they gain unauthorized access to the GCP environment.\u003c/li\u003e\n\u003cli\u003eOnce inside, the attacker can perform reconnaissance, escalate privileges, and access sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates data or deploys malicious resources within the GCP environment, causing damage or disruption.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGCP Authentication Failed During MFA Challenge\u003c/code\u003e to your SIEM and tune the threshold based on your environment's baseline for failed MFA attempts.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the \u003ccode\u003eGCP Authentication Failed During MFA Challenge\u003c/code\u003e rule to determine if the failed MFA attempts are legitimate or indicative of malicious activity.\u003c/li\u003e\n\u003cli\u003eMonitor login events for unusual patterns, such as multiple failed MFA attempts from the same IP address or user account.\u003c/li\u003e\n\u003cli\u003eEnsure all users have strong, unique passwords and are enrolled in MFA.\u003c/li\u003e\n\u003cli\u003eReview and enforce Conditional Access policies to restrict access based on location, device, and other factors.\u003c/li\u003e\n\u003cli\u003eInstall the latest version of Splunk Add-on for Google Workspace from Splunkbase (\u003ca href=\"https://splunkbase.splunk.com/app/5556\"\u003ehttps://splunkbase.splunk.com/app/5556\u003c/a\u003e) to collect the required Google Workspace login events.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-gcp-failed-mfa/","summary":"Detection of failed MFA challenges in Google Cloud Platform (GCP) using Google Workspace login failure events, potentially indicating credential compromise and unauthorized access attempts.","title":"GCP Authentication Failure During MFA Challenge","url":"https://feed.craftedsignal.io/briefs/2024-01-gcp-failed-mfa/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Cloud Platform"],"_cs_severities":["medium"],"_cs_tags":["gcp","iam","custom-role","initial-access","persistence","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis threat brief focuses on the detection of IAM custom role creation within Google Cloud Platform (GCP). IAM custom roles are user-defined roles that bundle one or more supported permissions, allowing for tailored access management. While legitimate use cases exist, adversaries can exploit this feature by creating roles with excessive permissions, potentially leading to privilege escalation or persistence. This activity can be used to maintain unauthorized access and control within the GCP environment. Defenders should monitor for anomalous role creation activity, especially roles with broad or unusual permission sets, as these could signal malicious intent. The rule is designed to work with GCP Fleet integration, Filebeat module, or similarly structured data.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a GCP account, possibly through compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the GCP environment using valid credentials (T1078).\u003c/li\u003e\n\u003cli\u003eThe attacker explores existing IAM roles and permissions to identify potential escalation paths.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a custom IAM role with overly permissive privileges (T1098, T1098.003), granting themselves access to critical resources.\u003c/li\u003e\n\u003cli\u003eThe attacker creates the custom IAM role using the \u003ccode\u003egoogle.iam.admin.v*.CreateRole\u003c/code\u003e API call.\u003c/li\u003e\n\u003cli\u003eThe event is logged as a successful operation (\u003ccode\u003eevent.outcome:success\u003c/code\u003e) in the GCP audit logs.\u003c/li\u003e\n\u003cli\u003eThe attacker assigns the newly created custom role to a compromised or attacker-controlled user or service account.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the escalated privileges to access sensitive data, modify configurations, or deploy malicious workloads, achieving persistence or further compromising the environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rules to your SIEM to detect suspicious IAM custom role creation events in GCP (logsource: gcp.audit).\u003c/li\u003e\n\u003cli\u003eReview and audit existing IAM roles and permissions regularly to identify and remediate overly permissive configurations.\u003c/li\u003e\n\u003cli\u003eImplement the principle of least privilege when assigning permissions to IAM roles, both built-in and custom.\u003c/li\u003e\n\u003cli\u003eMonitor GCP audit logs for \u003ccode\u003egoogle.iam.admin.v*.CreateRole\u003c/code\u003e events and investigate any unexpected or unauthorized role creation activity.\u003c/li\u003e\n\u003cli\u003eEnsure that only authorized personnel have the necessary permissions to create custom IAM roles, and implement controls to prevent unauthorized role creation.\u003c/li\u003e\n\u003cli\u003eEstablish a baseline of expected role creation activity and investigate any deviations from this baseline.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T15:00:00Z","date_published":"2024-01-02T15:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-gcp-iam-custom-role-creation/","summary":"Detection of Identity and Access Management (IAM) custom role creation in Google Cloud Platform (GCP), which can indicate potential privilege escalation or persistence by adversaries creating roles with excessive permissions.","title":"GCP IAM Custom Role Creation","url":"https://feed.craftedsignal.io/briefs/2024-01-gcp-iam-custom-role-creation/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Cloud Platform"],"_cs_severities":["low"],"_cs_tags":["cloud","gcp","persistence","iam"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThe creation of service accounts in Google Cloud Platform (GCP) is a common administrative task, but can be abused by attackers to maintain persistence. Service accounts are non-human accounts used by applications or VMs to make authorized API calls. Attackers may create service accounts to perform actions within a compromised GCP environment without relying on compromised user credentials, making their activities harder to track. The \u003ccode\u003egoogle.iam.admin.v*.CreateServiceAccount\u003c/code\u003e event indicates the creation of a new service account. Defenders should monitor for unexpected service account creation events, as they can signify unauthorized access or persistence mechanisms within a cloud environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a GCP environment, possibly through compromised credentials or a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing IAM roles and permissions to identify potential escalation paths.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create a new service account using the \u003ccode\u003egoogle.iam.admin.v*.CreateServiceAccount\u003c/code\u003e API call.\u003c/li\u003e\n\u003cli\u003eThe attacker assigns elevated privileges to the newly created service account, granting it broad access to GCP resources.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the service account to perform actions within the GCP environment, such as accessing data or modifying configurations.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the service account for persistence, allowing them to regain access even if their initial access method is revoked.\u003c/li\u003e\n\u003cli\u003eThe attacker monitors the service account activity to ensure it maintains its privileges and has not been detected.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to unauthorized access to sensitive data, modification of critical system configurations, or disruption of services. Even though rated as \u0026quot;low\u0026quot; severity, successful exploitation could allow attackers to maintain a persistent presence within the GCP environment, potentially leading to significant data breaches or service outages.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGCP Service Account Created\u003c/code\u003e to your SIEM and tune for your environment to detect unexpected service account creation.\u003c/li\u003e\n\u003cli\u003eReview IAM policies and permissions regularly to identify and remove any excessive privileges granted to service accounts.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, including service accounts where possible, to prevent unauthorized access.\u003c/li\u003e\n\u003cli\u003eMonitor GCP audit logs for suspicious activity related to service account creation and usage, using the \u003ccode\u003eevent.action:google.iam.admin.v*.CreateServiceAccount\u003c/code\u003e filter.\u003c/li\u003e\n\u003cli\u003eImplement automated workflows to validate and approve service account creation requests to ensure proper authorization and governance.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-02-gcp-service-account-creation/","summary":"Successful creation of a new service account in Google Cloud Platform (GCP) can indicate malicious persistence, as adversaries may create these accounts to evade detection by avoiding standard user accounts.","title":"GCP Service Account Creation for Persistence","url":"https://feed.craftedsignal.io/briefs/2024-01-02-gcp-service-account-creation/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Cloud Platform","Google Workspace"],"_cs_severities":["high"],"_cs_tags":["cloud","gcp","mfa","persistence","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis brief focuses on detecting the disabling of multi-factor authentication (MFA) within a Google Cloud Platform (GCP) environment. The activity is detected by monitoring Google Workspace Admin logs for the \u003ccode\u003eUNENROLL_USER_FROM_STRONG_AUTH\u003c/code\u003e command. An attacker who has compromised an account may disable MFA to maintain persistent access without triggering typical account compromise alerts. This allows them to bypass an important security control. This activity has been observed in GCP environments and is critical for defenders to monitor. Successful exploitation can lead to unauthorized access, data exfiltration, or further malicious activity within the organization.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a valid user account through credential compromise (e.g., phishing, password spraying).\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Google Workspace Admin console using the compromised account.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the user management section within the Google Workspace Admin console.\u003c/li\u003e\n\u003cli\u003eThe attacker locates the target user account for which they intend to disable MFA.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates the process to unenroll the target user from strong authentication, triggering the \u003ccode\u003eUNENROLL_USER_FROM_STRONG_AUTH\u003c/code\u003e command.\u003c/li\u003e\n\u003cli\u003eThe system processes the request, disabling MFA for the target user account.\u003c/li\u003e\n\u003cli\u003eThe attacker now maintains persistent access to the compromised account without MFA.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised account to perform unauthorized actions, such as accessing sensitive data, modifying configurations, or launching further attacks.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect GCP MFA Disable via GWS Admin Logs\u003c/code\u003e to your SIEM to identify instances of MFA being disabled.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the \u003ccode\u003euser\u003c/code\u003e and \u003ccode\u003eactor.email\u003c/code\u003e fields to determine the source and target of the action.\u003c/li\u003e\n\u003cli\u003eImplement 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).\u003c/li\u003e\n\u003cli\u003eReview and enforce strong MFA policies across your organization to minimize the attack surface (reference: \u003ca href=\"https://support.google.com/cloudidentity/answer/2537800?hl=en)\"\u003ehttps://support.google.com/cloudidentity/answer/2537800?hl=en)\u003c/a\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-gcp-mfa-disable/","summary":"Detection of disabled multi-factor authentication (MFA) for a Google Cloud Platform (GCP) user, potentially leading to unauthorized access and data exfiltration.","title":"GCP Multi-Factor Authentication Disabled","url":"https://feed.craftedsignal.io/briefs/2024-01-gcp-mfa-disable/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Cloud Platform"],"_cs_severities":["low"],"_cs_tags":["cloud","gcp","iam","persistence","impact"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis alert identifies the deletion of an Identity and Access Management (IAM) service account key within Google Cloud Platform (GCP). Each service account relies on a pair of public/private RSA keys for authentication. Deleting a key prevents associated applications from accessing Google Cloud resources. While regular key rotation is a security best practice, unauthorized or unexpected key deletions can indicate malicious activity, such as attempts to disrupt services or conceal unauthorized access. This detection focuses on successful key deletions as logged in GCP audit logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to a GCP account through compromised credentials or a misconfigured IAM policy.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing service accounts to identify potential targets for disruption or privilege escalation.\u003c/li\u003e\n\u003cli\u003eThe attacker selects a service account with the intent to disrupt dependent applications or services.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003egoogle.iam.admin.v*.DeleteServiceAccountKey\u003c/code\u003e API call to delete the key associated with the targeted service account.\u003c/li\u003e\n\u003cli\u003eThe GCP audit logs record a successful deletion event (\u003ccode\u003eevent.outcome: success\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eLegitimate applications or services that rely on the deleted service account key fail to authenticate, leading to service disruption.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to further compromise the environment or exfiltrate data, taking advantage of the chaos and confusion caused by the disruption.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGCP IAM Service Account Key Deletion\u003c/code\u003e to your SIEM to detect unauthorized key deletions.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the \u003ccode\u003eGCP IAM Service Account Key Deletion\u003c/code\u003e Sigma rule, paying close attention to the actor, affected service account, and context of the deletion event.\u003c/li\u003e\n\u003cli\u003eReview IAM policies and service account permissions to minimize the blast radius of compromised service accounts.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) for all GCP user accounts to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eImplement regular service account key rotation policies and monitor for deviations from established baselines.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-gcp-iam-key-deletion/","summary":"Detection of Identity and Access Management (IAM) service account key deletion in Google Cloud Platform (GCP), potentially indicating malicious activity such as disrupting services or covering tracks after unauthorized access.","title":"GCP IAM Service Account Key Deletion","url":"https://feed.craftedsignal.io/briefs/2024-01-gcp-iam-key-deletion/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Cloud Platform","Google Cloud VPC","Google App Engine"],"_cs_severities":["medium"],"_cs_tags":["cloud","defense-evasion","gcp"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis detection identifies when a firewall rule is deleted in Google Cloud Platform (GCP) for Virtual Private Cloud (VPC) or App Engine. Firewall rules are critical for controlling network traffic to and from virtual machine (VM) instances or specific applications. An adversary may delete a firewall rule to weaken a target's security controls, facilitating unauthorized access or data exfiltration. This behavior can be indicative of a defense evasion attempt. The deletion events are captured in audit logs within GCP, which are then monitored for specific actions related to firewall rule deletion in either VPC or App Engine environments.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a GCP account, potentially through compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing firewall rules within the VPC or App Engine environment to identify potential targets for deletion.\u003c/li\u003e\n\u003cli\u003eUsing compromised credentials or a service account, the attacker initiates the deletion of a specific firewall rule. The \u003ccode\u003egcloud\u003c/code\u003e CLI or GCP console could be used.\u003c/li\u003e\n\u003cli\u003eThe firewall rule is removed, altering the network access control configuration.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the modified firewall configuration to establish unauthorized connections to internal resources.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the GCP environment, accessing sensitive data or systems previously protected by the deleted firewall rule.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates data or performs other malicious activities, taking advantage of the weakened security posture.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGCP Firewall Rule Deletion\u003c/code\u003e to your SIEM to detect unauthorized firewall deletions based on \u003ccode\u003edata_stream.dataset:gcp.audit and event.action:(*.compute.firewalls.delete or google.appengine.*.Firewall.Delete*Rule)\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eEnable GCP audit logging to ensure that all firewall rule deletion events are captured for analysis.\u003c/li\u003e\n\u003cli\u003eReview and update access controls and permissions for users and service accounts to minimize the risk of unauthorized firewall rule modifications.\u003c/li\u003e\n\u003cli\u003eImplement enhanced monitoring and alerting for firewall rule changes to detect and respond to similar threats more quickly in the future, based on \u003ccode\u003eevent.action\u003c/code\u003e logs.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-gcp-firewall-deletion/","summary":"The deletion of firewall rules in Google Cloud Platform (GCP) for Virtual Private Cloud (VPC) or App Engine is detected, potentially weakening security controls and enabling unauthorized access or data exfiltration by adversaries.","title":"GCP Firewall Rule Deletion for Defense Evasion","url":"https://feed.craftedsignal.io/briefs/2024-01-gcp-firewall-deletion/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Cloud Platform","Google Cloud VPC","Google App Engine"],"_cs_severities":["low"],"_cs_tags":["gcp","firewall","defense_evasion"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis detection identifies the creation of firewall rules within Google Cloud Platform (GCP), specifically targeting Virtual Private Cloud (VPC) and App Engine environments. While firewall rules are legitimate components of network security, adversaries can exploit them to weaken existing defenses. By creating overly permissive rules, attackers can bypass security controls and establish unauthorized ingress or egress traffic flows. The focus is on detecting unexpected or suspicious firewall rule creation events that could indicate malicious activity. The original Elastic detection rule \u003ccode\u003e30562697-9859-4ae0-a8c5-dab45d664170\u003c/code\u003e published in 2020 and updated in 2026, helps security teams audit configuration changes and identify potential defense evasion attempts within their GCP environments. The scope includes both VPC and App Engine firewall configurations.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to a GCP account, potentially through compromised credentials or exploiting a misconfigured service account.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing firewall rules and network configurations to identify potential weaknesses.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a new firewall rule designed to allow unauthorized traffic, such as opening specific ports or IP ranges.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003egcloud\u003c/code\u003e command-line tool or the GCP console to create the new firewall rule, targeting either VPC or App Engine.\u003c/li\u003e\n\u003cli\u003eThe newly created firewall rule is activated, effectively modifying the network's security posture.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the permissive firewall rule to establish a command and control (C2) channel or exfiltrate sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the open port(s) to move laterally within the network.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective (data exfiltration, system compromise, etc.)\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGCP Firewall Rule Creation\u003c/code\u003e 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.\u003c/li\u003e\n\u003cli\u003eReview the audit logs for \u003ccode\u003eevent.dataset:gcp.audit\u003c/code\u003e entries, specifically focusing on the \u003ccode\u003eevent.action\u003c/code\u003e fields: \u003ccode\u003e*.compute.firewalls.insert\u003c/code\u003e or \u003ccode\u003egoogle.appengine.*.Firewall.Create*Rule\u003c/code\u003e to validate the source of firewall rule changes.\u003c/li\u003e\n\u003cli\u003eImplement 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.\u003c/li\u003e\n\u003cli\u003eEstablish a baseline of expected firewall rules and configurations to quickly identify deviations that could indicate malicious activity, using the provided references about GCP firewalls.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-02-gcp-firewall-rule-creation/","summary":"An adversary may create a new firewall rule in Google Cloud Platform (GCP) for Virtual Private Cloud (VPC) or App Engine to weaken their target's security controls and allow more permissive ingress or egress traffic flows for their benefit, indicating a defense evasion attempt.","title":"GCP Firewall Rule Creation for Defense Evasion","url":"https://feed.craftedsignal.io/briefs/2024-01-02-gcp-firewall-rule-creation/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Amazon Web Services","Microsoft Azure","Google Cloud Platform"],"_cs_severities":["medium"],"_cs_tags":["cloud","security-group","api-abuse"],"_cs_type":"advisory","_cs_vendors":["Amazon","Microsoft","Google"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting anomalous activity within cloud environments, specifically related to an abnormally high number of API calls targeting security groups. While no specific actor is named, this behavior is often associated with threat actors attempting to gain unauthorized access, enumerate resources, or modify security configurations for malicious purposes. The activity is detected through analysis of cloud provider logs, looking for significant deviations from baseline API call patterns related to security groups. The scope of targeting is broad, as any organization utilizing cloud infrastructure and security groups is potentially vulnerable. This detection is crucial because unauthorized modifications to security groups can lead to significant data breaches, service disruptions, and privilege escalation scenarios.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e An attacker gains initial access to a cloud account through compromised credentials or exploiting a misconfigured service.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker attempts to escalate privileges within the compromised account to gain broader access to cloud resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReconnaissance:\u003c/strong\u003e The attacker begins enumerating cloud resources, including security groups, to identify potential targets and vulnerabilities. This stage involves an increased volume of API calls.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSecurity Group Enumeration:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSecurity Group Modification:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker leverages the modified security groups to move laterally within the cloud environment, accessing previously restricted resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Resource Abuse:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker establishes persistent access by creating new accounts or modifying existing ones, ensuring continued access even if the initial vulnerability is patched.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromise 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;Cloud Security Group API Call Volume Anomaly\u0026quot; to your SIEM and tune the threshold based on your environment's baseline activity.\u003c/li\u003e\n\u003cli\u003eEnable 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.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all cloud accounts to mitigate the risk of credential compromise.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-cloud-security-group-api-abuse/","summary":"Detection of an abnormally high number of cloud security group API calls which can indicate malicious activity such as reconnaissance, privilege escalation, or lateral movement within a cloud environment.","title":"Abnormal Cloud Security Group API Call Activity","url":"https://feed.craftedsignal.io/briefs/2024-01-cloud-security-group-api-abuse/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Cloud Platform","Google Workspace"],"_cs_severities":["high"],"_cs_tags":["gcp","mfa","mfa-fatigue","credential-access"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis analytic focuses on identifying potential MFA fatigue attacks targeting Google Cloud Platform (GCP) users. The technique involves an attacker repeatedly sending MFA push notifications or other authentication requests to a victim, overwhelming them in the hope they will eventually approve a request, either accidentally or to stop the barrage. This attack is particularly effective against users who are not technically savvy or who are under pressure to quickly resolve issues. The detection logic triggers when a user experiences 10 or more failed MFA attempts within a 5-minute window, based on Google Workspace login failure events. This is a notable indicator of a potential compromise attempt, as legitimate users rarely fail MFA multiple times in such a short period. Identifying and responding to these events promptly is crucial to prevent unauthorized access and potential privilege escalation within the GCP environment. The activity aligns with observed techniques used by threat actors like LAPSUS$ and Russian government-backed groups.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker obtains a valid username and password through phishing, credential stuffing, or purchasing stolen credentials.\u003c/li\u003e\n\u003cli\u003eAttacker attempts to log in to a GCP service or application using the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe GCP environment prompts the user for MFA.\u003c/li\u003e\n\u003cli\u003eAttacker initiates a large number of login attempts within a short timeframe.\u003c/li\u003e\n\u003cli\u003eEach login attempt triggers an MFA request to the legitimate user's device (phone, authenticator app, etc.).\u003c/li\u003e\n\u003cli\u003eThe user is bombarded with MFA push notifications or prompts, leading to \u0026quot;MFA fatigue.\u0026quot;\u003c/li\u003e\n\u003cli\u003eThe user, either accidentally or intentionally, approves one of the MFA requests.\u003c/li\u003e\n\u003cli\u003eAttacker successfully authenticates and gains unauthorized access to the GCP account.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect multiple failed MFA requests (see \u003ccode\u003erules\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eReview and tune the threshold and time window in the Sigma rule based on your organization's baseline MFA behavior (see \u003ccode\u003erules\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine the legitimacy of the failed MFA attempts.\u003c/li\u003e\n\u003cli\u003eEnforce stricter MFA policies, such as requiring number matching or hardware security keys, to mitigate MFA fatigue attacks.\u003c/li\u003e\n\u003cli\u003eEducate users about MFA fatigue attacks and the importance of carefully reviewing MFA requests.\u003c/li\u003e\n\u003cli\u003eConsider implementing adaptive authentication measures that analyze login behavior and block suspicious requests.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T10:00:00Z","date_published":"2024-01-02T10:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-02-gcp-failed-mfa/","summary":"Detection of multiple failed multi-factor authentication (MFA) requests for a single user in Google Cloud Platform (GCP) within a short time window, potentially indicating an MFA fatigue attack attempting to bypass MFA and gain unauthorized access.","title":"GCP Multiple Failed MFA Requests Imply MFA Fatigue Attack","url":"https://feed.craftedsignal.io/briefs/2024-01-02-gcp-failed-mfa/"}],"language":"en","title":"CraftedSignal Threat Feed - Google Cloud Platform","version":"https://jsonfeed.org/version/1.1"}