The Semi-Automated SOC Project aims to automate key processes within the Security Operations Center (SOC) to enhance both effectiveness and efficiency in managing security information. This project integrates several powerful open-source tools, including Wazuh for comprehensive event management and alerting, Shuffle for workflow automation, IRIS for case management, and MISP for IoC management and threat intelligence. Administrators are given greater control over incident handling and response processes through Google Chat, enriched with Groq, as well as visual monitoring dashboard powered by Grafana.
- Enhance Incident Response Efficiency: Automate repetitive task and streamline incident handling workflows to reduce response time and minimize human error.
- Integrate Open-Source Security Tools: Establish seamless integration between Wazuh, Shuffle, IRIS, dan MISP for creating SOC environment capable of comprehensive event monitoring, case management, and decision-making.
- Improve Visibility and Decision-Making: Provide administrator with real-time insight from Groq, visual analythics through Grafana dashboard, and notification with Google Chat.
- Strengthen Threat Detection: Utilize MISP integrated with Wazuh to enhance the detection and management Indicators of Compromise (IoC), such as malicious file and IP addresses.
- A host machine that can operate several virtual machines simultaneously.
- Adequate CPU, RAM, and storage to support virtual machines and their expected workloads.
- Proxmox Virtual Environment (PVE): Industry-standard virtualization platform to create, manage, and monitor multiple virtual machines and containers.
- Windows 10: Serves as the client for testing the SOC's worklows.
- Ubuntu 22.04: Desktop serves both as a client for testing the SOC's workflows and as a server hosting Wazuh, Shuffle, IRIS, and MISP.
- Kali Linux 2024: Serves as the attacker for penetration testing both Windows and Ubuntu clients.
- Damn Vulnerable Web Application (DVWA): A purposely vulnerable web application designed for security testing and training purposes, which will be hosted on both Windows and Ubuntu.
- Wazuh: An open-source security monitoring platform that funnctions as a Security Information and Event Management (SIEM) system for event collection, analysis, and alerting.
- Shuffle: An open-source security automation platform that serves as Security Orchestration, Automation, and Response (SOAR) solution for managing automated incident handling workflows.
- IRIS: An open-source security collaboration platform that provides as case management to escalate alerts and coordinate with other security teams.
- MISP: An open-source threat intelligence platfform that functions as Cyber Threat Intelligence (CTI) system, enhancing Wazuh's ability to detect IoCs.
- Grafana: An open-source visualization platform that used to create dashboard for monitoring threats and analyzing Wazuh metrics and logs.
- Groq: An online analytical service that processes Wazuh logs and provides actionable recommendations to assist Administrator in incident decision-making.
- Google Chat: An online communication tool used to deliver incident information and receive input from Administrator for responding incident.
| VM | Platform | Network | CPU | RAM | Storage | OS | IP Address |
|---|---|---|---|---|---|---|---|
| 1 | Wazuh | Bridge | 4 CPU | 16 GB | 200 GB | Ubuntu 22.04 Server | 172.23.0.11 |
| 2 | Shuffle | Bridge | 4 CPU | 16 GB | 200 GB | Ubuntu 22.04 Server | 172.23.0.12 |
| 3 | IRIS & Grafana | Bridge | 4 CPU | 16 GB | 500 GB | Ubuntu 22.04 Server | 172.23.0.13 |
| 4 | MISP | Bridge | 4 CPU | 16 GB | 500 GB | Ubuntu 22.04 Server | 172.23.0.14 |
| 5 | Ubuntu Desktop | Bridge | 2 CPU | 4 GB | 80 GB | Ubuntu 22.04 Desktop | 172.23.0.44 |
| 6 | Windows Desktop | Bridge | 4 CPU | 4 GB | 80 GB | Windows 10 Superlite | 172.23.0.45 |
Wazuh is installed on Virtual Machine 1 using the Wazuh Installation Assistant, which simplifies the setup of required components such as keys, certificates, and passwords for Wazuh Server, Indexer, and Dashboard. Official Wazuh Documentation
3.1.1 Download the Wazuh Installation Assistant and configuration files:
curl -sO https://packages.wazuh.com/4.12/wazuh-install.sh
curl -sO https://packages.wazuh.com/4.12/config.yml3.1.2 Edit the config.yml file and replace the IP addresses with your VM IPs:
nodes:
# Wazuh indexer nodes
indexer:
- name: node-1
ip: 172.23.0.11
#- name: node-2
# ip: "<indexer-node-ip>"
#- name: node-3
# ip: "<indexer-node-ip>"
# Wazuh server nodes
# If there is more than one Wazuh server
# node, each one must have a node_type
server:
- name: wazuh-1
ip: 172.23.0.11
# node_type: master
#- name: wazuh-2
# ip: "<wazuh-manager-ip>"
# node_type: worker
#- name: wazuh-3
# ip: "<wazuh-manager-ip>"
# node_type: worker
# Wazuh dashboard nodes
dashboard:
- name: dashboard
ip: 172.23.0.113.1.3 Generate configuration files based on the adjusted config.yml:
wazuh-install.sh --generate-config-files3.1.4 Install the Wazuh Indexer, responsible for indexing and storing alerts:
wazuh-install.sh --wazuh-indexer node-1If you have multiple nodes, repeat this step for each Indexer node.
3.1.5 Start the cluster:
wazuh-install.sh --start-cluster3.1.6 Install the Wazuh Server, which analyzes data and triggers alerts for detected threats:
wazuh-install.sh --wazuh-server wazuh-13.1.6 Install the Wazuh Dashboard for exploring, analyzing, and visualizing security events via a web interface:
wazuh-install.sh --wazuh-dashboard dashboard3.1.7 After installation, check the generated credentials to log in to the Dashboard, and check for the API key:
tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt
3.1.8 Log in to the Wazuh Dashboard login using the provided credentials on https://172.23.0.11:
Shuffle is installed on Virtual Machine 2. Since Shuffle only runs in a containerized environment, Docker must be installed first. Prepare the Docker environment by downloading the required certificates, APT sources, and components. Official Shuffle Documentation
# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
# Add the repository to Apt sources:
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
# Install Docker and its dependencies:
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin3.2.1 After setting up Docker, clone the official Shuffle repository:
git clone https://github.com/Shuffle/Shuffle
cd Shuffle3.2.2 Create the database directory and adjust permissions:
mkdir shuffle-database
sudo chown -R 1000:1000 shuffle-database
sudo swapoff -a3.2.3 Update the docker-compose.yml file to match your environment:
orborus:
environment:
- BASE_URL: http://172.23.0.12:50013.2.4 Build Docker images and start containers using Docker Compose:
Docker compose build
Docker compose up -d3.2.5 Administrator account creation screen on https://172.23.0.12:3443:
3.2.6 User login screen (login using the administrator account):
IRIS is installed on Virtual Machine 3 and runs inside a containerized environment for easier deployment and management. The installation requires Docker, so ensure Docker is properly installed before proceeding. Official IRIS Documentation
3.3.1 After setting up Docker, clone the official IRIS repository:
git clone https://github.com/dfir-iris/iris-web.git
cd iris-web
git checkout v2.3.7The git checkout v2.3.7 command ensures compatibility by using a stable release version of IRIS.
3.3.2 Copy the environment template file to create your own configuration:
cp .env.model .env3.3.3 Edit the .env file to define your administrator credentials:
IRIS_ADM_PASSWORD=<your-iris-password>
IRIS_ADM_USERNAME=<your-iris-username>These credentials will be used to access the IRIS web interface after setup.
3.3.4 Build the Docker image from the docker-compose.yml configuration and start the container:
Docker compose build
Docker compose up -d3.3.5 Login screen after successful deployment on https://172.23.0.13:
3.3.6 IRIS API interface for automation and integration:
Grafana is installed on Virtual Machine 3 and runs inside a containerized environment for ease of deployment and maintenance. Ensure Docker is installed and running before proceeding. Official Grafana Documentation
3.4.1 Run Grafana using Docker (Enterprise Edition):
docker run -d -p 3000:3000 --name=grafana grafana/grafana-enterpriseThis command pulls the Grafana Enterprise image, runs it as a container, and exposes the web interface on port 3000.
3.4.2 Create and attach a Docker volume for persistent Grafana data storage:
docker volume create grafana-storage
docker volume inspect grafana-storage
docker run -d -p 3000:3000 --name=grafana \
--volume grafana-storage:/var/lib/grafana \
grafana/grafana-enterpriseUsing a volume ensures that dashboards, settings, and data persist even after container restarts.
3.4.3 Login to the Grafana dashboard (default credentials: admin / admin) on http://172.23.0.13:3000:
Make sure to change the password after login
3.4.4 Connect Wazuh as a data source at Open menu > Connections > Data sources > Add new data source > OpenSearch to visualize security metrics and alerts:
MISP is installed on Virtual Machine 4 and runs inside a containerized environment for simplified deployment and management. Ensure Docker is installed before proceeding. Official MISP Documentation
3.5.1 Clone the official MISP Docker repository:
git clone https://github.com/MISP/misp-docker/
cd misp-docker3.5.2 Copy the environment template file to create your configuration:
cp template.env .env3.5.3 Edit the .env file and set your administrator credentials and base URL:
ADMIN_EMAIL=<your-misp-username>
ADMIN_PASSWORD=<your-misp-password>
BASE_URL=https://172.23.0.14BASE_URL should match the IP of your MISP server and The credentials for login.
3.5.4 Build the Docker image and start the container using Docker Compose:
Docker compose build
Docker compose up -d3.5.5 Login to the MISP dashboard using your configured credentials on https://172.23.0.14:
3.5.6 Generate an API Key for integrations, Go to Administration > List Auth Keys and click Add authentication key.
Remember to copy the API Key after creation, as it cannot be viewed again later.
3.5.7 Add feeds as external threat intelligence sources to correlate events and attributes across organizations. These feeds, available in MISP default feeds as JSON metadata, can be copied and pasted into the provided input field, then click Add.
3.5.8 The added feeds can then be enabled and synchronized, allowing MISP to import the latest threat information automatically. Select all feeds, enable them, then fetch and store all feed data.
3.5.9 Set up a cron job to automatically update MISP feeds every day at midnight:
crontab -eThen, save this command:
0 0 * * * /usr/bin/curl -X POST --insecure \
--header "Authorization: <your-misp-api>" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
https://172.23.0.14/feeds/fetchFromAllFeedsThis ensures MISP regularly fetches new threat intelligence data without manual intervention.
3.5.10 MISP uses threat intelligence by correlating data between organizations. Create local events to store IoCs detected by Wazuh via Event Actions → Add Event:
ip_ioc_local— stores detected IP addresses.
filename_ioc_local— stores detected filenames.
hash_ioc_local— stores detected file hashes.
Groq is an online service that provides high-speed inference for AI models. Make sure to log in to your Groq account to obtain your API Key.
Remember to copy the API Key after creation, as it cannot be viewed again later.
3.6.1 This project interacts with Groq services directly via API calls without performing any local deployment. As a result, API usage is subject to rate limits and quota restrictions. Details about these limitations can be found. in your Groq Dashboard.
Google Chat is used to forward notifications and inputs for incident response actions. Log in using your Google account, then create a new chat to set up a new space or group.
3.7.1 This space will serve as the destination where the Google Chat Bot sends incident notifications.
3.7.2 In the space settings, select Apps & integrations.
3.7.3 Create and name your Google Chat Bot.
3.7.4 After setup, save the Bot Webhook URL. This will later be integrated with Shuffle to automate alert forwarding and notifications.
Remember to copy the API Key after creation, as it cannot be viewed again later.
This virtual machine hosts the DVWA web application and forwards its logs to the Wazuh Manager using the Wazuh Agent.
4.1.1 Install DVWA on Ubuntu. Follow the guide from bayuskylabs. After installation, verify that Apache2 is running:
systemctl status apache2
DVWA login page (default credentials: admin / password):
4.1.2 Install Wazuh Agent on Ubuntu. Log in to the Wazuh web interface. Click on Add agent and select Linux with architecture DEB amd64 as the agent's operating system. Set the VM address to the Wazuh server's IP.
# download & install the Wazuh agent package
wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.12.0-1_amd64.deb
sudo WAZUH_MANAGER='172.23.0.11' \
WAZUH_AGENT_GROUP='default' \
WAZUH_AGENT_NAME='a-ubuntu' \
dpkg -i ./wazuh-agent_4.12.0-1_amd64.deb
# enable & start agent
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl status wazuh-agentVerify that the agent is active and connected in the Wazuh Manager interface.
4.1.3 Configure log collection and file integrity monitoring. Edit the Wazuh Agent configuration file located at: var/ossec/etc/ossec.conf
<ossec_config>
<localfile>
<log_format>apache</log_format>
<location>/var/log/apache2/access.log</location>
</localfile>
<syscheck>
<directories>/home/<your-ubuntu-name>/Downloads</directories>
</syscheck>
</ossec_config>After saving the file, restart the agent:
sudo systemctl restart wazuh-agent4.1.4 Active Response on Ubuntu. Path:/var/ossec/active-response/bin
By default, when an IP-based attack is detected, the Wazuh Agent can execute an active response such as blocking the attacker’s IP using the firewall_drop script. The blocked IPs can be viewed using:
sudo iptables -LHowever, Wazuh does not natively delete malicious files detected on the system. To enhance this capability, add a custom shell script named lin-custom-remove-malware.sh that enables the agent to remove detected malware automatically. This script is a modified version based on the official Wazuh documentation: Wazuh Custom Active Response Documentation.
Note: Files removed by this script are permanently deleted.
This virtual machine hosts the DVWA web application and forwards its logs to the Wazuh Manager using the Wazuh Agent.
4.2.1 Install DVWA for Windows. Follow the installation tutorial by Robin Wood. After installation, verify that Apache is running:
DVWA login page (default credentials: admin / password):
4.2.2 Install Wazuh Agent on Windows. Log in to the Wazuh web interface. Click on Add agent and select Windows with architecture MSI 32/64 bits as the agent's operating system. Set the VM address to the Wazuh server's IP.
# Download & install Wazuh Agent
Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.12.0-1.msi -OutFile $env:tmp\wazuh-agent
msiexec.exe /i $env:tmp\wazuh-agent /q WAZUH_MANAGER='172.23.0.11' WAZUH_AGENT_GROUP='default' WAZUH_AGENT_NAME='a-windows'
# Start the agent service
NET START WazuhSvcAfter installation, verify the agent connection in the Wazuh dashboard.
4.2.3 Configure Wazuh Agent on Windows. Edit the agent configuration file located at: C:\Program Files (x86)\ossec-agent\ossec.conf
Add or modify the following configuration:
<ossec_config>
<!-- Collect Apache access logs -->
<localfile>
<log_format>apache</log_format>
<location>C:\xampp\apache\logs\access.log</location>
</localfile>
<!-- Monitor file integrity in the Downloads folder -->
<syscheck>
<directories>C:\Users\<your-windows-name>\Downloads</directories>
</syscheck>
</ossec_config>Restart the Wazuh Agent service after saving changes:
NET STOP WazuhSvc
NET START WazuhSvc4.2.4 Configure Active Response on Windows. Path: C:\Program Files (x86)\ossec-agent\ossec.conf\active-response\bin. By default, when an IP-based attack is detected, the Wazuh Agent executes an active response using netsh.exe to block the attacker's IP. These blocked IPs can be reviewed via Windows Defender Firewall. However, Wazuh cannot natively delete malicious files detected on Windows systems. To enhance this capability, add a custom executable script named win-custom-remove-malware.exe to automatically delete detected malware files. This executable is built using Python, and its source code can be found here: win-custom-remove-malware.py. The script is a modified version based on the official Wazuh documentation: Wazuh Custom Active Response Documentation.
Note: Files removed by this script are permanently deleted.
4.3.1 Create a workflow in Shuffle and add a webhook trigger, then copy the Shuffle Webhook Url.
4.3.2 Edit the configuration file /var/ossec/etc/ossec.conf on the Wazuh Server. Add the Shuffle Webhook Url inside the <hook_url> block. Alerts sent to Shuffle can be filtered by <level>, <rule_id>, <group>, or <event_location>.
<ossec_config>
<integration>
<name>shuffle</name>
<hook_url><your-shuffle-webhook></hook_url>
<level>10</level>
<alert_format>json</alert_format>
</integration>
</ossec_config>4.3.4 modify /var/ossec/integrations/shuffle.py by adding verify=False to skip SSL certificate verification.
def send_msg(msg: str, url: str) -> None:
"""Send the message to the API
Parameters
----------
msg : str
JSON message.
url: str
URL of the integration.
"""
headers = {'content-type': 'application/json', 'Accept-Charset': 'UTF-8'}
res = requests.post(url, data=msg, headers=headers, timeout=10, verify=False)
debug('# Response received: %s' % res.json)4.3.5 Restart the Wazuh Manager to apply the new configuration.
systemctl restart wazuh-manager4.4.1 Copy the custom-misp.py file as the main script to integrate Wazuh with MISP, along with its execution wrapper custom-misp to /var/ossec/integrations/ directory.
4.4.2 Set the file permissions and ownership to ensure Wazuh can read and execute both files properly:
sudo chown root:wazuh custom-misp*
sudo chmod 750 custom-misp*4.4.3 Add the misp_rules rule into /var/ossec/etc/rules/local_rules.xml to trigger Wazuh alerts when files or IPs are marked as malicious by MISP.
4.4.4 Add the custom MISP integration to the Wazuh Manager configuration file /var/ossec/etc/ossec.conf:
<ossec_config>
<integration>
<name>custom-misp</name>
<group>syscheck,recon,attack,web_scan</group>
<alert_format>json</alert_format>
</integration>
</ossec_config>4.4.5 Restart the Wazuh Manager to apply the configuration:
systemctl restart wazuh-manager4.5.1 Add the following active response configuration on Wazuh Agent (via Wazuh Manager) for Linux. /var/ossec/etc/ossec.conf. This uses firewall-drop to block IPs and lin-custom-remove-malware.sh to remove malicious files:
<ossec_conf>
<!-- Active Response Call Linux Drop IP -->
<command>
<name>lin-firewall-drop</name>
<executable>firewall-drop</executable>
<timeout_allowed>yes</timeout_allowed>
</command>
<active-response>
<disabled>no</disabled>
<command>lin-firewall-drop</command>
<location>local</location>
<timeout>no</timeout>
</active-response>
<!-- Active Response Call Linux Remove Malware -->
<command>
<name>lin-custom-remove-malware</name>
<executable>lin-custom-remove-malware.sh</executable>
<timeout_allowed>no</timeout_allowed>
</command>
<active-response>
<disabled>no</disabled>
<command>lin-custom-remove-malware</command>
<location>local</location>
</active-response>
<ossec_conf>4.5.2 Add the following active response configuration on Wazuh Agent (via Wazuh Manager) for Windows. /var/ossec/etc/ossec.conf. This uses netsh.exe to block IPs and win-custom-remove-malware.exe to remove malicious files:
<ossec_conf>
<!-- Active Response Call Windows Drop IP -->
<command>
<name>win-netsh</name>
<executable>netsh.exe</executable>
<timeout_allowed>yes</timeout_allowed>
</command>
<active-response>
<disabled>no</disabled>
<command>win-netsh</command>
<location>local</location>
<timeout>no</timeout>
</active-response>
<!-- Active Response Call Windows Remove Malware -->
<command>
<name>win-custom-remove-malware</name>
<executable>win-custom-remove-malware.exe</executable>
<timeout_allowed>no</timeout_allowed>
</command>
<active-response>
<disabled>no</disabled>
<command>win-custom-remove-malware</command>
<location>local</location>
</active-response>
</ossec_conf>4.5.3 Restart the Wazuh Manager to apply all new configurations:
systemctl restart wazuh-managerThe incident handling and response playbook provides a systematic guideline executed when a security incident occurs. It delivers a structured approach to identify, manage, and recover from cybersecurity incidents while giving administrators better control over how each incident is handled and responded to.
The playbook consists of five workflows: Detection, False Incident, True Incident, Investigate, and Active Response. Each workflow can be triggered based on the administrator’s decision, allowing flexibility in categorizing and responding to incidents.
Based on the playbook:
- Create 5 workflows:
Detection,False Incident,True Incident,Investigate, andActive Response. - Each workflow includes a Webhook to forward information and confirmation messages via Google Chat.
- Data from each workflow is stored using
set_cache_valueand retrieved usingget_cache_value.
Integration details:
- Shuffle ↔ MISP: Uses MISP API key.
- Shuffle ↔ Groq: Uses Groq API key.
- Shuffle ↔ Google Chat: Uses Google Chat Webhook URL.
- Shuffle ↔ IRIS: Uses IRIS API key.
- Shuffle ↔ Wazuh: Uses Wazuh API token.
- Inter-workflow communication: Uses individual Webhooks.
- Cache communication: Uses Wazuh or IRIS alert IDs as keys.
This workflow is automatically triggered when Wazuh Server forwards an alert to Shuffle with a severity level of 10 or higher. Shuffle performs classification and parsing simultaneously. The summarized information is stored in Shuffle’s cache for later use by workflows 2 and 3, while IoCs (IP, file, or hash) are stored in MISP. Next, the summary is analyzed by Groq, which provides additional insights and recommendations, then sends them to the security team via Google Chat. This process completes Workflow 1.
Details:
- Create a Webhook to receive alerts from Wazuh.
- Process the alert using
execute_pythonto performIncident Classification,Parse Asset, andParse IoC. - Connect to MISP to store IoC data (IP, file, or hash).
- Save parsed information to the cache using
set_cache_valuewith the Wazuh alert ID. - Connect to Groq for analysis and recommendations.
- Send the results and recommended actions to the security team via Google Chat.
This workflow is triggered when the security team selects the False Incident option, indicating a false positive. It retrieves cached information from Workflow 1 (such as IP or hash) and sends it to the security team via Google Chat. The IoC can then be added to Wazuh’s Constant Database (CDB) to prevent similar alerts in the future. This marks the end of the incident handling process.
Details:
- Create a Webhook to trigger this workflow from Google Chat.
- Retrieve information from Workflow 1 using
get_cache_valuebased on the Wazuh alert ID. - Use execute_python to extract the IoC (IP or hash).
- Send it via Google Chat for the administrator to whitelist in Wazuh’s CDB.
This workflow runs when the administrator selects True Incident, confirming the threat as a real incident. It retrieves cached data from Workflow 1 and forwards it to IRIS for case management. IRIS creates a new alert and escalates it into a case using the following logic:
- If no existing case title matches, a new case is created.
- If a case with the same title exists:
- If the affected asset is the same, IRIS escalates it to the same case without duplicating assets.
- If the asset differs, the asset is added to the same case.
- If the evidence is new and complete, it will be added to the case; otherwise, it will be ignored.
The processed information is cached for use in workflows 4 and 5, depending on the team’s next action. Finally, IRIS details are sent to Google Chat, marking the end of Workflow 3.
Details:
- Create a Webhook to trigger this workflow from Google Chat.
- Retrieve information from Workflow 1 using
get_cache_value(Wazuh alert ID). - Use execute_python to create alerts, escalate cases, and attach evidence in IRIS.
- Store incident information using set_cache_value with the IRIS alert ID.
- Notify the security team via Google Chat for further action.
This workflow is triggered when the administrator selects Investigate, meaning the team will perform a deeper investigation. It retrieves cached data from Workflow 3 and forwards it to IRIS for additional notes and task assignment. IRIS creates investigation notes related to the threat and asset, and assigns a new task to the security team with the status To Do. The investigation notice is then sent to Google Chat, marking the end of Workflow 4.
Details:
- Create a Webhook to trigger this workflow.
- Retrieve incident data from Workflow 3 using
get_cache_value(IRIS alert ID). - Use
execute_pythonto add notes and assign a task in IRIS. - Notify the team via Google Chat that an investigation task has been created.
This workflow is triggered when administrator selects Remove File or Block IP, indicating an active response action. It retrieves cached data from Workflow 3 to identify the affected asset type (Linux or Windows) and the IoC (file or IP). Then, Wazuh Agent executes the corresponding active response — deleting the file or blocking the IP — depending on the incident type. IRIS records the action, marks the task as Done, and closes the case. A confirmation message is sent via Google Chat, completing the playbook.
Details:
- Create a
Webhookto trigger this workflow. - Retrieve incident data from Workflow 3 using
get_cache_value(IRIS alert ID). - Use
execute_pythonto check the affected asset (Linux/Windows) and IoC type (file/IP). - Retrieve the Wazuh API token using the
curlcommand. - Communicate with the Wazuh Manager using the retrieved token to execute the appropriate response.
- Execute the appropriate response, create a note, and close the case in IRIS.
- Notify the administrator via Google Chat that the Wazuh Agent has completed the response.
Get Wazuh Token
Find Actions: Curl
Statement: curl -u wazuh-wui:'<your-api-wazuh-password>' -k -X GET "https://172.23.0.11:55000/security/user/authenticate?raw=true"Active Response by asset
- Linux
IoC type:
- File
# Advanced Find Actions: Run command APIkey: <Wazuh-Token> Url: https://172.23.0.11:55000 Body: {"alert":{"data":{"misp":{"file_path":"$linux_ioc_value.message"}}},"arguments":"","command":"lin-custom-remove-malware0","custom":""} Headers: Content-Type=application/json Accept=application/json Agents list: <impacted-asset-id>
- IP
# Simple Find Actions: Run command APIkey: <Wazuh-Token> Url: https://172.23.0.11:55000 Alert: {"data":{"srcip":"$linux_ioc_value.message"}} Command: lin-firewall-drop0 Headers: Content-Type=application/json Accept=application/json Agents list: <impacted-asset-id>
- File
- Windows
IoC type:
- File
# Advanced Find Actions: Run command APIkey: <Wazuh-Token> Url: https://172.23.0.11:55000 Body: {"alert":{"data":{"misp":{"file_path":"$windows_ioc_value.message"}}},"arguments":"","command":"win-custom-remove-malware0","custom":""} Headers: Content-Type=application/json Accept=application/json Agents list: <impacted-asset-id>
- IP
# Advanced Find Actions: Run command APIkey: <Wazuh-Token> Url: https://172.23.0.11:55000 Body: {"alert":{"data":{"srcip":"$windows_ioc_value.message"}},"arguments":"","command":"win-netsh0","custom":""} Headers: Content-Type=application/json Accept=application/json Agents list: <impacted-asset-id>
- File
The visualization options are provided along with plugins if the desired visuals are not available. Customize the dashboard visualization based on the monitoring needs.
Testing the detection of malicious files on Windows and deleting the file.
6.2.1 Disable Windows security protection in C:\Users\<your-windows-username\Downloads> to prevent the file from being auto-deleted.
6.2.2 Download the Eicar test file to test Wazuh malware detection.
6.2.3 Wazuh successfully detects the Eicar file as malware.
6.2.4 A notification is sent to the Administrator, confirming Workflow 1 executed successfully.
6.2.5 File hash and name are stored in ioc_local on MISP.
6.2.6 IRIS generates an alert, escalates the case, records affected assets, and gathers evidence.
6.2.7 A notification confirms Workflow 3 executed successfully and requests action confirmation.
6.2.8 IRIS adds notes for assets and threats, marks actions as Done, and closes the case.
6.2.9 A notification confirms Workflow 5 executed successfully and the malware file was deleted.
6.2.10 File deletion logs are detected by Syscheck in Wazuh Manager.
Testing the detection of web server attacks on Ubuntu and blocking the source IP address.
6.3.1 Set DVWA security level to Low.
6.2.2 Perform SQL Injection attack using ' OR '1'='1.
6.2.3 Wazuh successfully detects the SQL Injection attack from IP 172.23.0.50.
6.2.4 A notification is sent to the Administrator, confirming Workflow 1 executed successfully.
6.2.5 The source IP is stored in ioc_local on MISP.
6.2.6 IRIS generates an alert, escalates the case, records affected assets, and gathers evidence.
6.2.7 A notification confirms Workflow 3 executed successfully and requests action confirmation.
6.2.8 IRIS adds notes for assets and threats, marks actions as Done, and closes the case.
6.2.9 A notification confirms Workflow 5 executed successfully and the malicious source IP was blocked.
6.2.10 IP blocking information can be viewed using iptables -L on Ubuntu.
The semi-automated SOC system built in this project successfully integrates Wazuh, MISP, IRIS, Grafana, and Shuffle into a cohesive workflow for detecting, analyzing, and responding to cyber threats. A total of five automated workflows were developed, each designed to support different stages of the incident response lifecycle, from detection to eradication and post-incident. The testing results demonstrate that the system is capable of:
- Enhanced Wazuh’s capability to detect malicious files and IPs through MISP threat intelligence integration.
- Sending notifications and confirmation to administrators via Google Chat integrated workflows in Shuffle for quick confirmation of security incidents.
- Storing IOCs (hashes, IPs, filenames) in MISP for future correlation and intelligence enrichment.
- Creating and escalating cases automatically in IRIS to support structured investigation and evidence collection.
- Performing automated remediation actions, such as deleting malicious files or blocking attacker IP addresses through system commands.
- Visualized the security landscape using Grafana dashboards integrated with Wazuh, providing real-time visibility.
This implementation proves that semi-automation significantly enhances detection accuracy, reduces manual response time, and ensures consistent handling of security events. While human validation remains part of the process, automation through Shuffle and open-source SOC tools streamlines workflows and improves operational efficiency.
By adopting this approach, organizations can strengthen their Security Operations Center (SOC) capabilities using cost-effective, open-source solutions while maintaining flexibility for customization and future scalability.