---
title: 'SOC Home Lab'
---
# SOC Home Lab
I’m back with my first project in 2026. Today’s blog post is about building a SOC home lab. I created it to practice some of the concepts I learned in **SANS SEC450.3**.
SOC home lab architecture using Splunk Enterprise with agent-based log collection from a Windows victim VM:
**Structure of a blog post:**
1. Environment Setup
* Splunk installation
* Windows VM installation
* Enable PowerShell Script Block Logging
* Enable SMB Share Access Logging
* Sysmon installation
* Linux VM installation
2. SIEM integration
3. Attack Simulation && Analysis
# Environment Setup
**Splunk installation:**
1.Create account, then download and install the Splunk Enterprise installer for Windows from: https://www.splunk.com/en_us/download/splunk-enterprise.html
2. Launch Splunk (opens in a browser automatically) and navigate to "**Settings > Forwarding and receiving**"and add a new receiving port (9997) to accept data from Splunk Universal Forwarder.
3. Navigate to "**Settings > Indexes**" and create a new index to store incoming events (sysmon+ powershell).
We will need it in the SIEM integration section.
**Windows VM installation:**
1. Download the media creation tool from here: https://www.microsoft.com/en-ca/software-download/windows10
2. Run this tool and select the option to create an **ISO file**.
3. Use this ISO file to install Windows on your VM.
Now, Windows VM (Victim machine) is ready:
**Enable PowerShell Script Block Logging:** (Windows VM)
1. Open **Local Group policy Editor**
2. Go to
Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell
3. Enable **Turn on PowerShell Script Block Logging**
**Enable SMB Share Access Logging:** (Windows VM)
1. Open **Local Group policy Editor**
2. Go to
Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → System Audit Policies → Object Access
3. Enable **Audit File Share**
**Sysmon installation:**
We will install Sysmon on Windows VM.
1. Open PowerShell as an administrator and run this command:
```
Invoke-WebRequest -Uri https://download.sysinternals.com/files/Sysmon.zip -OutFile "C:\Sysmon.zip"
```
2. Run this command to extract the downloaded file (Sysmon.zip):
```
Expand-Archive -Path "C:\Sysmon.zip" -DestinationPath "C:\Sysmon"
```
3. Install Sysmon:
```
C:\Sysmon\Sysmon.exe -accepteula -i
```
4. Run the command below to check whether Sysmon is installed and running **or** navigate to the Sysmon Operational log in Event Viewer:
```
Get-Service sysmon
```
5. Update sysmon configuration to define which events sysmon should log and which ones should not be logged.
> I used sysmon modular configuration from the following gitHub repository: https://github.com/olafhartong/sysmon-modular/
Download configuration file:
```
Invoke-WebRequest
-Uri https://raw.githubusercontent.com/olafhartong/sysmon-modular/refs/heads/master/sysmonconfig.xml
-OutFile ".\sysmonconfig.xml"
```
Update sysmon configuration:
```
.\Sysmon.exe -accepteula -c sysmonconfig.xml
```
**Linux VM installation:** (kali linux)
There are different options for installing kali:
- [ ] Pre-built virtual machine which we can download and import into our VMware.
- [ ] Download it via an ISO file similar to how we did it with Windows.
I will download a pre-built virtual machine, download link: https://www.kali.org/get-kali/#kali-virtual-machines
Now, the Attacker machine is ready:
# SIEM integration
1. Download Splunk Universal Forwarder on Windows VM.
https://help.splunk.com/en/splunk-enterprise/forward-and-process-data/universal-forwarder-manual/9.4/install-the-universal-forwarder/install-a-windows-universal-forwarder#a19ec22d_68d3_4a7f_b41c_456267545717--en__Install_a_Windows_universal_forwarder_from_an_installer
2. Navigate to `C:\Program Files\Splunk Universal Forwarder\etc\app\Splunk Universal Forwarder\local\inputs.conf` and add :
> [WinEventLog://Microsoft-Windows-Sysmon/Operational]
> current_only = 0
> disabled = false
> renderxml = true
> sourcetype = XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
> start_from = oldest
> index=endpoint
>
> [WinEventLog://Microsoft-Windows-PowerShell/Operational]
> current_only = 0
> disabled = false
> renderxml = true
> sourcetype = XmlWinEventLog:Microsoft-Windows-PowerShell/Operational
> start_from = oldest
> index=endpoint
>
> [WinEventLog://Security]
> current_only = 0
> disabled = false
> renderxml = true
> sourcetype = WinEventLog://Security
> start_from = oldest
> index=endpoint
>
To instruct Splunk Universal Forwarder to send events to the index that we created in step3 in the Splunk installation
3. Stop Splunk Universal Forwarder service and start it again.
# Attack simulation
This attack simulation demonstrates how an attacker with internal network access can exploit an exposed SMB share to deliver a PowerShell script that is unintentionally executed by the victim.
**Windows VM (Victim):**
1. Create local user account for SMB access:
- Open Settings → Accounts → Family & Other users
- Click **Add someone else to this PC**
- Select **I don’t have this person’s sign-in information**
- Select **Add a user without a Microsoft account**
(I created local user account (`username: salsabelmosad`) )
2. Create Shared Folder: (c:\secret)
* Right click → Properties → Sharing → Advanced Sharing
* Enable **Share this folder**
* Click Permissions
* Add created user
* Grant **Full Control** permission
3. Ensure Windows Firewall allows SMB (Port 445)
**Linux VM (Attacker):**
1. Open http server:
```
python3 -m http.server 8080
```
2. Create `payload.ps1` in the same directory where the HTTP server is running.
contents of payload.ps1 → `Write-Output "Attack Simulation"`
3. Reconnaissance:
Execute a Nmap scan to enumerate open ports on the victim machine.
```
nmap -A <victim_ip>
```
Port 445 (SMB) is open on the victim machine :100:
4. Prepare script file:
5. Connect to the SMB Share:
```
smbclient //<victim_ip>/secret -U <username>
```
4. Upload script file:
```
put run.ps1
```
5. Exit session
```
exit
```
---
Navigate to the victim machine and run the delivered script (run.ps1).
Go back to the attacker machine, where you can observe an HTTP request from the victim followed by a successful response delivering `payload.ps1`.
When returning to the victim machine,`payload.ps1` is not found on disk.
why?
`payload.ps1` is not found on disk because it was executed directly in memory using `DownloadString` and `Invoke-Expression (IEX)` (fileless execution technique)
**Let's shift our focus to log analysis in our SIEM to detect this activity:**
Searching for SMB share access events in the endpoint index:
```
index="endpoint" sourcetype="WinEventLog:Security" EventCode=5140
```
This log shows that `192.168.27.129` accessed the shared folder “`secret`” using the user account “`salsabelmosad`”, which exactly matches the action we performed on the attacker's machine during the simulation.
I changed date and time to see what happened after this event, which are shown in Pictures 1,2, 3, 4,5 and 6.
This sequence of events validates the attack chain, demonstrating how initial SMB access led to PowerShell execution and subsequent in-memory payload activity without writing the payload to disk.
**Lessons learned:
This simulation gave me practical experience in correlating telemetry(powershell + sysmon + security logs(smb)), analyzing attacker behavior, making it a valuable step toward real-world security monitoring and incident response.**
Sign in with Wallet
Connect another wallet