Welcome to the Google Cloud Security Forums! Your ultimate security conversation spot. Collaborate with peers and experts to solve challenges, together.
Recently active
Hey Google Cloud Security Community!Whether you are a security engineer building custom parsers, a SOC analyst hunting threats, or a security leader keeping up with rapid product releases, staying ahead of the threat landscape requires continuous learning.To help you stay sharp, informed, and ahead of the curve, we are thrilled to introduce a brand-new, centralized section in our community: The Weekly Brief! 🎯 What is "The Weekly Brief"? The Weekly Brief is your structured, one-stop resource for technical guidance, product updates, and expert strategies across Google Security Operations (SecOps) and Google Threat Intelligence.Instead of searching multiple documentation pages or release notes, you can tune in every week to get highly actionable, bite-sized updates directly from Google security experts and community leaders.The Weekly Brief is organized into three specialized pillars: 📢 What's New in SecOpsYour weekly briefing on everything evolving across the Google SecOps ecosystem.
Hey folks, As Microsoft is deprecating the Microsoft Sentinel portal and transitions into Unified XDR platform by March 30th 2027, we want to proactively announce that some of the connectors will be considered deprecated on the same date.Additionally, we reviewed existing connectors and observed that there are multiple connectors that are solving the same use case. As part of this initiative, we want to consolidate and also deprecate redundant connectors to offer better supportability. The following connectors will be considered deprecated on March 30th 2027:Microsoft Azure Sentinel Incident Connector v2 (Microsoft Sentinel) Microsoft Sentinel Incident Tracking Connector (Microsoft Sentinel) Microsoft Defender ATP Connector V2 (Microsoft Defender for Endpoint) Microsoft Defender ATP Connector (Microsoft Defender for Endpoint) Microsoft Graph Security Connector (Microsoft Graph Security) Microsoft Graph Office 365 Security and Compliance Connector (Microsoft Graph Security)What is
I wanted to share the workflow we’ve been using to connect Chronicle detection rules with SOAR (Gemini) playbooks, specifically focusing on how rule design directly drives playbook effectiveness.The key idea is:The rule is not just a trigger — it is responsible for providing all the context the playbook needs to make a decision.1. Rule as the Context EngineInstead of relying on the playbook to “figure things out,” we push as much structure and meaning as possible into the rule itself.Each rule is responsible for:Identifying the behavior Normalizing key fields Providing investigation-ready context via the outcome sectionBy the time the alert reaches the playbook, it should already answer:What happened? Who did it? On what system? Why is it suspicious?2. Outcome Section as the ContractThe outcome section acts as a contract between the detection rule and the playbook.We standardize outcomes across rules so every playbook receives consistent inputs.Core pattern we use:$outcomeUserIsTechnic
Financial institutions face an ongoing battle against card fraud and credential leaks. A common challenge for security teams is identifying when Bank Identification Numbers (BINs) are leaked across underground channels. To address this, Google Threat Intelligence (GTI) provides advanced, real-time dark web search capabilities to gain direct visibility into illicit communication networks.This article details how to leverage GTI’s advanced dark web search capabilities to automate BIN leak monitoring, transitioning from manual searching to a scalable, automated pipeline. Harnessing Modern Dark Web Search Capabilities Google Threat Intelligence indexes underground communication platforms dynamically, allowing security teams to query massive volumes of raw dark web data using precise, granular filters. For a deeper understanding of these capabilities, you can review the Google Threat Intelligence Dark Web Guide.By interacting with these capabilities via the API, analysts can continuously sc
📣 New Feature Alert: Generate Threat Profile Recommendations directly from Splunk Events! 📣 With our latest release, you can now seamlessly map threat associations from IOC matches in Splunk directly into your Google Threat Intelligence (GTI) Threat Profiles! What’s New?By leveraging the Google Threat Intelligence for Splunk app, your administrators can automatically synchronize observed threats—straight from your Splunk Adversary Intelligence dashboard into your chosen GTI Threat Profile.Key Highlights: 🎯 Accurate & Noise-Free: The integration only sends automatically correlated data. Manual SPL query investigations are excluded to ensure your Threat Profile remains highly relevant and actionable. 🛡️ Comprehensive Coverage: Automatically sync specific threat association types including Threat Actors, Malware Families, Software Toolkits, and Campaigns. 🏷️ Clear Visualization & Filtering: Synchronized collections automatically populate in Google TI with "Observed" and "
Hey folks,As you know, managing credentials in Google SecOps can be quite tedious. To address this, we released a new integration called “Secret Manager”. The purpose of this integration is to allow you to automatically manage all of the credentials associated with Response Integrations, Connectors and Jobs from 1 place. How it works?Inside the integration, there is a job called “Sync Integration Credential Job”. This job is responsible for the synchronization of credentials.As part of the job, you will need to provide a configuration JSON that will map the Google SecOps content to Secret Manager entries.AuthenticationJust like all other Google Cloud integrations, this integration supports authentication via Workload Identity and Service Account key. You will need to assign “Secret Manager Secret Accessor” Role.Note: for situations, where you have identity created in Project A, but your Secret Manager credentials are located in Project B, you should use parameter Project ID, which wil
On April 2, 2026, reCAPTCHA will transition from a Data Controller to a Data Processor, offering customers greater control over their users' personal data. With this switch, customers deploying reCAPTCHA on their websites will become data controllers, while Google will become a data processor. To learn more, check out our blog.
Building true operational resilience requires moving faster than the threats you face. That starts with understanding exactly how adversaries are finding success, so you can use that intelligence to stop them.Today, we are proud to announce the release of the M-Trends 2026 report! Distilling insights from over 500k hours of incident investigations executed by Mandiant in 2025, and supporting Google Threat Intelligence Group (GTIG) research, this year’s edition reveals the critical shifts defining today's threat landscape. This post provides a quick preview of the themes from this year's report. Download the M-Trends 2026 report now for a comprehensive dive into our frontline data, and review the supporting resources below for more. The collapse of the "hand-off" window One of the most notable trends identified in Mandiant investigations is the increased specialization within the cybercrime ecosystem. In 2022, the median time between an initial access event and the hand-off to a seconda
Hello Everyone,As we realized, the impact of the React Vulnerability is very critical among your workloads. The React vulnerability, CVE-2025-55182, has a CVSS score of 10 and is being actively exploited. Customers need to be aware if their organization is impacted with this CVE. Google has created a pre-defined security graph rule for SCC Enterprise and Premium customers that will generate an "Issue" if your GKE workloads or Compute instances are externally exposed and vulnerable. You can view these alerts in the "Issues" queue within your environment.A sample representation of how this Issue appears in your SCC console is shown below, with the associated Findings for the vulnerability displayed within the Issue.If you are an SCC Premium or Enterprise customer, you can use Graph Search to check if your organization is impacted with this vulnerability. You can also use reachability context in Graph Search to prioritize remediation among impacted workloads with the CVE and focus on tho
Hi everyone,We are working on integrating Google SecOps SOAR with an external application security platform, and wanted to validate our approach as well as explore better alternatives.Use Case1. Incident Sync (Bi-directional)Sync status and comments: From SecOps SOAR → external platform From external platform → SecOps SOAR Current ApproachUsing a scheduled job (polling) to: Fetch updates from both systems Compare changes Push updates accordingly QuestionsArchitecture Validation Is a polling-based approach considered acceptable for this use case? Or is any other approach recommended? Webhook Capabilities in SecOps SOAR Are there limitations on which fields can be mapped via webhook? Is it possible to map custom fields (status, comments, metadata)? Is there any reference for the list of fields. Comments / Notes Mapping In SecOps SOAR alerts, which field is best suited to store external comments/notes? Is there a recommended standard field (e.g., notes, activity log)?
I have few questions about submission process for the SecOps SIEM custom integration:Can I publish my SecOps SIEM custom integration in Content Hub? It is containing these componants: Ingestion Script Dashboard Detection Rules Search Queries Is there any public repository to submit these componants or any of them as part of content hub?
Getting error while publishing Terraform Kubernetes App. on GCP marketplace.{ "taskReports": [ { "taskType": "EXECUTE_TERRAFORM_PLAN", "taskExecutionStatus": "ISSUES_FOUND", "digest": "Failed to execute terraform plan for some versions.", "errorMessage": "Error validating Terraform zip: Marketplace UI deployments must declare a variable 'goog_cm_deployment_name'. This variable specifies the name of the deployment, and should be used to avoid resource name collisions across deployments\n" } ]}Possible solutions I have tried:I have changed variable.tf file to include variable:variable "goog_cm_deployment_name" { description = "Name of the Google Cloud Marketplace deployment. Auto-populated by the Marketplace UI." type = string}Added below in metadata.yaml file:interfaces: variables: # ---- GCP / cluster --------------------------------------------------- - name: goog_cm_deployment_name description: The name of the deployment.
Since we can now change the deployment state of individual curated rules, I expected to read (GET) the same information using one of the following endpoints:https://docs.cloud.google.com/chronicle/docs/reference/rest/v1alpha/projects.locations.instances.rules.deployments/list - this returns deployment state for custom rules only; https://docs.cloud.google.com/chronicle/docs/reference/rest/v1alpha/projects.locations.instances.rules/getDeployment - this returns 404s when tried on curated rule IDs.Any guidance on how to GET there? 😁
I am getting below error while validating my terraform kubernetes app. Can any on ehelm what is the issue?{ "taskReports": [ { "taskType": "EXECUTE_TERRAFORM_PLAN", "taskExecutionStatus": "ISSUES_FOUND", "digest": "Unable to start verification.", "errorMessage": "Failed to process container images from schema file: Unexpected response.\nHeaders:\nHTTP/1.1 400 Bad Request\r\nContent-Type: application/json; charset=utf-8\r\ndocker-distribution-api-version: registry/2.0\r\nServer: Docker Registry\r\nVary: Accept-Encoding\r\nX-Content-Type-Options: nosniff\r\nX-Frame-Options: SAMEORIGIN\r\nx-gcr-using-artifact-registry: true\r\nx-google-artifactregistry-docker-imageref: us-docker.pkg.dev/cloud-launcher-images-prd/gcr.io/crestdata-public/test-app/test-app:1.0\r\nx-google-gfe-cloud-project-number: 720804119614\r\nX-Google-GFE-Backend-Request-Cost: 48.89476869076971\r\nX-Google-Security-Signals: FRAMEWORK=GOA\r\nX-Google-Security-Signals: ACTION=GOA_ACTION,ENV=borg,ENV
Hi Fraud Defense team, Starting 2026-07-17 (zero occurrences before that date), legitimate desktopChrome 150 users on our site began receiving very low reCAPTCHA Enterprisescores (0.1-0.3) with reason code UNEXPECTED_ENVIRONMENT on our sign-inaction, blocking them from logging in. Tokens are fully valid and the actionmatches the expected action -- only the risk score collapsed. Setup: web score-based site key (v3-style), server-side assessments via thereCAPTCHA Enterprise API. Users are mostly in Taiwan on residential ISPs. Evidence that this is browser-version-specific(rejected vs. allowed-with-low-score counts, same site key and threshold,last 2 days):- Chrome 150 desktop: 306 rejected / 22 allowed- Chrome 149 desktop: 2 rejected / 23 allowed- Edge (Chromium 150): 1 rejected / 4 allowed Daily rejected count for Chrome 150: 0 (before Jul 17) -> 98 (Jul 17) ->113 (Jul 18) -> 180 (Jul 19), still rising. Chrome 150 had already beenrolled out for about two weeks before Jul 17, so
Hello,My Google Cloud project has been suspended due to a security issue (ACCOUNT_HIJACKED).I fully understand the situation and I am ready to take all necessary actions to secure the project. However, I currently do not have access to the project anymore, which prevents me from revoking the compromised API keys or applying the required fixes.As a precaution, I have already stopped billing to prevent any further charges.At the moment, my application is completely down, which is having a severe impact on my business. My clients cannot access the service, and I am receiving increasing complaints and refund requests.I already have an open support case: 70327888This situation is becoming critical, and I would greatly appreciate any help to restore access or guidance on how I can proceed to secure the project.Thank you very much in advance for your support.Vincent
Project id: project-5580276092549813950My project got suspended 5. april, due to misuse of some keys.I have filed an appeal, taking actions on how to prevent this from happening again. But I do not get any response at all.Now observing users are dropping off, users not able to sign on, complaining. It is very devastating to observe, years of developing an app for dog owners. It is very critical. Actions Taken:• Removed exposed API keys from all repositories and application code• Ensured that no API keys or credentials are publicly accessible• Reviewed all Git repositories and verified that sensitive credentials are no longer present• Updated development practices to prevent API keys from being embedded in client-side applications• Planned migration of all Gemini API requests from client-side usage to a secure backend service• Implemented safeguards to ensure that future API usage is authenticated and controlled• Preparing to rotate all API keys and service account credentials immediat
According to the Google SecOps documentation, an outcome variable from a child detection rule can be accessed in a composite rule using a path such as:e.g. detection.detection.outcomes["dest_domain"]Link :- https://docs.cloud.google.com/chronicle/docs/yara-l/composite-detection-rules#reference_detection_content_with_variables_or_meta_labelsHowever, when I use this field in a YARA-L composite rule, I receive the following warning:outcomes field is deprecated and might not populate as expected.I have not been able to find an alternative field or updated syntax in the documentation.My requirement is to pass a variable that is calculated only in the child rule’s outcome section and use it in the parent composite rule.
Target Technology Watchlists are now in Public Preview for GTI customers. This capability allows you to easily track relevant intelligence based on your specific technology stack, driving focus to the threats that truly matter most.Key Benefits:Flexible Inputs: Simply drop a list of technologies or CPEs into your threat scenario to immediately get vulnerability intelligence alerts through the alert section in the org profile. Customizable Alerts:Receive notifications specifically for CVEs affecting the organization's tech stack. Rich Vulnerability Details: Every alert is enriched with full exploit context, including assigned priority, vulnerability Risk Rating, real-world Exploitation State, and more. Intelligence Context: Leverage direct integration with GTI vulnerability intelligence for full exploit context. Unified View & API Access: Access a unified alerts stream, fully available via API for programmatic and agentic workflows.For more information, please refer to the documenta
I'm currently testing an application hosted on Google Cloud, and I'm running into a security validation issue that I can't explain. The OAuth consent screen has been configured, the authorized redirect URIs are correct, and all required scopes have been reviewed. However, every time I attempt the validation process, it reports a generic security validation failure without identifying which specific requirement is not being met.I have already verified that the domain ownership is confirmed through Search Console, HTTPS is properly configured with a valid SSL certificate, and the privacy policy and terms pages are publicly accessible. I've also tested the application using different Google accounts and browsers, cleared caches, and even recreated the OAuth credentials, but the validation result remains the same.Has anyone experienced a similar issue where the security validation fails even though the project appears to meet all documented requirements? I'm mainly looking for guidance on
I’m trying to write a rule that checks the value of the “network.dns.questions.name” field, but will only trigger if the value is NOT in a data table using regex matching instead of a static value.Assuming I have a data table named dns_tunnel_list with below values:domain_names <« column headerexample.invaliddoes-not-exist.example.comgoogleapis.commetadata.google.internal I cannot seem to get right a UDM search query that will ignore values from the above table with a query like below, for example: metadata.log_type = "GCP_DNS"metadata.event_type = "NETWORK_DNS"not network.dns.questions.name in regex %dns_tunnel_list.domain_names Similarly, for a rule such as below:rule LOG_SECOPS_005_dns_newly_seen_domain_v2 { meta: (snip) version = "1.0" events: $dns.metadata.log_type = "GCP_DNS" $dns.metadata.event_type = "NETWORK_DNS" $querying_ip = $dns.principal.ip $query_name = $dns.network.dns.questions.name not $query_name in regex %dns_tunnel_list.domai
Hello,I'm parsing Qumulo JSON audit logs in Google SecOps and I'm able to successfully extract top-level and nested fields such as:{"operation": "fs_write_metadata","details": {"file_id": "9283XXXXXXXXXX329","path": "/smb/underwritingscan/Windows (C) - Shortcut.lnk","before": {"ctime": "2026-07-16T16:06:05.106082716Z"},"after": {"ctime": "2026-07-16T17:56:43.431152651Z"}}}-- Using statedump, I can confirm the parser is exposing: details.before.ctimedetails.after.ctime--- and temporary test fields are populated:before_ctime_test = 2026-07-16T16:06:05.106082716Zafter_ctime_test = 2026-07-16T17:56:43.431152651Z------Current UDM mappings work successfully for:principal.user.useridprincipal.iptarget.file.full_pathmetadata.product_log_idmetadata.product_event_type------- My goal is to expose the following fields in UDM for dashboarding:details.before.ctimedetails.after.ctimedetails.before.mtimedetails.after.mtime------I attempted to use:event.idm.read_only_udm.additional.fields---but receive
Hi all,We operate multiple Google SecOps instances and use the managed remote MCP server (chronicle.<region>.rep.googleapis.com/mcp, negotiated protocol version 2025-11-25) from an AI agent. On one specific instance, every SOAR-backed tool fails, while the same tools work fine on our other instance. This is not agent-specific — it reproduces with direct, bare MCP tool calls (minimal arguments, no LLM involved).Symptom — on the affected instance, with only customerId / projectId / region / pageSize: 1:tool: list_cases→ isError: true, "Internal error encountered."Same result with/without filter ("Status='OPENED'") and orderBy — all argument variants fail identically.Side-by-side (identical bare calls on both instances): What we've ruled out:1. Caller permissions — the same service account runs all SIEM tools successfully on the affected instance, so MCP authorization passes. And when we deliberately call with an SA that lacks access, we get an explicit PERMISSION_DENIED with a tr
VHR20260722 - July 22, 2026The Mandiant Intelligence Validation Research Team (VRT) has published VHR20260722 - Content Expansion. This content pack requires Director version 4.12.1.0-0 or higher.If you’ve enabled the Content Service, this content pack will automatically download and be applied to your Director. Otherwise, you can download the security content pack from the Mandiant Documentation Portal.Summary of Changes109 Actions added 88 Files addedRelease HighlightsA new Action covering Campaign 26-069, an initial access campaign by actor UNC6910 leveraging social engineering lures and delivering CURLYGATE, CURLYFENCE, and NEONSLIDE malware. A new Action covering Campaign 26-014, involving North Korea-nexus threat actor UNC5342 deploying Python backdoors such as JADESNOW and INVISIBLEFERRET.JAVASCRIPT to target GitHub repositories for unauthorized code modification. New Actions demonstrating Campaign 26-068, a campaign by UNC6468 using recipe-themed executables to deliver PINESAP
Hi,I have created a data table by the following steps 1.Create data table then i have entered the name 2.Import file → CSV file was uploaded 3.Configure Columns -→ primary key was set While i am referencing the column in Rule it is not working.This was in the data table I have added the below line. It was not taking the column field . not ($e.target.resource.attribute.labels["res_metadata_namespace"] in %test1.namespace )namespace gke-managed-cim gke-managed-networking-dra-driver gke-managed-system gke-managed-volumepopulator
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
