Windows Telemetry in Depth: Sysmon + WEF in a Lab

If you want serious Windows detection in a home lab, you need structured telemetry. Sysmon gives you high value process, network, and file events. Windows Event Forwarding (WEF) ships those events to a collector without installing third party agents. Together, they form a clean, low maintenance pipeline that mirrors enterprise logging.

This guide focuses on a small lab with a domain controller, a single WEF collector, and a handful of Windows endpoints. The goal is not just to turn logging on, but to make it searchable and consistent so you can write detections and verify them quickly.

Architecture overview

The WEF model is pull-based. Endpoints (sources) send events to the collector using WinRM over HTTP or HTTPS. Subscriptions on the collector decide what events to collect, and Group Policy configures the sources to forward.

A minimal lab looks like this:

• wec01 (collector) joined to the domain
• win10-lab and win11-lab (sources)
• Sysmon installed on the sources

The collector stores events in the Forwarded Events log. You can later forward those into a SIEM or export them for analysis.

Install and configure Sysmon

Download Sysmon from Microsoft Sysinternals and use a curated configuration. The SwiftOnSecurity sysmon config is popular, but you can start with a smaller configuration and add rules as needed. The example below enables core process creation, network connections, and process injection events.

# run as admin
.
Sysmon.exe -accepteula -i sysmon-config.xml

A small Sysmon config snippet looks like this:

<Sysmon schemaversion="4.90">
  <EventFiltering>
    <ProcessCreate onmatch="include">
      <Image condition="end with">\powershell.exe</Image>
      <Image condition="end with">\rundll32.exe</Image>
    </ProcessCreate>
    <NetworkConnect onmatch="include">
      <DestinationPort condition="is">445</DestinationPort>
      <DestinationPort condition="is">5985</DestinationPort>
    </NetworkConnect>
    <ProcessAccess onmatch="include">
      <TargetImage condition="end with">\lsass.exe</TargetImage>
    </ProcessAccess>
  </EventFiltering>
</Sysmon>

Keep the config small at first. Large rulesets can flood your collector and make it harder to identify baseline behavior.

Configure the collector

On wec01, enable the Windows Event Collector service and create a subscription. For a lab, a single source-initiated subscription is easiest.

wecutil qc
wecutil cs "C:\wef\sysmon-subscription.xml"

A basic subscription file might look like this:

<Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription">
  <SubscriptionId>Sysmon-Forward</SubscriptionId>
  <SubscriptionType>SourceInitiated</SubscriptionType>
  <Description>Collect Sysmon events</Description>
  <Enabled>true</Enabled>
  <Uri>http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog</Uri>
  <ConfigurationMode>Custom</ConfigurationMode>
  <Delivery Mode="Push">
    <Batching>
      <MaxItems>50</MaxItems>
      <MaxLatencyTime>300000</MaxLatencyTime>
    </Batching>
  </Delivery>
  <Query>
    <Select Path="Microsoft-Windows-Sysmon/Operational">*</Select>
  </Query>
</Subscription>

Group Policy for sources

On your domain controller, create a GPO to configure the subscription manager and allow the WinRM listener. The key setting is:

Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Event Forwarding

Set the subscription manager to your collector:

Server=http://wec01:5985/wsman/SubscriptionManager/WEC,Refresh=60

Then ensure WinRM is enabled on the sources. You can do this in GPO or with winrm quickconfig in the lab.

Verifying event flow

From a source endpoint, trigger a test event by running a simple PowerShell command. Then check the collector.

Get-Process | Select-Object -First 1

On the collector, open Event Viewer and confirm the Sysmon event appears under Forwarded Events. You can also query it directly:

Get-WinEvent -LogName "Forwarded Events" -MaxEvents 5 | Format-List

If you see events but they are delayed, reduce the batching latency. For a lab, low latency is more useful than storage efficiency.

Sysmon events worth prioritizing

Sysmon produces a lot of events, but a few are consistently high value. Event ID 1 (process creation) is the core for detecting suspicious executions. Event ID 3 (network connections) ties processes to destinations. Event ID 7 (image load) helps identify unsigned modules. Event ID 10 (process access) is key for credential dumping attempts against LSASS. Event ID 11 (file create) is useful for dropper behavior.

Start with those and avoid enabling everything at once. If you enable Event ID 7 globally, for example, you will flood your collector with DLL load noise. Instead, scope it to high risk processes like browsers, scripting engines, or admin tools. That keeps the signal to noise ratio high and makes your lab analytics easier to validate.

WEF subscription scoping

WEF subscriptions can include filters to reduce volume. Use XPath in the subscription to only collect specific event IDs or provider names. This is especially useful when you want to forward Sysmon and select Security events but ignore low value logs.

Here is an example of a scoped subscription query that collects Sysmon and key Security events:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select>*</Select>
  </Query>
  <Query Id="1" Path="Security">
    <Select>*[System[(EventID=4624 or EventID=4625 or EventID=4688)]]</Select>
  </Query>
</QueryList>

Scoped subscriptions keep the collector stable and make it easier to build detections because the dataset is consistent.

Normalizing fields for hunting

Sysmon event IDs are consistent, but you should normalize field names if you plan to hunt with scripts. The example below pulls a few fields from Event ID 1 (process creation) and writes them to CSV.

Get-WinEvent -FilterHashtable @{LogName="Forwarded Events"; Id=1} | 
  ForEach-Object {
    $xml = [xml]$_.ToXml()
    [pscustomobject]@{
      TimeCreated = $_.TimeCreated
      Image = $xml.Event.EventData.Data | Where-Object {$_.Name -eq "Image"} | Select-Object -ExpandProperty "#text"
      CommandLine = $xml.Event.EventData.Data | Where-Object {$_.Name -eq "CommandLine"} | Select-Object -ExpandProperty "#text"
      ParentImage = $xml.Event.EventData.Data | Where-Object {$_.Name -eq "ParentImage"} | Select-Object -ExpandProperty "#text"
    }
  } | Export-Csv .\sysmon-process.csv -NoTypeInformation

Detection use cases

With Sysmon and WEF in place, you can start building detections that are hard to do with default Windows logs:

• Parent-child anomalies, like winword.exe spawning powershell.exe
• Credential dumping attempts via LSASS access
• New services and scheduled tasks created by non-admin processes
• Network connections from unsigned binaries

The lab makes it easy to test these. For example, run rundll32 with a suspicious DLL path and ensure the process creation event is collected. Then add a detection rule to flag it.

Operational tips

Keep your collector tidy. The Forwarded Events log can grow quickly, so adjust log size limits or forward to a SIEM. In a home lab, exporting to EVTX once a day is often enough.

Also document your GPO settings. WEF can be fragile if GPOs conflict, and you do not want to troubleshoot it every time you rebuild a VM.

Takeaways

Sysmon plus WEF gives you enterprise-grade Windows telemetry without extra agents. The setup cost is a few GPOs and an hour of lab time. Once it is running, you can simulate attacks, collect the events, and iteratively build detections. This is the backbone for serious Windows security work, and a strong foundation for any blue team lab.