From Scrap to SOC: My Journey Setting Up a Wazuh Server on a Dell Laptop
This is a blog that is about my journey installing, and setting up a Wazuh server. With limited resources, this setup promises to be both challenging and fun!
The Adventure Begins: Gathering Resources
The first challenge was sourcing an 8GB stick of RAM from a donated ThinkPad that no longer booted and installing it into my Dell laptop.
My Equipment:
- Dell laptop with a Core i5 processor, 16GB of RAM, and a 256GB NVMe SSD.
- Installing Ubuntu 24.04 LTS and Wazuh.
- MSI laptop that will host a Wazuh Agent VM
After creating an Ubuntu installer USB, the Ubuntu installation on the laptop was smooth and took about 15 minutes give or take.
Prepping Ubuntu for Wazuh
Once booted into Ubuntu, I installed some essential tools: net-tools, curl, openssh, and a system monitor. I chose system-monitor-next with GNOME extensions.
Pro Tip: If you encounter an error requiring gtop for system-monitor-next, use this command:
sudo apt install gir1.2-gtop-2.0 libgtop2-dev
Then reboot the machine, this fixed system-monitor-next for me!
Next, I tweaked the system a little bit. Considering this is a laptop that will be used as a server, I don’t want to kill the battery prematurely. Also I have limited space so I wanted to be able to close the display so I can tuck the machine away somewhere.
With these two requirements I edited the logind.conf file:
sudo nano /etc/systemd/logind.conf
and uncommented/changed these lines:
HandleLidSwitch=ignore
HandleLidSwitchDocked=ignore
Doing this effectively made it so that when the display lid is closed the session stays logged in, the downside is however, the display will not turn off. BUT we can FIX this!
Crafting Scripts to Manage the Display
To fix it so that the display will turn off when the lid is closed, I created the following scripts.
First, place the scripts in /usr/local/bin/:
cd /usr/local/bin/
touch display-lid-watch.sh
display-lid-watch.sh
#!/bin/bash
# Initialize previous state variable to keep track of the lid state
prev_state="unknown"
# Start an infinite loop
while true; do
# Read the current state of the lid (open or closed)
lid_state=$(cat /proc/acpi/button/lid/*/state | awk '{print $2}')
# Check if the current lid state is different from the previous state
if [ "$lid_state" != "$prev_state" ]; then
# If the lid is closed, run the script to turn off the screen
if [ "$lid_state" == "closed" ]; then
/usr/local/bin/turn-off-screen.sh
# If the lid is open, run the script to turn on the screen
else
/usr/local/bin/turn-on-screen.sh
fi
# Update the previous state to the current state
prev_state=$lid_state
fi
# Wait for 1 second before checking the lid state again
sleep 1
done
For the next two scripts you will need to check to see if backlight controls are available. You can do that with this command:
ls /sys/class/backlight/
The output will determine how to structure the command in the scripts we are about to create:
touch turn-off-screen.sh
turn-off-screen.sh
#!/bin/bash
# Sets the backlight brightness value to 0 which is off
echo 0 | sudo tee /sys/class/backlight/intel_backlight/brightness
touch turn-on-screen.sh
turn-on-screen.sh
#!/bin/bash
# Sets the backlight brightness value to 100 which is on. Adjust value for your brightness preference.
echo 100 | sudo tee /sys/class/backlight/intel_backlight/brightness
Make the scripts executable:
sudo chmod +x /usr/local/bin/display-lid-watch.sh
sudo chmod +x /usr/local/bin/turn-off-screen.sh
sudo chmod +x /usr/local/bin/turn-on-screen.sh
Setting Up the Service
Now that we have created the scripts we now need to create a service to actually run these scripts.
Place this service in /etc/systemd/system/:
cd /etc/systemd/system/
touch display-lid-watch.service
display-lid-watch.service
[Unit]
Description=Lid state change handler
[Service]
Type=simple
ExecStart=/usr/local/bin/display-lid-watch.sh
[Install]
WantedBy=multi-user.target
To set up this service to start running and start at boot:
sudo systemctl daemon-reload
sudo systemctl enable display-lid-watch.service
sudo systemctl start display-lid-watch.service
To check and make sure that the service is running correctly:
sudo systemctl status display-lid-watch.service
Battery Health: Preserving Longevity
Since the laptop will be plugged in all the time, I needed to limit battery charging to preserve it’s health. My BIOS actually had an option to set the battery charge configuration, but if yours doesn’t, you can use TLP:
sudo apt-get install tlp
sudo tlp start
Configure the battery thresholds:
sudo nano /etc/tlp.conf
Add or uncomment these lines and set your desired charge thresholds:
START_CHARGE_THRESH_BAT0=50
STOP_CHARGE_THRESH_BAT0=50
Installing Wazuh: Indexer, Server, Dashboard
With the laptop set up as my server, I proceeded to install Wazuh. I have chosen the assisted installation method from the Wazuh Documentation as it is the easiest way to get started.
For the full installation details, refer to: https://documentation.wazuh.com/current/installation-guide/index.html
Once the indexer was installed I ran this command to jot down the admin password:
tar -axf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt -O | grep -P "\'admin\'" -A 1
Then I ran the next two commands to make sure the indexer was installed successfully and to check if the cluster was working correctly:
curl -k -u admin:<ADMIN_PASSWORD> https://<WAZUH_INDEXER_IP>:9200
curl -k -u admin:<ADMIN_PASSWORD> https://<WAZUH_INDEXER_IP>:9200/_cat/nodes?v
Once I verified the indexer was working I installed the server and dashboard, then retrieved the passwords:
tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt
Setting Up the Wazuh Agent
With the Wazuh server installed, I now need an Agent. For this I have installed a Windows 10 VM on my MSI laptop with VMware Workstation.
To set up the VM properly I set up Sysmon, and ran the YamatoSecurityConfigureWinEventLogs.bat file:
Sysmon: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon Yamato Security Batch File: https://github.com/Yamato-Security/EnableWindowsLogSettings
To install Sysmon extract the Sysmon.exe you need for your system and open CMD. Then navigate to the directory you extracted the exe and run this command:
Sysmon64.exe -accepteula -i
To install the YamatoSecurityConfigureWinEventLogs.bat run it as administrator. You can also edit the .bat file if you need to change any settings.
It is now time to install the Wazuh Agent software.
Wazuh Agent Download Page with Installation Instructions: https://documentation.wazuh.com/current/installation-guide/wazuh-agent/index.html
Since I am running windows I installed the Windows Agent software and set up the Manager IP.
Now that I have installed Wazuh server, and set up an agent it was finally time to log into the Wazuh Dashboard! I did notice once I logged in the agent wasn’t enrolled yet, to fix this I just had to restart the agent machine and refresh the Wazuh dashboard page.
Monitoring User Logon Activities
Now that we have everything set up we can start learning Wazuh! Let’s configure Wazuh to monitor user logon activities on the Windows Agent.
What we want to do first is simulate a physical access brute force attack and then look out for failed logon attempts.
On the Agent machine open Notepad as Administrator and open ossec.conf located in: C:\Program Files (x86)\ossec-agent
Find the section that looks like this:
<localfile>
<log_format>eventchannel</log_format>
<location>Security</location>
<query>Event/System[EventID != #### and EventID ...]</query>
</localfile>
And add:
Event ID 4624: For Successful logon Event ID 4625: For Failed logon Event ID 4647: For User-initiated logoff Event ID 4648: For Logon with explicit credentials
After enabling these event logs we can now test it out.
Simulating an unauthorized user with physical access to the Wazuh agent, we go to the lock screen and attempt to brute force the password.
After simulating the brute force attack we can now check Wazuh to see if this was detected!
We will navigate to Agents Summary -> Active -> Agent Machine -> MITRE ATT&CK -> Events
On the events page we can see there are a ton of events to go through so to make it simple I found that I can search for “60122” which is the rule.id for Logon Failure - Unknown user or bad password.
Note: You can also hover over any of the items in the events list and a “+” “-” will appear allowing you to add a filter to the search.
This yielded all 12 of the failed attempts in the simulated attack!
We can click the > to inspect an event table or view the log itself (JSON).
SOC Report: Failed Login Attempts
Now that we have some logs from failed login attempts we need to write up a report.
We can do one of two things, use a report template and write it up in a document, or we can use the Wazuh Reporting Module.
Here is a template for document reports:
#### Executive Summary
**Incident Title:** [Title of the Incident]
**Date:** [Date of the Report]
**Summary:** This report provides an analysis of the detected security incident, including the nature of the event, its impact, and recommended mitigation steps.
---
#### Incident Description
**Date and Time of Incident:** [Date and Time]
**Source:** [Source of the Incident]
**Description:**
- A detailed description of the incident.
- How it was detected.
- The type and number of alerts generated.
---
#### Analysis and Findings
**Log Review:**
- A summary of relevant log entries.
- Patterns or anomalies detected.
- Any additional context (e.g., timeframes, affected systems).
**Incident Details:**
- Specifics of the attempted or successful breach.
- User accounts involved.
- IP addresses or physical locations if applicable.
---
#### Impact Assessment
**System Impact:**
- Description of any system disruptions or data compromise.
- Scope of the incident (e.g., number of affected systems, data at risk).
**Security Implications:**
- Potential risks posed by the incident.
- Assessment of overall security posture.
---
#### Recommendations
**Immediate Actions:**
- Steps taken to contain the incident.
- Any temporary measures implemented.
**Preventative Measures:**
- Suggested changes to policies or configurations.
- Long-term improvements to security infrastructure.
**Additional Recommendations:**
- Further investigations required.
- Training or awareness programs for staff.
---
#### Visualizations
- Charts, graphs, or screenshots from Wazuh dashboard.
- Visual representations of logon attempts, alert trends, etc.
---
#### Conclusion
- Summary of the incident’s handling.
- Final thoughts on improving security posture.
- Next steps and follow-up actions.
---
**Prepared by:** [Your Name]
**Title:** SOC Analyst
**Date:** [Date of Report]
For the scope of this blog I will just fill out the template and provide what it will look like, and in the next blog post I will go over setting up the Wazuh Reporting Module and get more in depth with Wazuh.
Failed Login Attempts SOC Report
Executive Summary
Incident Title: Unauthorized Logon Attempts Detected
Date: 6/17/2024
Summary: This report provides an analysis of a security incident involving multiple failed logon attempts on the monitored machine DESKTOP-KI6LQC4$ (IP: 10.0.0.231). The incident was detected by Wazuh, indicating potential unauthorized physical access and password guessing attempts.
Incident Description
Date and Time of Incident: 6/17/2024 09:07 - 10:24
Source: Physical Access to DESKTOP-KI6LQC4$ | 10.0.0.231
Description:
- On 6/17/2024, 12 failed logon attempts were detected on the machine DESKTOP-KI6LQC4$ (IP: 10.0.0.231).
- The attempts were made by an individual with physical access to the machine, who repeatedly tried to guess the password.
- The logon attempts were identified and logged by Wazuh.
Analysis and Findings
Log Review:
- The following log entries were identified corresponding to the failed logon attempts:
{
"_index": "wazuh-alerts-4.x-2024.06.17",
"_id": "xzOVJpAB-Lgo0XJM6pIu",
"_version": 1,
"_score": null,
"_source": {
"input": {
"type": "log"
},
"agent": {
"ip": "10.0.0.231",
"name": "DESKTOP-KI6LQC4",
"id": "001"
},
"manager": {
"name": "fzr76-wazuh-box"
},
"data": {
"win": {
"eventdata": {
"subjectLogonId": "0x3e7",
"subjectDomainName": "WORKGROUP",
"ipAddress": "127.0.0.1",
"authenticationPackageName": "Negotiate",
"workstationName": "DESKTOP-KI6LQC4",
"subStatus": "0xc000006a",
"logonProcessName": "User32",
"targetUserName": "WazuhAgent",
"keyLength": "0",
"subjectUserSid": "S-1-5-18",
"processId": "0x69c",
"processName": "C:\\\\Windows\\\\System32\\\\svchost.exe",
"ipPort": "0",
"failureReason": "%%2313",
"targetDomainName": "DESKTOP-KI6LQC4",
"targetUserSid": "S-1-0-0",
"logonType": "2",
"subjectUserName": "DESKTOP-KI6LQC4$",
"status": "0xc000006d"
},
"system": {
"eventID": "4625",
"keywords": "0x8010000000000000",
"providerGuid": "{54849625-5478-4994-a5ba-3e3b0328c30d}",
"level": "0",
"channel": "Security",
"opcode": "0",
"message": "\"An account failed to log on.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-5-18\r\n\tAccount Name:\t\tDESKTOP-KI6LQC4$\r\n\tAccount Domain:\t\tWORKGROUP\r\n\tLogon ID:\t\t0x3E7\r\n\r\nLogon Type:\t\t\t2\r\n\r\nAccount For Which Logon Failed:\r\n\tSecurity ID:\t\tS-1-0-0\r\n\tAccount Name:\t\tWazuhAgent\r\n\tAccount Domain:\t\tDESKTOP-KI6LQC4\r\n\r\nFailure Information:\r\n\tFailure Reason:\t\tUnknown user name or bad password.\r\n\tStatus:\t\t\t0xC000006D\r\n\tSub Status:\t\t0xC000006A\r\n\r\nProcess Information:\r\n\tCaller Process ID:\t0x69c\r\n\tCaller Process Name:\tC:\\Windows\\System32\\svchost.exe\r\n\r\nNetwork Information:\r\n\tWorkstation Name:\tDESKTOP-KI6LQC4\r\n\tSource Network Address:\t127.0.0.1\r\n\tSource Port:\t\t0\r\n\r\nDetailed Authentication Information:\r\n\tLogon Process:\t\tUser32 \r\n\tAuthentication Package:\tNegotiate\r\n\tTransited Services:\t-\r\n\tPackage Name (NTLM only):\t-\r\n\tKey Length:\t\t0\r\n\r\nThis event is generated when a logon request fails. It is generated on the computer where access was attempted.\r\n\r\nThe Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.\r\n\r\nThe Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).\r\n\r\nThe Process Information fields indicate which account and process on the system requested the logon.\r\n\r\nThe Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.\r\n\r\nThe authentication information fields provide detailed information about this specific logon request.\r\n\t- Transited services indicate which intermediate services have participated in this logon request.\r\n\t- Package name indicates which sub-protocol was used among the NTLM protocols.\r\n\t- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.\"",
"version": "0",
"systemTime": "2024-06-17T14:24:31.5694054Z",
"eventRecordID": "21651",
"threadID": "1776",
"computer": "DESKTOP-KI6LQC4",
"task": "12544",
"processID": "760",
"severityValue": "AUDIT_FAILURE",
"providerName": "Microsoft-Windows-Security-Auditing"
}
}
},
"rule": {
"mail": false,
"level": 5,
"hipaa": [
"164.312.b"
],
"pci_dss": [
"10.2.4",
"10.2.5"
],
"tsc": [
"CC6.1",
"CC6.8",
"CC7.2",
"CC7.3"
],
"description": "Logon failure - Unknown user or bad password.",
"groups": [
"windows",
"windows_security",
"authentication_failed"
],
"nist_800_53": [
"AC.7",
"AU.14"
],
"gdpr": [
"IV_32.2",
"IV_35.7.d"
],
"firedtimes": 6,
"mitre": {
"technique": [
"Valid Accounts",
"Account Access Removal"
],
"id": [
"T1078",
"T1531"
],
"tactic": [
"Defense Evasion",
"Persistence",
"Privilege Escalation",
"Initial Access",
"Impact"
]
},
"id": "60122",
"gpg13": [
"7.1"
]
},
"location": "EventChannel",
"decoder": {
"name": "windows_eventchannel"
},
"id": "1718634273.3721477",
"timestamp": "2024-06-17T10:24:33.530-0400"
},
"fields": {
"timestamp": [
"2024-06-17T14:24:33.530Z"
]
},
"highlight": {
"rule.id": [
"@opensearch-dashboards-highlighted-field@60122@/opensearch-dashboards-highlighted-field@"
],
"agent.id": [
"@opensearch-dashboards-highlighted-field@001@/opensearch-dashboards-highlighted-field@"
],
"manager.name": [
"@opensearch-dashboards-highlighted-field@fzr76-wazuh-box@/opensearch-dashboards-highlighted-field@"
]
},
"sort": [
1718634273530
]
}
- The failed attempts occurred within a short time frame, suggesting a brute force attack.
Incident Details:
- User Account: The attempts were made on the WazuhAgent account associated with DESKTOP-KI6LQC4$.
- IP Address: 10.0.0.231
- Time Frame: All attempts were logged within a 1 hour and 17 minute window.
Impact Assessment
System Impact:
- No successful logon was achieved. However, repeated failed attempts could indicate a targeted attack on the system.
Security Implications:
- The incident highlights a vulnerability due to physical access, where an attacker could attempt brute force attacks without detection if not monitored properly.
- Such attempts, if successful, could lead to unauthorized access and potential data breaches.
Recommendations
Immediate Actions:
- Ensure that the machine DESKTOP-KI6LQC4$ is physically secured to prevent unauthorized access.
- Investigate any potential physical security breaches and reinforce access control measures.
Preventative Measures:
- Implement stricter password policies, including the use of complex passwords and regular changes.
- Enable account lockout policies after a specified number of failed logon attempts to prevent brute force attacks.
Additional Recommendations:
- Conduct a thorough review of physical security controls and improve where necessary.
- Train staff to recognize and report suspicious activities related to physical access to systems.
Visualizations
Conclusion
- This incident underscores the importance of robust physical and logical security measures to prevent unauthorized access attempts. By implementing the recommended actions, the risk of successful brute force attacks can be mitigated, enhancing overall security posture.
Prepared by: Joshua Gaither
Title: SOC Analyst
Date: 6/17/2024
Wrapping Up
Thanks for sticking with me through this exciting journey! We covered setting up a Wazuh server on a Dell laptop, installing a Wazuh agent in a Windows 10 VM, simulating a brute force attack, and writing a SOC report. Stay tuned for the next blog, where we’ll dive deeper into Wazuh and set up the Wazuh Reporting Module.
Author: Joshua Gaither
