Verify that Event Threat Detection is working by intentionally triggering the detectors, viewing the findings in Security Command Center or Cloud Logging, and then cleaning up the test resources.
Event Threat Detection is a built-in service that monitors your organization's Cloud Logging and Google Workspace logging streams and detects threats in near-real time. To learn more, read Event Threat Detection overview.
Before you begin
To test Event Threat Detection, verify the following prerequisites:
- Service enablement: to view Event Threat Detection findings, the service must be enabled in Security Command Center Services settings.
- IAM permissions: depending on which detector you want to test, you must have one of the following roles:
- IAM Anomalous Grant: an Identity and Access Management (IAM) role with the
resourcemanager.projects.setIamPolicypermission, like the Project IAM Admin role. - Malware: Bad Domain: an IAM role with the
compute.instances.createanddns.policies.createpermissions, like the Project Editor role. - SSH Brute Force: an IAM role with the
compute.instances.createpermission, like the Compute Instance Admin (v1) role or Project Editor role.
- IAM Anomalous Grant: an Identity and Access Management (IAM) role with the
Trigger test findings
To verify that Event Threat Detection generates findings, select one of the following detectors to trigger:
- IAM Anomalous Grant detector: trigger this detector by granting a sensitive role to an external test user account.
- Malware: Bad Domain detector: trigger this detector by executing a query to a test bad domain from a VM instance.
- SSH Brute Force detector: trigger this detector by configuring a VM instance to stream system authentication logs. Then, simulate multiple failed SSH sign-in attempts, followed by a successful sign in.
Trigger the IAM Anomalous Grant detector
To trigger the IAM Anomalous Grant detector, create an external test user and grant the Project Owner role:
Create a test user with a personal
@gmail.comemail address. Make sure that this@gmail.comaccount doesn't already have any IAM permissions in the project where you are performing the test.In the Google Cloud console, go to the IAM page.
Click Grant access.
In the New principals field, enter the test user's
@gmail.comaddress.In the Select a role drop-down list, select Project > Owner.
Click Save.
Trigger the Malware: Bad Domain detector
To trigger the Malware: Bad Domain detector, create a VM instance with DNS query logging enabled and then query a test domain:
- Create a VM instance on a VPC network. For instructions, see Create and start a VM instance. Ensure that the project containing the VM instance is in scope for Event Threat Detection. That is, Event Threat Detection service is enabled for the project or its parent organization.
To enable logging, configure a DNS server policy for the VPC network:
In the Google Cloud console, go to the Cloud DNS page.
Select the DNS server policies tab.
Click Create policy.
In the Name field, enter a name for the policy.
Under Logs, select On to enable logging of DNS queries.
Under Networks, select the VPC network that your VM instance uses.
Click Create.
In the Google Cloud console, go to the VM instances page.
In the list of virtual machine instances, click SSH in the row of the VM instance you created. A terminal window opens on your VM instance.
Run the following command:
curl etd-malware-trigger.goog
Trigger the SSH Brute Force detector
To trigger the SSH Brute Force detector, configure authentication logging and simulate failed SSH sign-in attempts:
- Create a Linux VM instance (such as Debian) on a VPC network. For instructions, see Create and start a VM instance. Ensure that the project containing the VM instance is in scope for Event Threat Detection.
In the Google Cloud console, go to the VM instances page.
In the list of virtual machine instances, click SSH in the row of the VM instance you created. A terminal window opens on your VM instance.
Enable SSH password authentication on the VM instance:
Open the SSH daemon configuration file in a text editor:
sudo vim /etc/ssh/sshd_configSet
PasswordAuthenticationtoyes:PasswordAuthentication yesRestart the SSH service:
sudo systemctl restart ssh
Create a test user account with a password:
sudo adduser TEST_USERFollow the prompts to specify a password for the test user.
To stream authentication logs to Cloud Logging, install the Ops Agent on the VM instance. For instructions, see Install the Ops Agent.
From an external host or terminal with network access to the VM instance, attempt to sign in to the VM instance by using SSH with incorrect credentials 8 consecutive times:
ssh TEST_USER@INSTANCE_IP_ADDRESSWhen prompted for a password, enter an incorrect password. Repeat this 8 times.
Sign in with the correct password:
ssh TEST_USER@INSTANCE_IP_ADDRESSWhen prompted, enter the correct password for TEST_USER.
Verify that the authentication logs appear in Cloud Logging under the log ID
authlog.
View findings
After triggering findings by testing a detector, verify that the findings are generated by viewing them in Security Command Center or Cloud Logging:
View findings in Security Command Center
To view the Event Threat Detection finding in Security Command Center, do the following:
In the Google Cloud console, go to the Security Command Center Findings page.
In the Category section of the Quick filters panel, select the finding category:
- For IAM Anomalous Grant, select Persistence: IAM anomalous grant (click View more if necessary).
- For Malware: Bad Domain, select Malware: Bad Domain (click View more if necessary).
- For SSH Brute Force, select Brute Force: SSH (click View more if necessary).
To sort the list in the Findings query results panel, click the Event time column header so that the most recent finding displays first.
In the Findings query results panel, display the details of the finding by clicking the category name (Persistence: IAM Anomalous Grant, Malware: Bad Domain, or Brute Force: SSH) in the Category column. The details panel for the finding opens and displays the Summary tab.
Verify the details of the finding:
- For IAM anomalous grant, check that the value on the Principal
email row contains your test
gmail.comemail address. - For Malware: Bad Domain, select the Source properties tab and check
that the Domains row contains
etd-malware-trigger.goog. - For SSH Brute Force, check that the User name matches your test username and that the Caller IP matches the IP address from which you performed the sign-in attempts.
- For IAM anomalous grant, check that the value on the Principal
email row contains your test
View findings in Cloud Logging
If you enabled logging findings to Cloud Logging, you can view the findings there.
To view findings in Cloud Logging, follow these steps:
In the Google Cloud console, go to Logs Explorer.
Select the Google Cloud project where you are storing your Event Threat Detection logs.
Use the Query pane to query findings using one of the following methods:
- In the All resources list, do the following:
- Select Threat Detector to display a list of all detectors.
- Under DETECTOR_NAME, select iam_anomalous_grant, bad_domain, or ssh_brute_force.
- Click Apply.
In the query editor, enter the following query and click Run query:
resource.type="threat_detector"
- In the All resources list, do the following:
To view the log, click a table row and click Expand nested fields.
Clean up test resources
To avoid leaving security anomalies or incurring unwanted charges, clean up the test resources for the detector that you tested:
Clean up IAM Anomalous Grant resources
To revoke permissions granted for the IAM Anomalous Grant test:
In the Google Cloud console, go to the IAM page.
In the row for the test user's gmail.com address, click Edit principal.
In the pane that appears, click Delete role next to the Owner role.
Click Save.
Clean up Malware: Bad Domain resources
To clean up resources created for the Malware: Bad Domain test, follow these steps:
- Delete the VM instance you created. For instructions, see Delete a VM instance.
- Disassociate or delete the DNS server policy that you created. For instructions, see Delete a DNS policy.
Clean up SSH Brute Force resources
To clean up resources created for the SSH Brute Force test, follow these steps:
- Delete the VM instance that you created. For instructions, see Delete a VM instance.
- Alternatively, if you want to keep the VM instance, revert
PasswordAuthenticationtonoin/etc/ssh/sshd_config, restart the SSH service (sudo systemctl restart ssh), and delete the test user account (sudo deluser TEST_USER).
Troubleshoot
If a finding doesn't appear in Security Command Center or Cloud Logging after testing:
- Verify that Event Threat Detection is enabled in your Security Command Center Services settings.
- If testing the Malware: Bad Domain or SSH Brute Force detectors, verify that the project containing the VM instance is in scope for Event Threat Detection.
- For viewing findings in Cloud Logging, ensure you have configured log export.
- For more troubleshooting steps, see Troubleshooting Security Command Center.
What's next
- Learn more about using Event Threat Detection.
- Read a high-level overview of Event Threat Detection concepts.
- Learn how to investigate and develop response plans for threats.