Response to SSH Attack Using Shuffle, Wazuh, and TheHive

Let's explore a different scenario:

• Create ubuntu machine

• Install Wazuh agent on ubuntu

• Perform SSH attack on this machine

• Push all level 5 alerts to Shuffle

• Perform IP enrichment using VirusTotal

• Send details to the analyst via telegrm bot (ask to block source ip)

• Create an alert in TheHive

Let's start by setting up a new Ubuntu machine and conduct an SSH attack on it. However, before proceeding with the attack, we need to install a Wazuh agent on the machine to collect and analyze logs for monitoring and security analysis.

Let's run this command on the Ubuntu machine we set up to install the Wazuh agent.

wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.10.1-1_amd64.deb && sudo WAZUH_MANAGER='192.168.204.150' WAZUH_AGENT_NAME='Ubuntu' dpkg -i ./wazuh-agent_4.10.1-1_amd64.deb

sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent
sudo systemctl status wazuh-agent

Let's install the SSH server on the Ubuntu machine that will be used as the target for the SSH attack.

sudo apt update
sudo apt install openssh-server -y
sudo systemctl start ssh
sudo systemctl enable ssh
sudo systemctl status ssh

Next, we need to conduct an SSH attack on this machine from a separate system. I created two files containing usernames and passwords to utilize in the attack.

hydra -L users.txt -P passwords.txt ssh://192.168.204.146

Let's review the logs to determine the cause of the attack.

Let's review our Wazuh dashboard to determine if any logs related to this attack have been recorded.

We are currently observing a significant number of Level 5 alerts related to SSH brute-force attacks. To enhance detection, we will create a rule that triggers an additional alert when the specific Level 5 alert "sshd: Attempt to login using a non-existent user" occurs more than three times within a 60-second timeframe. This new alert will explicitly indicate that an SSH brute-force attack is in progress.

nano /var/ossec/etc/rules/local_rules.xml

  <rule id="5764" level="10" frequency="3" timeframe="60">
    <if_matched_sid>5710</if_matched_sid>
    <same_source_ip />
    <description>Multiple SSH login attempts using non-existent usernames.</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>

systemctl restart wazuh-manager

Rule Breakdown:

1. <rule id="5764" level="10" frequency="3" timeframe="60">:

   • id="5764": A unique identifier for this rule.

   • level="10": The severity level of the alert (10 is relatively high, indicating a significant security event).

   • frequency="3": The rule triggers an alert if the event occurs 3 times.

   • timeframe="60": The event must occur 3 times within 60 seconds for the alert to trigger.

2. <if_matched_sid>5710</if_matched_sid>:

   • This rule depends on another rule with ID 5710. Rule 5710 is typically a base rule that detects a single failed SSH login attempt using a non-existent username.

   • This means the rule will only trigger if rule 5710 has already matched (i.e., a failed SSH login attempt with an invalid username has been detected).

3. <same_source_ip />:

   • This ensures that the same source IP address is responsible for the multiple failed attempts.

   • Without this, the rule might trigger for failed attempts from different IPs, which is less indicative of a brute-force attack.

4. <description>Multiple SSH login attempts using non-existent usernames.</description>:

   • A human-readable description of the rule. This will appear in the alert message.

5. <mitre><id>T1110</id></mitre>:

   • Maps this rule to the MITRE ATT&CK framework.

   • T1110 refers to the technique "Brute Force", which is used by attackers to guess usernames and passwords.

Let's simulate the brute force attack again to verify the effectiveness of the rule.

hydra -L users.txt -P passwords.txt ssh://192.168.204.146

Next, let's review the alerts in the Wazuh dashboard.

We received an alert triggered by Rule ID 5764, which we previously configured to activate when Event ID 5710 occurs three times. To reduce the frequency of alerts, we can modify the rule to trigger after five occurrences instead of three.

Next, let's set up a webhook to receive alerts from the Wazuh dashboard.

Now, let's modify the Wazuh configuration to include our webhook URL.

nano /var/ossec/etc/ossec.conf

systemctl restart wazuh-manager

Let's reattempt the attack and check if any results appear in Shuffle.

We now need to submit the IP address to VirusTotal for analysis.

As previously mentioned, you must provide your API key for authentication.

Let's rerun the process and review the results from VirusTotal.

Since this is our internal IP address, it is not classified as malicious by VirusTotal.

Before proceeding with obtaining the Wazuh API to block the IP address involved in SSH brute-force attacks on an Ubuntu machine, it is essential to first understand Wazuh's Active Response mechanism.

​Wazuh's Active Response feature enables automated reactions to detected threats by executing predefined scripts or commands. A common application is blocking malicious IP addresses to safeguard your systems.

Active Response is a Wazuh feature that enables automated actions (e.g., blocking an IP, killing a process) in response to detected threats. For example:

• Block an IP address after multiple failed SSH login attempts.

• Block an IP address after a port scan is detected.

Let's open the Wazuh manager configuration file:

nano /var/ossec/etc/ossec.conf

We need to specify the action to be taken when a threat is detected. Wazuh provides default scripts, like firewall-drop, which utilize the system's firewall to block IPs.​

<command>firewall-drop</command>
<location>local</location>
<rules_id>5764</rules_id>                                          
<timeout>no</timeout>

• firewall-drop: This is the command that will execute the script to block the IP.

• rules_id: Specify the rule IDs that should trigger the Active Response.

• local: Indicates that the command should run on the agent where the threat was detected.

• no: Specifies that the block remains indefinitely, requiring manual intervention to lift it.

This setup ensures that when rule 5764 is triggered, the offending IP is blocked locally without an automatic unblock.​

Next, let's save the file and restart the Wazuh Manager to apply the changes.

systemctl restart wazuh-manager

Before proceeding with using Shuffle to block the IP, let's first understand the scenario. There is a tool called agent_control. This tool, provided by Wazuh, enables administrators to manage and monitor Wazuh agents from the Wazuh Manager. It allows for various administrative tasks, including listing connected agents, restarting or removing agents, and checking their status.

Also, Wazuh's agent_control utility can be used to manually block specific IP addresses across your monitored endpoints.

Let's display the list of available active responses.

./agent_control -L

Here is the active response we created before. This command will display all configured active responses, allowing us to choose the appropriate one for blocking IP addresses. ​

We will attempt to block the Ubuntu machine from pinging 8.8.8.8 using agent_control. However, before implementing the block, we will first verify that the Ubuntu machine can successfully ping 8.8.8.8.

ping 8.8.8.8

Now, let's execute the active response command.

./agent_control -b 8.8.8.8 -f firewall-drop0 -u 002

• -b 8.8.8.8: Specifies the IP address to be targeted by the active response

• -f firewall-drop0: Indicates the active response command to execute. firewall-drop is a standard script in Wazuh designed to block IP addresses using the system's firewall

• -u 002: Identifies the agent by its unique ID (002) on which the active response should be executed.​

Next, let's try to ping 8.8.8.8 from the Ubuntu machine.

Let's confirm this by reviewing the firewall rules.

sudo iptables --list

We can also review the logs of the active response from this location.

cat /var/ossec/logs/active-responses.log 

Now, let's return to our Shuffle workflow and utilize an HTTP app to retrieve the Wazuh API JWT.

However, obtaining the API JWT requires access to the necessary credentials.

During the Wazuh installation process, we previously downloaded this file. We now need to extract it in order to retrieve the credentials required to obtain the JWT.

tar -xvf wazuh-install-files.tar

You can find the necessary credentials in the file wazuh-passwords.txt.

We can get the JWT we need using the following command:

curl -u username:password -k -X GET "https://192.168.204.150:55000/security/user/authenticate?raw=true

Let's proceed with this on Shuffle. However, before doing so, let's remove the rule that blocks ping requests to 8.8.8.8 on the Ubuntu machine. Once the rule is removed, we can attempt the same scenario using Shuffle.

sudo iptables -L -n -v --line-numbers

sudo iptables -D INPUT 1
sudo iptables -D FORWARD 1

ping 8.8.8.8

Now, let's attempt to block the IP using the Shuffle workflow.

You will need to enter your IP address, username, and password.

Now, let's integrate the Wazuh application into our workflow.

Let's save the changes and execute the workflow again.

Let's verify whether the Ubuntu machine can successfully ping 8.8.8.8.

ping 8.8.8.8

iptables -L

Let's incorporate the user input trigger into our workflow to send an email to the analyst, allowing them to decide whether to block the IP address.

Before utilizing the user input trigger, let's first create a new workflow named "Send an Alert." This workflow will be used to send an alert via a Telegram bot.

Next, after saving the workflow, we will incorporate the user input trigger into the process.

Please select the previously created workflow.

Let's configure the Wazuh application to dynamically assign the source IP.

{"data":{"srcip":"$exec.all_fields.data.srcip"}}

Now, let's review the other workflow to ensure everything is functioning correctly.

We now need to integrate the Telegram app into this workflow to send the alert to the analyst.

Refer to this resource for guidance on creating a Telegram bot: https://faresbltagy.gitbook.io/footprintinglabs/weinnovate-training/soar/send-alerts-to-email-and-telegram-bot

$exec.information\n$exec.frontend_continue\n$exec.frontend_abort

Next, let's save the changes and re-execute the workflow.

Next, we will review the results on our Telegram bot.

The first URL is used when blocking the source IP is necessary, whereas the second URL is used when blocking is not required. Therefore, we will proceed with the first URL to block the IP.

http://192.168.204.151:3001/forms/933e34e4-524f-47d5-8538-7065cfb6843a?authorization=e2430a6c-a958-45f7-92e2-2868bedddebd&reference_execution=4188690f-ba43-4070-82be-7c4fac6c6616&answer=true&source_node=76868dcc-1e5f-4ec4-8156-917099ae83cc

Now that we have blocked the IP address 192.168.204.151 from attacking the Ubuntu machine at 192.168.204.146, let's verify whether the attacker can still ping the Ubuntu machine.

ping 192.168.204.146

Let's also review the firewall rules on the Ubuntu machine.

iptables -L

Let's also generate and send an alert to TheHive.

Summary -> Multiple SSH login attempts using non-existent usernames on host: $exec.all_fields.predecoder.hostname from source IP:$exec.all_fields.data.srcip

Now, let's save the changes and execute the workflow again.

I hope the project was clear and easy to understand. Thank you for your time and consideration.