Windows Event Forwarding (WEF) Systems

For organizations managing dozens or thousands of Windows systems, security events are generated constantly across every endpoint—yet without centralized visibility, these critical logs remain siloed on individual machines. Windows Event Forwarding (WEF) provides a native, agent-free solution for collecting and centralizing event logs from distributed Windows hosts, enabling security teams to detect intrusions, respond to incidents, and maintain compliance without expensive third-party agents.

What is Windows Event Forwarding?

Windows Event Forwarding is a built-in log forwarding mechanism integrated into Windows Vista/Server 2008 and later versions. WEF allows administrators to configure Windows systems to automatically forward selected event logs from source computers to one or more centralized Windows Event Collector (WEC) servers. The architecture leverages the WS-Management protocol (WinRM) and uses Kerberos authentication by default, providing encrypted transport of security-critical event data without requiring additional software agents.

Unlike traditional SIEM solutions that require per-endpoint licensing and agent installation, WEF uses components already present in modern Windows operating systems. Organizations configure event forwarding through Group Policy, specifying which events to collect via XPath queries. Forwarded events are stored in the ForwardedEvents log channel on the WEC server, where they can be queried, exported, or integrated with downstream analysis platforms. The official Microsoft documentation on Windows Event Forwarding provides comprehensive guidance on implementing WEF for intrusion detection.

The Problem WEF Solves

In distributed Windows environments, every workstation and server generates security events locally—logon attempts, process executions, registry modifications, service installations, and administrative actions. These events are recorded in local Windows Event Logs, but remain trapped on individual machines unless explicitly collected. Manual log review across hundreds or thousands of endpoints is impractical, and incident response teams lack real-time visibility when investigating suspicious activity.

Traditional security information and event management (SIEM) solutions address this problem by deploying proprietary agents to every endpoint. However, commercial agents introduce several challenges: per-endpoint licensing costs that scale linearly with infrastructure size, ongoing agent maintenance and updates, compatibility issues across Windows versions, and performance overhead on endpoints. For budget-constrained organizations or those with large Windows footprints, these costs become prohibitive.

Compliance frameworks including SOC 2, PCI DSS, and HIPAA require centralized log retention and audit trails demonstrating security monitoring capabilities. Without automated log collection, organizations struggle to demonstrate continuous monitoring or reconstruct event timelines during forensic investigations. WEF addresses these challenges by providing enterprise-grade centralized logging using built-in Windows capabilities, eliminating per-endpoint costs while maintaining compatibility with existing Active Directory infrastructure.

WEF Architecture and Components

Windows Event Forwarding consists of four primary components working together to transport events from sources to collectors. The Windows Event Collector (WEC) service runs on designated Windows Server systems, receiving forwarded events via WinRM and storing them in event log channels. WEC servers act as aggregation points, typically deployed regionally or centrally depending on network topology and event volume.

Event sources are the Windows endpoints—workstations, servers, or domain controllers—that generate events and forward selected logs to WEC servers. Sources require the Windows Remote Management (WinRM) service to be enabled and configured with the WEC server address. No additional software installation is required on source systems beyond standard Windows components.

Subscriptions define the collection parameters: which events to collect, from which sources, and how to deliver them. Subscriptions are XML-based configuration files containing XPath queries that filter events, delivery mode settings controlling batching and latency, and security descriptors controlling which computers can forward to a given subscription. The Windows Event Collector API documentation details subscription structure and management options.

The ForwardedEvents log channel is the default destination on WEC servers where collected events are stored. Administrators can create custom event channels to separate different subscription types or event categories, allowing targeted retention policies and access controls. Communication flows as follows: events generate on source systems, local Windows Event Log service applies XPath filters defined in subscriptions, WinRM transports matching events to WEC servers using HTTP or HTTPS, and WEC service writes events to designated log channels.

Subscription Types: Source-Initiated vs Collector-Initiated

WEF supports two subscription models with distinct architectural characteristics. Source-Initiated (Push) subscriptions allow Windows endpoints to discover WEC servers via Group Policy and push events to collectors automatically. This model scales to thousands of endpoints because new systems auto-enroll when Group Policy applies, requiring no per-machine configuration on the WEC server. Source-initiated subscriptions are ideal for enterprise-wide baseline monitoring where all Windows systems should forward a standard set of security events.

Collector-Initiated (Pull) subscriptions require the WEC server to maintain explicit lists of source computers and actively pull events from each. This model limits scalability since every source must be manually added to subscription configurations, but provides precise control for targeted monitoring scenarios. Organizations use collector-initiated subscriptions when monitoring specific critical systems—domain controllers, database servers, or financial application hosts—that require verbose event collection separate from baseline monitoring.

Microsoft recommends a dual-subscription strategy: deploying source-initiated subscriptions for baseline security event collection from all Windows hosts, plus collector-initiated subscriptions for suspect systems under active investigation requiring comprehensive event capture. This approach balances broad visibility with the ability to increase logging granularity when needed without impacting all endpoints.

Setting Up Your WEC Server

WEC server deployment begins with enabling the Windows Event Collector service on a Windows Server system. The service is installed by default but disabled. Administrators execute wecutil qc to perform quick configuration, which sets the WecSvc service to automatic startup, starts the service, and enables the ForwardedEvents log channel:

# Quick config to enable WEC service
wecutil qc /q

# Or manual steps
Set-Service -Name WecSvc -StartupType Automatic
Start-Service WecSvc

# Enable ForwardedEvents log channel
wevtutil sl ForwardedEvents /e:true

The default ForwardedEvents log has a maximum size of 20 MB, insufficient for production environments collecting events from multiple hosts. Administrators should increase log size based on expected event volume. For environments generating 1,000 events per second, a 10 GB log size provides approximately 3 days of retention before log wrapping:

# Set ForwardedEvents log to 10 GB
wevtutil sl ForwardedEvents /ms:10737418240

Create custom event channels for different subscription types to separate baseline monitoring events from suspect system events or different organizational units. Custom channels allow independent retention policies and access controls:

# Create custom channel for suspect subscriptions
wevtutil im manifest.xml

WEC servers require appropriate security group configuration. Add the WEC server computer account to the Event Log Readers group on source computers (typically via Group Policy) to grant log read permissions. Configure Windows Firewall to allow WinRM traffic on TCP 5985 (HTTP) or 5986 (HTTPS). For domain-joined environments, Group Policy-based firewall rules simplify management across all WEC servers.

Configuring Event Sources

Event sources must be configured to discover WEC servers and forward events. For source-initiated subscriptions, deploy the SubscriptionManager registry key via Group Policy, specifying the WEC server address and refresh interval:

# Set WEC server address (typically deployed via GPO)
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\EventLog\EventForwarding\SubscriptionManager" /v 1 /t REG_SZ /d "Server=http://WEC-SERVER.domain.com:5985/wsman/SubscriptionManager/WEC" /f

# Restart Windows Remote Management service
Restart-Service WinRM

The SubscriptionManager value uses the format Server=http://FQDN:PORT/wsman/SubscriptionManager/WEC, where multiple WEC servers can be specified for redundancy. Sources will attempt to forward to each server in order until successful. The WinRM service must be enabled and started on all source systems:

# Enable and start WinRM
Enable-PSRemoting -Force
Set-Service -Name WinRM -StartupType Automatic

For non-domain environments or when Kerberos authentication is unavailable, configure certificate-based authentication or HTTPS transport. Production environments should enable advanced security audit policies to generate the events WEF will collect. Critical policies include process creation auditing with command line logging:

# Enable process creation auditing with command line logging
auditpol /set /subcategory:"Process Creation" /success:enable
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

# Enable common security auditing
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Account Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Security System Extension" /success:enable
auditpol /set /subcategory:"System Integrity" /success:enable /failure:enable

Adjust local event log sizes on source systems to ensure events aren’t lost during network outages or when WEC servers are unavailable. A 100 MB Security log provides sufficient buffering for most workstations.

Creating WEF Subscriptions

Subscriptions define which events to collect through XML configuration files managed with the wecutil command-line tool. A basic source-initiated subscription collects critical security events from all Windows hosts that contact the WEC server:

<Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription">
  <SubscriptionId>Baseline-Security-Events</SubscriptionId>
  <SubscriptionType>SourceInitiated</SubscriptionType>
  <Description>Collect critical security events from all Windows hosts</Description>
  <Enabled>true</Enabled>
  <Uri>http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog</Uri>
  <ConfigurationMode>Normal</ConfigurationMode>
  <Delivery Mode="Push">
    <Batching>
      <MaxItems>5</MaxItems>
      <MaxLatencyTime>30000</MaxLatencyTime>
    </Batching>
    <PushSettings>
      <Heartbeat Interval="3600000"/>
    </PushSettings>
  </Delivery>
  <Query><![CDATA[
    <QueryList>
      <Query Id="0">
        <Select Path="Security">*[System[(EventID=4624 or EventID=4625 or EventID=4688 or EventID=4689 or EventID=4697 or EventID=1102)]]</Select>
      </Query>
    </QueryList>
  ]]></Query>
  <ReadExistingEvents>false</ReadExistingEvents>
  <TransportName>HTTP</TransportName>
  <ContentFormat>RenderedText</ContentFormat>
  <Locale Language="en-US"/>
  <LogFile>ForwardedEvents</LogFile>
  <AllowedSourceNonDomainComputers/>
  <AllowedSourceDomainComputers>O:NSG:NSD:(A;;GA;;;DC)(A;;GA;;;NS)</AllowedSourceDomainComputers>
</Subscription>

The Query element contains XPath expressions filtering events from source systems. The example above collects successful logons (4624), failed logons (4625), process creation (4688), process termination (4689), service installation (4697), and security log clearing (1102). XPath queries can combine multiple event IDs, filter by severity level, or match specific event data fields.

Delivery modes control batching behavior and latency. Normal mode provides 15-minute maximum latency with batches of 5 events, balancing network efficiency and timeliness. MinLatency mode reduces maximum latency to 30 seconds for near-real-time collection at the cost of increased network traffic. MinBandwidth mode batches up to 50 events with 6-hour maximum latency, minimizing network impact for low-priority events.

Create subscriptions using wecutil:

# List all subscriptions
wecutil enum-subscription

# Create subscription from XML file
wecutil create-subscription subscription.xml

# Get subscription details
wecutil get-subscription "Baseline-Security-Events"

# Check subscription runtime status
wecutil get-subscriptionruntimestatus "Baseline-Security-Events"

# Delete a subscription
wecutil delete-subscription "Baseline-Security-Events"

The get-subscriptionruntimestatus command displays which source computers are actively forwarding events, last heartbeat times, and any connection errors. This information is critical for troubleshooting connectivity issues.

Production-ready subscription examples are available in Palantir’s Windows Event Forwarding GitHub repository, providing battle-tested XPath queries and subscription configurations for baseline monitoring, domain controller events, PowerShell script block logging, and custom event channels including AutorunsToWinEventLog for persistence detection.

Essential Events to Collect

Effective security monitoring with WEF requires collecting events that indicate suspicious activity while avoiding excessive noise. Account logon events are foundational: Event ID 4624 captures successful logons with logon type (interactive, network, service), source IP address, and authentication package. Event ID 4625 records failed logon attempts, essential for detecting brute-force attacks or credential spraying. Event ID 4634 logs logoffs, helping establish user session timelines.

Process creation and termination events provide visibility into command execution. Event ID 4688 (process creation) is particularly valuable when command line logging is enabled, capturing the full command line including arguments for every process execution. This enables detection of suspicious PowerShell commands, encoded commands, or living-off-the-land binary (LOLBin) abuse. Event ID 4689 records process termination, though most security monitoring focuses on process creation.

Service installation events indicate potential persistence mechanisms. Event ID 4697 (Security log) and Event ID 7045 (System log) both capture new service installations, recording service name, executable path, and service type. Attackers frequently install services for persistence, making these events high-value indicators.

Security log manipulation events warn of anti-forensics activity. Event ID 1102 records security log clearing—a strong indicator that an attacker is attempting to cover their tracks. Event ID 1100 indicates the Windows Event Log service was shut down, another anti-forensics technique. Both events warrant immediate investigation.

Scheduled task events reveal another common persistence mechanism. Event IDs 4698, 4699, 4700, 4701, and 4702 track scheduled task creation, deletion, enablement, disablement, and updates. Attackers use scheduled tasks to execute payloads at system startup or on specific triggers.

PowerShell and script execution events from the Microsoft-Windows-PowerShell/Operational channel provide visibility into script-based attacks. Event ID 4103 captures module logging when enabled, while Event ID 4104 records PowerShell Script Block Logging, capturing the actual PowerShell code executed even if obfuscation was attempted. Configure WEF subscriptions to collect Event ID 4104 from all endpoints for centralized threat detection. These events are essential for detecting fileless malware and post-exploitation frameworks.

Organizations should start with a baseline subscription collecting high-value, low-volume events, then expand coverage based on operational needs and security maturity. Microsoft’s WEF guidance categorizes events into baseline, suspect, and comprehensive tiers, allowing staged deployment.

Monitoring and Troubleshooting WEF

Operational monitoring of WEF requires checking subscription health, source connectivity, and event delivery rates. The wecutil get-subscriptionruntimestatus command provides real-time status of source computers, displaying last heartbeat, total events forwarded, and any connection errors:

# View recent forwarded events
Get-WinEvent -LogName ForwardedEvents -MaxEvents 100

# Filter for specific event IDs (e.g., failed logons)
Get-WinEvent -FilterHashtable @{LogName='ForwardedEvents'; Id=4625} -MaxEvents 50

# Export forwarded events to CSV
Get-WinEvent -LogName ForwardedEvents -MaxEvents 1000 | 
  Select-Object TimeCreated, Id, MachineName, Message | 
  Export-Csv -Path "ForwardedEvents.csv" -NoTypeInformation

On source computers, the Eventlog-ForwardingPlugin/Operational channel logs subscription activity, including subscription refresh, event forwarding attempts, and connection failures. Event ID 100 indicates successful subscription activation, while error events indicate authentication failures, network connectivity issues, or WEC server unavailability.

On WEC servers, the Microsoft-Windows-EventCollector/Operational channel logs subscription management activities and source connection events. Event ID 111 logs when a source computer successfully subscribes, while Event ID 105 indicates subscription errors.

Common issues include Kerberos authentication failures when SPNs are not correctly registered, network connectivity problems when firewalls block WinRM ports, and event log full errors on sources when logs wrap before events can be forwarded. Verify WinRM connectivity from sources to WEC servers using Test-WSMan:

# Test WinRM connectivity to WEC server
Test-WSMan -ComputerName WEC-SERVER.domain.com

WEF uses bookmarks to track which events have been forwarded from each source, preventing duplicate event delivery. If sources repeatedly forward the same events, bookmark corruption may have occurred, requiring subscription recreation or manual bookmark deletion.

Scaling WEF for Enterprise Environments

Microsoft’s scaling guidance provides event volume thresholds for different backend storage solutions. Environments generating 0-5,000 events per second can use SQL Server or commercial SIEM platforms for storage and analysis. Environments generating 5,000-50,000 events per second require enterprise SIEM platforms designed for high-throughput ingestion. Environments exceeding 50,000 events per second need big data platforms like Hadoop, Azure HDInsight, or cloud-based security analytics solutions.

Organizations with distributed infrastructure deploy multiple WEC servers to balance load and maintain regional data sovereignty. DNS round-robin provides simple load distribution, where the WEC server address resolves to multiple IP addresses and sources randomly select a WEC server from the list. For higher availability, deploy WEC servers with identical subscription configurations and configure sources with multiple SubscriptionManager entries listing all WEC servers.

Tiered architectures forward events from regional WEC servers to central collectors for long-term retention or SIEM ingestion. Regional WEC servers collect from local sources, reducing WAN traffic, then forward aggregated events to central systems. This model scales to global enterprises while maintaining acceptable network utilization.

Integration with commercial SIEM platforms including Splunk, IBM QRadar, and Microsoft Sentinel typically occurs via Windows Event Log forwarding, where SIEM agents read from ForwardedEvents logs, or through WEF subscriptions configured to write to custom event channels that SIEM collectors monitor. This approach leverages WEF’s agent-free collection while providing SIEM platforms with centralized event feeds.

Security Best Practices

WEF deployments should enforce Kerberos-only authentication, disabling NTLM fallback to prevent downgrade attacks. In Active Directory environments, verify that WinRM SPNs are properly registered and that API security best practices are followed for any external integrations.

Use HTTPS transport (port 5986) for non-domain environments or when WinRM traffic traverses untrusted networks. Certificate-based authentication provides mutual authentication without Kerberos dependencies, though certificate management introduces operational complexity.

Restrict which computers can forward to subscriptions using Security Descriptor Definition Language (SDDL) in the AllowedSourceDomainComputers element. The default descriptor allows all domain computers, but production subscriptions should limit access to specific security groups or organizational units.

Protect WEC servers as Tier 0 assets when collecting domain controller events, since compromised WEC servers provide attackers visibility into authentication events across the entire Active Directory forest. Implement network segmentation, restrict administrative access, and encrypt forwarded event logs at rest using BitLocker or similar encryption technologies.

Regularly audit subscription configurations and event collection scope to ensure that sensitive data isn’t unnecessarily collected or retained beyond compliance requirements. Review XPath queries periodically to remove redundant filters and add new event IDs as threat landscape evolves.

Real-World Use Cases

Intrusion detection scenarios leverage WEF to identify lateral movement and privilege escalation indicators. Security teams create anomaly detection techniques that flag suspicious patterns such as interactive logons from service accounts, unusual process executions by privileged users, or new service installations on endpoints that historically don’t run custom services. WEF provides the centralized event data necessary for correlation across multiple hosts.

Forensic investigation benefits from WEF’s ability to collect historical events from suspected compromised systems without alerting attackers. When incident responders identify a potentially compromised host, they create a collector-initiated subscription targeting that system with comprehensive event collection, capturing process execution history, network logons, registry changes, and file access events necessary for root cause analysis and timeline reconstruction.

Compliance auditing requirements under SOC 2, PCI DSS, HIPAA, and similar frameworks mandate centralized log retention and evidence of security monitoring. WEF provides auditable evidence that security-critical events are collected, retained for required periods, and available for review during audits. Compliance teams export events from ForwardedEvents logs to demonstrate monitoring coverage and investigation capabilities.

Insider threat monitoring programs use WEF to track sensitive file access patterns, credential usage across systems, and administrative actions by privileged users. Subscriptions targeting file servers collect Event ID 4663 (file access auditing) for sensitive directories, while subscriptions targeting all systems collect logon events to detect credential sharing or abnormal access patterns indicating account compromise or policy violations.

Change management processes track system modifications through WEF collection of registry changes (Event ID 4657), scheduled task modifications, service installations, and Group Policy changes. Operations teams establish baselines of expected changes, then investigate unexpected modifications that could indicate misconfigurations, unauthorized changes, or malicious activity.

Common Misconceptions

“WEF is a complete SIEM replacement” — WEF provides centralized log collection but lacks correlation engines, threat intelligence integration, and advanced analytics capabilities that commercial SIEM platforms offer. WEF works best as a log collection layer feeding downstream analysis platforms, or as a cost-effective monitoring solution for Windows-only environments with basic requirements.

“WEF requires Windows Server licenses for every source” — Only WEC servers require Windows Server licenses. All source systems (workstations and servers) use WEF forwarding capabilities included in standard Windows licensing at no additional cost.

“WEF significantly impacts endpoint performance” — WEF uses lightweight WinRM transport and filters events locally before forwarding, minimizing performance impact. Properly configured WEF subscriptions collecting baseline security events typically consume less than 1% CPU and negligible network bandwidth. Overly aggressive event collection or poorly optimized XPath queries can impact performance, which is why Microsoft recommends tiered subscription strategies rather than verbose logging on all systems.

Related Articles

Organizations implementing WEF should understand the underlying Active Directory infrastructure since WEF relies on domain membership and Kerberos authentication in most deployments. For comprehensive security monitoring, apply broader security best practices including network segmentation, privileged access management, and endpoint protection. Advanced WEF deployments integrate with anomaly detection techniques to automatically identify suspicious patterns in forwarded events, moving beyond manual log review to proactive threat hunting.