SOC Case Study: Adversary Simulation & Detection Engineering

Context and Goals

This case study documents a controlled adversary simulation I performed in my home cyber lab.

I deliberately:

Misconfigured a Windows server to reflect common small-business weaknesses.
Launched targeted attacks from an "attacker" VM.
Monitored how those attacks were captured by Windows logs, Sysmon, Wazuh, and OpenEDR.
Practiced a full SOC-style investigation and remediation workflow.

Lab Highlights

Active Directory domain with domain controller and member servers
Windows Server 2016 system acting as a file/utility server (SRV-WIN01)
Windows 10 workstation representing a user endpoint
Wazuh collecting Windows Event Logs and Sysmon events
OpenEDR deployed on endpoints for additional telemetry
A dedicated attacker VM on an "external" / detonation segment

The scenario is inspired by "Investigating Windows" and "Windows Logging for SOC" style labs, but built and executed entirely in my own environment.

Scenario Overview

What I Simulated

I set up SRV-WIN01 to intentionally resemble a poorly secured production server:

RDP exposed from a restricted "external" segment
Built-in Administrator account enabled for remote login
No MFA, weak RDP posture, and basic password-only auth

Attack Chain Executed

RDP brute force against the Administrator account
Authenticated successfully over RDP using the compromised credentials
Created a new local admin account for persistence
Added that account to Administrators and Remote Desktop Users
Set up a scheduled task to run a PowerShell script on a schedule
Had that script initiate outbound HTTPS connections to a simulated C2 server

My goal was to:

Watch how every step showed up in Windows logs, Sysmon, and Wazuh
Practice investigating it as if I were a SOC analyst seeing this in a customer network
Design detections and remediation steps based on my own simulated attack

Detection: How the Attack Was Captured

Initial Alerts in Wazuh

Once the brute-force portion of the simulation started, Wazuh began generating alerts based on Windows Security events:

Brute-force Pattern Detected

Multiple 4625 (failed logon) events targeting Administrator. All from the attacker VM IP: 10.10.25.50. Attempts clustered into a short time window.

Successful RDP Logon Following Failures

4624 (successful logon) with:

LogonType = 10 (RemoteInteractive – RDP)
TargetUserName = Administrator
IpAddress = 10.10.25.50

Detection Validation: I confirmed that my simulated brute-force behavior was correctly detected as "Excessive failed logons followed by a successful RDP logon on a privileged account."

Log Sources Used

To analyze how my own attack showed up, I focused on:

Windows Security Log – Authentication: 4624, 4625, 4634, 4647; Account changes: 4720, 4722, 4728, 4732, 4756
Sysmon – Process creation: Event ID 1; Network connections: Event ID 3; File/registry activity: Event ID 7, 11, 13
PowerShell Operational Logs – Script block logging: 4103, 4104
Wazuh SIEM – For correlation, alerting, and timeline reconstruction

The point of this exercise was to prove that my logging stack (Windows + Sysmon + Wazuh + OpenEDR) captured every step.

Investigation: Replaying My Own Attack as a SOC Analyst

Establishing the Timeline

Starting from the Wazuh alerts, I worked backwards and then forwards:

Brute Force Phase

Numerous 4625 events against Administrator from 10.10.25.50. Clear time clustering showing a scripted or tool-based attack.

Initial Compromise

A 4624 with LogonType = 10 (RDP), same IP, same account. Treated as the pivot event indicating the moment my simulated attack succeeded.

Account and Group Activity

As part of my simulated persistence, I:

Created a new local account: svc_backup
Added it to admin-related groups

As a SOC analyst looking at the logs, I validated that:

4720 – User Account Created

TargetUserName = svc_backup, SubjectUserName = Administrator. Proved the attacker (me) used Administrator to create the new account.

4728 / 4732 / 4756 – Group Membership Changes

Showed svc_backup being added to Administrators and Remote Desktop Users.

From the defender perspective: "Attacker created a new local admin account and granted it RDP access."

Scheduled Task and Persistence

As the attacker, I then:

Created a scheduled task named OneDrive Update Service
Configured it to run: cmd.exe /c powershell.exe -File C:\ProgramData\update.ps1

In the logs, I confirmed this showed up as:

Security Log – 4698 (Scheduled task created). Task name and command visible in event details.
Sysmon – Process creation events for schtasks.exe with my command line. Creation of update.ps1 under C:\ProgramData\.

This let me verify that a SOC team could detect fake "update" tasks pretending to be legitimate software and see the exact script path and commands my simulated attacker used.

Outbound Network Connections and PowerShell

My script (update.ps1) was coded to:

Collect basic host information
Establish an HTTPS connection to a simulated C2 host
Check in on a timer to mimic beaconing behavior

In logs:

Sysmon Event ID 3 – Recorded powershell.exe making outbound connections to IP 203.0.113.50:443 (lab C2)
PowerShell Operational Logs (4104) – Showed script block content, including web requests and host/user info being gathered

Detection Validation

With Sysmon + PowerShell logging enabled, I can see suspicious outbound PowerShell traffic and reconstruct the script behavior without ever seeing the original file.

Detection Engineering: Rules I Designed from My Own Attack

A big goal of this exercise was to convert what I did as an attacker into concrete detections.

Detection 1: RDP Brute Force Followed by Success

Detection Logic

Count failed logons (4625) against a single account from one IP in a short window
Raise an alert when a successful logon (4624) with LogonType 10 occurs afterward from the same IP and user
Prioritize if account is privileged (Administrator, Domain Admins, etc.)

Purpose: Catch the exact pattern I generated: repeated failures, then success on RDP.

Detection 2: New Local Admin Account Creation

Detection Logic

Watch for 4720 (user created) on servers and critical endpoints
Correlate with 4728 / 4732 / 4756 (user added to admin/RDP groups)
Conditions: Creator is a privileged account; account name matches common "service" naming patterns (svc_*, backup, etc.)

Purpose: This rule is directly based on my svc_backup persistence step.

Detection 3: Suspicious Scheduled Tasks

Detection Logic

Identify 4698 events creating scheduled tasks whose command line includes powershell.exe or cmd.exe launching scripts from unusual directories (C:\ProgramData, temp paths)
Flag task names that mimic common software (*Update*, *Service*) but point to non-standard script locations

Purpose: This detection was tuned using the exact OneDrive Update Service task I set up.

Detection 4: Outbound PowerShell Beaconing

Detection Logic

Use Sysmon Event ID 3 to find: ProcessName = powershell.exe, destination IPs or domains not seen in baseline
Alert on repeated outbound connections to the same external host on 443 from PowerShell

Purpose: Built around the HTTPS traffic I generated in update.ps1.

Remediation and Hardening

After finishing the simulated attack and investigation, I switched fully back into blue team mode and remediated my own mess.

Immediate Host-Level Remediation

On SRV-WIN01, I:

Disabled and removed the svc_backup account
Deleted the malicious scheduled task
Removed the update.ps1 script and verified no additional artifacts remained
Reviewed OpenEDR/Wazuh telemetry to confirm no other processes or connections were active

Authentication & RDP Hardening

To prevent a replay of my own attack, I:

Disabled RDP exposure directly from the "external" segment
Required VPN with MFA for administrative access
Restricted or disabled the built-in Administrator account for remote logons
Implemented account lockout policies suitable for thwarting brute-force attempts

Logging & Monitoring Improvements

I used lessons learned to tighten logging:

Verified Sysmon configuration on all lab Windows systems (ensured process, network, and registry events were reliably captured)
Confirmed PowerShell script block logging was fully enabled and forwarding to Wazuh
Tuned Wazuh rules to implement the detections described above (brute force + success, new local admin, scheduled task persistence, outbound PowerShell anomalies)

Playbook Creation

I documented the steps I took into a "Windows Host Compromise (RDP)" playbook that includes:

How to recognize this pattern in Wazuh
Which event IDs and Sysmon logs to pivot on
How to identify new accounts, tasks, and outbound connections
The exact remediation sequence: Isolate → investigate → remove persistence → reset credentials → hunt for spread

Skills Demonstrated

Adversary Simulation – Design and execute realistic attacks in a controlled lab
SOC Analysis – Treat my own attacks like a real incident and reconstruct them from logs
Windows Logging Expertise – Security log, Sysmon, and PowerShell Operational log usage
Detection Engineering – Convert real attacker behavior into concrete detection rules for Wazuh/SIEM
Remediation and Hardening – Close the exact gaps I exploited (RDP, MFA, admin rights, logging coverage)
Playbook Creation – Turn a one-off lab exercise into a reusable incident response process
SIEM/EDR Operations – Wazuh deployment, rule tuning, alert correlation, and telemetry validation

Summary

In this homelab simulation, I intentionally compromised my own Windows server, then:

Verified that my logging stack (Windows + Sysmon + Wazuh + OpenEDR) captured every step
Practiced investigating it like a real SOC analyst
Built detections and hardening controls directly from what I observed

This is the same cycle I would apply in production: Observe what logs show → Build detections and playbooks → Harden the environment against what we just learned.