Test Event Threat Detection

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.setIamPolicy permission, like the Project IAM Admin role.
    • Malware: Bad Domain: an IAM role with the compute.instances.create and dns.policies.create permissions, like the Project Editor role.
    • SSH Brute Force: an IAM role with the compute.instances.create permission, like the Compute Instance Admin (v1) role or Project Editor role.

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:

  1. Create a test user with a personal @gmail.com email address. Make sure that this @gmail.com account doesn't already have any IAM permissions in the project where you are performing the test.

  2. In the Google Cloud console, go to the IAM page.

    Go to IAM

  3. Click Grant access.

  4. In the New principals field, enter the test user's @gmail.com address.

  5. In the Select a role drop-down list, select Project > Owner.

  6. 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:

  1. 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.
  2. To enable logging, configure a DNS server policy for the VPC network:

    1. In the Google Cloud console, go to the Cloud DNS page.

      Go to Cloud DNS

    2. Select the DNS server policies tab.

    3. Click Create policy.

    4. In the Name field, enter a name for the policy.

    5. Under Logs, select On to enable logging of DNS queries.

    6. Under Networks, select the VPC network that your VM instance uses.

    7. Click Create.

  3. In the Google Cloud console, go to the VM instances page.

    Go to VM instances

  4. 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.

  5. 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:

  1. 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.
  2. In the Google Cloud console, go to the VM instances page.

    Go to VM instances

  3. 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.

  4. Enable SSH password authentication on the VM instance:

    1. Open the SSH daemon configuration file in a text editor:

      sudo vim /etc/ssh/sshd_config
      
    2. Set PasswordAuthentication to yes:

      PasswordAuthentication yes
      
    3. Restart the SSH service:

      sudo systemctl restart ssh
      
  5. Create a test user account with a password:

    sudo adduser TEST_USER
    

    Follow the prompts to specify a password for the test user.

  6. To stream authentication logs to Cloud Logging, install the Ops Agent on the VM instance. For instructions, see Install the Ops Agent.

  7. 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_ADDRESS
    

    When prompted for a password, enter an incorrect password. Repeat this 8 times.

  8. Sign in with the correct password:

    ssh TEST_USER@INSTANCE_IP_ADDRESS
    

    When prompted, enter the correct password for TEST_USER.

  9. 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:

  1. In the Google Cloud console, go to the Security Command Center Findings page.

    Go to Findings

  2. 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).
  3. To sort the list in the Findings query results panel, click the Event time column header so that the most recent finding displays first.

  4. 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.

  5. Verify the details of the finding:

    • For IAM anomalous grant, check that the value on the Principal email row contains your test gmail.com email 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.

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:

  1. In the Google Cloud console, go to Logs Explorer.

    Go to Logs Explorer

  2. Select the Google Cloud project where you are storing your Event Threat Detection logs.

  3. Use the Query pane to query findings using one of the following methods:

    • In the All resources list, do the following:
      1. Select Threat Detector to display a list of all detectors.
      2. Under DETECTOR_NAME, select iam_anomalous_grant, bad_domain, or ssh_brute_force.
      3. Click Apply.
    • In the query editor, enter the following query and click Run query:

      resource.type="threat_detector"
      
  4. 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:

  1. In the Google Cloud console, go to the IAM page.

    Go to IAM

  2. In the row for the test user's gmail.com address, click Edit principal.

  3. In the pane that appears, click Delete role next to the Owner role.

  4. Click Save.

Clean up Malware: Bad Domain resources

To clean up resources created for the Malware: Bad Domain test, follow these steps:

  1. Delete the VM instance you created. For instructions, see Delete a VM instance.
  2. 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:

  1. Delete the VM instance that you created. For instructions, see Delete a VM instance.
  2. Alternatively, if you want to keep the VM instance, revert PasswordAuthentication to no in /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