What is Event Threat Detection?
Event Threat Detection is a built-in service for the Security Command Center Premium tier that continuously monitors your organization or projects and identifies threats within your systems in near-real time. Event Threat Detection is regularly updated with new detectors to identify emerging threats at cloud scale.
How Event Threat Detection works
Event Threat Detection monitors the Cloud Logging stream for your organization or projects. If you activate Security Command Center Premium tier at the organization level, Event Threat Detection consumes logs for your projects as they are created and Event Threat Detection can monitor Google Workspace Logs. Cloud Logging contains log entries of API calls and other actions that create, read, or modify the configuration or metadata of your resources. Google Workspace logs track user sign-ins to your domain and provide a record of actions performed on your Google Workspace Admin Console.
Log entries contain status and event information that Event Threat Detection uses to quickly detect threats. Event Threat Detection applies detection logic and proprietary threat intelligence, including tripwire indicator matching, windowed profiling, advanced profiling, machine learning, and anomaly detection, to identify threats in near-real time.
When Event Threat Detection detects a threat, it writes a finding to Security Command Center. If you activate Security Command Center Premium tier at the organization level, Security Command Center can write findings to a Cloud Logging project. From Cloud Logging and Google Workspace logging, you can export findings to other systems with Pub/Sub and process them with Cloud Run functions.
If you activate Security Command Center Premium tier at the organization level, you can additionally use Google Security Operations to investigate some findings. Google SecOps is a Google Cloud service that lets you investigate threats and pivot through related entities in a unified timeline. For instructions on sending findings to Google SecOps, see Investigate findings in Google SecOps.
Your ability to view and edit findings and logs is determined by the Identity and Access Management (IAM) roles you are granted. For more information on Security Command Center IAM roles, see Access control.
Event Threat Detection rules
Rules define the type of threats that Event Threat Detection detects and the types of logs that must be enabled for detectors to work. Admin Activity audit logs are always written; you can't configure or disable them.
Event Threat Detection includes the following default rules:
Display name | API name | Log source types | Description |
---|---|---|---|
Active Scan: Log4j Vulnerable to RCE | Unavailable | Cloud DNS logs | Detects active Log4j vulnerabilities by identifying DNS queries for unobfuscated domains that were initiated by supported Log4j vulnerability scanners. |
Inhibit System Recovery: Deleted Google Cloud Backup and DR host | BACKUP_HOSTS_DELETE_HOST |
Cloud Audit Logs: Backup and DR Service Data Access logs |
A host was deleted from Backup and DR. Applications that are associated with the deleted host might not be protected. |
Data Destruction: Google Cloud Backup and DR expire image | BACKUP_EXPIRE_IMAGE |
Cloud Audit Logs: Backup and DR Data Access logs |
A user requested the deletion of a backup image from Backup and DR. The deletion of a backup image does not prevent future backups. |
Inhibit System Recovery: Google Cloud Backup and DR remove plan | BACKUP_REMOVE_PLAN |
Cloud Audit Logs: Backup and DR Data Access logs |
A backup plan with multiple policies for an application was deleted from Backup and DR. The deletion of a backup plan can prevent future backups. |
Data Destruction: Google Cloud Backup and DR expire all images | BACKUP_EXPIRE_IMAGES_ALL |
Cloud Audit Logs: Backup and DR Data Access logs |
A user requested the deletion of all backup images for a protected application from Backup and DR. The deletion of backup images does not prevent future backups. |
Inhibit System Recovery: Google Cloud Backup and DR delete template | BACKUP_TEMPLATES_DELETE_TEMPLATE |
Cloud Audit Logs: Backup and DR Data Access logs |
A predefined backup template, which is used to set up backups for multiple applications, was deleted. The ability to set up backups in the future might be impacted. |
Inhibit System Recovery: Google Cloud Backup and DR delete policy | BACKUP_TEMPLATES_DELETE_POLICY |
Cloud Audit Logs: Backup and DR Data Access logs |
A Backup and DR policy, which defines how a backup is taken and where it is stored, was deleted. Future backups that use the policy might fail. |
Inhibit System Recovery: Google Cloud Backup and DR delete profile | BACKUP_PROFILES_DELETE_PROFILE |
Cloud Audit Logs: Backup and DR Data Access logs |
A Backup and DR profile, which defines which storage pools should be used to store backups, was deleted. Future backups that use the profile might fail. |
Data Destruction: Google Cloud Backup and DR remove appliance | BACKUP_APPLIANCES_REMOVE_APPLIANCE |
Cloud Audit Logs: Backup and DR Data Access logs |
A backup appliance was deleted from Backup and DR. Applications that are associated with the deleted backup appliance might not be protected. |
Inhibit System Recovery: Google Cloud Backup and DR delete storage pool | BACKUP_STORAGE_POOLS_DELETE |
Cloud Audit Logs: Backup and DR Data Access logs |
A storage pool, which associates a Cloud Storage bucket with Backup and DR, has been removed from Backup and DR. Future backups to this storage target will fail. |
Impact: Google Cloud Backup and DR reduced backup expiration | BACKUP_REDUCE_BACKUP_EXPIRATION |
Cloud Audit Logs: Backup and DR Data Access logs |
The expiration date for a backup protected by Backup and DR has been reduced. |
Impact: Google Cloud Backup and DR reduced backup frequency | BACKUP_REDUCE_BACKUP_FREQUENCY |
Cloud Audit Logs: Backup and DR Data Access logs |
The Backup and DR backup schedule has been modified to reduce backup frequency. |
Brute force SSH | BRUTE_FORCE_SSH |
authlog | Detection of successful brute force of SSH on a host. |
Cloud IDS: THREAT_IDENTIFIER | CLOUD_IDS_THREAT_ACTIVITY |
Cloud IDS logs |
Threat events that are detected by Cloud IDS. Cloud IDS detects layer 7 attacks by analyzing mirrored packets and, when a threat event is detected, sends a threat-class finding to Security Command Center. Finding category names start with "Cloud IDS" followed by the Cloud IDS threat identifier. The Cloud IDS integration with Event Threat Detection does not include Cloud IDS vulnerability detections. To learn more about Cloud IDS detections, see Cloud IDS Logging information. |
Credential Access: External Member Added To Privileged Group | EXTERNAL_MEMBER_ADDED_TO_PRIVILEGED_GROUP |
Google Workspace Logs: Login Audit Permissions: DATA_READ
|
Detects events where an external member is added to a privileged Google Group (a group granted sensitive roles or permissions). A finding is generated only if the group doesn't already contain other external members from the same organization as the newly added member. To learn more, see Unsafe Google Group changes. Findings are classified as High or Medium severity, depending on the sensitivity of the roles associated with the group change. For more information, see Sensitive IAM roles and permissions. This finding isn't available for project-level activations. |
Credential Access: Privileged Group Opened To Public | PRIVILEGED_GROUP_OPENED_TO_PUBLIC |
Google Workspace: Admin Audit Permissions: DATA_READ
|
Detects events where a privileged Google Group (a group granted sensitive roles or permissions) is changed to be accessible to the general public. To learn more, see Unsafe Google Group changes. Findings are classified as High or Medium severity, depending on the sensitivity of the roles associated with the group change. For more information, see Sensitive IAM roles and permissions. This finding isn't available for project-level activations. |
Credential Access: Sensitive Role Granted To Hybrid Group | SENSITIVE_ROLE_TO_GROUP_WITH_EXTERNAL_MEMBER |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects events where sensitive roles are granted to a Google Group with external members. To learn more, see Unsafe Google Group changes. Findings are classified as High or Medium severity, depending on the sensitivity of the roles associated with the group change. For more information, see Sensitive IAM roles and permissions. This finding isn't available for project-level activations. |
Defense Evasion: Breakglass Workload Deployment Created (Preview) | BINARY_AUTHORIZATION_BREAKGLASS_WORKLOAD_CREATE |
Cloud Audit Logs: Admin Activity logs |
Detects the deployment of workloads that are deployed by using the break-glass flag to override Binary Authorization controls. |
Defense Evasion: Breakglass Workload Deployment Updated (Preview) | BINARY_AUTHORIZATION_BREAKGLASS_WORKLOAD_UPDATE |
Cloud Audit Logs: Admin Activity logs |
Detects when workloads are updated by using the break-glass flag to override Binary Authorization controls. |
Defense Evasion: Modify VPC Service Control | DEFENSE_EVASION_MODIFY_VPC_SERVICE_CONTROL |
Cloud Audit Logs VPC Service Controls audit logs |
Detects a change to an existing VPC Service Controls perimeter that would lead to a reduction in the protection offered by that perimeter. This finding isn't available for project-level activations. |
Discovery: Can get sensitive Kubernetes object check | GKE_CONTROL_PLANE_CAN_GET_SENSITIVE_OBJECT |
Cloud Audit Logs: GKE Data Access logs |
A potentially malicious actor attempted to determine what sensitive objects in
GKE they can query for, by using the
|
Discovery: Service Account Self-Investigation | SERVICE_ACCOUNT_SELF_INVESTIGATION |
Cloud Audit Logs: IAM Data Access audit logs Permissions: DATA_READ
|
Detection of an IAM service account credential that is used t investigate the roles and permissions associated with that same service account. Sensitive roles Findings are classified as High or Medium severity, depending on the sensitivity of the roles granted. For more information, see Sensitive IAM roles and permissions. |
Evasion: Access from Anonymizing Proxy | ANOMALOUS_ACCESS |
Cloud Audit Logs: Admin Activity logs |
Detection of Google Cloud service modifications that originated from anonymous proxy IP addresses, like Tor IP addresses. |
Exfiltration: BigQuery Data Exfiltration | DATA_EXFILTRATION_BIG_QUERY |
Cloud Audit Logs:
BigQueryAuditMetadata data access logs Permissions: DATA_READ
|
Detects the following scenarios:
|
Exfiltration: BigQuery Data Extraction | DATA_EXFILTRATION_BIG_QUERY_EXTRACTION |
Cloud Audit Logs:
BigQueryAuditMetadata data access logs Permissions: DATA_READ
|
Detects the following scenarios:
For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization. |
Exfiltration: BigQuery Data to Google Drive | DATA_EXFILTRATION_BIG_QUERY_TO_GOOGLE_DRIVE |
Cloud Audit Logs:
BigQueryAuditMetadata data access logs Permissions: DATA_READ
|
Detects the following:
|
Exfiltration: Move to Public BigQuery resource | DATA_EXFILTRATION_BIG_QUERY_TO_PUBLIC_RESOURCE |
Cloud Audit Logs:
BigQueryAuditMetadata data access logs Permissions: DATA_READ
|
Detects the following:
|
Exfiltration: Cloud SQL Data Exfiltration |
CLOUDSQL_EXFIL_EXPORT_TO_EXTERNAL_GCS
|
Cloud Audit Logs:
MySQL data access logs PostgreSQL data access logs SQL Server data access logs |
Detects the following scenarios:
For project-level activations of the Security Command Center Premium tier, this finding is available only if the Standard tier is enabled in the parent organization. |
Exfiltration: Cloud SQL Restore Backup to External Organization | CLOUDSQL_EXFIL_RESTORE_BACKUP_TO_EXTERNAL_INSTANCE |
Cloud Audit Logs:
MySQL admin activity logs PostgreSQL admin activity logs SQL Server admin activity logs |
Detects events where the backup of a Cloud SQL instance is restored to an instance outside of the organization. |
Exfiltration: Cloud SQL Over-Privileged Grant | CLOUDSQL_EXFIL_USER_GRANTED_ALL_PERMISSIONS |
Cloud Audit Logs:
PostgreSQL data access logs Note: You must enable the pgAudit extension to use this rule. |
Detects events where a Cloud SQL for PostgreSQL user or role has been granted all privileges to a database, or to all tables, procedures, or functions in a schema. |
Initial Access: Database Superuser Writes to User Tables | CLOUDSQL_SUPERUSER_WRITES_TO_USER_TABLES |
Cloud Audit Logs:
Cloud SQL for PostgreSQL data access logs Cloud SQL for MySQL data access logs Note: You must enable the pgAudit extension for PostgreSQL or database auditing for MySQL to use this rule. |
Detects events where a Cloud SQL superuser (postgres for PostgreSQL
servers or root for MySQL users) writes to non-system tables.
|
Privilege Escalation: AlloyDB Over-Privileged Grant | ALLOYDB_USER_GRANTED_ALL_PERMISSIONS |
Cloud Audit Logs:
AlloyDB for PostgreSQL data access logs Note: You must enable the pgAudit extension to use this rule. |
Detects events where an AlloyDB for PostgreSQL user or role has been granted all privileges to a database, or to all tables, procedures, or functions in a schema. |
Privilege Escalation: AlloyDB Database Superuser Writes to User Tables | ALLOYDB_SUPERUSER_WRITES_TO_USER_TABLES |
Cloud Audit Logs:
AlloyDB for PostgreSQL data access logs Note: You must enable the pgAudit extension to use this rule. |
Detects events where an AlloyDB for PostgreSQL superuser (postgres ) writes
to non-system tables.
|
Initial Access: Dormant Service Account Action | DORMANT_SERVICE_ACCOUNT_USED_IN_ACTION |
Cloud Audit Logs: Admin Activity logs | Detects events where a dormant user-managed service account triggered an action. In this context, a service account is considered dormant if it has been inactive for more than 180 days. |
Privilege Escalation: Dormant Service Account Granted Sensitive Role | DORMANT_SERVICE_ACCOUNT_ADDED_IN_IAM_ROLE |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects events where a dormant user-managed service account was granted one or more sensitive IAM roles. In this context, a service account is considered dormant if it has been inactive for more than 180 days. Sensitive roles Findings are classified as High or Medium severity, depending on the sensitivity of the roles granted. For more information, see Sensitive IAM roles and permissions. |
Persistence: Impersonation Role Granted For Dormant Service Account | DORMANT_SERVICE_ACCOUNT_IMPERSONATION_ROLE_GRANTED |
Cloud Audit Logs: IAM Admin Activity audit logs | Detects events where a principal is granted permissions to impersonate a dormant user-managed service account. In this context, a service account is considered dormant if it has been inactive for more than 180 days. |
Initial Access: Dormant Service Account Key Created | DORMANT_SERVICE_ACCOUNT_KEY_CREATED |
Cloud Audit Logs: Admin Activity logs | Detects events where a key is created for a dormant user-managed service account. In this context, a service account is considered dormant if it has been inactive for more than 180 days. |
Initial Access: Leaked Service Account Key Used | LEAKED_SA_KEY_USED |
Cloud Audit Logs:
Admin Activity logs Data Access logs |
Detects events where a leaked service account key is used to authenticate the action. In this context, a leaked service account key is one that was posted on the public internet. |
Initial Access: Excessive Permission Denied Actions | EXCESSIVE_FAILED_ATTEMPT |
Cloud Audit Logs: Admin Activity logs | Detects events where a principal repeatedly triggers permission denied errors by attempting changes across multiple methods and services. |
Impair Defenses: Strong Authentication Disabled |
ENFORCE_STRONG_AUTHENTICATION
|
Google Workspace: Admin Audit |
2-step verification was disabled for the organization. This finding isn't available for project-level activations. |
Impair Defenses: Two Step Verification Disabled |
2SV_DISABLE
|
Google Workspace Logs: Login Audit Permissions: DATA_READ
|
A user disabled 2-step verification. This finding isn't available for project-level activations. |
Initial Access: Account Disabled Hijacked |
ACCOUNT_DISABLED_HIJACKED
|
Google Workspace Logs: Login Audit Permissions: DATA_READ
|
A user's account was suspended due to suspicious activity. This finding isn't available for project-level activations. |
Initial Access: Disabled Password Leak |
ACCOUNT_DISABLED_PASSWORD_LEAK
|
Google Workspace Logs: Login Audit Permissions: DATA_READ
|
A user's account is disabled because a password leak was detected. This finding isn't available for project-level activations. |
Initial Access: Government Based Attack |
GOV_ATTACK_WARNING
|
Google Workspace Logs: Login Audit Permissions: DATA_READ
|
Government-backed attackers might have tried to compromise a user account or computer. This finding isn't available for project-level activations. |
Initial Access: Log4j Compromise Attempt | Unavailable |
Cloud Load Balancing Logs: Cloud HTTP Load Balancer Note: You must enable external Application Load Balancer logging to use this rule. |
Detects Java Naming and Directory Interface (JNDI) lookups within headers or URL parameters. These lookups may indicate attempts at Log4Shell exploitation. These findings have low severity, because they only indicate a detection or exploit attempt, not a vulnerability or a compromise. This rule is always on. |
Initial Access: Suspicious Login Blocked |
SUSPICIOUS_LOGIN
|
Google Workspace Logs: Login Audit Permissions: DATA_READ
|
A suspicious login to a user's account was detected and blocked. This finding isn't available for project-level activations. |
Log4j Malware: Bad Domain | LOG4J_BAD_DOMAIN |
Cloud DNS logs | Detection of Log4j exploit traffic based on a connection to, or a lookup of, a known domain used in Log4j attacks. |
Log4j Malware: Bad IP | LOG4J_BAD_IP |
VPC flow logs Firewall Rules logs Cloud NAT logs |
Detection of Log4j exploit traffic based on a connection to a known IP address used in Log4j attacks. |
Malware: bad domain | MALWARE_BAD_DOMAIN |
Cloud DNS logs | Detection of malware based on a connection to, or a lookup of, a known bad domain. |
Malware: bad IP | MALWARE_BAD_IP |
VPC flow logs Firewall Rules logs Cloud NAT logs |
Detection of malware based on a connection to a known bad IP address. |
Malware: Cryptomining Bad Domain | CRYPTOMINING_POOL_DOMAIN |
Cloud DNS logs | Detection of cryptomining based on a connection to, or a lookup of, a known mining domain. |
Malware: Cryptomining Bad IP | CRYPTOMINING_POOL_IP |
VPC flow logs Firewall Rules logs Cloud NAT logs |
Detection of cryptomining based on a connection to a known mining IP address. |
Outgoing DoSShut down | OUTGOING_DOS |
VPC flow logs | Detection of outgoing denial of service traffic. |
Persistence: GCE Admin Added SSH Key | GCE_ADMIN_ADD_SSH_KEY |
Cloud Audit Logs: Compute Engine audit logs |
Detection of a modification to the Compute Engine instance metadata ssh key value on an established instance (older than 1 week). |
Persistence: GCE Admin Added Startup Script | GCE_ADMIN_ADD_STARTUP_SCRIPT |
Cloud Audit Logs: Compute Engine audit logs |
Detection of a modification to the Compute Engine instance metadata startup script value on an established instance (older than 1 week). |
Persistence: IAM Anomalous Grant | IAM_ANOMALOUS_GRANT |
Cloud Audit Logs>: IAM Admin Activity audit logs |
This finding includes subrules that provide more specific information about each instance of this finding. The following list shows all possible subrules:
|
Persistence: Unmanaged Account Granted Sensitive Role (Preview) | UNMANAGED_ACCOUNT_ADDED_IN_IAM_ROLE |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detection of a sensitive role being granted to an unmanaged account. |
Persistence: New API Method |
ANOMALOUS_BEHAVIOR_NEW_API_METHOD |
Cloud Audit Logs: Admin Activity logs |
Detection of anomalous usage of Google Cloud services by IAM service accounts. |
Persistence: New Geography | IAM_ANOMALOUS_BEHAVIOR_IP_GEOLOCATION |
Cloud Audit Logs: Admin Activity logs |
Detection of IAM user and service accounts accessing Google Cloud from anomalous locations, based on the geolocation of the requesting IP addresses. This finding isn't available for project-level activations. |
Persistence: New User Agent | IAM_ANOMALOUS_BEHAVIOR_USER_AGENT |
Cloud Audit Logs: Admin Activity logs |
Detection of IAM service accounts accessing Google Cloud from anomalous or suspicious user agents. This finding isn't available for project-level activations. |
Persistence: SSO Enablement Toggle |
TOGGLE_SSO_ENABLED
|
Google Workspace: Admin Audit |
The Enable SSO (single sign-on) setting on the admin account was disabled. This finding isn't available for project-level activations. |
Persistence: SSO Settings Changed |
CHANGE_SSO_SETTINGS
|
Google Workspace: Admin Audit |
The SSO settings for the admin account were changed. This finding isn't available for project-level activations. |
Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity | ANOMALOUS_SA_DELEGATION_IMPERSONATION_OF_SA_ADMIN_ACTIVITY |
Cloud Audit Logs: Admin Activity logs |
Detects when a potentially anomalous impersonated service account is used for an administrative activity. |
Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity | ANOMALOUS_SA_DELEGATION_MULTISTEP_ADMIN_ACTIVITY |
Cloud Audit Logs: Admin Activity logs |
Detects when an anomalous multistep delegated request is found for an administrative activity. |
Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access | ANOMALOUS_SA_DELEGATION_MULTISTEP_DATA_ACCESS |
Cloud Audit Logs: Data Access logs |
Detects when an anomalous multistep delegated request is found for a data access activity. |
Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity | ANOMALOUS_SA_DELEGATION_IMPERSONATOR_ADMIN_ACTIVITY |
Cloud Audit Logs: Admin Activity logs |
Detects when a potentially anomalous caller/impersonator in a delegation chain is used for an administrative activity. |
Privilege Escalation: Anomalous Service Account Impersonator for Data Access | ANOMALOUS_SA_DELEGATION_IMPERSONATOR_DATA_ACCESS |
Cloud Audit Logs: Data Access logs |
Detects when a potentially anomalous caller/impersonator in a delegation chain is used for a data access activity. |
Privilege Escalation: Changes to sensitive Kubernetes RBAC objects | GKE_CONTROL_PLANE_EDIT_SENSITIVE_RBAC_OBJECT |
Cloud Audit Logs: GKE Admin Activity logs |
To escalate privilege, a potentially malicious actor attempted to modify a
ClusterRole , RoleBinding , or ClusterRoleBinding
role-based access control (RBAC) object of the sensitive
cluster-admin
role by using a PUT or PATCH request.
|
Privilege Escalation: Create Kubernetes CSR for master cert | GKE_CONTROL_PLANE_CSR_FOR_MASTER_CERT |
Cloud Audit Logs: GKE Admin Activity logs |
A potentially malicious actor created a Kubernetes master
certificate signing request
(CSR), which gives them
cluster-admin
access.
|
Privilege Escalation: Creation of sensitive Kubernetes bindings | GKE_CONTROL_PLANE_CREATE_SENSITIVE_BINDING |
Cloud Audit Logs: IAM Admin Activity audit logs |
To escalate privilege, a potentially malicious actor attempted to create a new
RoleBinding or ClusterRoleBinding object for the
cluster-admin
role.
|
Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials | GKE_CONTROL_PLANE_GET_CSR_WITH_COMPROMISED_BOOTSTRAP_CREDENTIALS |
Cloud Audit Logs: GKE Data Access logs |
A potentially malicious actor queried for a
certificate signing request
(CSR), with the kubectl command, using compromised bootstrap credentials.
|
Privilege Escalation: Launch of privileged Kubernetes container | GKE_CONTROL_PLANE_LAUNCH_PRIVILEGED_CONTAINER |
Cloud Audit Logs: GKE Admin Activity logs |
A potentially malicious actor created a Pod that contains privileged containers or containers with privilege escalation capabilities.
A privileged container has the |
Persistence: Service Account Key Created | SERVICE_ACCOUNT_KEY_CREATION |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects the creation of a service account key. Service account keys are long-lived credentials that increase the risk of unauthorized access to Google Cloud resources. |
Privilege Escalation: Global Shutdown Script Added | GLOBAL_SHUTDOWN_SCRIPT_ADDED |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects when a global shutdown script is added to a project. |
Persistence: Global Startup Script Added | GLOBAL_STARTUP_SCRIPT_ADDED |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects when a global startup script is added to a project. |
Defense Evasion: Organization-Level Service Account Token Creator Role Added | ORG_LEVEL_SERVICE_ACCOUNT_TOKEN_CREATOR_ROLE_ADDED |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects when the Service Account Token Creator IAM role is granted at the organization level. |
Defense Evasion: Project-Level Service Account Token Creator Role Added | PROJECT_LEVEL_SERVICE_ACCOUNT_TOKEN_CREATOR_ROLE_ADDED |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects when the Service Account Token Creator IAM role is granted at the project level. |
Lateral Movement: OS Patch Execution From Service Account | OS_PATCH_EXECUTION_FROM_SERVICE_ACCOUNT |
Cloud Audit Logs. IAM Admin Activity audit logs |
Detects when a service account uses the Compute Engine Patch feature to update the operating system of any currently running Compute Engine instance. |
Lateral Movement: Modified Boot Disk Attached to Instance (Preview) | MODIFY_BOOT_DISK_ATTACH_TO_INSTANCE |
Cloud Audit Logs: Compute Engine audit logs |
Detects when a boot disk is detached from one Compute Engine instance and attached to another, which could indicate a malicious attempt to compromise the system using a modified boot disk. |
Credential Access: Secrets Accessed In Kubernetes Namespace | SECRETS_ACCESSED_IN_KUBERNETES_NAMESPACE |
Cloud Audit Logs: GKE Data Access logs |
Detects when secrets or service account tokens are accessed by a service account in the current Kubernetes namespace. |
Resource Development: Offensive Security Distro Activity | OFFENSIVE_SECURITY_DISTRO_ACTIVITY |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects successful Google Cloud resource manipulations from known penetration testing or offensive security distros. |
Privilege Escalation: New Service Account is Owner or Editor | SERVICE_ACCOUNT_EDITOR_OWNER |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects when a new service account is created with Editor or Owner roles for a project. |
Discovery: Information Gathering Tool Used | INFORMATION_GATHERING_TOOL_USED |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects the use of ScoutSuite, a cloud security auditing tool that is known to be used by threat actors. |
Privilege Escalation: Suspicious Token Generation | SUSPICIOUS_TOKEN_GENERATION_IMPLICIT_DELEGATION |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects when the iam.serviceAccounts.implicitDelegation permission is
abused to generate access tokens from a more privileged service account.
|
Privilege Escalation: Suspicious Token Generation | SUSPICIOUS_TOKEN_GENERATION_SIGN_JWT |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects when a service account uses the
serviceAccounts.signJwt
method to generate an access token for another service account.
|
Privilege Escalation: Suspicious Token Generation | SUSPICIOUS_TOKEN_GENERATION_CROSS_PROJECT_OPENID |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects cross-project use of the This finding isn't available for project-level activations. |
Privilege Escalation: Suspicious Token Generation | SUSPICIOUS_TOKEN_GENERATION_CROSS_PROJECT_ACCESS_TOKEN |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects cross-project use of the This finding isn't available for project-level activations. |
Privilege Escalation: Suspicious Cross-Project Permission Use | SUSPICIOUS_CROSS_PROJECT_PERMISSION_DATAFUSION |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects cross-project use of the This finding isn't available for project-level activations. |
Command and Control: DNS Tunneling | DNS_TUNNELING_IODINE_HANDSHAKE |
Cloud DNS logs | Detects the handshake of the DNS tunneling tool Iodine. |
Defense Evasion: VPC Route Masquerade Attempt | VPC_ROUTE_MASQUERADE |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects the manual creation of VPC routes masquerading as Google Cloud default routes, allowing egress traffic to external IP addresses. |
Impact: Billing Disabled | BILLING_DISABLED_SINGLE_PROJECT |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects when billing has been disabled for a project. |
Impact: Billing Disabled | BILLING_DISABLED_MULTIPLE_PROJECTS |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects when billing has been disabled for multiple projects in an organization within a short time period. |
Impact: VPC Firewall High Priority Block | VPC_FIREWALL_HIGH_PRIORITY_BLOCK |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects when a VPC firewall rule that blocks all traffic is added at priority 0. |
Impact: VPC Firewall Mass Rule DeletionTemporarily unavailable | VPC_FIREWALL_MASS_RULE_DELETION |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects the mass deletion of VPC firewall rules by non-service accounts. This rule is temporarily unavailable. To monitor updates to your firewall rules, use the Cloud audit logs. |
Impact: Service API Disabled | SERVICE_API_DISABLED |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects when a Google Cloud service API is disabled in a production environment. |
Impact: Managed Instance Group Autoscaling Set To Maximum | MIG_AUTOSCALING_SET_TO_MAX |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects when a managed instance group is configured for maximum autoscaling. |
Discovery: Unauthorized Service Account API Call | UNAUTHORIZED_SERVICE_ACCOUNT_API_CALL |
Cloud Audit Logs: IAM Admin Activity audit logs |
Detects when a service account makes an unauthorized cross-project API call. |
Defense Evasion: Anonymous Sessions Granted Cluster Admin Access | ANONYMOUS_SESSIONS_GRANTED_CLUSTER_ADMIN |
Cloud Audit Logs: GKE Admin Activity logs |
Detects the creation of a role-based access control (RBAC)
ClusterRoleBinding object adding the
root-cluster-admin-binding behavior to anonymous users.
|
Initial Access: Anonymous GKE Resource Created from the Internet (Preview) | GKE_RESOURCE_CREATED_ANONYMOUSLY_FROM_INTERNET |
Cloud Audit Logs: GKE Admin Activity logs |
Detects resource creation events from effectively anonymous internet users. |
Initial Access: GKE Resource Modified Anonymously from the Internet (Preview) | GKE_RESOURCE_MODIFIED_ANONYMOUSLY_FROM_INTERNET |
Cloud Audit Logs: GKE Admin Activity logs |
Detects resource manipulation events from effectively anonymous internet users. |
Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access (Preview) | GKE_ANONYMOUS_USERS_GRANTED_ACCESS |
Cloud Audit Logs: GKE Admin Activity logs |
Someone created an RBAC binding that references one of the following users or groups:
These users and groups are effectively anonymous and should be avoided when creating role bindings or cluster role bindings to any RBAC roles. Review the binding to ensure that it is necessary. If the binding isn't necessary, remove it. |
Execution: Suspicious Exec or Attach to a System Pod (Preview) | GKE_SUSPICIOUS_EXEC_ATTACH |
Cloud Audit Logs: GKE Admin Activity logs |
Someone used the exec or attach commands to get a shell or
execute a command on a container running in the kube-system namespace.
These methods are sometimes used for legitimate debugging purposes. However, the
kube-system namespace is intended for system objects created by Kubernetes,
and unexpected command execution or shell creation should be reviewed.
|
Privilege Escalation: Workload Created with a Sensitive Host Path Mount (Preview) | GKE_SENSITIVE_HOSTPATH |
Cloud Audit Logs: GKE Admin Activity logs |
Someone created a workload that contains a hostPath volume mount to a
sensitive path on the host node's file system. Access to these paths on the host
filesystem can be used to access privileged or sensitive information on the node and for
container escapes. If possible, don't allow any hostPath volumes in your
cluster.
|
Privilege Escalation: Workload with shareProcessNamespace enabled (Preview) | GKE_SHAREPROCESSNAMESPACE_POD |
Cloud Audit Logs: GKE Admin Activity logs |
Someone deployed a workload with the shareProcessNamespace option set to
true , allowing all containers to share the same Linux process namespace.
This could allow an untrusted or compromised container to escalate privileges by
accessing and controlling environment variables, memory, and other sensitive data from
processes running in other containers.
|
Privilege Escalation: ClusterRole with Privileged Verbs (Preview) | GKE_CLUSTERROLE_PRIVILEGED_VERBS |
Cloud Audit Logs: GKE Admin Activity logs |
Someone created an RBAC ClusterRole that contains the bind ,
escalate , or impersonate verbs. A subject that's bound to a
role with these verbs can impersonate other users with higher privileges, bind to
additional Roles or ClusterRoles that contain additional
permissions, or modify their own ClusterRole permissions. This might lead to those
subjects gaining cluster-admin privileges.
|
Privilege Escalation: ClusterRoleBinding to Privileged Role (Preview) | GKE_CRB_CLUSTERROLE_AGGREGATION_CONTROLLER |
Cloud Audit Logs: GKE Admin Activity logs |
Someone created an RBAC ClusterRoleBinding that references the default
system:controller:clusterrole-aggregation-controller
ClusterRole . This default ClusterRole has the
escalate verb, which allows subjects to modify the privileges of their own
roles, allowing for privilege escalation.
|
Defense Evasion: Manually Deleted Certificate Signing Request (CSR) (Preview) | GKE_MANUALLY_DELETED_CSR |
Cloud Audit Logs: GKE Admin Activity logs |
Someone manually deleted a certificate signing request (CSR). CSRs are automatically removed by a garbage collection controller, but malicious actors might manually delete them to evade detection. If the deleted CSR was for an approved and issued certificate, the potentially malicious actor now has an additional authentication method to access the cluster. The permissions associated with the certificate vary depending on which subject they included, but can be highly privileged. Kubernetes does not support certificate revocation. |
Credential Access: Failed Attempt to Approve Kubernetes Certificate Signing Request (CSR) (Preview) | GKE_APPROVE_CSR_FORBIDDEN |
Cloud Audit Logs: GKE Admin Activity logs |
Someone attempted to manually approve a certificate signing request (CSR) but the action failed. Creating a certificate for cluster authentication is a common method for attackers to create persistent access to a compromised cluster. The permissions associated with the certificate vary depending on which subject they included, but can be highly privileged. |
Credential Access: Manually Approved Kubernetes Certificate Signing Request (CSR) (Preview) | GKE_CSR_APPROVED |
Cloud Audit Logs: GKE Admin Activity logs |
Someone manually approved a certificate signing request (CSR). Creating a certificate for cluster authentication is a common method for attackers to create persistent access to a compromised cluster. The permissions associated with the certificate vary depending on which subject they included, but can be highly privileged. |
Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments (Preview) | GKE_REVERSE_SHELL_POD |
Cloud Audit Logs: GKE Admin Activity logs |
Someone created a Pod that contains commands or arguments commonly associated with a reverse shell. Attackers use reverse shells to expand or maintain their initial access to a cluster and to execute arbitrary commands. |
Defense Evasion: Potential Kubernetes Pod Masquerading (Preview) | GKE_POD_MASQUERADING |
Cloud Audit Logs: GKE Admin Activity logs |
Someone deployed a Pod with a naming convention similar to the default workloads that GKE creates for regular cluster operation. This technique is called masquerading. |
Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape (Preview) | GKE_SUSPICIOUS_EXPLOIT_POD |
Cloud Audit Logs: GKE Admin Activity logs |
Someone deployed a Pod with a naming convention similar to common tools used for container escapes or to execute other attacks on the cluster. |
Impact: Suspicious Kubernetes Container Names - Coin Mining (Preview) | GKE_SUSPICIOUS_CRYPTOMINING_POD |
Cloud Audit Logs: GKE Admin Activity logs |
Someone deployed a Pod with a naming convention similar to common cryptocurrency coin miners. This may be an attempt by an attacker who has achieved initial access to the cluster to use the cluster's resources for cryptocurrency mining. |
Custom modules for Event Threat Detection
In addition to built-in detection rules, Event Threat Detection provides module templates that you can use to create custom detection rules. For more information, see Overview of custom modules for Event Threat Detection.
To create detection rules for which no custom module templates are available, you can export your log data to BigQuery, and then run unique or recurring SQL queries that capture your threat models.
Unsafe Google Group changes
This section explains how Event Threat Detection uses Google Workspace logs, Cloud Audit Logs, and IAM policies to detect unsafe Google Groups changes. Detecting Google Groups changes is only supported when you activate Security Command Center at the organization level.
Google Cloud customers can use Google Groups to manage roles and permissions for members in their organizations, or apply access policies to collections of users. Instead of granting roles directly to members, administrators can grant roles and permissions to Google Groups, and then add members to specific groups. Group members inherit all of a group's roles and permissions, which lets members access specific resources and services.
While Google Groups are a convenient way to manage access control at scale, they can pose a risk if external users from outside your organization or domain are added to privileged groups—groups that are granted sensitive roles or permissions. Sensitive roles control access to security and network settings, logs, and personally identifiable information (PII), and are not recommended for external group members.
In large organizations, administrators might not be aware when external members are added to privileged groups. Cloud Audit Logs record role grants to groups, but those log events don't contain information on group members, which can obscure the potential impact of some group changes.
If you share your Google Workspace logs with Google Cloud, Event Threat Detection monitors your logging streams for new members added to your organization's Google Groups. Because the logs are at the organization level, Event Threat Detection can scan Google Workspace logs only when you activate Security Command Center at the organization level. Event Threat Detection can't scan these logs when you activate Security Command Center at the project level.
Event Threat Detection identifies external group members and, using Cloud Audit Logs, reviews each affected group's IAM roles to check whether the groups are granted sensitive roles. That information is used to detect the following unsafe changes for privileged Google Groups:
- External group members added to privileged groups
- Sensitive roles or permissions granted to groups with external group members
- Privileged groups that are changed to allow anyone in the general public to join
Event Threat Detection writes findings to Security Command Center. Findings contain the email addresses of newly added external members, internal group members that initiate events, group names, and the sensitive roles associated with groups. You can use the information to remove external members from groups or revoke sensitive roles granted to groups.
For more information on Event Threat Detection findings, see Event Threat Detection rules.
Sensitive IAM roles and permissions
This section explains how Event Threat Detection defines sensitive IAM roles. Detections like IAM Anomalous Grant and Unsafe Google Group changes generate findings only if changes involve high- or medium-sensitivity roles. The sensitivity of roles impacts the severity rating assigned to findings.
- High-sensitivity roles control critical services in organizations, including billing, firewall settings, and logging. Findings that match these roles are classified as High severity.
- Medium-sensitivity roles have editing permissions
that let principals make changes to Google Cloud resources; and viewing
and executing permissions on data storage services that often hold sensitive
data. The severity assigned to findings depends on the resource:
- If medium-sensitivity roles are granted at the organization level, findings are classified as High severity.
- If medium-sensitivity roles are granted at lower levels in your resource hierarchy (folders, projects, and buckets, among others), findings are classified as Medium severity.
Granting these sensitive roles is considered dangerous if the grantee is an External Member or an abnormal identity, like a principal that has been inactive for a long time.
Granting sensitive roles to external members creates a potential threat because they can be abused for account compromise and data exfiltration.
Finding categories that use these sensitive roles include:
- Persistence: IAM Anomalous Grant
- Subrule:
external_service_account_added_to_policy
- Subrule:
external_member_added_to_policy
- Subrule:
- Credential Access: Sensitive Role Granted To Hybrid Group
- Privilege Escalation: Dormant Service Account Granted Sensitive Role
Finding categories that use a subset of the sensitive roles include:
- Persistence: IAM Anomalous Grant
- Subrule:
service_account_granted_sensitive_role_to_member
- Subrule:
The service_account_granted_sensitive_role_to_member
subrule targets both
external and internal members generally and therefore uses only a subset of
sensitive roles, as explained in Event Threat Detection rules.
Category | Role | Description |
---|---|---|
Basic roles: contain thousands of permissions across all Google Cloud services. | roles/owner |
Basic roles |
roles/editor |
||
Security roles: control access to security settings | roles/cloudkms.* |
All Cloud Key Management Service roles |
roles/cloudsecurityscanner.* |
All Web Security Scanner roles | |
roles/dlp.* |
All Sensitive Data Protection roles | |
roles/iam.* |
All IAM roles | |
roles/secretmanager.* |
All Secret Manager roles | |
roles/securitycenter.* |
All Security Command Center roles | |
Logging roles: control access to an organization's logs | roles/errorreporting.* |
All Error Reporting roles |
roles/logging.* |
All Cloud Logging roles | |
roles/stackdriver.* |
All Cloud Monitoring roles | |
Personal information roles: control access to resources that contain personally identifiable information, including banking and contact information | roles/billing.* |
All Cloud Billing roles |
roles/healthcare.* |
All Cloud Healthcare API roles | |
roles/essentialcontacts.* |
All Essential Contacts roles | |
Networking roles: control access to an organization's network settings | roles/dns.* |
All Cloud DNS roles |
roles/domains.* |
All Cloud Domains roles | |
roles/networkconnectivity.* |
All Network Connectivity Center roles | |
roles/networkmanagement.* |
All Network Connectivity Center roles | |
roles/privateca.* |
All Certificate Authority Service roles | |
Service roles: control access to service resources in Google Cloud | roles/cloudasset.* |
All Cloud Asset Inventory roles |
roles/servicedirectory.* |
All Service Directory roles | |
roles/servicemanagement.* |
All Service Management roles | |
roles/servicenetworking.* |
All Service Networking roles | |
roles/serviceusage.* |
All Service Usage roles | |
Compute Engine roles: control access to Compute Engine virtual machines, which carry long-running jobs and are associated with firewall rules |
|
All Compute Engine Admin and Editor roles |
Category | Role | Description |
---|---|---|
Editing roles: IAM roles that include permissions to make changes to Google Cloud resources |
Examples:
|
Role names usually end with titles like Admin, Owner, Editor, or Writer. Expand the node in the last row of the table to see All medium-sensitivity roles |
Data storage roles: IAM roles that include permissions to view and execute data storage services |
Examples:
|
Expand the node in the last row of the table to see All medium-sensitivity roles |
All medium-sensitivity roles
Managed Service for Microsoft Active Directory
Vertex AI Workbench user-managed notebooks
|
Log types and activation requirements
This section lists the logs that Event Threat Detection uses, along with the threats that Event Threat Detection looks for in each log, and what, if anything, you need to do to turn on each log.
You need to turn a log on for Event Threat Detection only if all of the following are true:
- You are using the product or service that writes to the log.
- You need to protect the product or service against the threats that Event Threat Detection detects in the log.
- The log is a data access audit log or other log that is off by default.
Certain threats can be detected in multiple logs. If Event Threat Detection can detect a threat in a log that is already turned on, you don't need to turn on another log to detect that same threat.
If a log isn't listed in this section, Event Threat Detection does not scan it, even if it is turned on. For more information, see Potentially redundant log scans.
As described in the following table, some log types are only available at the organization level. If you activate Security Command Center at the project level, Event Threat Detection doesn't scan these logs and doesn't produce any findings.
Potentially redundant log scans
Event Threat Detection can provide network detection of malware by scanning any one of the following logs:
- Cloud DNS logging
- Cloud NAT logging
- Firewall Rules Logging
- VPC Flow Logs
If you are already using Cloud DNS logging, Event Threat Detection can detect malware using domain resolution. For most users, the Cloud DNS logs are sufficient for the network detection of malware.
If you need another level of visibility beyond domain resolution, you can turn on VPC Flow Logs, but VPC Flow Logs can incur costs. To manage these costs, we recommend increasing the aggregation interval to 15 minutes and reducing the sample rate to between 5% and 10%, but there is a tradeoff between recall (higher sample) and cost management (lower sample rate).
If you are already using Firewall Rules Logging or Cloud NAT logging, these logs are useful in place of VPC Flow Logs.
You don't need to enable more than one of Cloud NAT logging, Firewall Rules Logging, or VPC Flow Logs.
Logs that you need to turn on
This section lists the Cloud Logging and Google Workspace logs that you can turn on or otherwise configure to increase the number of threats that Event Threat Detection can detect.
Certain threats, such as threats posed by the anomalous impersonation or delegation of a service account, can be found in most audit logs. For these types of threats, you determine which logs you need to turn on based on the products and services you are using.
The following table shows specific logs you need to turn on for threats that can be detected in only certain specific log types.
Log type | Threats detected | Configuration required |
---|---|---|
Cloud DNS logging |
|
Turn on Cloud DNS logging |
Cloud NAT logging |
|
Turn on Cloud NAT logging |
Firewall Rules Logging |
|
Turn on Firewall Rules Logging. |
Google Kubernetes Engine (GKE) Data Access audit logs |
|
Activate Logging Data Access audit logs for GKE |
Google Workspace Admin Audit logs |
|
Share Google Workspace Admin Audit logs with Cloud Logging This log type can't be scanned in project-level activations. |
Google Workspace Login Audit logs |
|
Share Google Workspace Login Audit logs with Cloud Logging This log type can't be scanned in project-level activations. |
External Application Load Balancer backend service logs | Initial Access: Log4j Compromise Attempt |
Turn on external Application Load Balancer logging |
Cloud SQL MySQL Data Access audit logs | Exfiltration: Cloud SQL Data Exfiltration |
Activate Logging Data Access audit logs for Cloud SQL for MySQL |
Cloud SQL PostgreSQL Data Access audit logs |
|
|
AlloyDB for PostgreSQL Data Access audit logs |
|
|
IAM Data Access audit logs |
Discovery: Service Account Self-Investigation
|
Activate Logging Data Access audit logs for Resource Manager |
SQL Server Data Access audit logs | Exfiltration: Cloud SQL Data Exfiltration |
Activate Logging Data Access audit logs for Cloud SQL for SQL Server |
Generic Data Access audit logs |
|
Activate Logging Data Access audit logs. |
authlogs/authlog on virtual machines | Brute force SSH |
Install the Ops Agent or the legacy Logging agent on your VM hosts |
VPC Flow Logs |
|
Turn on VPC Flow Logs |
Backup and DR audit logging |
|
Enable Backup and DR audit logging |
Logs that are always on
The following table lists the Cloud Logging logs that you don't need to turn on or configure. These logs are always on and Event Threat Detection scans them automatically.
Log type | Threats detected | Configuration required |
---|---|---|
BigQueryAuditMetadata Data Access logs |
Exfiltration: BigQuery Data Exfiltration Exfiltration: BigQuery Data Extraction Exfiltration: BigQuery Data to Google Drive Exfiltration: Move to Public BigQuery resource (Preview) |
None |
Google Kubernetes Engine (GKE) Admin Activity audit logs |
Privilege Escalation: Changes to sensitive Kubernetes RBAC objects Privilege Escalation: Creation of sensitive Kubernetes bindings Privilege Escalation: Launch of privileged Kubernetes container Privilege Escalation: Create Kubernetes CSR for master cert Defense Evasion: Anonymous Sessions Granted Cluster Admin Access Initial Access: Anonymous GKE Resource Created from the Internet (Preview) Initial Access: GKE Resource Modified Anonymously from the Internet (Preview) Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access (Preview) Execution: Suspicious Exec or Attach to a System Pod (Preview) Privilege Escalation: Workload Created with a Sensitive Host Path Mount (Preview) Privilege Escalation: Workload with shareProcessNamespace enabled (Preview) Privilege Escalation: ClusterRole with Privileged Verbs (Preview) Privilege Escalation: ClusterRoleBinding to Privileged Role (Preview) Defense Evasion: Manually Deleted Certificate Signing Request (CSR) (Preview) Credential Access: Failed Attempt to Approve Kubernetes Certificate Signing Request (CSR) (Preview) Credential Access: Manually Approved Kubernetes Certificate Signing Request (CSR) (Preview) Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments (Preview) Defense Evasion: Potential Kubernetes Pod Masquerading (Preview) Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape (Preview) Impact: Suspicious Kubernetes Container Names - Coin Mining (Preview) |
None |
IAM Admin Activity audit logs |
Credential Access: Sensitive Role Granted To Hybrid Group Privilege Escalation: Dormant Service Account Granted Sensitive Role Persistence: Impersonation Role Granted For Dormant Service Account Persistence: IAM Anomalous Grant (Preview) Persistence: Unmanaged Account Granted Sensitive Role |
None |
MySQL Admin Activity logs | Exfiltration: Cloud SQL Restore Backup to External Organization | None |
PostgreSQL Admin Activity logs | Exfiltration: Cloud SQL Restore Backup to External Organization | None |
SQL Server Admin Activity logs | Exfiltration: Cloud SQL Restore Backup to External Organization | None |
Generic Admin Activity audit logs |
Initial Access: Dormant Service Account Action> Initial Access: Dormant Service Account Key Created Initial Access: Excessive Permission Denied Actions Initial Access: Leaked Service Account Key Used Persistence: Compute Engine Admin Added SSH Key Persistence: Compute Engine Admin Added Startup Script Persistence: New API Method Persistence: New Geography Persistence: New User Agent Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity Lateral Movement: Modified Boot Disk Attached to Instance (Preview) |
None |
VPC Service Controls Audit logs | Defense Evasion: Modify VPC Service Control (Preview) | None |
What's next
- Learn about using Event Threat Detection.
- Learn how to investigate and develop response plans for threats.