Controlled Filebeat test event -> Logstash Beats input -> OpenSearch -> OpenSearch Dashboards

Overview

OPFORGE-v2 reached its first validated telemetry foundation.

The goal for this milestone was simple: prove that a cleanly rebaselined cyber range could collect Windows endpoint telemetry, route it through a controlled ingestion pipeline, store it in a searchable backend, and make it available for analyst review.

The validated path was:

Windows endpoint -> Winlogbeat -> Logstash -> OpenSearch -> OpenSearch Dashboards

This matters because OPFORGE is not just a collection of virtual machines. It is intended to become a repeatable threat emulation and detection validation environment. Before adding complex scenarios, adversary behaviors, Sysmon tuning, or AI-assisted analytics, the telemetry foundation has to work.

This milestone proves that foundation exists.

What Was Built

The logging stack milestone included five core components:

The primary logging server is opf-srv-log01. The initial Windows telemetry endpoint is OPF-WKS-WIN01.

For this first IOC, the endpoint and logging server were placed on the same controlled lab network so I could validate the telemetry path before introducing more realistic routing, segmentation, and firewall complexity.

Why This Milestone Matters

A cyber range becomes useful when it can produce evidence.

That means more than just “the VM boots” or “the service installed.” The range needs to prove that:

• Endpoint activity creates observable telemetry.
• The telemetry is collected reliably.
• The ingestion layer can receive and enrich it.
• The storage layer can index and search it.
• The analyst interface can support investigation.
• The process is documented well enough to repeat.

This milestone validates that OPFORGE-v2 can support those requirements.

Validated Data Path

The validated telemetry path was:

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

A controlled Windows Application event was generated on the endpoint, collected by Winlogbeat, forwarded to Logstash, indexed into OpenSearch, and confirmed searchable.

The controlled validation token was:

opforge-winlogbeat-test-001

That token was intentionally generated so the test could be searched and verified without relying only on background Windows noise.

Validation Highlights

The following capabilities were validated:

The most important result was confirming that a controlled Windows event generated on OPF-WKS-WIN01 appeared in OpenSearch with the expected endpoint, agent, event, and OPFORGE enrichment fields.

Representative Event Evidence

The controlled validation event included these key fields:

In addition to the controlled validation event, the pipeline also collected representative Windows Application, System, and Security telemetry. That is important because it shows the pipeline is not limited to a single synthetic test event.

Logstash Role

Logstash is the control point for this IOC.

For now, it receives Beats input, applies OPFORGE-specific enrichment, and forwards the data into OpenSearch using a controlled index pattern.

This is a deliberate design choice. I want OPFORGE-v2 to support detection validation, not just log collection. Logstash gives the lab a place to normalize, enrich, tag, and route telemetry before it reaches the search layer.

That will matter later when the lab begins validating specific adversary behaviors against expected detections.

OpenSearch and Dashboards Role

OpenSearch provides the searchable backend. OpenSearch Dashboards provides the analyst interface.

At this stage, the goal was not to build polished dashboards yet. The goal was to prove that telemetry could be searched, inspected, and used as evidence.

Dashboards will become more important once OPFORGE-v2 starts building repeatable detection validation scenarios and evidence packs.

Lessons Learned

The biggest lesson from this milestone is that rebaselining is worth the time.

Instead of continuing to layer new work on top of the older lab, OPFORGE-v2 now has a cleaner structure:

• Clearer naming
• Better runbook discipline
• Documented architecture decisions
• Evidence-backed validation
• A cleaner split between local build notes and public portfolio updates

Another lesson is that validation should happen in small, controlled increments. Before adding Sysmon, domain telemetry, adversary emulation, or AI analytics, the basic telemetry path needed to be proven.

Now it is.

What This Unlocks

With the logging stack IOC validated, OPFORGE-v2 is ready for the next layer of work:

1. Add Sysmon baseline telemetry.
2. Create the first Windows telemetry smoke-test scenario.
3. Build detection validation artifacts.
4. Add adversary emulation events.
5. Capture structured evidence packs for each scenario.
6. Begin mapping telemetry to detection logic and ATT&CK-aligned behaviors.
7. Prepare the lab for future AI-assisted analysis.

This is the foundation for the rest of OPFORGE-v2.

Current Status

OPFORGE-v2 now has a working initial telemetry pipeline:

Windows endpoint telemetry -> Winlogbeat -> Logstash -> OpenSearch -> Dashboards

That means the lab has crossed an important threshold. It is no longer just infrastructure. It is now producing searchable operational evidence.

The next milestone will be to improve endpoint visibility with Sysmon and begin turning raw telemetry into detection validation scenarios.

• H.Y.P.R.