Sysmon and Windows Event Forwarding: Enterprise-Grade Endpoint Telemetry

Introduction

Default Windows event logging is surprisingly sparse. Process creation gives you a PID and an image name — but no command-line arguments, no parent process, no network connections. An attacker can live-off-the-land for days before a log entry looks suspicious.

Sysmon (System Monitor) is a free Sysinternals driver from Microsoft that installs as a Windows service and enriches the Event Log with 30+ event types: full command lines, parent/child process trees, DNS queries, file creation timestamps, registry mutations, named pipe activity, and more. Paired with Windows Event Forwarding (WEF), every endpoint ships its Sysmon events to a central Windows Event Collector (WEC) server — no agent beyond what's already in Windows, no extra licence.

This howto walks through:

1. Installing Sysmon with a production-grade community configuration
2. Deploying it domain-wide via Group Policy
3. Configuring a WEC server and WinRM
4. Creating event subscriptions to pull logs from endpoints
5. Verifying the pipeline end-to-end

Prerequisites

Before you begin, confirm the following:

• WEC server — a Windows Server 2019/2022 that will receive forwarded events. Give it at least 4 GB RAM; 8 GB if collecting from >200 endpoints.
• Domain environment — the guide uses Group Policy. For workgroup environments, see the workgroup note in the Troubleshooting section.
• Sysmon binary — download the latest Sysmon64.exe from the Microsoft Sysinternals page and stage it in a network share (e.g., \\dc01\NETLOGON\Sysmon\).
• Sysmon configuration file — the community-maintained Sysmon Modular config by Olaf Hartong is recommended. Download sysmonconfig.xml and place it alongside Sysmon64.exe.

Step 1 — Install Sysmon Manually (Pilot Endpoint)

Start on a single test machine to validate the config before pushing via GPO.

Open an elevated PowerShell prompt:

# Copy files locally (adjust UNC path)
Copy-Item "\\dc01\NETLOGON\Sysmon\Sysmon64.exe"     C:\Tools\Sysmon\
Copy-Item "\\dc01\NETLOGON\Sysmon\sysmonconfig.xml" C:\Tools\Sysmon\
 
# Install with the config
C:\Tools\Sysmon\Sysmon64.exe -accepteula -i C:\Tools\Sysmon\sysmonconfig.xml

Expected output:

System Monitor v15.x - System activity monitor
Copyright (C) 2014-2026 Mark Russinovich and Thomas Garnier
Sysinternals - www.sysinternals.com

Loading configuration file with schema version 4.90
Sysmon64 installed.
SysmonDrv installed.
Starting SysmonDrv.
SysmonDrv started.
Starting Sysmon64.
Sysmon64 started.

Confirm the service is running:

Get-Service Sysmon64 | Select-Object Name, Status, StartType

Name      Status  StartType
----      ------  ---------
Sysmon64  Running Automatic

Open Event Viewer → Applications and Services Logs → Microsoft → Windows → Sysmon → Operational. You should see events accumulating immediately.

Step 2 — Understand Key Sysmon Event IDs

Focus your initial tuning on IDs 1, 3, 10, and 22 — they catch the majority of common attacker behaviours.

Step 3 — Update the Sysmon Configuration

The sysmon-modular config is a good baseline but may be noisy in your environment. Update config without reinstalling:

# Update running config (no reboot required)
C:\Tools\Sysmon\Sysmon64.exe -c C:\Tools\Sysmon\sysmonconfig.xml

To exclude a noisy process (e.g., your backup agent generating thousands of network events):

<!-- Add inside <RuleGroup name="" groupRelation="or"> for NetworkConnect -->
<NetworkConnect onmatch="exclude">
  <Image condition="is">C:\Program Files\BackupAgent\agent.exe</Image>
</NetworkConnect>

Check the current running config version:

C:\Tools\Sysmon\Sysmon64.exe -c

Step 4 — Deploy Sysmon via Group Policy

4.1 — Create the GPO

On your Domain Controller, open Group Policy Management Console:

1. Right-click the target OU → Create a GPO in this domain, and Link it here
2. Name it Security - Sysmon Deployment
3. Right-click → Edit

4.2 — Script-based Installation

Navigate to: Computer Configuration → Policies → Windows Settings → Scripts → Startup

Add a startup script pointing to a PowerShell script in NETLOGON:

# \\dc01\NETLOGON\Sysmon\Install-Sysmon.ps1
$sysmonPath   = "\\dc01\NETLOGON\Sysmon\Sysmon64.exe"
$configPath   = "\\dc01\NETLOGON\Sysmon\sysmonconfig.xml"
$localDir     = "C:\Tools\Sysmon"
$localBin     = "$localDir\Sysmon64.exe"
$localConfig  = "$localDir\sysmonconfig.xml"
 
# Skip if already installed and up to date
$svc = Get-Service -Name "Sysmon64" -ErrorAction SilentlyContinue
$srcHash  = (Get-FileHash $sysmonPath).Hash
$destHash = if (Test-Path $localBin) { (Get-FileHash $localBin).Hash } else { "" }
 
if ($svc -and $svc.Status -eq "Running" -and $srcHash -eq $destHash) {
    # Update config only
    Copy-Item $configPath $localConfig -Force
    & $localBin -c $localConfig | Out-Null
    exit 0
}
 
# Fresh install
New-Item -ItemType Directory -Path $localDir -Force | Out-Null
Copy-Item $sysmonPath $localBin -Force
Copy-Item $configPath $localConfig -Force
 
$svc = Get-Service -Name "Sysmon64" -ErrorAction SilentlyContinue
if ($svc) {
    & $localBin -u force | Out-Null
}
& $localBin -accepteula -i $localConfig | Out-Null

4.3 — Set PowerShell Execution Policy via GPO

Navigate to: Computer Configuration → Policies → Administrative Templates → Windows Components → Windows PowerShell → Turn on Script Execution

Set to: Allow all scripts (or Allow local scripts and remote signed scripts if preferred).

4.4 — Verify Rollout

After the next Group Policy refresh (or gpupdate /force on a test endpoint):

# Run from DC or a management workstation
Invoke-Command -ComputerName ENDPOINT01, ENDPOINT02 -ScriptBlock {
    Get-Service Sysmon64 | Select-Object PSComputerName, Name, Status
}

Step 5 — Configure the Windows Event Collector (WEC) Server

All steps below run on the WEC server.

5.1 — Enable the Windows Event Collector Service

# Configure and start the WEC service
wecutil qc /q
 
# Verify
Get-Service -Name "Wecsvc" | Select-Object Name, Status, StartType

5.2 — Enable WinRM

WEF uses WinRM (HTTP/5985 by default) for the pull subscription model. Enable it on the WEC server:

Enable-PSRemoting -Force
Set-Service -Name WinRM -StartupType Automatic

For HTTPS (recommended in production), bind a certificate to WinRM on port 5986:

$cert = Get-ChildItem Cert:\LocalMachine\My |
        Where-Object { $_.Subject -match "CN=wec01" } |
        Select-Object -First 1
 
winrm create winrm/config/listener?Address=*+Transport=HTTPS `
    "@{Hostname=`"wec01.corp.local`";CertificateThumbprint=`"$($cert.Thumbprint)`"}"

5.3 — Add the WEC Server to the Event Log Readers Group

Source endpoints authenticate as the WEC server's machine account. On the WEC server:

# Confirm the machine account is in Event Log Readers locally
# (The source endpoints need this on THEIR side — handled in Step 6)
net localgroup "Event Log Readers"

Step 6 — Configure Source Endpoints via GPO

6.1 — Enable WinRM on Endpoints

Create or edit a GPO for the target endpoints. Navigate to:

Computer Configuration → Policies → Windows Settings → Security Settings → System Services

Set Windows Remote Management (WS-Management) to Automatic.

Then under: Computer Configuration → Preferences → Control Panel Settings → Services

Add the WinRM service with Startup: Automatic and Service action: Start service.

6.2 — Allow WinRM Through Windows Firewall

Computer Configuration → Policies → Windows Settings → Security Settings → Windows Defender Firewall with Advanced Security → Inbound Rules

Add a rule:

• Name: Allow WinRM from WEC
• Protocol: TCP
• Local port: 5985 (or 5986 for HTTPS)
• Remote IP: <WEC server IP>
• Action: Allow

6.3 — Add the WEC Server to Event Log Readers

The WEC machine account needs permission to read event logs on source endpoints.

Computer Configuration → Preferences → Local Users and Groups → Local Group

• Group name: Event Log Readers
• Action: Update
• Members to add: CORP\wec01$ (the WEC server machine account)

6.4 — Configure the Event Forwarding Subscription via GPO

Computer Configuration → Administrative Templates → Windows Components → Event Forwarding → Configure target Subscription Manager

Set value to:

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

For HTTPS:

Server=https://wec01.corp.local:5986/wsman/SubscriptionManager/WEC,Refresh=60,IssuerCA=<CA Thumbprint>

Step 7 — Create a WEF Subscription on the WEC Server

A subscription defines what events to collect and from where.

7.1 — Create the Subscription XML

Save the following as C:\WEF\sysmon-subscription.xml on the WEC server:

<Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription">
  <SubscriptionId>Sysmon-All-Endpoints</SubscriptionId>
  <SubscriptionType>SourceInitiated</SubscriptionType>
  <Description>Collect all Sysmon events from domain endpoints</Description>
  <Enabled>true</Enabled>
  <Uri>http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog</Uri>
  <ConfigurationMode>Custom</ConfigurationMode>
  <Delivery Mode="Push">
    <Batching>
      <MaxItems>500</MaxItems>
      <MaxLatencyTime>30000</MaxLatencyTime>
    </Batching>
    <PushSettings>
      <Heartbeat Interval="3600000"/>
    </PushSettings>
  </Delivery>
  <Query>
    <![CDATA[
      <QueryList>
        <Query Id="0">
          <Select Path="Microsoft-Windows-Sysmon/Operational">*</Select>
        </Query>
      </QueryList>
    ]]>
  </Query>
  <ReadExistingEvents>false</ReadExistingEvents>
  <TransportName>HTTP</TransportName>
  <ContentFormat>RenderedText</ContentFormat>
  <Locale Language="en-US"/>
  <LogFile>ForwardedEvents</LogFile>
  <AllowedSourceDomainComputers>
    O:NSG:NSD:(A;;GA;;;DC)
  </AllowedSourceDomainComputers>
</Subscription>

The AllowedSourceDomainComputers SDDL (A;;GA;;;DC) grants access to all domain computers. Restrict to a specific security group for tighter control.

7.2 — Register the Subscription

wecutil cs C:\WEF\sysmon-subscription.xml

7.3 — Verify the Subscription

wecutil gs Sysmon-All-Endpoints

Look for RuntimeStatus: Active and a growing NumberOfSources count as endpoints check in.

Step 8 — Increase the Forwarded Events Log Size

By default the ForwardedEvents log is only 20 MB — far too small for enterprise use.

# Set to 4 GB
wevtutil sl ForwardedEvents /ms:4294967296
 
# Verify
wevtutil gl ForwardedEvents | Select-String "maxSize"

For very large deployments, consider forwarding to a dedicated volume:

wevtutil sl ForwardedEvents /lfn:"D:\EventLogs\ForwardedEvents.evtx"

Verification

Check That Sysmon Events Are Arriving

On the WEC server, open Event Viewer → Windows Logs → Forwarded Events and filter for Event ID 1 (Process Create):

Get-WinEvent -LogName "ForwardedEvents" -FilterXPath "*[System[EventID=1]]" -MaxEvents 10 |
    Select-Object TimeCreated, MachineName, Message

You should see process creation events with full command lines from multiple endpoints.

Count Active Sources

# List all endpoints currently sending events
wecutil gs Sysmon-All-Endpoints | Select-String "ComputerName"

Validate Sysmon Event ID 10 (LSASS Access) Is Firing

Trigger a benign LSASS read (Task Manager opening, which reads LSASS memory):

# On an endpoint — open Task Manager briefly, then:
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" `
    -FilterXPath "*[System[EventID=10]][EventData[Data[@Name='TargetImage'] and Data='C:\Windows\system32\lsass.exe']]" `
    -MaxEvents 5 |
    Format-List TimeCreated, Message

Troubleshooting

Endpoints Not Appearing in Subscription

# On the endpoint — check the forwarding service
Get-Service -Name "Wecsvc" -ErrorAction SilentlyContinue
Get-EventLog -LogName "System" -Source "Microsoft-Windows-Forwarding" -Newest 20

Common causes:

• WinRM not enabled on the endpoint
• WEC machine account not in Event Log Readers on the endpoint
• Firewall blocking TCP 5985 between endpoint and WEC

Sysmon Driver Fails to Load

sc query SysmonDrv

If state is STOPPED, check for driver signing issues or Secure Boot configuration:

# Confirm driver is signed
Get-AuthenticodeSignature "C:\Windows\SysmonDrv.sys"

Microsoft-signed Sysmon drivers should always pass. If you see UnknownError, try reinstalling:

Sysmon64.exe -u force
Sysmon64.exe -accepteula -i sysmonconfig.xml

Workgroup Environments

Without Active Directory, configure WEF using local accounts:

# On the WEC server — add a dedicated service account
net user wefcollector <strongpassword> /add
 
# On each endpoint — allow that account in Event Log Readers
net localgroup "Event Log Readers" wefcollector /add
 
# Set up the subscription with explicit credentials
winrm set winrm/config/client/auth @{Basic="true"}

Then adjust the subscription SDDL to reference the local account's SID instead of the domain computers group.

High Event Volume Causing ForwardedEvents Backpressure

Tune the Sysmon config to exclude noisy processes, or increase the batch size and latency in the subscription XML:

<MaxItems>2000</MaxItems>
<MaxLatencyTime>60000</MaxLatencyTime>

Integrating with a SIEM

Once events land in ForwardedEvents on the WEC server, ingest them into your SIEM:

• Wazuh: install the Wazuh agent on the WEC server, configure ossec.conf to monitor Microsoft-Windows-Sysmon/Operational and ForwardedEvents
• Elastic/OpenSearch: deploy a Winlogbeat agent on the WEC server with the Sysmon ingest pipeline
• Splunk: deploy a Splunk Universal Forwarder on the WEC server, add a WinEventLog://ForwardedEvents input

A single Wazuh or Winlogbeat agent on the WEC server covers your entire endpoint fleet — no agents needed on individual workstations beyond Sysmon itself.

Summary

You now have:

• Sysmon deployed across endpoints via GPO, generating 30+ enriched event types including full process command lines, DNS queries, network connections, and LSASS access attempts
• Windows Event Forwarding centralising all Sysmon telemetry to a WEC server with no extra licences
• A ForwardedEvents log sized for production and ready to feed into any SIEM via a single agent

This stack gives you the raw material for detections like process injection, living-off-the-land abuse, credential theft, and C2 beaconing — all from built-in Windows capabilities. The next step is writing detection rules against these events in your SIEM of choice, or piping them into a tool like Sigma for cross-platform rule translation.