Wazuh Configuration
Now, we need an agent to collect and analyze events from endpoints. The Wazuh Agent is responsible for collecting security-relevant data from the endpoints (such as servers, workstations, and other devices) and forwarding it to the Wazuh manager or Wazuh server for analysis.
After access the page, click Add Agent. In Server Address section, we need to write Wazuh IP Address.
Then wazuh gives us thw command to execute endpoint for installing agent and start it.
And then execute this command on Windows10 machine which we have already installed.
Next step is checking the service of wazuh is running.
Then, refresh and again access to Wazuh, we can see the agent which is activated.
Next step is to configure the ossec.conf file to send sysmon logs of Windows to Wazuh. For to do this, Open C:\Program Files (x86)\ossec-agent\ossec.conf file with notepad but as Administrator(Open Notepad as Administartor and click File and select ossec.conf file). Then add following into the file.
<localfile>
<location>Microsoft-Windows-Sysmon/Operational</location>
<log_format>eventchannel</log_format>
</localfile>Why Microsoft-Windows-Sysmon/Operational ? — Well, beacuse we want to send sysmon logs, if we open the sysmon on Windows on EventViewer, it shows this path.
Also we can send Powershell logs and add the following (instead of Microsoft-Windows-Sysmon/Operational, we write Microsoft-Windows-PowerShell/Operational)
Microsoft-Windows-PowerShell/Operational
Then it looks like this:
Save and quit the file. Then, open services and restart wazuh service.
Then, again access to Wazuh and then select Discover tab.
type sysmon.
As we can see, our Windows10 sysmon logs are successfully sending.
Mimikatz Download
Mimikatz is an open-source tool used to extract sensitive information like passwords, hashes, and Kerberos tickets from Windows systems. It can perform actions like credential dumping, Pass-the-Hash, and creating Golden or Silver Tickets for unauthorized access.
We downloaded mimikatz_trunk.zip from here with two different ways. You can choose any of the two you want.
- Disable the Windows Defender
- Exclude the specific folder from firewall(in our case this folder is Downloads folder)
We will exclude the Downloads folder and download mimikatz into i.
open Windows Security
Click Virus & threat protection
scroll down a little bit and select Add or remove exclusions.
Then select Add exclustions -> folder -> Downloads
Next step, probably web browser blocked the mimikatz, avoid this select setting ( for Google Chrome) open settings and under privacy and security select security and click no protection.
Note: Don’t forget to restore these settings after downloading Mimikatz.
Now, extract the mimikatz_trunk.zip file. Then, run Powershell as Administrator, change the directory to mimikatz.exe, then run mimikatz.exe.
Now if we look the logs related to mimikatz which is malicious file, we see that:
Don’t worry, we are on the right track :)
Firstly let’s start why the mimikatz can’t be shown on Wazuh? — Well, By default, Wazuh logs only events that align with its established rules, instead of recording every single event. Wazuh uses a set of predefined rules and configurations to filter and analyze the collected data. When an event matches one of these rules, it gets logged and an alert may be generated. This approach helps in focusing on significant events and reducing the amount of logged data, making it easier to identify potential security issues and anomalies. Because we don’t have any rules which triggered by mimikatz, that’s why wazuh doesn’t showed it. How can we solved it? — We we will make some changes in the ossec.conf file and then wazuh will log everything, not just the events that match the rules. And then, we’ll create a rule that defines the mimikatz. Let’s start :)
Open the /var/ossec/etc/ossec.conf file and set yes as value of <logall> and <logall_json>.
Note: It is recommended to copy of ossec.conf file before modifying it because any msitake cause stop working of service
<logall> — This toggles whether to store events even when they do not trip a rule with results written to /var/ossec/logs/archives/archives.log. When enabled, the Wazuh server stores the logs in a syslog format.
<logall_json> — This toggles whether to store events even when they do not trip a rule with results written to /var/ossec/logs/archives/archives.json. When enabled, the Wazuh server stores the events in a JSON format.
Next restart the Wazuh manager in order for the configuration changes to take effect.
sudo systemctl restart wazuh-manager.service
Depending on our chosen format, the file archives.log, archives.json, or both will be created in the /var/ossec/logs/archives/ directory on the Wazuh server.
Next we have to edit the /etc/filebeat/filebeat.yml and set true as value of filebeat.modules archive.
Next restart the filebeat in order for the configuration changes to take effect.
systemctl restart filebeat
Click Create Index
Discover tab
If you don’t see any logs related to mimikatz, then again execute the mimikatz on windows machine and then again execute this command on wazuh-manager.
It is also can be shown in sysmon/EventViewer and Wazuh.
Creating Rule
Click Management -> Rules -> Custom Rules
In Manage rules files section, via typing sysmon in search bar and we can see the sysmon EventID 1 (Process creation) rules in sysmon_id_1.xml, so we take one of them as reference and build it out a custom rule to detect mimikatz.
Click the Custom Rules.
Select the local_rules.xml. And add following into it:
<rule id="100002" level="15">
<if_group>sysmon_event1</if_group>
<field name="win.eventdata.originalFileName" type="pcre2">(?i)mimikatz\.exe</field>
<description>Malicious Activity : Mimikatz Detected!</description>
<mitre>
<id>T1003</id>
</mitre>
</rule>It should looks like this:
- rule-id — The unique identity of the rule. As we can see, rule_id should start from 100000 and the first rule started 100001, so we wrote the 100002 as rule_id. Because after the previous one, we wrote 100002 as the next rule.
- rule level — The classification of levels from 0–15 indicating the level of severity as listed by Wazuh. We wrote 15 as the severity.
- field name — The name of the field extracted from the decoder. The value in this field is matched using regex. By setting the originalFileName as field name to mimikatz.exe, we ensure that even if the attacker changes the file’s name, the original name remains the same, allowing us to detect it.
- Description — It definded when trigerred this rule what will be displayed? we set as Malicious Activity : Mimikatz Detected!. So when mimikatz will be run on our system, this rule wil triggered and shows us Malicious Activity : Mimikatz Detected!
- mitre — we set as T1003. Because this is credential dumping techniques which is what mimikatz is known to do.
When we are done, we confirm the request to restart wazuh-manager which automatically asked to us.
Testing
Run mimikatz on the windows machine.
Go to “Security Events” and we can see alert there:
As we can see, alert is triggered. Now we test our rule in a different way, change the mimikatz name and check alert would triggered or not.
We changed the mimikatz.exe name to svchost.exe and executed it.
As we can see the alert is trigger and show us the mimikatz though we change the filename.
As we can see the alert triggered because of originalFileName (mimikatz.exe) if we write eventdata.image instead originalFileName in the rule then the alert triggered by eventdata.image and because the attacker change file name from mimikatz.exe to svchost.exe then attacker can bypass this rule and alert would not tirgger. This is reason why we write the originalFileName in the rule.
