This topic offers informal guidance to help you investigate and respond to threats, and use additional resources to add context to Security Command Center findings. Following these steps helps you understand what happened during a potential attack and develop possible responses for affected resources.
The techniques on this page are not guaranteed to be effective against any previous, current, or future threats you face. See Remediating threats to understand why Security Command Center does not provide official remediation guidance for threats.
Before you begin
You need adequate Identity and Access Management (IAM) roles to view or edit findings and logs, and modify Google Cloud resources. If you encounter access errors in Security Command Center, ask your administrator for assistance and see Access control to learn about roles. To resolve resource errors, read documentation for affected products.
Understanding threat findings
Event Threat Detection produces security findings by matching events in your Cloud Logging and Google Workspace log streams to known indicators of compromise (IoC). IoCs, developed by internal Google security sources, identify potential vulnerabilities and attacks. Event Threat Detection also detects threats by identifying known adversarial tactics, techniques, and procedures in your logging stream, and by detecting deviations from historically observed behavior of your organization.
Container Threat Detection generates findings by collecting and analyzing low-level observed behavior in the guest kernel of containers.
Findings are written to Security Command Center and Cloud Logging.
Reviewing findings
To review threat findings, do the following:
Legacy Findings page
In the Google Cloud console, go to the Security Command Center Findings page.
If necessary, select your Google Cloud project or organization.
On the Findings page, next to View by, click Source type.
Select Event Threat Detection or Container Threat Detection.
The table is populated with findings for the source you selected.
To view details for a specific finding, click the finding name under category in the table.
Findings page (Preview)
If you opted to upgrade to the Findings Workflow Improvements, follow these steps:
In the Google Cloud console, go to the Security Command Center Findings page.
If necessary, select your Google Cloud project or organization.
In the Quick filters section, in the Source display name subsection, select Event Threat Detection or Container Threat Detection.
The table is populated with findings for the source you selected.
To view details of a specific finding, click the finding name under
Category
. The finding details pane expands to display the finding's attributes.To view the finding's JSON definition, click the JSON tab.
Findings provide the names and numeric identifiers of resources involved in an incident, along with environment variables and asset properties. You can use that information to quickly isolate affected resources and determine the potential scope of an event.
To aid in your investigation, threat findings also contain links to the following external resources:
- MITRE ATT&CK framework entries. The framework explains techniques for attacks against cloud resources and provides remediation guidance.
- VirusTotal, an Alphabet-owned service that provides context on potentially malicious files, URLs, domains, and IP addresses.
The following sections outline potential responses to threat findings.
Event Threat Detection responses
To learn more about Event Threat Detection, see how Event Threat Detection works.
Evasion: Access from Anonymizing Proxy
Anomalous access from an anonymous proxy is detected by examining Cloud Audit Logs for Google Cloud service modifications that originated from anonymous proxy IP addresses, like Tor IP addresses.
To respond to these findings, do the following:
Step 1: Review finding details
- Open an
Evasion: Access from Anonymizing Proxy
finding, as directed in Reviewing findings. In the Finding Details pane, under Additional Information, click Source Properties and note the following fields.
principalEmail
: the account that made the changes (a potentially compromised account)Ip
: The proxy IP address where the changes are conducted from
Step 2: Research attack and response methods
- Review the MITRE ATT&CK framework entry for this finding type: Proxy: Multi-hop Proxy.
- Contact the owner of the account in the
principalEmail
field. Confirm whether the action was conducted by the legitimate owner. - To develop a response plan, combine your investigation results with MITRE research.
Defense Evasion: Modify VPC Service Control
Audit logs are examined to detect changes to VPC Service Controls perimeters that would lead to a reduction in the protection offered by that perimeter. The following are some examples:
- A project is removed from a perimeter
- An access level policy is added to an existing perimeter
- One or more services are added to the list of accessible services
To respond to this finding, do the following:
Step 1: Review finding details
- Open a
Defense Evasion: Modify VPC Service Control
finding, as directed in Reviewing findings. - In the Finding Details pane, under Additional Information, note the
following fields:
access.principalEmail
: the account that performed the modificationresource.name
: the name of the VPC Service Controls perimeter that was modified
In the Finding Details pane, under Additional Information, click Source Properties and note the following fields.
properties
name
: the name of the VPC Service Controls perimeter that was modifiedpolicyLink
: the link to the access policy that controls the perimeterdelta
: the changes, eitherREMOVE
orADD
, to a perimeter that reduced its protectionrestricted_resources
: the projects that follow the restrictions of this perimeter. Protection is reduced if you remove a projectrestricted_services
: the services that are forbidden from running by the restrictions of this perimeter. Protection is reduced if you remove a restricted serviceallowed_services
: the services that are allowed to run under this perimeter's restrictions. Protection is reduced if you add an allowed serviceaccess_levels
: the access levels that are configured to allow access to resources under the perimeter. Protection is reduced if you add more access levels
contextUris
: internal and external resources to add context to findingsmitreURI
: link to the MITRE ATT&CK framework entry for this finding typecloudLoggingQueryURI
: link to the Logging pagerelatedFindingURI
: link to related findings
Step 2: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in
cloudLoggingQueryURI
. - Find admin activity logs related to VPC Service Controls changes by using
the following filters:
protoPayload.methodName:"AccessContextManager.UpdateServicePerimeter"
protoPayload.methodName:"AccessContextManager.ReplaceServicePerimeters"
Step 3: Research attack and response methods
- Review the MITRE ATT&CK framework entry for this finding type: Defense Evasion: Modify Authentication Process.
- Review related findings by clicking the link in
relatedFindingURI
. - To develop a response plan, combine your investigation results with MITRE research.
Step 4: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the VPC Service Controls policy and perimeter.
- Consider reverting the changes for the perimeter until the investigation is completed.
- Consider revoking Access Context Manager roles on the principal that modified the perimeter until the investigation is completed.
- Investigate how the reduced protections have been used. For example, if "BigQuery Data Transfer Service API" is enabled, or added as allowed service, check who started using that service and what they are transferring.
Exfiltration: BigQuery Data Exfiltration
Data exfiltration from BigQuery is detected by examining audit logs for three scenarios:
- A resource is saved outside of your organization.
- VPC Service Controls blocks a copy operation.
- An attempt is made to access BigQuery resources that are protected by VPC Service Controls.
To respond to this finding, do the following:
Step 1: Review finding details
- Open an
Exfiltration: BigQuery Data Exfiltration
finding, as directed in Reviewing findings. In the Finding Details pane, on the Attributes tab, note the following fields.
exfiltration
sources
: details about the tables from which data was exfiltratedtargets
: details about the tables where exfiltrated data was stored
In the Finding Details pane, under Additional Information, click Source Properties and note the following fields.
properties
projectId
: the finding involves an asset in this projectjobLink
: the link to the BigQuery job that exfiltrated dataQuery
: the SQL query run on the BigQuery datasetuserEmail
: the account used to exfiltrate the data
contextUris
: internal and external resources to add context to findingsmitreURI
: link to the MITRE ATT&CK framework entry for this finding typecloudLoggingQueryURI
: link to the Logging pagerelatedFindingURI
: link to related findings
Step 2: Investigate in Chronicle
You can use Chronicle to investigate this finding. Chronicle is a Google Cloud service that lets you investigate threats and pivot through related entities in a unified timeline. Chronicle enriches findings data, letting you identify indicators of interest and simplify investigations.
Go to the Security Command Center Findings page in the Google Cloud console.
Next to View by, click Source Type.
In the Source type list, select Event Threat Detection.
The table populates with findings for the source type you selected.
In the table, under category, click on an
Exfiltration: BigQuery Data Exfiltration
finding.In the Finding Details pane, click Investigate in Chronicle.
Follow the instructions in Chronicle's guided user interface.
Use the following guides to conduct investigations in Chronicle:
Step 3: Review permissions and settings
In the Google Cloud console, go to the IAM page .
If necessary, select the project listed in
projectID
.On the page that appears, in the Filter box, enter the email address listed in
userEmail
and check what permissions are assigned to the account.
Step 4: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in
cloudLoggingQueryURI
. - Find admin activity logs related to BigQuery jobs by using
the following filters:
protoPayload.methodName="Jobservice.insert"
protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"
Step 5: Research attack and response methods
- Review the MITRE ATT&CK framework entry for this finding type: Exfiltration Over Web Service: Exfiltration to Cloud Storage.
- Review related findings by clicking the link in
relatedFindingURI
. Related findings are the same finding type on the same instance and network. - To develop a response plan, combine your investigation results with MITRE research.
Step 6: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project with exfiltrated data.
- Consider revoking permissions for
userEmail
until the investigation is completed. - To stop further exfiltration, add restrictive IAM policies to the impacted
BigQuery datasets (
exfiltration.sources
andexfiltration.targets
). - To scan impacted datasets for sensitive information, use Cloud Data Loss Prevention. You can also send Cloud DLP data to Security Command Center. Depending on the quantity of information, Cloud DLP costs can be significant. Follow best practices for keeping Cloud DLP costs under control.
- To limit access to the BigQuery API, use VPC Service Controls.
- To identify and fix overly permissive roles, use IAM Recommender.
Exfiltration: BigQuery Data Extraction
Data exfiltration from BigQuery is detected by examining audit logs for two scenarios:
- A resource is saved to a Cloud Storage bucket outside of your organization.
- A resource is saved to a publicly accessible Cloud Storage bucket owned by your organization.
To respond to this finding, do the following:
Step 1: Review finding details
- Open an
Exfiltration: BigQuery Data Extraction
finding, as directed in Reviewing findings. In the Finding Details pane, on the Attributes tab, note the following fields.
access.principalEmail
: the account used to exfiltrate the dataresource.name
: the name of the BigQuery resource whose data was exfiltratedresource.project_name
: the project containing the BigQuery data that was exfiltratedexfiltration
sources
: details about the BigQuery table from which data was exfiltratedtargets
: details about the Cloud Storage buckets where data was exported to
In the Finding Details pane, under Additional Information, click Source Properties and note the following fields.
properties
jobLink
: the link to the BigQuery job that exfiltrated data
contextUris
: internal and external resources to add context to findingsmitreURI
: link to the MITRE ATT&CK framework entry for this finding typecloudLoggingQueryURI
: link to the Logging pagerelatedFindingURI
: link to related findings
Step 2: Review permissions and settings
In the Google Cloud console, go to the IAM page .
If necessary, select the project listed in
resource.project_name
(from Step 1).On the page that appears, in the Filter box, enter the email address listed in
access.principalEmail
(from Step 1) and check what permissions are assigned to the account.
Step 3: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in
cloudLoggingQueryURI
. - Find admin activity logs related to BigQuery jobs by using
the following filters:
protoPayload.methodName="Jobservice.insert"
protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"
Step 4: Research attack and response methods
- Review the MITRE ATT&CK framework entry for this finding type: Exfiltration Over Web Service: Exfiltration to Cloud Storage.
- Review related findings by clicking the link in
relatedFindingURI
. Related findings are the same finding type on the same instance and network. - To develop a response plan, combine your investigation results with MITRE research.
Step 5: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project with exfiltrated data.
- Consider revoking permissions for the
principal in the
access.principalEmail
field until the investigation is completed. - To stop further exfiltration, add restrictive IAM policies to the impacted
BigQuery datasets (
exfiltration.sources
). - To scan impacted datasets for sensitive information, use Cloud Data Loss Prevention. You can also send Cloud DLP data to Security Command Center. Depending on the quantity of information, Cloud DLP costs can be significant. Follow best practices for keeping Cloud DLP costs under control.
- To limit access to the BigQuery API, use VPC Service Controls.
- If you are the owner of the bucket, consider revoking public access permissions.
- To identify and fix overly permissive roles, use IAM Recommender.
Exfiltration: BigQuery Data to Google Drive
Data exfiltration from BigQuery is detected by examining audit logs for the following scenario:
- A resource is saved to a Google Drive folder.
To respond to this finding, do the following:
Step 1: Review finding details
- Open an
Exfiltration: BigQuery Data to Google Drive
finding, as directed in Reviewing findings. In the Finding Details pane, under Additional Information, note the following fields.
access.principalEmail
: the account used to exfiltrate the dataresource.name
: the name of the BigQuery resource whose data was exfiltratedresource.project_name
: the project containing the BigQuery data that was exfiltratedexfiltration
sources
: details about the BigQuery table from which data was exfiltratedtargets
: details about the Google Drive files where data was exported to
In the Finding Details pane, under Additional Information, click Source Properties and note the following fields:
properties
jobLink
: the link to the BigQuery job that exfiltrated data
contextUris
: internal and external resources to add context to findingsmitreURI
: link to the MITRE ATT&CK framework entry for this finding typecloudLoggingQueryURI
: link to the Logging pagerelatedFindingURI
: link to related findings
Step 2: Review permissions and settings
In the Google Cloud console, go to the IAM page .
If necessary, select the project listed in
resource.project_name
(from Step 1).On the page that appears, in the Filter box, enter the email address listed in
access.principalEmail
(from Step 1) and check what permissions are assigned to the account.
Step 3: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in
cloudLoggingQueryURI
. - Find admin activity logs related to BigQuery jobs by using
the following filters:
protoPayload.methodName="Jobservice.insert"
protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"
Step 4: Research attack and response methods
- Review the MITRE ATT&CK framework entry for this finding type: Exfiltration Over Web Service: Exfiltration to Cloud Storage.
- Review related findings by clicking the link in
relatedFindingURI
. Related findings are the same finding type on the same instance and network. - To develop a response plan, combine your investigation results with MITRE research.
Step 5: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project with exfiltrated data.
- Consider revoking permissions for the
principal in the
access.principalEmail
field until the investigation is completed. - To stop further exfiltration, add restrictive IAM policies to the impacted
BigQuery datasets (
exfiltration.sources
). - To scan impacted datasets for sensitive information, use Cloud Data Loss Prevention. You can also send Cloud DLP data to Security Command Center. Depending on the quantity of information, Cloud DLP costs can be significant. Follow best practices for keeping Cloud DLP costs under control.
- To limit access to the BigQuery API, use VPC Service Controls.
- To identify and fix overly permissive roles, use IAM Recommender.
Exfiltration: Cloud SQL Data Exfiltration
Data exfiltration from Cloud SQL is detected by examining audit logs for two scenarios:
- Live instance data exported to a Cloud Storage bucket outside the organization.
- Live instance data exported to a Cloud Storage bucket that is owned by the organization and is publicly accessible.
To respond to this finding, do the following:
Step 1: Review finding details
- Open an
Exfiltration: Cloud SQL Data Exfiltration
finding, as directed in Reviewing findings. In the Finding Details pane, on the Attributes tab, note the following fields.
access.principalEmail
: the account used to exfiltrate the dataresource.name
: the resource name of the Cloud SQL whose data was exfiltratedresource.project_name
: the project containing the Cloud SQL instance the backup was created fromexfiltration
sources
: details about the Cloud SQL instance whose data was exfiltratedtargets
: details about the Cloud Storage bucket the data was exported to
In the Finding Details pane, under Additional Information, click Source Properties and note the following fields.
properties
bucketAccess
: whether the Cloud Storage bucket is publicly accessible or external to the organizationexportScope
: how much of the data was exported (the whole instance, one or more databases, one or more tables, or a subset specified by a query)
contextUris
: internal and external resources to add context to findingsmitreURI
: a link to the MITRE ATT&CK framework entry for this finding typecloudLoggingQueryURI
: link to the Logging pagerelatedFindingURI
: link to other Cloud SQL exfiltration findings for the same Cloud SQL instance
Step 2: Review permissions and settings
In the Google Cloud console, go to the IAM page .
If necessary, select the project of the instance listed in
resource.project_name
(from Step 1).On the page that appears, in the Filter box, enter the email address listed in
access.principalEmail
(from Step 1) and check what permissions are assigned to the account.
Step 3: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in
cloudLoggingQueryURI
(from Step 1). The Logs Explorer page includes all logs related to the relevant Cloud SQL instance.
Step 4: Research attack and response methods
- Review the MITRE ATT&CK framework entry for this finding type: Exfiltration Over Web Service: Exfiltration to Cloud Storage.
- Review related findings by clicking the link in
relatedFindingURI
(from Step 1). Related findings have the same finding type on the same Cloud SQL instance. - To develop a response plan, combine your investigation results with MITRE research.
Step 5: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project with exfiltrated data.
- Consider revoking permissions for
access.principalEmail
until the investigation is completed. - To stop further exfiltration, add restrictive IAM policies to the impacted Cloud SQL instances.
- To limit access to and export from the Cloud SQL Admin API, use VPC Service Controls.
- To identify and fix overly permissive roles, use IAM Recommender.
Exfiltration: Cloud SQL Restore Backup to External Organization
Data exfiltration from a Cloud SQL backup is detected by examining audit logs to determine whether data from the backup has been restored to a Cloud SQL instance outside the organization.
To respond to this finding, do the following:
Step 1: Review finding details
- Open an
Exfiltration: Cloud SQL Restore Backup to External Organization
finding, as directed in Reviewing findings. In the Finding Details pane, on the Attributes tab, note the following fields.
access.principalEmail
: the account used to exfiltrate the dataresource.name
: the resource name of the backup that was restoredresource.parent_name
: the resource name of the Cloud SQL instance the backup was created fromresource.project_name
: the project containing the Cloud SQL instance the backup was created fromexfiltration
sources
: details about the Cloud SQL instance the backup was created fromtargets
: details about the Cloud SQL instance the backup data was restored to
In the Finding Details pane, under Additional Information, click Source Properties and note the following fields:
properties/restoreToExternalInstance
backupId
: the ID of the backup run that was restored
contextUris
: internal and external resources to add context to findingsmitreURI
: a link to the MITRE ATT&CK framework entry for this finding typecloudLoggingQueryURI
: link to the Logging pagerelatedFindingURI
: link to other Cloud SQL exfiltration findings for the same Cloud SQL instance
Step 2: Review permissions and settings
In the Google Cloud console, go to the IAM page .
If necessary, select the project of the instance listed in
resource.project_name
(from Step 1).On the page that appears, in the Filter box, enter the email address listed in
access.principalEmail
(from Step 1) and check what permissions are assigned to the account.
Step 3: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in
cloudLoggingQueryURI
(from Step 1). The Logs Explorer page includes all logs related to the relevant Cloud SQL instance.
Step 4: Research attack and response methods
- Review the MITRE ATT&CK framework entry for this finding type: Exfiltration Over Web Service: Exfiltration to Cloud Storage.
- Review related findings by clicking the link in
relatedFindingURI
(from Step 1). Related findings have the same finding type on the same Cloud SQL instance. - To develop a response plan, combine your investigation results with MITRE research.
Step 5: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project with exfiltrated data.
- Consider revoking permissions for
access.principalEmail
until the investigation is completed. - To stop further exfiltration, add restrictive IAM policies to the impacted Cloud SQL instances.
- To limit access to the Cloud SQL Admin API, use VPC Service Controls.
- To identify and fix overly permissive roles, use IAM Recommender.
Brute Force: SSH
Detection of successful brute force of SSH on a host. To respond to this finding, do the following:
Step 1: Review finding details
- Open a
Brute Force: SSH
finding, as directed in Reviewing findings. In the Finding Details pane, under Additional Information, click Source Properties and note the following fields.
sourceLogId
: the project ID and timestamp to identify the log entryprojectId
: the project that contains the finding
Attempts
: the number of login attemptssourceIP
: the IP address that launched the attackusername
: the account that logged invmName
: the name of the virtual machineauthResult
: the SSH authentication result
contextUris
: internal and external resources to add context to findingsmitreURI
: link to the MITRE ATT&CK framework entry for this finding typecloudLoggingQueryURI
: link to the Logging pagerelatedFindingURI
: link to related findings of the same type
Step 2: Investigate in Chronicle
You can use Chronicle to investigate this finding. Chronicle is a Google Cloud service that lets you investigate threats and pivot through related entities in an easy to use timeline. Chronicle enriches findings data, letting you identify indicators of interest and simplify investigations.
Go to the Security Command Center Findings page in the Google Cloud console.
Next to View by, click Source Type.
In the Source type list, select Event Threat Detection.
The table populates with findings for the source type you selected.
In the table, under category, click on a
Brute Force: SSH
finding.In the Finding Details pane, click Investigate in Chronicle.
Follow the instructions in Chronicle's guided user interface.
Use the following guides to conduct investigations in Chronicle:
Step 3: Review permissions and settings
In the Google Cloud console, go to the Dashboard.
Click the Select from drop-down list at the top of the page. In the Select from window that appears, select the project listed in
projectId
.Navigate to the Resources card and click Compute Engine.
Click the VM instance that matches the name and zone in
vmName
. Review instance details, including network and access settings.In the navigation pane, click VPC Network, then click Firewall. Remove or disable overly permissive firewall rules on port 22.
Step 4: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in
cloudLoggingQueryURI
. - On the page that loads, find VPC Flow Logs related to
srcIP
by using the following filter:logName="projects/projectId/logs/syslog"
labels."compute.googleapis.com/resource_name"="vmName"
Step 5: Research attack and response methods
- Review the MITRE ATT&CK framework entry for this finding type: Valid Accounts: Local Accounts.
- Review related findings by clicking the link in
relatedFindingURI
. Related findings are the same finding type and the same instance and network. - To develop a response plan, combine your investigation results with MITRE research.
Step 6: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project with the successful brute force attempt.
- Investigate the potentially compromised instance and remove any discovered malware. To assist with detection and removal, use an endpoint detection and desponse solution.
- Consider disabling SSH access to the VM. This step could interrupt authorized access to the VM, so consider the needs of your organization before you proceed.
- Only use SSH authentication with authorized keys.
- Block the malicious IP addresses by updating firewall rules or by using Google Cloud Armor. You can enable Google Cloud Armor on the Security Command Center Integrated Services page. Depending on the quantity of information, Google Cloud Armor costs can be significant. See the Google Cloud Armor pricing guide for more information.
Credential Access: External Member Added To Privileged Group
Detects when an external member is added to a privileged Google Group (a group granted sensitive roles or permissions). To respond to this finding, do the following:
Step 1: Review finding details
- Open a
Credential Access: External Member Added To Privileged Group
finding, as directed in Reviewing findings. In the Finding Details pane, under Additional Information, click Source Properties, and then note the following fields.
principalEmail
: the account that made the changesgroupName
: the Google Group where the changes were madeexternalMember
: the newly added external membersensitiveRoles
: the sensitive roles associated with this groupcloudLoggingQueryURI
: link to the Logging pagemitreURI
: link to the MITRE ATT&CK framework entry for this finding type
Step 2: Review group members
Go to Google Groups.
Click the name of the group you want to review.
In the navigation menu, click Members.
If the newly added external member should not be in this group, click the checkbox next to the members name, and then select
Remove member or Ban member.To remove or members, you must be a Google Workspace Admin, or assigned the Owner or Manager role in the Google Group. For more information, see Assign roles to a group's members.
Step 3: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in
cloudLoggingQueryURI
. If necessary, select your project.
On the page that loads, check logs for Google Group membership changes using the following filters:
protoPayload.methodName="google.apps.cloudidentity.groups.v1.MembershipsService.UpdateMembership"
protoPayload.authenticationInfo.principalEmail="principalEmail"
Step 4: Research attack and response methods
- Review the MITRE ATT&CK framework entry for this finding type: Valid Accounts.
- To determine if additional remediation steps are necessary, combine your investigation results with MITRE research.
Credential Access: Privileged Group Opened To Public
Detects when a privileged Google Group (a group granted sensitive roles or permissions) is changed to be accessible to the general public. To respond to this finding, do the following:
Step 1: Review finding details
- Open a
Credential Access: Privileged Group Opened To Public
finding, as directed in Reviewing findings. In the Finding Details pane, under Additional Information, click Source Properties, and then note the following fields:
principalEmail
: the account that made the changes (a potentially compromised account)groupName
: the Google Group where the changes were madesensitiveRoles
: the sensitive roles associated with this groupwhoCanJoin
: the joinability setting of the groupcloudLoggingQueryURI
: link to the Logging pagemitreURI
: link to the MITRE ATT&CK framework entry for this finding type
Step 2: Review group access settings
Go to the Admin Console for Google Groups. You must be a Google Workspace Admin to sign in to the console.
In the navigation pane, click Directory, and then select Groups.
Click the name of the group you want to review.
Click Access Settings, and then, under Who can join the group, review the group's joinability setting.
In the drop-down menu, if needed, change the joinability setting.
Step 3: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in
cloudLoggingQueryURI
. If necessary, select your project.
On the page that loads, check logs for Google Group settings changes using the following filters:
protoPayload.methodName="google.admin.AdminService.changeGroupSetting"
protoPayload.authenticationInfo.principalEmail="principalEmail"
Step 4: Research attack and response methods
- Review the MITRE ATT&CK framework entry for this finding type: Valid Accounts.
- To determine if additional remediation steps are necessary, combine your investigation results with MITRE research.
Credential Access: Sensitive Role Granted To Hybrid Group
Detects when sensitive roles or permissions are granted to a Google Group with external members. To respond to this finding, do the following:
Step 1: Review finding details
- Open a
Credential Access: Sensitive Role Granted To Hybrid Group
finding, as directed in Reviewing findings. In the Finding Details pane, under Additional Information, click Source Properties, and then note the following fields.
principalEmail
: the account that made the changes (a potentially compromised account)groupName
: the Google Group where the changes were madebindingDeltas
: the sensitive roles that are newly granted to this groupresourceName
: the resource where the new role was grantedcloudLoggingQueryURI
: link to the Logging pagemitreURI
: link to the MITRE ATT&CK framework entry for this finding type
Step 2: Review group permissions
Go to the IAM page in the Google Cloud console.
In the Filter field, enter the account name listed in
groupName
.Review the sensitive roles granted to the group.
If the newly added sensitive role is not needed, revoke the role.
You need specific permissions to manage roles in your organization. For more information, see Required permissions.
Step 3: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in
cloudLoggingQueryURI
. If necessary, select your project.
On the page that loads, check logs for Google Group settings changes using the following filters:
protoPayload.methodName="SetIamPolicy"
protoPayload.authenticationInfo.principalEmail="principalEmail"
Step 4: Research attack and response methods
- Review the MITRE ATT&CK framework entry for this finding type: Valid Accounts.
- To determine if additional remediation steps are necessary, combine your investigation results with MITRE research.
Cryptomining
Malware is detected by examining VPC Flow Logs and Cloud DNS logs for connections to known command and control domains and IP addresses. To respond to this finding, do the following:
Step 1: Review finding details
- Open a
Cryptomining: Bad IP
finding, as directed in Reviewing findings. In the Finding Details pane, on the Attributes tab, note the following fields.
connections
sourceIp
: the suspected cryptomining IP addresssourcePort
: the source port of the connectiondestinationIp
: the target IP addressdestinationPort
: the destination port of the connectionprotocol
: the IANA protocol number associated with the connection
In the Finding Details pane, under Additional Information, click Source Properties and note the following fields.
properties_sourceInstance
: the affected Compute Engine VM instanceproperties_project_id
: the project for the Compute Engine instance
Step 2: Review permissions and settings
In the Google Cloud console, go to the Dashboard page.
Click the Select from drop-down list at the top of the page. In the Select from window that appears, select the project listed in
properties_project_id
.Navigate to the Resources card and click Compute Engine.
Click the VM instance that matches
properties_sourceInstance
. Investigate the potentially compromised instance for malware.In the navigation pane, click VPC Network, then click Firewall. Remove or disable overly permissive firewall rules.
Step 3: Check logs
In the Google Cloud console, go to Logs Explorer.
On the Google Cloud console toolbar, select your project.
On the page that loads, find VPC Flow Logs related to
Properties_ip_0
by using the following filter:logName="projects/properties_project_id/logs/compute.googleapis.com%2Fvpc_flows"
(jsonPayload.connection.src_ip="Properties_ip_0" OR jsonPayload.connection.dest_ip="Properties_ip_0")
Step 4: Research attack and response methods
- Review MITRE ATT&CK framework entries for this finding type: Resource Hijacking.
- To develop a response plan, combine your investigation results with MITRE research.
Step 5: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project containing malware.
- Investigate the potentially compromised instance and remove any discovered malware. To assist with detection and removal, use an endpoint detection and response solution.
- If necessary, stop the compromised instance and replace it with a new instance.
- Block the malicious IP addresses by updating firewall rules or by using Google Cloud Armor. You can enable Google Cloud Armor on the Security Command Center Integrated Services page. Depending on the data volume, Google Cloud Armor costs can be significant. See the Google Cloud Armor pricing guide for more information.
Initial Access: Log4j Compromise Attempt
This finding is generated when Java Naming and Directory Interface (JNDI) lookups within headers or URL parameters are detected. These lookups may indicate attempts at Log4Shell exploitation. To respond to this finding, do the following:
Step 1: Review finding details
- Open an
Initial Access: Log4j Compromise Attempt
finding, as directed in Reviewing finding details. In the Finding Details pane, under Additional Information, click Source Properties, and note the following fields.
properties
loadBalancerName
: the name of the load balancer that received the JNDI lookuprequestUrl
: the request URL of the HTTP request. If present, this contains a JNDI lookup.requestUserAgent
: the user agent that sent the HTTP request. If present, this contains a JNDI lookup.refererUrl
: the URL of the page that sent the HTTP request. If present, this contains a JNDI lookup.
contextUris
: internal and external resources to add context to findingsmitreURI
: link to the MITRE ATT&CK framework entry for this finding typecloudLoggingQueryURI
: link to the Logging pagerelatedFindingURI
: link to related findings of the same type
Step 2: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in the
cloudLoggingQueryURI
field from step 1. On the page that loads, check the
httpRequest
fields for string tokens like${jndi:ldap://
that may indicate possible exploitation attempts.See CVE-2021-44228: Detecting Log4Shell exploit in the Logging documentation for example strings to search for and for an example query.
Step 3: Research attack and response methods
- Review the MITRE ATT&CK framework entry for this finding type: Exploit Public-Facing Application.
- Review related findings by clicking the link in
relatedFindingURI
. Related findings are the same finding type and the same instance and network. - To develop a response plan, combine your investigation results with MITRE research.
Step 4: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Upgrade to the latest version of Log4j2.
- Follow Google Cloud's recommendations for investigating and responding to the "Apache Log4j 2" vulnerability {: .external target="blog" track-type="tasks" track-name="blogLink"}
- Implement the recommended mitigation techniques in Apache Log4j Security Vulnerabilities
- If you use Google Cloud Armor, deploy the
cve-canary rule
into a new or existing Google Cloud Armor security policy. For more information, see Google Cloud Armor WAF rule to help mitigate Apache Log4j vulnerability
Active Scan: Log4j Vulnerable to RCE
Supported Log4j vulnerability scanners inject obfuscated JNDI lookups in HTTP parameters, URLs, and text fields with callbacks to domains controlled by the scanners. This finding is generated when DNS queries for the unobfuscated domains are found. Such queries only occur if a JNDI lookup was successful, indicating an active Log4j vulnerability. To respond to this finding, do the following:
Step 1: Review finding details
- Open an
Active Scan: Log4j Vulnerable to RCE
finding, as directed in Reviewing finding details. In the Finding Details pane, click the Attributes tab and note the following field.
resource.name
: the full resource name of the Compute Engine instance that is vulnerable to the Log4j RCE.
In the Finding Details pane, under Additional Information, click Source Properties, and note the following fields:
properties
scannerDomain
: the domain used by the scanner as part of the JNDI lookup. This tells you which scanner identified the vulnerability.sourceIp
: the IP address used to make the DNS queryvpcName
: the name of the network on the instance where the DNS query was made
contextUris
: internal and external resources to add context to findingsmitreURI
: link to the MITRE ATT&CK framework entry for this finding typecloudLoggingQueryURI
: link to the Logging pagerelatedFindingURI
: link to related findings of the same type
Step 2: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in the
cloudLoggingQueryURI
field from step 1. On the page that loads, check the
httpRequest
fields for string tokens like${jndi:ldap://
that may indicate possible exploitation attempts.See CVE-2021-44228: Detecting Log4Shell exploit in the Logging documentation for example strings to search for and for an example query.
Step 3: Research attack and response methods
- Review the MITRE ATT&CK framework entry for this finding type: Exploitation of Remote Services.
- Review related findings by clicking the link in
relatedFindingURI
. Related findings are the same finding type and the same instance and network. - To develop a response plan, combine your investigation results with MITRE research.
Step 4: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Upgrade to the latest version of Log4j2.
- Follow Google Cloud's recommendations for investigating and responding to the "Apache Log4j 2" vulnerability {: .external target="blog" track-type="tasks" track-name="blogLink"}
- Implement the recommended mitigation techniques in Apache Log4j Security Vulnerabilities
- If you use Google Cloud Armor, deploy the
cve-canary rule
into a new or existing Google Cloud Armor security policy. For more information, see Google Cloud Armor WAF rule to help mitigate Apache Log4j vulnerability
Leaked credentials
This finding is generated when Google Cloud service account credentials are accidentally leaked online or compromised. To respond to this finding, do the following:
Step 1: Review finding details
- Open an
account_has_leaked_credentials
finding, as directed in Reviewing finding details. In the Finding Details pane, under Additional Information, click Source Properties and note the following fields.
Compromised_account
: the potentially compromised service accountProject_identifier
: the project that contains the potentially leaked account credentialsURL
: the link to the GitHub repository
Step 2: Review project and service account permissions
In the Google Cloud console, go to the IAM page.
If necessary, select the project listed in
Project_identifier
.On the page that appears, in the Filter box, enter the account name listed in
Compromised_account
and check assigned permissions.In the Google Cloud console, go to the Service Accounts page.
On the page that appears, in the Filter box, enter the name of the compromised service account and check the service account's keys and key creation dates.
Step 3: Check logs
In the Google Cloud console, go to Logs Explorer.
On the Google Cloud console toolbar, select your project.
On the page that loads, check logs for activity from new or updated IAM resources using the following filters:
proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
protoPayload.methodName="SetIamPolicy"
resource.type="gce_instance" AND log_name="projects/Project_identifier/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.methodName="InsertProjectOwnershipInvite"
protoPayload.authenticationInfo.principalEmail="Compromised_account"
Step 4: Research attack and response methods
- Review the MITRE ATT&CK framework entry for this finding type: Valid Accounts: Cloud Accounts.
- Review related findings by clicking the link in
relatedFindingURI
. Related findings are the same finding type and the same instance and network. - To develop a response plan, combine your investigation results with MITRE research.
Step 5: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project with leaked credentials.
- Consider deleting the compromised service account and rotate and delete all service account access keys for the compromised project. After deletion, resources that use the service account for authentication lose access. Before proceeding, your security team should identify all impacted resources and work with resource owners to ensure business continuity.
- Work with your security team to identify unfamiliar resources, including Compute Engine instances, snapshots, service accounts, and IAM users. Delete resources not created with authorized accounts.
- Respond to notifications from Google Cloud Support.
- To limit who can create service accounts, use the Organization Policy Service.
- To identify and fix overly permissive roles, use IAM Recommender.
- Open the
URL
link and delete the leaked credentials. Gather more information about the compromised account and contact the owner.
Malware
Malware is detected by examining VPC Flow Logs and
Cloud DNS logs for connections to known command and control domains and
IP addresses. Currently, Event Threat Detection provides general malware detection (
Malware: Bad IP
and Malware: Bad Domain
) and detectors
particularly for Log4j-related malware (Log4j Malware: Bad IP
and
Log4j Malware: Bad Domain
). The following steps describe how to investigate and
respond to IP-based findings. The remediation steps are similar for domain-based
findings.
Step 1: Review finding details
- Open a
Malware: Bad IP
finding, as directed in Reviewing findings. In the Finding Details pane, on the Attributes tab, note the following fields.
connections
sourceIp
: a known malware command and control IP addresssourcePort
: the source port of the connectiondestinationIp
: the target IP address of the malwaredestinationPort
: the destination port of the connectionprotocol
: the IANA protocol number associated with the connection
In the Finding Details pane, under Additional Information, click Source Properties and note the following fields.
sourceLogId
projectId
: the project that contains the finding
InstanceDetails
: the resource address for the Compute Engine instancecontextUris
: internal and external resources to add context to findingsmitreURI
: link to the MITRE ATT&CK framework entry for this finding typevirustotalIndicatorQueryUI
: link to the VirusTotal analysis pagecloudLoggingQueryURI
: link to the Logging pagerelatedFindingURI
: link to related findings of the same type
Step 2: Investigate in Chronicle
You can use Chronicle to investigate this finding. Chronicle is a Google Cloud service that lets you investigate threats and pivot through related entities in an easy to use timeline. Chronicle enriches findings data, letting you identify indicators of interest and simplify investigations.
Go to the Security Command Center Findings page in the Google Cloud console.
Next to View by, click Source Type.
In the Source type list, select Event Threat Detection.
The table populates with findings for the source type you selected.
In the table, under category, click on a
Malware: Bad IP
finding.In the Finding Details pane, click Investigate in Chronicle.
Follow the instructions in Chronicle's guided user interface.
Use the following guides to conduct investigations in Chronicle:
Step 3: Review permissions and settings
In the Google Cloud console, go to the Dashboard page.
Click the Select from drop-down list at the top of the page. In the Select from window that appears, select the project listed in
projectId
.Navigate to the Resources card and click Compute Engine.
Click the VM instance that matches the name and zone in
instanceDetails
. Review instance details, including network and access settings.In the navigation pane, click VPC Network, then click Firewall. Remove or disable overly permissive firewall rules.
Step 4: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in
cloudLoggingQueryURI
. - On the page that loads, find VPC Flow Logs related to the IP
address in
srcIP
by using the following filter:logName="projects/projectId/logs/compute.googleapis.com%2Fvpc_flows" AND (jsonPayload.connection.src_ip="srcIP" OR jsonPayload.connection.dest_ip="destIP")
Step 5: Research attack and response methods
- Review MITRE ATT&CK framework entries for this finding type: Dynamic Resolution and Command and Control.
- Review related findings by clicking the link in
relatedFindingURI
. Related findings are the same finding type and the same instance and network. - Check flagged URLs and domains on
VirusTotal by
clicking the link in
virustotalIndicatorQueryUI
. VirusTotal is an Alphabet-owned service that provides context on potentially malicious files, URLs, domains, and IP addresses. - To develop a response plan, combine your investigation results with MITRE research.
Step 6: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project containing malware.
- Investigate the potentially compromised instance and remove any discovered malware. To assist with detection and removal, use an endpoint detection and response solution.
- To track activity and vulnerabilities that allowed the insertion of malware, check audit logs and syslogs associated with the compromised instance.
- If necessary, stop the compromised instance and replace it with a new instance.
- Block the malicious IP addresses by updating firewall rules or by using Google Cloud Armor. You can enable Google Cloud Armor on the Security Command Center Integrated Services page. Depending on data volume, Google Cloud Armor costs can be significant. See the Google Cloud Armor pricing guide for more information.
- To control access and use of VM images, use Shielded VM and Trusted Images IAM policy.
Outgoing DoS
Event Threat Detection detects potential use of an instance to launch a denial of service (DoS) attack by analyzing VPC Flow Logs. To respond to this finding, do the following:
Step 1: Review finding details
- Open a
Malware: Outgoing DoS
finding as directed in Reviewing findings. In the Finding Details pane, under Additional Information, click Source Properties and note the following fields.
sourceInstanceDetails
: the affected Compute Engine VM instanceipConnection
srcIP
: the source IP address of the DoS activitysrcPort
: the source port of the connectiondestIP
: the target IP address of the DoS activitydestPort
: the destination port of the connection
contextUris
: internal and external resources to add context to findingsmitreURI
: link to the MITRE ATT&CK framework entry for this finding typecloudLoggingQueryURI
: link to the Logging pagerelatedFindingURI
: link to related findings of the same type
Step 2: Review permissions and settings
In the Google Cloud console, go to the Dashboard page.
Click the Select from drop-down list at the top of the page. In the Select from window that appears, select the project ID listed in
sourceInstanceDetails
.Navigate to the Resources card and click Compute Engine.
Click the VM instance that matches the instance name and zone in
sourceInstanceDetails
. Review instance details, including network and access settings.In the navigation pane, click VPC Network, then click Firewall. Remove or disable overly permissive firewall rules.
Step 3: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in
cloudLoggingQueryURI
. - On the page that loads, find VPC Flow Logs related to the IP
address in
srcIP
by using the following filter:logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND (jsonPayload.connection.src_ip="srcIP" OR jsonPayload.connection.dest_ip="destIP")
Step 4: Research attack and response methods
- Review MITRE ATT&CK framework entries for this finding type: Network Denial of Service.
- Review related findings by clicking the link in
relatedFindingURI
. Related findings are the same finding type and the same instance and network. - To develop a response plan, combine your investigation results with MITRE research.
Step 5: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project experiencing outgoing DoS traffic.
- Investigate the potentially compromised instance and remove any discovered malware. To assist with detection and removal, use an endpoint detection and response solution.
- To track activity and vulnerabilities that allowed the insertion of malware, check audit logs and syslogs associated with the compromised instance.
- If necessary, stop the compromised instance and replace it with a new instance.
- Block the malicious IP addresses by updating firewall rules or by using Google Cloud Armor. You can enable Google Cloud Armor on the Security Command Center Integrated Services page. Depending on the data volume, Google Cloud Armor costs can be significant. See the Google Cloud Armor pricing guide for more information.
- To control access and use of VM images, use Shielded VM and Trusted Images IAM policy.
Persistence: IAM Anomalous Grant
Audit logs are examined to detect the addition of IAM (IAM) role grants that might be considered suspicious. The following are examples of anomalous grants:
- Inviting a gmail.com user as a project owner from the Google Cloud Console
- A service account granting sensitive permissions
- A custom role granting sensitive permissions
- A service account added from outside your organization
To respond to this finding, do the following:
Step 1: Review finding details
- Open a
Persistence: IAM Anomalous Grant
finding as directed in Reviewing findings. In the Finding Details pane, under Additional Information, click Source Properties and note the following fields.
projectId
: the project that contains the findingprincipalEmail
: email address for the user or service account that assigned the rolebindingDeltas
Action
: the action taken by the userRole
: the role assigned to the usermember
: the email address of the user that received the role
contextUris
: internal and external resources to add context to findingsmitreURI
: link to the MITRE ATT&CK framework entry for this finding typevirustotalIndicatorQueryUI
: link to the VirusTotal analysis pagecloudLoggingQueryURI
: link to the Logging pagerelatedFindingURI
: link to related findings of the same type
Step 2: Investigate in Chronicle
You can use Chronicle to investigate this finding. Chronicle is a Google Cloud service that lets you investigate threats and pivot through related entities in an easy to use timeline. Chronicle enriches findings data, letting you identify indicators of interest and simplify investigations.
Go to the Security Command Center Findings page in the Google Cloud console.
Next to View by, click Source Type.
In the Source type list, select Event Threat Detection.
The table populates with findings for the source type you selected.
In the table, under category, click on a
Persistence: IAM Anomalous Grant
finding.In the Finding Details pane, click Investigate in Chronicle.
Follow the instructions in Chronicle's guided user interface.
Use the following guides to conduct investigations in Chronicle:
Step 3: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in
cloudLoggingQueryURI
. - On the page that loads, look for new or updated IAM
resources using the following filters:
protoPayload.methodName="SetIamPolicy"
protoPayload.methodName="google.iam.admin.v1.UpdateRole"
protoPayload.methodName="google.iam.admin.v1.CreateRole"
Step 4: Research attack and response methods
- Review MITRE ATT&CK framework entries for this finding type: Valid Accounts: Cloud Accounts.
- Review related findings by clicking the link in
relatedFindingURI
. Related findings are the same finding type and the same instance and network. - To develop a response plan, combine your investigation results with MITRE research.
Step 5: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project with the compromised account.
- Delete the compromised service account and rotate and delete all service account access keys for the compromised project. After deletion, resources that use the service account for authentication lose access.
- Delete project resources created by unauthorized accounts, like unfamiliar Compute Engine instances, snapshots, service accounts, and IAM users.
- To restrict adding gmail.com users, use the Organization Policy.
- To identify and fix overly permissive roles, use IAM Recommender.
Persistence: New Geography
An IAM user or service account is accessing Google Cloud from an anomalous location, based on the geolocation of the requesting IP address.
Step 1: Review finding details
- Open a
Persistence: New Geography
finding, as directed in Reviewing finding details earlier on this page. In the Finding Details pane, under Additional Information, click Source Properties and note the following fields.
principalEmail
: the potentially compromised user accountprojectId
: the project that contains the potentially compromised user accountcallerIp
: the external IP addressanomalousLocation
: the estimated current location of the usertypicalGeolocations
: the locations where the user usually accesses Google Cloud resourcesnotSeenInLast
: the time period used to establish a baseline for normal behaviorgcpResourceName
: the affected resourcecloudLoggingQueryURI
: the link to Cloud Logging entriesmitreUri
: the link to the MITRE ATT&CK framework entry
Step 2: Review project and account permissions
In the Google Cloud console, go to the IAM page.
If necessary, select the project listed in
projectId
.On the page that appears, in the Filter box, enter the account name listed in
principalEmail
and check granted roles.
Step 3: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in
cloudLoggingQueryURI
. - If necessary, select your project.
- On the page that loads, check logs for activity from new or updated
IAM resources using the following filters:
protoPayload.methodName="SetIamPolicy"
protoPayload.methodName="google.iam.admin.v1.UpdateRole"
protoPayload.methodName="google.iam.admin.v1.CreateRole"
protoPayload.authenticationInfo.principalEmail="principalEmail"
Step 4: Research attack and response methods
- Review the MITRE ATT&CK framework entry for this finding type: Valid Accounts: Cloud Accounts.
- To develop a response plan, combine your investigation results with MITRE research.
Step 5: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project with the compromised account.
- Review the
anomalousLocation
,typicalGeolocations
, andnotSeenInLast
fields to verify whether the access is abnormal and if the account has been compromised. - Delete project resources created by unauthorized accounts, like unfamiliar Compute Engine instances, snapshots, service accounts, and IAM users.
- To restrict the creation of new resources to specific regions, see Restricting Resource Locations.
- To identify and fix overly permissive roles, use IAM Recommender.
Persistence: New User Agent
An IAM service account is accessing Google Cloud using suspicious software, as indicated by an anomalous user agent.
Step 1: Review finding details
- Open a
Persistence: New User Agent
finding, as directed in Reviewing finding details earlier on this page. In the Finding Details pane, under Additional Information, click Source Properties and note the following fields.
principalEmail
: the potentially compromised service accountprojectId
: the project that contains the potentially compromised service accountcallerUserAgent
: the anomalous user agentanomalousSoftwareClassification
: the type of softwarenotSeenInLast
: the time period used to establish a baseline for normal behaviorcloudLoggingQueryURI
: the link to Cloud Logging entriesmitreUri
: the link to the MITRE ATT&CK framework entry
Step 2: Review project and account permissions
In the Google Cloud console, go to the IAM page.
If necessary, select the project listed in
projectId
.On the page that appears, in the Filter box, enter the account name listed in
principalEmail
and check granted roles.In the Google Cloud console, go to the Service Accounts page.
On the page that appears, in the Filter box, enter the account name listed in
principalEmail
and check the service account's keys and key creation dates.
Step 3: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in
cloudLoggingQueryURI
. - If necessary, select your project.
- On the page that loads, check logs for activity from new or updated
IAM resources using the following filters:
proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
protoPayload.methodName="SetIamPolicy"
protoPayload.methodName="google.iam.admin.v1.UpdateRole"
protoPayload.methodName="google.iam.admin.v1.CreateRole"
protoPayload.authenticationInfo.principalEmail="principalEmail"
Step 4: Research attack and response methods
- Review the MITRE ATT&CK framework entry for this finding type: Valid Accounts: Cloud Accounts.
- To develop a response plan, combine your investigation results with MITRE research.
Step 5: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project with the compromised account.
- Review the
anomalousSoftwareClassification
,callerUserAgent
, andbehaviorPeriod
fields to verify whether the access is abnormal and if the account has been compromised. - Delete project resources created by unauthorized accounts, like unfamiliar Compute Engine instances, snapshots, service accounts, and IAM users.
- To restrict the creation of new resources to specific regions, see Restricting Resource Locations.
- To identify and fix overly permissive roles, use IAM Recommender.
Service account self-investigation
A service account credential is being used to investigate the roles and permissions associated with that same service account. This finding indicates that service account credentials might be compromised and immediate action should be taken.
Step 1: Review finding details
- Open a
Discovery: Service Account Self-Investigation
finding, as directed in Reviewing finding details earlier on this page. In the Finding Details pane, under Additional Information, click Source Properties and note the following fields.
principalEmail
: the potentially compromised service accountprojectId
: the project that contains the potentially leaked account credentialscallerIp
: the internal or external IP addresscloudLoggingQueryURI
: the link to Cloud Logging entriesmitreUri
: the link to the MITRE ATT&CK framework entryseverity
: the risk level assigned to the finding;severity
isHIGH
if the API call that triggered this finding was unauthorized—the service account doesn't have permission to query its own IAM permissions with theprojects.getIamPolicy
API.
Step 2: Review project and service account permissions
In the Google Cloud console, go to the IAM page.
If necessary, select the project listed in
projectId
.On the page that appears, in the Filter box, enter the account name listed in
principalEmail
and check assigned permissions.In the Google Cloud console, go to the Service Accounts page.
On the page that appears, in the Filter box, enter the name of the compromised service account and check the service account's keys and key creation dates.
Step 3: Check logs
- In the Google Cloud console, go to Logs Explorer by clicking
the link in
cloudLoggingQueryURI
. - If necessary, select your project.
- On the page that loads, check logs for activity from new or updated
IAM resources using the following filters:
proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
protoPayload.methodName="SetIamPolicy"
protoPayload.authenticationInfo.principalEmail="principalEmail"
Step 4: Research attack and response methods
- Review the MITRE ATT&CK framework entry for this finding type: Permission Groups Discovery: Cloud Groups.
- To develop a response plan, combine your investigation results with MITRE research.
Step 5: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project with the compromised account.
- Delete the compromised service account and rotate and delete all service account access keys for the compromised project. After deletion, resources that use the service account for authentication lose access.
- Delete project resources created by the compromised account, like unfamiliar Compute Engine instances, snapshots, service accounts, and IAM users.
Compute Engine Admin Metadata detections
Unexpected modifications to Compute Engine VM instance metadata can be an indication of suspicious activity.
Persistence: Compute Engine Admin Added SSH Key
Description | Actions | |
---|---|---|
The ssh-keys Compute Engine instance metadata key was changed on an established instance.
|
The Compute Engine instance metadata key ssh-keys was modified on an instance that was created more than seven days ago. Verify
whether the change was done intentionally by a member, or if it was
implemented by an adversary to introduce new access to your organization.
|
Check logs using the following filters:
Replace the following:
|
Research events that trigger this finding: |
Persistence: Compute Engine Admin Added Startup Script
Description | Actions | |
---|---|---|
The startup-script or startup-script-url Compute Engine instance metadata key was changed on an established instance.
|
The Compute Engine instance metadata key startup-script or
startup-script-url was modified on an instance that was created more than
seven days ago. Verify whether the change was done intentionally by a member, or if it was
implemented by an adversary to introduce new access to your organization.
|
Check logs using the following filters:
Replace the following:
|
Research events that trigger this finding: |
Google Workspace logs detections
If you share your Google Workspace logs with Cloud Logging, Event Threat Detection generates findings for several Google Workspace threats.
Event Threat Detection enriches log events and writes findings to Security Command Center. The following table contains Google Workspace threats, relevant MITRE ATT&CK framework entries, and details about the events that trigger findings. You can also check logs using specific filters, and combine all of the information to respond to Google Workspace threats.
Initial Access: Disabled Password Leak
Description | Actions | |
---|---|---|
A member's account is disabled because a password leak was detected. | Reset passwords for affected accounts, and advise members to use strong, unique passwords for corporate accounts. |
Check logs using the following filters:
Replace |
Research events that trigger this finding: |
Initial Access: Suspicious Login Blocked
Description | Actions | |
---|---|---|
A suspicious login to a member's account was detected and blocked. | This account might be targeted by adversaries. Ensure the user account follows your organization's security guidelines for strong passwords and multifactor authentication. |
Check logs using the following filters:
Replace |
Research events that trigger this finding: |
Initial Access: Account Disabled Hijacked
Description | Actions | |
---|---|---|
A member's account was suspended due to suspicious activity. | This account was hijacked. Reset the account password and encourage users to create strong, unique passwords for corporate accounts. |
Check logs using the following filters:
Replace |
Research events that trigger this finding: |
Impair Defenses: Two Step Verification Disabled
Description | Actions | |
---|---|---|
A member disabled 2-step verification. | Verify if the user intended to disable 2-step verification. If your organization requires 2-step verification, ensure that the user enables it promptly. |
Check logs using the following filters:
Replace |
Research events that trigger this finding:
|
Initial Access: Government Based Attack
Description | Actions | |
---|---|---|
Government-backed attackers might have tried to compromise a member account or computer. | This account might be targeted by adversaries. Ensure the user account follows your organization's security guidelines for strong passwords and multifactor authentication. |
Check logs using the following filters:
Replace |
Research events that trigger this finding: |
Persistence: SSO Enablement Toggle
Description | Actions | |
---|---|---|
The Enable SSO (single sign-on) setting on the admin account was disabled. | SSO settings for your organization were changed. Verify whether the change was done intentionally by a member or if it was implemented by an adversary to introduce new access to your organization. |
Check logs using the following filters:
Replace the following:
|
Research events that trigger this finding: |
Persistence: SSO Settings Changed
Description | Actions | |
---|---|---|
The SSO settings for the admin account were changed. | SSO settings for your organization were changed. Verify whether the change was done intentionally by a member or if it was implemented by an adversary to introduce new access to your organization. |
Check logs using the following filters:
Replace the following:
|
Research events that trigger this finding: |
Impair Defenses: Strong Authentication Disabled
Description | Actions | |
---|---|---|
2-step verification was disabled for the organization. | 2-step verification is no longer required for your organization. Find out if this was an intentional policy change by an administrator, or if this is an attempt by an adversary to make account hijacking easier. |
Check logs using the following filters:
Replace |
Research events that trigger this finding: |
Respond to Google Workspace threats
If you're a Google Workspace Admin, you can use the service's security tools to resolve these threats:
The tools include alerts, a security dashboard, security recommendations, and can help you investigate and remediate threats.
If you're not a Google Workspace Admin, do the following:
- If you still have access to your account, change or reset your password and turn on 2-Step verification.
- Reach out to your Google Workspace Admin or the team at your company that manages your Google Workspace account. Use these findings as an indication that an account might be compromised.
Container Threat Detection responses
To learn more about Container Threat Detection, see how Container Threat Detection works.
Added Binary Executed
A binary that was not part of the original container image was executed. Attackers commonly install exploitation tooling and malware after the initial compromise. To respond to this finding, do the following:
Step 1: Review finding details
- Open an
Added Binary Executed
finding as directed in Reviewing findings. In the Finding Details pane, on the Attributes tab, note the following fields.
resource.name
: the full resource name of the cluster including the project number, location, and cluster nameresource.project_display_name
: the name of the project that contains the clusterprocesses
binary.path
: the absolute path of the added binaryargs
: the arguments provided when invoking the added binary
Click the Source Properties tab and note the following fields:
Pod_Namespace
: the name of the Pod's Kubernetes namespacePod_Name
: the name of the GKE PodContainer_Name
: the name of the affected containerContainer_Image_Uri
: the name of the container image being deployedVM_Instance_Name
: the name of the GKE node where the Pod executed
Step 2: Review cluster and node
In the Google Cloud console, go to the Kubernetes clusters page.
On the Google Cloud console toolbar, select the project listed in
resource.project_display_name
, if necessary.Select the cluster listed in
resource.name
. Note any metadata about the cluster and its owner.Click the Nodes tab. Select the node listed in
VM_Instance_Name
.Click the Details tab and note the
container.googleapis.com/instance_id
annotation.
Step 3: Review Pod
In the Google Cloud console, go to the Kubernetes Workloads page.
On the Google Cloud console toolbar, select the project listed in
resource.project_display_name
, if necessary.Filter on the cluster listed in
resource.name
and the Pod namespace listed inPod_Namespace
, if necessary.Select the Pod listed in
Pod_Name
. Note any metadata about the Pod and its owner.
Step 4: Check logs
In the Google Cloud console, go to Logs Explorer.
On the Google Cloud console toolbar, select the project listed in
resource.project_display_name
, if necessary.Set Select time range to the period of interest.
On the page that loads, do the following:
- Find Pod logs for
Pod_Name
by using the following filter:resource.type="k8s_container"
resource.labels.project_id="resource.project_display_name"
resource.labels.location="location"
resource.labels.cluster_name="cluster_name"
resource.labels.namespace_name="Pod_Namespace"
resource.labels.pod_name="Pod_Name"
- Find cluster audit logs by using the following filter:
logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
resource.type="k8s_cluster"
resource.labels.project_id="resource.project_display_name"
resource.labels.location="location"
resource.labels.cluster_name="cluster_name"
Pod_Name
- Find GKE node console logs by using the following filter:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Find Pod logs for
Step 5: Investigate running container
If the container is still running, it might be possible to investigate the container environment directly.
Go to the Google Cloud console.
On the Google Cloud console toolbar, select the project listed in
resource.project_display_name
, if necessary.Click Activate Cloud Shell
Obtain GKE credentials for your cluster by running the following commands.
For zonal clusters, run:
gcloud container clusters get-credentials cluster_name --zone location --project project_name
For regional clusters, run:
gcloud container clusters get-credentials cluster_name --region location --project project_name
Replace the following:
cluster_name
: the cluster listed inresource.labels.cluster_name
location
: the location listed inresource.labels.location
project_name
: the project name listed inresource.project_display_name
Retrieve the added binary by running:
kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name local_file
Replace
local_file
with a local file path to store the added binary.Connect to the container environment by running:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
This command requires the container to have a shell installed at
/bin/sh
.
Step 6: Research attack and response methods
- Review MITRE ATT&CK framework entries for this finding type: Ingress Tool Transfer, Native API.
- To develop a response plan, combine your investigation results with MITRE research.
Step 7: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project with the compromised container.
- Stop or delete the compromised container and replace it with a new container.
Added Library Loaded
A library that was not part of the original container image was loaded. Attackers might load malicious libraries into existing programs in order to bypass code execution protections and to hide malicious code. To respond to this finding, do the following:
Step 1: Review finding details
- Open an
Added Library Loaded
finding as directed in Reviewing findings. In the Finding Details pane, on the Attributes tab, note the following fields.
resource.name
: the full resource name of the clusterresource.project_display_name
: the name of the project that contains the assetprocesses
libraries
: details about the added librarybinary.path
: the full path of the process binary that loaded the libraryargs
: the arguments provided when invoking the process binary
Click the Source Properties tab and note the following fields:
Pod_Namespace
: the name of the Pod's Kubernetes namespacePod_Name
: the name of the GKE PodContainer_Name
: the name of the affected containerContainer_Image_Uri
: the name of the container image being executedVM_Instance_Name
: the name of the GKE node where the Pod executed
Step 2: Review cluster and node
In the Google Cloud console, go to the Kubernetes clusters page.
On the Google Cloud console toolbar, select the project listed in
resource.project_display_name
, if necessary.Select the cluster listed in
resource.name
. Note any metadata about the cluster and its owner.Click the Nodes tab. Select the node listed in
VM_Instance_Name
.Click the Details tab and note the
container.googleapis.com/instance_id
annotation.
Step 3: Review Pod
In the Google Cloud console, go to the Kubernetes Workloads page.
On the Google Cloud console toolbar, select the project listed in
resource.project_display_name
, if necessary.Filter on the cluster listed in
resource.name
and the Pod namespace listed inPod_Namespace
, if necessary.Select the Pod listed in
Pod_Name
. Note any metadata about the Pod and its owner.
Step 4: Check logs
In the Google Cloud console, go to Logs Explorer.
On the Google Cloud console toolbar, select the project listed in
resource.project_display_name
, if necessary.Set Select time range to the period of interest.
On the page that loads, do the following:
- Find Pod logs for
Pod_Name
by using the following filter:resource.type="k8s_container"
resource.labels.project_id="resource.project_display_name"
resource.labels.location="location"
resource.labels.cluster_name="cluster_name"
resource.labels.namespace_name="Pod_Namespace"
resource.labels.pod_name="Pod_Name"
- Find cluster audit logs by using the following filter:
logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
resource.type="k8s_cluster"
resource.labels.project_id="resource.project_display_name"
resource.labels.location="location"
resource.labels.cluster_name="cluster_name"
Pod_Name
- Find GKE node console logs by using the following filter:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Find Pod logs for
Step 5: Investigate running container
If the container is still running, it might be possible to investigate the container environment directly.
Go to the Google Cloud console.
On the Google Cloud console toolbar, select the project listed in
resource.project_display_name
, if necessary.Click Activate Cloud Shell.
Obtain GKE credentials for your cluster by running the following commands.
For zonal clusters, run:
gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
For regional clusters, run:
gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
Retrieve the added library by running:
kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name local_file
Replace local_file with a local file path to store the added library.
Connect to the container environment by running:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
This command requires the container to have a shell installed at
/bin/sh
.
Step 6: Research attack and response methods
- Review MITRE ATT&CK framework entries for this finding type: Ingress Tool Transfer, Shared Modules.
- To develop a response plan, combine your investigation results with MITRE research.
Step 7: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project with the compromised container.
- Stop or delete the compromised container and replace it with a new container.
Malicious Script Executed
A machine learning model identified an executed bash script as malicious. Attackers can use bash to transfer tools and execute commands without binaries.
To respond to this finding, do the following:
Step 1: Review finding details
- Open a
Malicious Script Detected
finding as directed in Reviewing findings. In the Finding Details pane, on the Attributes tab, note the following fields.
resource.name
: the full resource name of the cluster, including the project number, location, and cluster nameresource.project_display_name
: the name of the project that contains the assetprocesses
binary
: details about the interpreter that invoked the scriptargs
: the arguments provided when invoking the scriptscript.contents
: Prefix of the executed script's file contents, which can aid in your investigation; the contents might be truncated for performance reasonsscript.sha256
: the SHA-256 hash of the scriptscript.path
: absolute path of the name of the script on disk; this attribute only appears for scripts written to disk, not for literal script execution, for example,bash -c
Click the Source Properties tab and note the following fields:
Pod_Namespace
: the name of the Pod's Kubernetes namespacePod_Name
: the name of the GKE PodContainer_Name
: the name of the affected containerContainer_Image_Uri
: the name of the container image being executedVM_Instance_Name
: the name of the GKE node where the Pod was executed
Step 2: Review cluster and node
In the Google Cloud console, go to the Kubernetes clusters page.
On the Google Cloud console toolbar, select the project listed in
resource.project_display_name
, if necessary.Select the cluster listed in
resource.name
. Note any metadata about the cluster and its owner.Click the Nodes tab. Select the node listed in
VM_Instance_Name
.Click the Details tab and note the
container.googleapis.com/instance_id
annotation.
Step 3: Review Pod
In the Google Cloud console, go to the Kubernetes Workloads page.
On the Google Cloud console toolbar, select the project listed in
resource.project_display_name
, if necessary.Filter on the cluster listed in
resource.name
and the Pod namespace listed inPod_Namespace
, if necessary.Select the Pod listed in
Pod_Name
. Note any metadata about the Pod and its owner.
Step 4: Check logs
In the Google Cloud console, go to Logs Explorer.
On the Google Cloud console toolbar, select the project listed in
resource.project_display_name
, if necessary.Set Select time range to the period of interest.
On the page that loads, do the following:
- Find Pod logs for
Pod_Name
by using the following filter:resource.type="k8s_container"
resource.labels.project_id="resource.project_display_name"
resource.labels.location="location"
resource.labels.cluster_name="cluster_name"
resource.labels.namespace_name="Pod_Namespace"
resource.labels.pod_name="Pod_Name"
- Find cluster audit logs by using the following filter:
logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
resource.type="k8s_cluster"
resource.labels.project_id="resource.project_display_name"
resource.labels.location="location"
resource.labels.cluster_name="cluster_name"
Pod_Name
- Find GKE node console logs by using the following filter:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Find Pod logs for
Step 5: Investigate running container
If the container is still running, it might be possible to investigate the container environment directly.
In the Google Cloud console, go to the Kubernetes clusters page.
Click the name of the cluster shown in
resource.labels.cluster_name
.On the Clusters page, click Connect, and then click Run in Cloud Shell.
Cloud Shell launches and adds commands for the cluster in the terminal.
Press enter and, if the Authorize Cloud Shell dialog appears, click Authorize.
Connect to the container environment by running the following command:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
This command requires the container to have a shell installed at
/bin/sh
.
Step 6: Research attack and response methods
- Review MITRE ATT&CK framework entries for this finding type: Command and Scripting Interpreter, Ingress Tool Transfer.
- To develop a response plan, combine your investigation results with MITRE research.
Step 7: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project with the compromised container.
- Stop or delete the compromised container and replace it with a new container.
Reverse Shell
A process started with stream redirection to a remote connected socket. Spawning a network-connected shell can allow an attacker to perform arbitrary actions after a limited initial compromise. To respond to this finding, do the following:
Step 1: Review finding details
- Open a
Reverse Shell
finding as directed in Reviewing findings. In the Finding Details pane, on the Attributes tab, note the following fields.
resource.name
: the full resource name of the clusterresource.project_display_name
: the name of the project that contains the assetprocesses
binary.path
: the absolute path of the process started with stream redirection to a remote socketargs
: the arguments provided when invoking the process binary
Click the Source Properties tab and note the following fields:
Pod_Namespace
: the name of the Pod's Kubernetes namespacePod_Name
: the name of the GKE PodContainer_Name
: the name of the affected containerContainer_Image_Uri
: the name of the container image being executedReverse_Shell_Stdin_Redirection_Dst_Ip
: the remote IP address of the connectionReverse_Shell_Stdin_Redirection_Dst_Port
: the remote portReverse_Shell_Stdin_Redirection_Src_Ip
: the local IP address of the connectionReverse_Shell_Stdin_Redirection_Src_Port
: the local portVM_Instance_Name
: the name of the GKE node where the Pod executed
Step 2: Review cluster and node
In the Google Cloud console, go to the Kubernetes clusters page.
On the Google Cloud console toolbar, select the project listed in
resource.project_display_name
, if necessary.Select the cluster listed in
resource.name
. Note any metadata about the cluster and its owner.Click the Nodes tab. Select the node listed in
VM_Instance_Name
.Click the Details tab and note the
container.googleapis.com/instance_id
annotation.
Step 3: Review Pod
In the Google Cloud console, go to the Kubernetes Workloads page.
On the Google Cloud console toolbar, select the project listed in
resource.project_display_name
, if necessary.Filter on the cluster listed in
resource.name
and the Pod namespace listed inPod_Namespace
, if necessary.Select the Pod listed in
Pod_Name
. Note any metadata about the Pod and its owner.
Step 4: Check logs
In the Google Cloud console, go to Logs Explorer.
On the Google Cloud console toolbar, select the project listed in
resource.project_display_name
, if necessary.Set Select time range to the period of interest.
On the page that loads, do the following:
- Find Pod logs for
Pod_Name
by using the following filter:resource.type="k8s_container"
resource.labels.project_id="resource.project_display_name"
resource.labels.location="location"
resource.labels.cluster_name="cluster_name"
resource.labels.namespace_name="Pod_Namespace"
resource.labels.pod_name="Pod_Name"
- Find cluster audit logs by using the following filter:
logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
resource.type="k8s_cluster"
resource.labels.project_id="resource.project_display_name"
resource.labels.location="location"
resource.labels.cluster_name="cluster_name"
Pod_Name
- Find GKE node console logs by using the following filter:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Find Pod logs for
Step 5: Investigate running container
If the container is still running, it might be possible to investigate the container environment directly.
Go to the Google Cloud console.
On the Google Cloud console toolbar, select the project listed in
resource.project_display_name
, if necessary.Click Activate Cloud Shell.
Obtain GKE credentials for your cluster by running the following commands.
For zonal clusters, run:
gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
For regional clusters, run:
gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
Launch a shell within the container environment by running:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
This command requires the container to have a shell installed at
/bin/sh
.To view all processes running in the container, run the following command in the container shell:
ps axjf
This command requires the container to have
/bin/ps
installed.
Step 6: Research attack and response methods
- Review MITRE ATT&CK framework entries for this finding type: Command and Scripting Interpreter, Ingress Tool Transfer.
- To develop a response plan, combine your investigation results with MITRE research.
Step 7: Implement your response
The following response plan might be appropriate for your organization, but may impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.
- Contact the owner of the project with the compromised container.
- Stop or delete the compromised container and replace it with a new container.
Fix related vulnerabilities
To help keep threats from reoccurring, review and fix vulnerabilities identified by Security Health Analytics.
In the Security Command Center dashboard, go to the Assets page.
Next to View by, select Project.
In the Project list, select the project that contains the threat finding.
In the Filter box, enter "securityCenterProperties.resourceType:google.compute.Instance". The table lists instances in the project.
Under the resourceProperties.name column, select the instance that contains the finding.
In the pane that loads, under Additional Information, select the Findings tab. If findings are listed, review and follow the remediation guidance for each finding.
In addition to Google-provided indicators of compromise, users who are customers of Palo Alto Networks can integrate Palo Alto Networks' AutoFocus Threat Intelligence with Event Threat Detection. AutoFocus is a threat intelligence service that provides information about network threats. To learn more, visit the AutoFocus page in Google Cloud console.
Remediating threats
Remediating Event Threat Detection and Container Threat Detection findings is not as simple as fixing misconfigurations and vulnerabilities identified by Security Command Center.
Misconfigurations and compliance violations identify weaknesses in resources that could be exploited. Typically, misconfigurations have known, easily implemented fixes, like enabling a firewall or rotating an encryption key.
Threats differ from vulnerabilities in that they are dynamic and indicate a possible active exploit against one or more resources. A remediation recommendation might not be effective in securing your resources because the exact methods used to achieve the exploit might not be known.
For example, an Added Binary Executed
finding indicates that an unauthorized
binary was launched in a container. A basic remediation recommendation might
advise you to quarantine the container and delete the binary, but that might not
resolve the underlying root cause that allowed the attacker access to execute
the binary. You need to find out how the container image was corrupted to fix
the exploit. Determining whether the file was added through a misconfigured port
or by some other means requires a thorough investigation. An analyst with
expert-level knowledge of your system might need to review it for weaknesses.
Bad actors attack resources using different techniques, so applying a fix for a
specific exploit might not be effective against variations of that attack. For
example, in response to a Brute Force: SSH
finding, you might lower permission
levels for some user accounts to limit access to resources. However, weak
passwords might still provide an attack path.
The breadth of attack vectors makes it difficult to provide remediation steps that work in all situations. Security Command Center's role in your cloud security plan is to identify impacted resources in near-real time, tell you what threats you face, and provide evidence and context to aid your investigations. However, your security personnel must use the extensive information in Security Command Center findings to determine the best ways to remediate issues and secure resources against future attacks.
What's next
See Event Threat Detection overview to learn more about the service and the threats it detects.
See Container Threat Detection overview to learn how the service works.