Building a Windows 11 Blue Team SOC Lab Using Only Built-In Tools Single-Host Incident Investigation Lab (No External Tools)

One of the biggest misconceptions about getting started in blue team security is that you need expensive software, enterprise SIEM platforms, or a home lab full of virtual machines. While those tools are certainly useful, the reality is that you can learn many of the core skills used by Security Operations Centre (SOC) analysts using nothing more than a Windows 11 PC.

This project was designed to simulate real-world security investigations using only the tools already included with Windows. No third-party software, no Linux virtual machines, and no external logging platforms. Just Windows 11 and a curious mindset.

By the end of this lab I'll showcase my skills with:

• Windows Event Log analysis

• Authentication investigations

• Process execution tracking

• Privilege escalation monitoring

• Incident reporting

• SOC-style documentation
  

Project Objectives

The goal was to transform a standard Windows 11 workstation into a self-contained security monitoring environment.

The machine would serve three purposes:

1. The endpoint being monitored

2. The source of security telemetry

3. The analyst workstation used to investigate events
   

This approach mirrors the investigative process used by many entry-level SOC analysts and provides a solid foundation before moving on to more advanced platforms.

Phase 1 – Configuring Windows Security Logging

The first step was enabling the audit policies required to generate meaningful security data.

Using Local Security Policy (secpol.msc), I configured Windows to record:

• Successful logons

• Failed logons

• User account changes

• Administrative privilege assignments

• Process creation events
  

Navigate to:

Security Settings└── Advanced Audit Policy Configuration    └── Audit Policies

Within the audit policies, I enabled the following settings:

Account Logon

Audit Credential Validation

• Success

• Failure

This records authentication attempts and password validation activity.

Logon/Logoff

Audit Logon

• Success

• Failure

Audit Logoff

• Success

Audit Special Logon

• Success

Audit Other Logon/Logoff Events

• Success

These settings generate some of the most useful security events:

Event ID	Description
4624	Successful Logon
4625	Failed Logon
4634	Logoff
4672	Special Privileges Assigned

Account Management

Audit User Account Management

• Success
  

This tracks:

• User account creation

• User account deletion

• Password changes

• Account modifications

Detailed Tracking

Audit Process Creation

• Success

Audit Process Termination

• Success

Process creation logging is particularly valuable because it records programs executed on the endpoint.

Advanced Audit Policy Configuration Overview

Credential Validation Settings

Logon/Logoff Audit Configuration

User Account Management Audit Settings

Detailed Tracking Settings

Enabling Command-Line Visibility

By default, Windows records process execution but does not always include the command line used to launch a process.

To improve visibility, I enabled command-line auditing.

Open:

gpedit.msc

Navigate to:

Computer Configuration└── Administrative Templates    └── System        └── Audit Process Creation

Enable:

Include command line in process creation events

This significantly improves the usefulness of Event ID 4688 by recording the exact commands executed.

Audit Process Creation Policy Location

Include Command Line In Process Creation Events Enabled

After making the changes, I refreshed policy settings using:

gpupdate /force

Phase 2 – Creating a SOC Monitoring View

Rather than searching through thousands of events, I created a custom Event Viewer filter focused on the most useful event IDs for this project.

Open:

Event Viewer└── Windows Logs    └── Security

Filter the following Event IDs:

4624, 4625, 4634, 4672, 4688

These events provide visibility into:

• Authentication activity

• Failed logons

• Administrative privilege assignments

• Process execution

• User logoffs
  

Event Viewer Security Log

Custom Event Filter Configuration

Filtered Security Events View

This effectively became a lightweight SOC dashboard using only native Windows functionality.

Phase 3 – Authentication Investigation

The first simulated incident involved authentication activity.

To generate events:

1. Lock the workstation using Win + L

2. Enter an incorrect password several times

3. Log in successfully

This creates:

• Event ID 4625 (Failed Logon)

• Event ID 4624 (Successful Logon)

  
  

Failed Logon Events (4625)

Successful Logon Event (4624)

During analysis I reviewed:

• Username

• Failure reason

• Logon type

• Event timestamps

• 
  

  

This exercise demonstrates how SOC analysts investigate suspicious authentication activity and identify patterns that may indicate password guessing or brute-force attempts.

Phase 4 – Process Execution Investigation

Next, I generated command-line activity using PowerShell and Command Prompt.

PowerShell commands:

whoamiipconfig /allnet usertasklist

Command Prompt commands:

hostnamesysteminfoecho test

I also launched:

• Notepad

• Calculator

PowerShell Activity

Command Prompt, Notepad and Caculator Activity

Windows recorded these activities using Event ID 4688.

During investigation I reviewed:

• Process Name

• Parent Process

• Command Line

• Process Creation Time
  

  

Event ID 4688 Process Creation Events

This is one of the most valuable event types available to defenders because it provides visibility into exactly what was executed on the endpoint.

Phase 5 – Privilege Escalation Monitoring

Administrative activity often attracts additional scrutiny during investigations because attackers frequently attempt to gain elevated privileges.

To generate administrative events, I launched Command Prompt as Administrator.

Commands executed:

whoami /privnet session

These actions generated Event ID 4672.

Special Privileges Assigned (4672)

The investigation focused on:

• Which account received privileges

• When privileges were assigned

• Whether elevation was expected
  

  

This exercise helped demonstrate how privileged activity appears within Windows security logs.

Phase 6 – File Activity Investigation

To simulate normal user activity, I created a dedicated investigation folder.

C:\SOC_Lab

Within this directory I:

• Created files

• Renamed files

• Deleted files

Although Windows does not provide detailed file auditing by default, correlating Explorer activity with process creation events helps build a broader picture of endpoint activity.

Lessons Learned

This project reinforced several important blue team concepts.

Logs Tell the Story A single event rarely provides enough information on its own. The real value comes from correlating multiple events together. Understanding how authentication events, process creation events, and privilege assignments relate to each other is a fundamental SOC skill.

Authentication Is Often the Starting Point

Successful and failed logons provide valuable context when investigating suspicious activity. Learning how to identify these events in Event Viewer helps build a strong foundation for future security investigations.

Process Creation Events Are Gold

Event ID 4688 quickly became one of the most valuable sources of information throughout this project. It provides visibility into what was executed on the system, how it was launched, and often why it was launched.

Administrative Activity Requires Context

Administrative privileges are not inherently suspicious. The key is understanding whether privileged activity aligns with expected user behaviour and whether it occurred at an appropriate time.

Windows Already Provides Powerful Visibility

Many people assume they need expensive software or enterprise-grade security tools to start learning blue team skills. This project demonstrated that Windows 11 already includes a surprisingly useful set of logging and investigative capabilities.

Investigation Skills Matter More Than Tools

Security tools change from organisation to organisation, but the ability to analyse logs, understand system behaviour, and ask the right investigative questions remains constant. Developing these skills early makes it easier to adapt to SIEM platforms, EDR solutions, and enterprise security environments later on.

Final Thoughts

One of the biggest takeaways from this project is that you do not need a complex home lab to start learning blue team fundamentals. With nothing more than a Windows 11 machine and the tools already included with the operating system, it is possible to gain hands-on experience with authentication monitoring, process investigation, privilege analysis, and basic incident response techniques.