Adversary emulation on GCP with Stratus Red Team and Wazuh

July 21st 2023 | by Adedamola Okelola | Wazuh 4.4.5

Google Cloud Platform (GCP) is a highly scalable cloud computing platform offered by Google. It provides organizations with several cloud-based services, including computing, storage, machine learning, and data analytics. GCP is renowned for its robust infrastructure, global network, and cutting-edge technologies, making it an ideal choice for businesses seeking to leverage the cloud for their digital transformation initiatives.

Wazuh is a free, open source, enterprise-grade security monitoring platform that provides comprehensive protection for cloud, on-premises, containerized, and virtualized environments. It provides visibility across the infrastructure to enable users to detect threats, maintain integrity of files, respond to security incidents, and meet compliance requirements.

Analyzing GCP logs with Wazuh provides organizations with centralized log management, real-time threat detection, and compliance reporting. This ensures enhanced security and accountability, helping organizations maintain a good security posture.

This blog post demonstrates how to use Wazuh for threat detection on the Google Cloud Platform.

Infrastructure setup for threat detection on GCP

A pre-built ready-to-use Wazuh 4.4.5 OVA (Open Virtual Appliance). The OVA contains the Wazuh central components (Wazuh server, Wazuh indexer, and Wazuh dashboard). Refer to the OVA documentation to download and set this up.
A GCP account with administrative privileges. We recommend using a test account that does not manage production workloads.
An Ubuntu 22.04 endpoint to perform the attack emulation against the GCP account.

Integrating Wazuh with GCP

We integrate Wazuh with GCP using the Google Cloud publisher and subscriber service (GCP Pub/Sub). Google Cloud Pub/Sub is a messaging service that helps you send and receive data between applications. Wazuh provides a Pub/Sub integration module for GCP that fetches event logs from the Cloud Logging sink. Cloud Logging sink is a configuration that defines how logs are routed to a specific destination.

Configuration on GCP

We create a new GCP Project and a service account that enables the Wazuh GCP module to pull log data from the Google Pub/Sub service. We then configure the Pub/Sub service and the Cloud Logging Sink. Follow the steps below to perform the configuration.

1. Create a new GCP project. Note the new project ID.

2. Go to the IAM and admin drop-down menu and select Service accounts to create a new service account. On the service accounts creation page, add the Pub/Sub Publisher and Pub/Sub Subscriber roles to the account.

3. Open the newly created service account and create a private key in JSON format. Your browser automatically downloads the key. Wazuh uses the key to authenticate to your GCP account.

Configuring the Pub/Sub service

This section demonstrates the step-by-step process of configuring the Google Cloud Pub/Sub service to integrate with Wazuh.

1. Search for Pub/Sub from the console search field at the top of the page. Click on Create Topic. On the Create Topic page, input the Topic ID and select the Add a default subscription checkbox. Then, click Create. Take note of the Subscription ID.

2. Search for Log Router in the console search. Click on Create Sink.

3. Name the sink and click Next. On the Sink destination service, select Cloud Pub/Sub topic. Next, select the topic name created above.

4. Click Create Sink.

5. Enable Identity and Access Management (IAM) API, Compute Engine API,and Cloud Resource Manager API. The APIs are required for the Stratus Red Team adversary emulation.

Configuration on the Wazuh server

We configure the Wazuh server to receive logs from GCP by performing the following steps.

1. Create a credentials.json file in the /var/ossec/wodles/gcloud/ directory on the Wazuh server:

# touch /var/ossec/wodles/gcloud/credentials.json

2. Update the /var/ossec/wodles/gcloud/credentials.json file with the contents of the private key JSON file we downloaded earlier. The Wazuh GCP module uses the key file to authenticate to your GCP account.

3. Append the following content to the Wazuh server /var/ossec/etc/ossec.conf configuration file. The configuration specifies how Wazuh connects to GCP using the project information, GCP PubSub subscription ID and a credential.

<ossec_config>
  <gcp-pubsub>
    <pull_on_start>yes</pull_on_start>
    <interval>1m</interval>
    <project_id><PROJECT_ID></project_id>
    <subscription_name><SUBSCRIPTION_ID></subscription_name>
     <credentials_file>/var/ossec/wodles/gcloud/credentials.json</credentials_file>
  </gcp-pubsub>
</ossec_config>

Replace the variables in the configuration with the appropriate values.

Where:

<PROJECT_ID> is the ID of the new project created at the beginning.
<SUBSCRIPTION_NAME> is the subscription ID of your GCP Pub/Sub.

4. Restart the Wazuh manager to apply the configuration:

# systemctl restart wazuh-manager

Configuration on Wazuh dashboard

We turn on the Google Cloud Platform module on the Wazuh dashboard.

1. Enable the Google Cloud Platform module on the Wazuh dashboard. Navigate to Settings > Modules and toggle on Google Cloud Platform.

2. Perform some actions on your GCP console and confirm that Wazuh is receiving GCP logs. Navigate to Modules > Google Cloud Platform on the Wazuh dashboard to visualize the events.

Stratus Red Team detection with Wazuh

We create rules on the Wazuh server to detect Stratus Red Team attacks on GCP. The rules will enable Wazuh to identify and alert you about any suspicious activities or potential security breaches within your GCP environment.

1. Create a rule file gcp_rules.xml in the /var/ossec/etc/rules/ directory and add the following custom rules to detect potential GCP attacks. These rules are created based on the attack emulation performed.

<group name="gcp,cloud,">  

  <!--GCP service account impersonation-->
  <rule id="100111" level="12">
    <if_sid>65043</if_sid>
    <field name="gcp.protoPayload.methodName">GenerateAccessToken</field>
    <field name="gcp.protoPayload.status.message" type="pcre2">PERMISSION_DENIED</field>
    <description>GCP service account impersonation detected on $(gcp.resource.labels.email_id).</description>
    <mitre>
      <id>T1098</id>
  </mitre>
  </rule>
  
  
  <!--GCP service account key creation-->
  <rule id="100112" level="12">
    <if_sid>65071</if_sid>
    <field name="gcp.protoPayload.methodName">google.iam.admin.v\d.CreateServiceAccountKey$</field>
    <field name="gcp.protoPayload.serviceName">iam.googleapis.com</field>
    <field name="gcp.protoPayload.response.name" type="pcre2">key</field>
    <description>GCP service account key creation detected.</description>
    <mitre>
      <id>T1098.004</id>
    </mitre>
  </rule>
  
  
  <!--External user invited to a GCP project-->
  <rule id="100113" level="12">
    <if_sid>65042</if_sid>
    <field name="gcp.protoPayload.request.@type">type.googleapis.com/google.iam.v1.SetIamPolicyRequest</field>
    <match>Add</match>
    <description>An external user was invited to the project $(gcp.resource.labels.project_id).</description>
    <mitre>
      <id>T1098.003</id>
    </mitre>
  </rule>
    

  <!--Compute disk exfiltration by sharing-->
  <rule id="100114" level="5">
    <if_sid>65042</if_sid>
    <field name="gcp.protoPayload.methodName">v\d.compute.disks.insert$</field>
    <field name="gcp.protoPayload.request.@type">type.googleapis.com/compute.disks.insert$</field>
    <description>The user $(gcp.protoPayload.authenticationInfo.principalEmail) created the compute disk $(gcp.protoPayload.resourceName).</description>
    <mitre>
      <id>T1578.001</id>
    </mitre>
  </rule>
    
  <rule id="100115" level="12">
    <if_sid>65042</if_sid>
    <field name="gcp.protoPayload.methodName">v\d.compute.disks.setIamPolicy$</field>
    <field name="gcp.protoPayload.request.@type">type.googleapis.com/compute.disks.setIamPolicy$</field>
    <description>IAM policy change detected on the compute disk $(gcp.protoPayload.resourceName).</description>
    <mitre>
      <id>T1530</id>
    </mitre>
  </rule>


</group>

Where:

Rule ID 100111 detects an attempt to impersonate a GCP service account.
Rule ID 100112 detects the creation of a service account key on an existing service account.
Rule ID 100113 detects the invitation of an external user to a GCP project while granting the user an elevated privilege.
Rule ID 100114 detects the creation of a compute disk snapshot.
Rule ID 100115 detects the sharing of a commute disk snapshot with an external account.

NOTE: These behaviors are not malicious in all cases, however, they are privileged activities that threat actors can abuse in a GCP infrastructure. Therefore, it is important to detect them and prioritize their investigation.

2. Restart the Wazuh manager to apply the configuration:

# systemctl restart wazuh-manager

Attack emulation using Stratus Red Team

Stratus Red Team is a cloud adversary emulation framework written in Golang. It offers a variety of automated cloud-native red team attacks for AWS, Azure, Kubernetes, and GCP. These attacks are mapped with the MITRE ATT&CK tactics and executed via a command-line interface (CLI).

Configure the attack endpoint

Follow the steps below to configure the Stratus Red Team tool and the GCP command-line interface on the Ubuntu attack endpoint.

1. Download the Stratus Red Team tool:

$ wget https://github.com/DataDog/stratus-red-team/releases/download/v2.8.0/stratus-red-team_2.8.0_Linux_x86_64.tar.gz
$ tar xvf stratus-red-team_2.8.0_Linux_x86_64.tar.gz

2. Switch to the root user:

$ sudo su

3. Test the Stratus Red Team tool by searching for GCP-related tests:

# ./stratus list | grep 'gcp.' | awk '{ print $2 }' | cat -n

Output

1   gcp.exfiltration.share-compute-disk
2   gcp.persistence.backdoor-service-account-policy
3   gcp.persistence.create-admin-service-account
4   gcp.persistence.create-service-account-key
5   gcp.persistence.invite-external-user
6   gcp.privilege-escalation.impersonate-service-accounts

4. Download and install the GCP CLI tool:

# snap install google-cloud-cli --classic

5. Authenticate the GCP infrastructure from the CLI using your administrative GCP account:

# gcloud auth application-default login

6. Copy the generated Google authentication link and paste it into a browser. Log in with your GCP administrative credentials and allow the Google Auth Library to access your Google Account.

7. Set the GCP billing project quota. Replace <YOUR_PROJECT_ID> with the ID of your GCP project.

# gcloud auth application-default set-quota-project <YOUR_PROJECT_ID>

Note: Retrieve YOUR_PROJECT_ID from the project created above.

8. Set the GCP project ID:

# export GOOGLE_PROJECT=<YOUR_PROJECT_ID>

Attack emulation

Perform the following Stratus Red Team attacks on the attack emulation endpoint.

Impersonate GCP service accounts

The attack attempts to impersonate several GCP service accounts. Service account impersonation in GCP allows retrieving temporary credentials allowing one to act as a service account.

# ./stratus warmup gcp.privilege-escalation.impersonate-service-accounts
# ./stratus detonate gcp.privilege-escalation.impersonate-service-accounts

Create a GCP service account key

This establishes persistence by creating a service account key on an existing service account:

# ./stratus warmup gcp.persistence.create-service-account-key
# ./stratus detonate gcp.persistence.create-service-account-key

Invite an external user to a GCP project

This is a persistence attack that attempts to invite an external user into a GCP project while granting the attacker an elevated role on the project:

# ./stratus detonate gcp.persistence.invite-external-user

Exfiltrate compute disk by sharing it

The attack attempts to exfiltrate a Compute Disk by sharing it with an attacker account. The attacker could then create a snapshot of the disk in their GCP project:

# ./stratus warmup gcp.exfiltration.share-compute-disk
# ./stratus detonate gcp.exfiltration.share-compute-disk

Cleanup the infrastructure

At the end of the emulation, run the command below to clean up the attack emulation activities on the GCP account:

# ./stratus cleanup --all

Detection results

View the detection result on the Wazuh dashboard by navigating to Modules > Security events.

Conclusion

In this blog post, we demonstrated how to integrate the Google Cloud Platform with Wazuh. We showed how to detect Stratus Red Team attacks on GCP using Wazuh. By leveraging Wazuh real-time threat detection capability, businesses can effectively detect attacks, enhance incident response readiness, and strengthen their overall security posture on GCP. With Wazuh, organizations can stay ahead of adversaries and effectively safeguard their critical assets.

References