Day 1: Building My First SOC Lab and Catching My First Alerts

In this post I’m documenting what I’ve learned about what a SOC Analyst actually does day to day, the tools, the alerts, and the workflow.

I finally stopped just reading about cybersecurity and actually built something.

Today was about creating my own mini company network inside my laptop and getting a security monitoring system to watch it. The goal is simple. Learn by doing, break things safely, and understand what real attacks and alerts look like from a SOC analyst’s perspective.

Building the Lab Environment

I set up a 5 machine lab using Oracle VirtualBox:

• Kali Linux as the attacker machine
• Windows Desktop as the victim endpoint
• Ubuntu as the Wazuh SIEM server
• Windows Server
• Metasploitable as a deliberately vulnerable machine

At first, I made a classic mistake. I put everything on NAT. That meant none of the machines could talk to each other properly. Not very useful for a network lab.

After troubleshooting, I switched everything to NatNetwork and built an isolated network on the 10.0.2.0/24 range. That fixed communication between all machines.

Kali also refused to grab an IP address at first, which I fixed using:
dhcpcd eth0

Final IP setup looked like this:

• Ubuntu (SIEM): 10.0.2.5
• Windows Desktop: 10.0.2.15
• Kali: 10.0.2.6
• Metasploitable: 10.0.2.4

In simple terms, I built a safe, isolated playground that behaves like a real company network.

Deploying Wazuh SIEM

Next step was getting visibility.

I installed Wazuh 4.7.5 on Ubuntu using the official script. Since I am running Ubuntu 24.04, I had to use the ignore check flag to bypass version restrictions.

Then everything broke.

The Wazuh indexer kept crashing. The issue turned out to be Java heap memory. It was trying to use more RAM than the VM had available.

Fix:

• Edited /etc/wazuh-indexer/jvm.options
• Set both Xms and Xmx to 2g
• Increased VM RAM to 4096MB

After that, the stack finally stabilized.

I also manually registered agent keys using manage_agents to enroll Metasploitable.

Lesson learned: SIEM tools are powerful, but they are resource hungry. If the system is unstable, check memory first.

Connecting the Windows Endpoint

I installed the Wazuh agent on the Windows Desktop machine and confirmed it showed up as active in the dashboard.

Then I added Sysmon logging by enabling:
Microsoft-Windows-Sysmon/Operational

I configured it directly in the ossec.conf file on the agent.

Once that was done, I could see detailed process level events flowing into Wazuh. This is where things start to feel real. You are not just collecting logs, you are watching behavior.

First Attack Simulation: Nmap Scan

Time to act like an attacker.

From Kali, I ran an Nmap scan against the Windows machine:

• Target: 10.0.2.15

The scan revealed:

• Port 135 (RPC)
• Port 139 (NetBIOS)
• Port 445 (SMB)

Port 445 immediately stands out. This is a common target in real world attacks like WannaCry.

I also ran a more aggressive scan against Metasploitable and found 23 open ports, many tied to known vulnerabilities including:

• vsftpd backdoor
• Samba RCE
• UnrealIRCd backdoor
• Open VNC with no authentication

This machine is basically a training goldmine.

One interesting observation. Wazuh did not alert on the Nmap scan. That is a detection gap I will come back to later.

First Alert Triage

To generate alerts, I simulated failed logins on the Windows machine by entering incorrect passwords.

Wazuh picked up:

• Failed logon events (Event ID 4625)
• Successful logon after failures (Event ID 4624)
• Service startup changes

The key pattern was this:

Multiple failed logins followed by a successful one.

That is classic brute force behavior.

I marked this as my first incident.

Incident #001: Brute Force Leading to Successful Login

This was the moment everything clicked. I was not just setting up tools anymore. I was detecting behavior.

False Positives and Rule Tuning

Then came the noise.

Wazuh kept triggering alerts for successful logins, but they were not real user logins. They were Windows services running in the background using logon type 5.

Instead of disabling the rule completely, I tuned it.

I added conditions to filter alerts where:

• rule.id = 60106
• logonType = 5

This kept meaningful alerts while removing noise.

Key lesson: never blindly disable alerts. Always add context.

What I Learned Today

• Networking mistakes will break everything before you even start
• SIEM tools need proper resources or they will fail silently
• Visibility is everything. Without logs, you are blind
• Attack simulation helps you understand what normal vs abnormal looks like
• Detection gaps exist and finding them is part of the job
• Tuning alerts is just as important as creating them

Final Thoughts

Today felt like a shift from theory to reality.

I built a working SOC lab, deployed a SIEM, connected endpoints, simulated attacks, and investigated my first incident.

There is still a lot that does not work perfectly, but that is the point.

Tomorrow I want to focus on improving detection, especially around reconnaissance like Nmap, and start exploring exploitation on Metasploitable.

This is just Day 1.