SOC Automation Project - Wazuh, TheHive, Shuffle

This project consists of building a SOC (Security Operations Center) automation lab from scratch, aimed at gaining hands-on experience in the field. The project involves setting up various tools such as Wazuh (SIEM and XDR), TheHive (for case management), and Shuffle (for SOAR capabilities).

The project includes 5 different parts:

Part 1: Creating a logical diagram to visualize the lab and project.

Part 2: Installing necessary components and setting up the lab in the cloud and virtual machines (VM).

Part 3: Configuring servers and endpoints for seamless communication with each other.

Part 4: Generating telemetry related to Mimikatz to trigger alerts.

Part 5: Setting up SOAR, integrating all tools, and automating responses and alerts.

Part 1: 

In the first part of the project, the focus is on creating a logical diagram to visualize the lab setup, which would help to understand data flow and identify necessary components. I used a free tool called draw.io to build this diagram, by connecting elements such as the PC, router, internet, Wazuh manager, Shuffle, and TheHive. 

The Windows 10 client sends events to the Wazuh Manager.

The Wazuh Manager creates alerts and sends them to Shuffle.

Shuffle performs enrichment of Indicators of Compromise (IOCs) and sends alerts to TheHive.

Shuffle also sends an email to the SOC analyst with details of the alert.

The diagram serves as a reference for the project, outlining the sequence of actions like sending events, triggering alerts, and performing responsive actions. 

Part 2:

In part two, the focus is on installing necessary applications and virtual machines. By the end of this part, there should be a Windows 10 machine with Sysmon installed, a Wazuh server, and a Hive server set up. 

Overview of Tools:

Wazuh: Described as an open-source cybersecurity platform that integrates Security Information and Event Management (SIEM) and Extended Detection and Response (XDR) capabilities. It offers features like security analytics, intrusion detection, and incident response. Wazuh comprises three main components: the indexer, server, and dashboard.

TheHive: Introduced as a 4-in-1 open-source security incident response platform. It will be used as the case management system for this project.

Virtual Machine Setup: The lab uses Windows 10 as the client PC, and Ubuntu 22.04 for both Wazuh and TheHive servers. The instructor mentions that while they are using an ESXi server for the Windows 10 VM, you can also use VirtualBox or a cloud provider.

Step-by-Step Installation Process:

Installing VirtualBox and Setting Up Windows 10 VM:

Download and install VirtualBox from the official website. Check the SHA-256 checksum to verify the integrity of the downloaded file. Install necessary dependencies, such as the Microsoft Visual C++ 2019 package, if prompted. Set up the Windows 10 virtual machine using a Windows ISO file created with the Media Creation Tool. Customize the VM settings (e.g., memory, CPU, hard disk space). Install Sysmon (System Monitor) on the Windows 10 VM by downloading and configuring it. Sysmon provides detailed logging of system activity, which is useful for security monitoring.

Installing and Configuring Wazuh:

The Wazuh server is set up on a cloud provider, specifically DigitalOcean.

Create a droplet (virtual machine) in DigitalOcean with Ubuntu 22.04, and configure it with 4 GB RAM and 50 GB hard drive space.

Set up a firewall to restrict access to the Wazuh server, allowing only your IP address to connect via SSH. This is done to prevent unauthorized access.

SSH into the Wazuh server and perform system updates and upgrades.

Install Wazuh using a curl command to fetch the installer from the Wazuh website. The installation includes setting up the Wazuh manager, essential for managing security alerts and responses.

Installing and Configuring TheHive:

Like Wazuh, TheHive is also set up on a cloud-based Ubuntu 22.04 server.

The setup involves installing four key components: Java, Cassandra (a NoSQL database), Elasticsearch (a search engine), and TheHive itself.

Each component is installed sequentially, with commands provided for each step.

Once the installation is complete, the next step is configuring TheHive to work with Wazuh, which will be covered in the next part.

Firewall Configuration:

After setting up the servers, ensure the previously configured firewall protects both Wazuh and TheHive. This limits access to only authorized users.

Accessing the Wazuh Dashboard:

Once Wazuh is installed, log in to the Wazuh dashboard using the admin credentials generated during the installation.

Access the Wazuh dashboard by navigating to the server’s public IP address via HTTPS.

At the end of this part, I have successfully set up the core components of the SOC automation lab: a Windows 10 client machine with Sysmon, and servers running Wazuh and TheHive. I will configure these components in the next part to create a fully integrated security operations environment.

Part 3: 

In Part 3, I will be configuring TheHive and Wazuh servers and getting them to communicate with a Windows 10 client. The main object is to configure both servers so that they are fully operational, with a Windows 10 client reporting to Wazuh.

Configuring TheHive

Cassandra Configuration:

Start with configuring Cassandra, the database used by TheHive. Open the Cassandra configuration file and adjust the cluster_name, replacing "Test Cluster" with something more relevant, like "mycluster." Then, update both the listen_address and rpc_address fields from localhost to the public IP address of TheHive. Similarly, the seed_provider address needs to be updated to match this IP. After making these changes, save the file, stop the Cassandra service, and remove any old files from the directory to avoid conflicts. Once done, restart the service and ensure it is running by checking its status.

ElasticSearch Configuration:

Next, configure ElasticSearch, which handles data indexing and querying. Open its configuration file and customize settings such as cluster.name and node.name. Replace the network.host value with the public IP address of TheHive and uncomment the default http.port (9200) for clarity. If needed, configure the cluster.initial_master_nodes by uncommenting it and removing any unnecessary nodes, as this setup will only use a single node. After completing these configurations, start and enable the ElasticSearch service. Be sure to check that it is active and running correctly.

TheHive Configuration:

With Cassandra and ElasticSearch configured, proceed to configure TheHive itself. First, change the ownership of the necessary directories to the TheHive user and group using the chown command. This step ensures that TheHive has the proper permissions to access these directories. Then, open TheHive’s main configuration file and update the database and index configurations, replacing any localhost entries with the public IP address of TheHive. Make sure that storage paths are correctly set and accessible by TheHive, and update the application.baseUrl to reflect the public IP address. Save these changes, start TheHive, and enable it to run on boot. Finally, verify that Cassandra, ElasticSearch, and TheHive services are all active and running.

Accessing TheHive Dashboard:

Once the configuration is complete, access TheHive dashboard by navigating to the public IP address with port 9000. Use the default credentials (admin@thehive.local and secret) to log in. If you encounter an issue logging in, such as authentication failure, it may be due to ElasticSearch being down. In this case, create a custom JVM options file to limit memory usage to 2 GB, then restart ElasticSearch and attempt to log in again.

Configuring Wazuh

Logging into Wazuh Dashboard:

 - Log into the Wazuh dashboard using the administrative credentials.

 - If credentials are lost, retrieve them from the Wazuh installation directory.

Adding a Windows 10 Agent:

 - Add a Windows 10 client as an agent in Wazuh by copying a command from the Wazuh dashboard and executing it on the Windows machine via Powershell with administrative privileges.

 - Start the Wazuh service on the Windows machine and verify that the agent appears in the Wazuh dashboard.

Verifying Agent Connection:

 - Confirm that the Windows 10 client appears as an active agent in Wazuh, indicating successful communication with the Wazuh manager.

 - Query security events from the agent to ensure everything is functioning correctly.

Part 4: Generating Telemetry and Creating Alerts

Objective:

In this part, we will generate telemetry from the Windows 10 machine and ensure it's being ingested into Wazuh. You'll have successfully configured and sent telemetry containing Mimikatz by the end, triggering a custom alert.

Configuring Windows 10 Telemetry

Start by locating the Wazuh configuration file on your Windows 10 machine under Program Files (x86). The file you need to modify is ossec.conf. Open it with administrative privileges using Notepad. You'll be editing the file to ensure Wazuh ingests Sysmon logs, which are critical for detecting Mimikatz.

First, back up the original configuration file by copying and renaming it. Then, scroll down to the log analysis section in ossec.conf, and replace the default application logs with the Sysmon channel name. You can find the correct channel name by opening Windows Event Viewer, navigating to Applications and Services Logs > Microsoft > Windows > Sysmon > Operational, and copying the full name from the properties.

After updating the configuration, save the file and restart the Wazuh service to apply the changes. This ensures Wazuh begins ingesting Sysmon logs, including any Mimikatz activity.

Verifying Ingestion in Wazuh Dashboard

Go to the Wazuh dashboard, search for Sysmon events under the alerts index, and confirm that the logs are being ingested. If no events appear, the logs may take a few moments to process. Next, disable Windows Defender for the Downloads folder to prevent interference and download Mimikatz. Run Mimikatz and check the Wazuh dashboard for related events. If no Mimikatz events are visible, adjust Wazuh to log everything by editing the ossec.conf file on the Wazuh manager and setting logall and logall_json to "yes."

Restart the Wazuh manager to begin archiving all logs stored in the archives directory. Ensure the Filebeat configuration is also set to true for archives, then restart the Filebeat service. Create a new index for archives in the Wazuh dashboard to view all ingested logs.

Testing and Creating a Custom Alert

To create a custom alert for Mimikatz, start by accessing the rules section in the Wazuh dashboard. Use a built-in Sysmon rule as a reference, copying it into the custom rules section. Modify the rule to focus on the original_file_name field, ensuring it detects Mimikatz even if the executable is renamed. Set the rule ID, severity level, and field details, ensuring the field names are case-sensitive. Save the rule and restart the Wazuh manager.

Test the new rule by renaming Mimikatz to a different name and running it. Check the Wazuh dashboard to verify that the custom alert triggers based on the original file name, demonstrating the effectiveness of your configuration.

Part 5: Integrating Shuffle, The Hive, and Wazuh

Objective:
In this final part of the SOC automation project series, I aim to connect Shuffle, the SOAR (Security Orchestration, Automation, and Response) platform, to The Hive and Wazuh. By the end of this part, I will have a fully functional lab that integrates Wazuh, The Hive, and Shuffle. While Wazuh alone has many capabilities, using a SOAR platform like Shuffle alongside a case management system like The Hive offers additional benefits. 

Setting Up Shuffle:
To start, I headed over to Shuffle's site and created an account. Once logged in, I bypassed the initial setup and went straight to creating a workflow. I named the workflow "SOC Automation Project" and added a description. The workspace allowed me to add apps and triggers. I dragged a webhook trigger onto the workspace and named it "Wazuh Alerts." After copying the webhook URL, I moved to the Wazuh manager to integrate this webhook.

Integrating Wazuh with Shuffle:
In the Wazuh manager, I opened the ossec.conf file to add the integration tag with the webhook URL. I made sure the URL was correctly formatted and changed the tag from level to rule_id so that only alerts with a specific rule ID, in this case, the custom rule I created earlier, would be sent to Shuffle. After saving the configuration, I restarted the Wazuh manager service to apply the changes.

Testing the Integration:
To test the integration, I regenerated Mimikatz telemetry on my Windows client machine and then checked Shuffle to see if the alerts were received. Initially, nothing appeared in Shuffle due to a URL formatting issue in the Wazuh configuration. I corrected this by removing the http:// portion from the webhook URL and restarted the Wazuh manager. After running Mimikatz again, Shuffle successfully received the alert, and I could see the relevant information in the execution arguments.

Parsing Hash Values with Shuffle:
Next, I needed to parse out the SHA-256 hash value from the alert before sending it to VirusTotal. I used regular expressions (regex) to capture just the hash value, excluding any additional text like sha1= or sha256= that might be included. I utilized ChatGPT to generate the regex, which I then implemented in Shuffle. After running the workflow again, the hash value was correctly parsed and ready for submission to VirusTotal.

Checking Hash Reputation with VirusTotal:
I integrated VirusTotal into the Shuffle workflow to automatically check the reputation of the parsed hash. After configuring VirusTotal with my API key, I encountered a 404 error due to an outdated API endpoint in Shuffle's VirusTotal app. I resolved this by editing the app's URL to match the current VirusTotal API documentation, replacing /report it with /ID. After making this change, VirusTotal successfully returned the reputation score for the hash.

Creating an Alert in The Hive:
With the VirusTotal integration working, I connected Shuffle to The Hive to create an alert for case management. I configured the alert to include relevant information, such as the detection time, hostname, and user account. I also added MITRE ATT&CK tags and specified the alert's severity level. Before running the workflow, I temporarily modified my cloud firewall to allow inbound traffic on port 9000, which The Hive uses. After running the workflow, I verified that the alert was successfully created in The Hive, complete with all the necessary details.

Sending Email Notifications: To keep analysts informed, I set up an email notification step in Shuffle. I used SquareX’s disposable email service to test the functionality. I configured the email to include the alert's title, detection time, and host information, ensuring that analysts would have all the details they need to investigate further. After running the workflow, I confirmed that the email was sent and contained all the relevant information.

Conclusion:
At the end of the project, I successfully integrated Wazuh, The Hive, and Shuffle into a cohesive automation workflow. I demonstrated how to parse telemetry data, check it against VirusTotal, create an alert in The Hive, and notify analysts via email. This project has provided me with a robust platform for automating incident response tasks, improving efficiency, and ensuring that critical alerts are managed effectively.