# 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. ```bash 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 ```

```bash 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. ```bash 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. ```bash 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. ```bash nano /var/ossec/etc/rules/local_rules.xml ``` ```xml 5710 Multiple SSH login attempts using non-existent usernames. T1110 ```

```bash systemctl restart wazuh-manager ``` #### **Rule Breakdown**: 1. **``**: * **`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. **`5710`**: * 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. **``**: * 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. **`Multiple SSH login attempts using non-existent usernames.`**: * A human-readable description of the rule. This will appear in the alert message. 5. **`T1110`**: * 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. ```bash 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. ```bash nano /var/ossec/etc/ossec.conf ```

```bash 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: ```bash 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.

```xml firewall-drop local 5764 no ``` * **`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. ```bash 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. ```bash ./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. ```bash ping 8.8.8.8 ```

Now, let's execute the active response command. ```bash ./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. ```bash sudo iptables --list ```

We can also review the logs of the active response from this location. ```bash 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. ```bash 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. ```bash sudo iptables -L -n -v --line-numbers ```

```bash sudo iptables -D INPUT 1 sudo iptables -D FORWARD 1 ```

```bash 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. ```bash ping 8.8.8.8 ```

```bash 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. ```json {"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:

```bash $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. ```uri 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. ```bash ping 192.168.204.146 ```

Let's also review the firewall rules on the Ubuntu machine. ```bash iptables -L ```

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

```json 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://faresbltagy.gitbook.io/footprintinglabs/build-home-lab-soc-automation/response-to-ssh-attack-using-shuffle-wazuh-and-thehive.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.