In my previous blog, I show off how I was able to get Wazuh up and running on an Ubuntu VM, 4 agents installed on 4 separate Raspberry Pis, and 1 agent on a Windows 10 VM. I dove into configurations and testing to understand the beginning fundamentals of Wazuh SIEM. The goal of this article is to continue this blue team journey, exploring alerts, use cases, and proof of concepts!
Immediately after getting Wazuh and agents up and running, I returned to the Wazuh dashboard and said to myself “well what the hell do I do now?” At this point, I did what any curious cybersecurity professional would do…. Click the shit out of all the buttons! Only when that stopped making sense, I decided to start researching for real. Activate RTFM mode!
This month, I really want to dive into the detection area of Wazuh. Something I’m starting to understand here, is that there are rule sets within Wazuh where the user can set customize what works best for them, unlike, say, Windows Defender. It’s interesting because when you’re preparing for OSCP, pretty much all defenses are off, then you go study post-OSCP, and start learning about getting around things like Defender and Anti-Virus software. While I can admit I am still within this stage, it should be fun to start at least getting exposure to how an EDR system can spot my malicious activities! It’s worth noting that as much customization is allowed in these tools, something could work against one organization, while not work in another organization. I will go through a couple of these examples by setting up certain rules.
I started off by looking into Wazuh’s summary from their docs: https://documentation.wazuh.com/current/getting-started/use-cases/malware-detection.html
Wazuh for malware detection
“Traditional methods, which rely solely on signature-based detections, have limitations and fail to capture new threats. Signature-based approaches struggle with detecting zero-day attacks, polymorphic malware, and other evasion techniques employed by threat actors. As a result, organizations are at risk of undetected breaches and data exfiltration. Wazuh empowers organizations to detect and respond to sophisticated and evasive threats effectively. Wazuh encompasses different modules that identify malware properties, activities, network connections, and more.”
The doc continues on with an example of how Wazuh detects malicious activities with threat detection rules. To try to get a better understanding of everything, I’m going to experiment by following along with some of their guides, testing against Hoaxshell and webshells.
HOAXSHELL
In order to get familiar with things around Wazuh, I’m following an example they have in order to detect hoaxshell: https://wazuh.com/blog/detecting-hoaxshell-with-wazuh/
This is also my first interaction with Hoaxshell, so I’m excited to jump in! I won’t bother re-writing the article here, so I’ll pick up where it ends. Within the steps, I needed to edit `/var/ossec/etc/rules/local_rules.xml` within the wazuh-manager docker, so to do so, I copy the file out from docker, edit it, then copy it back:
sudo docker cp $(sudo docker ps | grep wazuh-manager | awk '{print $1}'):/var/ossec/etc/rules/local_rules.xml .Here is where I made the necessary changes as stated in Wazuh article, then when I am done, I just copy it back where it belongs within the docker with:
sudo docker cp local_rules.xml $(sudo docker ps | grep wazuh-manager | awk '{print $1}'):/var/ossec/etc/rules/local_rules.xmlThen simply restart the wazuh-manager service to take effect:
service wazuh-manager restartFinally, I continue on throughout the article, to start executing the Hoaxshell. Once executed, I return to Wazuh > Security Events to review detections:
Taking a closer look at the T1059.001 Execution Alert, I found a base64 encoded command:
Decoding that command reveals my original payload that I modified following the Wazuh Hoaxshell detection guide.
At first, I was under the assumption that that any base64 decoding activity was going to be flagged like this, so I went ahead and did a simple test in PowerShell ISE to confirm.
$Text = ‘Can I run this without alerting Wazuh?’
$Bytes = [System.Text.Encoding]::Unicode.GetBytes($Text)
$EncodedText =[Convert]::ToBase64String($Bytes)
$EncodedText
$EncodedText = “QwBhAG4AIABJACAAcgB1AG4AIAB0AGgAaQBzACAAdwBpAHQAaABvAHUAdAAgAGEAbABlAHIAdABpAG4AZwAgAFcAYQB6AHUAaAA/AA==”
$DecodedText = [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($EncodedText))
$DecodedTextI test this out by simply running the script, generating base64 code, and decoding it.
I ran this a few times, and verified this it did not flag high level, there was an entry, but only at level 6, and not 12 like the hoax shell. I’m really looking forward to coming back to this in the future and looking at how this works when I introduce backdoor Word documents, PowerShell cradles and such.
WEBSHELL
https://wazuh.com/blog/web-shell-attack-detection-with-wazuh/
Next up, webshells! WOOOOO. How do we even start testing this? Do I have to start building a web app from the ground up? Ewwwww, no. I’m thinking it would be much easier to just drop an agent on my favorite web security testing VM: Web Security Dojo! This bad boy already has all sorts of vulnerable web apps set up, and requires minimal configuration from me, which… I like. I download a fresh copy of Web Security Dojo, fire it up, and start configuring it in a way it is remotely accessible:
sudo nano /var/www/.htaccessHere, All I gotta do is comment out all of the lines for “limit access to local area network” by adding a # in front of the lines. **Ctrl X | Y** to save the changes and exit nano.
To ensure that the changes are applied and persist, restart the virtual appliance with the following command.
reboot -hOnce Dojo is back up, I’m back in Wazuh GUI, generating an agent for it:
Wazuh > Add new agent
Same as I did for the Raspberry pi’s months back, I slap some commands into Dojo VM to get the wazuh agent up and running, talking to the server:
wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.7.4-1_amd64.deb && sudo WAZUH_MANAGER='192.168.0.249' WAZUH_AGENT_NAME='Dojo' dpkg -i ./wazuh-agent_4.7.4-1_amd64.debsudo systemctl daemon-reloadsudo systemctl enable wazuh-agentsudo systemctl start wazuh-agentNow to check back in Wazuh, and perfectly see Dojo agent has been picked up.
Boom, done. Now to follow the https://wazuh.com/blog/web-shell-attack-detection-with-wazuh/ guide to see what needs to be modified in the wauzh config files.
“Add the following configuration to the Wazuh agent /var/ossec/etc/ossec.conf file within the <syscheck> block. This detects file changes in the /var/www/html/ directory.”
First thing I noticed here, is the default ‘/var/www/html’, if I look at ‘/var/www/’ in Dojo, I see sub directories such as DVWA, mutillidae, etc, that are all vulnerable webapps, so I am going to configure ‘/var/www/’ in my ossec.conf to hopefully cover all those directories.
sudo nano /var/ossec/etc/ossec.confAgain, ensureing I put “/var/www/” in the proper place.
The rest was straightforward, just following the article by Wazuh. Once finally applying all their rules and configs, I am ready for a test drive.
Now to grab a php webshell to help us out, I’m just going to snag a php reverse shell from revshells.com, upload it to DVWA > File Upload, and track it down.
As shown above, simply visiting “dvwa.local/hackable/uploads/” reveals my webshell.php file.
When I executed the webshell however, I got nothing back in Wazuh and began backtracking my steps through the Wazuh walkthrough… I check to see if the wazuh and audit services are running, and funny enough, my audit service was borked!
The output clues me in that on my “/etc/audit/audit/rules” file, there’s an issue on line 5. Turns out, I totally missed the step to fill in the audit.rules. I was not reading close enough, I just copy – pasted the template blindly. SHAME ON ME! So be sure to actually edit this file, and read all the words in the directions.
Once updated, I knew I was on the right track when I refreshed in Wazuh dashboard, and a gang of green bars started to appear.
Checking into the Security Events again, I can finally see webshell detections come in!
Digging in and viewing the full log shows us what binary and path were executed.
Tested by running cat /etc/passwd
Nice, I can drill down specific commands being ran.
So, on one hand, I can see the obvious advantage of having such a powerful tool as Wazuh. Previously, I began initial setup and tested failed authentication login detection by brute forcing creds. This month, I pushed it a bit further and was able to detect attacks such as hoaxshell and webshells. But on the other hand, I feel like I was kind of surprised at just how much effort needed to take place to set up the rules and configuration. I didn’t even get to the part of setting up mail notifications. Either way, it’s an incredible tool for anyone to configure and learn the ins-and-outs of it. Maybe commercial tools are easier to configure or come with a tiny personal SIEM engineer dude to configure everything perfectly.
Well, I think this should conclude my 3-part Blue side adventure for now. What I find really interesting now, is how (in many ways) similar a SIEM is to a C2….
Both have their frameworks, both have agents, and both have some sort of ruleset / conditions, just one is for detection, and one is for stealth. Either way, I’m ready to get back to my malware studies 😊
I’ll again leave some extra helpful links below:
Straight out the box, Wazuh is likely not configured exactly the way I wanted to be. Browse this resource for more helpful rules:
https://github.com/socfortress/Wazuh-Rules
Use cases / malware detection:
https://documentation.wazuh.com/current/getting-started/use-cases/index.html
https://documentation.wazuh.com/current/getting-started/use-cases/malware-detection.html
https://documentation.wazuh.com/current/proof-of-concept-guide/index.html
By the way, anyone catch that Nebraska vs Colorado game?….. yyyyiiiikkkkes!
