OPFORGE-v2 Detection Validation: Windows Telemetry, Sysmon, and PowerShell Execution

From Logging Stack IOC to Detection Validation

OPFORGE-v2 has crossed an important line.

The first milestone was proving that the logging stack worked. That meant getting OpenSearch, OpenSearch Dashboards, Logstash, and endpoint telemetry connected in a way that was repeatable and documented.

This milestone goes further.

OPFORGE-v2 now validates endpoint telemetry through controlled detection-validation scenarios. The lab can generate known Windows activity, collect it from the endpoint, enrich and route it through Logstash, store it in OpenSearch, and confirm it in OpenSearch Dashboards.

The current validated path is:

OPF-WKS-WIN01 -> Winlogbeat -> Logstash -> OpenSearch -> OpenSearch Dashboards

For Sysmon-focused telemetry, the path is:

OPF-WKS-WIN01 -> Sysmon -> Windows Event Log -> Winlogbeat -> Logstash -> OpenSearch -> OpenSearch Dashboards

This matters because it turns the lab from a collection of tools into a repeatable validation environment.

Current Lab Components

The current OPFORGE-v2 validation stack includes:

The Windows endpoint is currently validating from:

OPF-WKS-WIN01
192.168.20.50
Windows 10 Pro

The active validation data view in OpenSearch Dashboards is:

opforge-beats-test-*

Validated Scenario Progression

This post covers three formal detection-validation scenarios.

Each scenario is documented under:

E:\OPFORGE-v2\03-detection-validation\scenarios\

The purpose is not just to say “logs are coming in.” The purpose is to prove that specific activity can be generated, searched, and validated with expected fields.

DV-0001: Windows Telemetry Smoke Test

DV-0001 validated the baseline Windows telemetry path.

A controlled Windows Application event was generated on OPF-WKS-WIN01 with:

OpenSearch Dashboards confirmed the event with endpoint and agent metadata.

Key fields included:

agent.type: winlogbeat
agent.name: OPF-WKS-WIN01
agent.version: 8.19.16
host.hostname: OPF-WKS-WIN01
host.ip: 192.168.20.50
event.provider: OPFORGE-Winlogbeat-Validation
winlog.event_id: 33001

This proved the basic telemetry chain:

Windows Event Log -> Winlogbeat -> Logstash -> OpenSearch -> Dashboards

DV-0002: Sysmon Process Creation Smoke Test

DV-0002 validated Sysmon Event ID 1, which captures process creation telemetry.

After installing Sysmon and updating Winlogbeat to collect the Sysmon operational channel, OpenSearch returned process creation events from:

Microsoft-Windows-Sysmon/Operational

Validated fields included:

winlog.channel: Microsoft-Windows-Sysmon/Operational
winlog.event_id: 1
event.provider: Microsoft-Windows-Sysmon
event.action: Process Create (rule: ProcessCreate)
agent.name: OPF-WKS-WIN01
host.ip: 192.168.20.50

Observed process creation examples included:

C:\Windows\Sysmon64.exe
C:\Windows\System32\cmd.exe /c ver
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
C:\Windows\System32\HOSTNAME.EXE

This proved the lab can collect and validate process telemetry, not just generic Windows events.

DV-0003: PowerShell Execution Telemetry Smoke Test

DV-0003 narrowed the focus to PowerShell execution telemetry.

The controlled test generated PowerShell process creation activity using:

powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "Write-Output 'OPFORGE PowerShell validation event opforge-powershell-test-001'"

A second test generated a parent-child relationship through cmd.exe:

cmd.exe /c powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "Write-Output 'OPFORGE PowerShell child process validation opforge-powershell-test-001'"

OpenSearch returned matching Sysmon Event ID 1 results from the active date-specific index:

opforge-beats-test-2026.06.01

Validated fields included:

winlog.channel: Microsoft-Windows-Sysmon/Operational
winlog.event_id: 1
event.provider: Microsoft-Windows-Sysmon
event.action: Process Create (rule: ProcessCreate)
winlog.event_data.Image: powershell.exe
winlog.event_data.CommandLine: -NoProfile -ExecutionPolicy Bypass
winlog.event_data.CommandLine: opforge-powershell-test-001
winlog.event_data.ParentImage: present
winlog.event_data.User: OPF-WKS-WIN01\OPFORGEAdmin

This scenario is important because it moves OPFORGE-v2 toward actual analytic work. PowerShell is both a legitimate administration tool and a common adversary tradecraft surface. The lab now proves that PowerShell execution characteristics are visible and searchable.

Why This Matters

A cyber range is only useful if it can produce evidence.

For OPFORGE-v2, the goal is not just to run tools. The goal is to validate whether telemetry exists, whether detections can be built from it, and whether the analyst can prove what happened.

This milestone proves that OPFORGE-v2 can support:

• Endpoint telemetry validation
• Sysmon process creation analysis
• PowerShell execution analysis
• Controlled event generation
• Repeatable evidence collection
• Detection engineering workflows
• Future threat emulation validation

The important shift is this:

Before: The logging stack is installed.
Now: The logging stack supports repeatable detection validation.

That difference matters.

Validation Lessons Learned

A few useful lessons came out of this milestone.

1. Use Structured Queries for Precision

A broad OpenSearch URL q= query produced a too_many_nested_clauses error when searching across validation indexes.

The fix was to use a structured JSON bool/filter query against the active date-specific index.

The clean validation target became:

opforge-beats-test-2026.06.01

That gave a better validation pattern for future scenarios.

2. Generic Dataset Values Need Tuning

The current Logstash pipeline still applies generic dataset values such as:

windows-eventlog-validation
beats-ingestion-validation

That is acceptable for IOC validation, but future tuning should classify Sysmon data more precisely.

A better future dataset would be:

windows-sysmon-operational

3. Validation Tokens Should Become First-Class Fields

The validation tokens are currently visible in fields such as:

message
event.original
winlog.event_data.CommandLine

Future pipeline tuning should extract tokens into a dedicated field:

validation_id

That will make future scenario searches cleaner and easier to automate.

4. ECS Normalization Is the Next Upgrade

Sysmon process fields currently appear under:

winlog.event_data.Image
winlog.event_data.CommandLine
winlog.event_data.ParentImage
winlog.event_data.User

Future enrichment should map key values toward ECS-style fields where practical:

That will improve detection portability and make future analytics cleaner.

Current Validated Data Path

The current validated telemetry flow is:

Controlled endpoint activity
-> Windows Event Log / Sysmon
-> Winlogbeat
-> Logstash Beats input on 192.168.20.10:5044
-> OpenSearch
-> OpenSearch Dashboards

The validated host flow is:

OPF-WKS-WIN01 -> opf-srv-log01

The validated service flow is:

Winlogbeat -> Logstash -> OpenSearch -> Dashboards

The validated analytic progression is:

Windows Application event
-> Sysmon process creation
-> PowerShell execution telemetry

What Comes Next

The next scenario is:

DV-0004 PowerShell Encoded Command Telemetry Smoke Test

The objective is to validate visibility for encoded PowerShell command-line behavior before treating it as malicious.

Future work will focus on:

• PowerShell encoded command telemetry
• Pipeline tuning
• Validation token extraction
• Sysmon dataset classification
• ECS-style field normalization
• Detection rules
• Dashboards for scenario evidence
• Threat emulation events mapped to expected telemetry

This is how OPFORGE-v2 becomes more than a lab.

It becomes a detection-validation platform.

Closing Thought

OPFORGE-v2 is now past the basic build phase.

The logging stack is operational. Windows telemetry is flowing. Sysmon process creation is validated. PowerShell execution telemetry is searchable and visible in Dashboards.

The next phase is disciplined detection engineering.

The range can now answer the question that matters:

Did the activity happen, did we collect it, and can we prove it?

That is the foundation for meaningful threat emulation, explainable detection, and future cyber-AI experimentation.

• H.Y.P.R.