Windows Event Forwarding (WEF): Free Central Log Collection Without a SIEM

Most teams that "don't have a SIEM" assume they also have no way to centralize Windows logs. That's wrong. Windows has shipped a perfectly capable, agentless log-collection pipeline for over a decade: Windows Event Forwarding (WEF). It rides on WinRM, needs no third-party agent, no per-endpoint license, and no cloud dependency. For a small shop or a lab, WEF is the difference between "the logs were on the box the attacker wiped" and "we have a durable copy on a hardened collector."

Why forward events at all?

Local event logs are the first thing an attacker tampers with. Clearing the Security log (Event ID 1102), stopping the EventLog service, or simply overwriting a small log buffer erases the evidence you'd need for incident response. Forwarding solves three problems at once:

• Durability — a copy leaves the endpoint within seconds, so wiping the local log no longer wipes the evidence.
• Central visibility — you query one collector instead of RDP-ing into 40 machines during an incident.
• Retention — the collector can hold months of history that a 20 MB local log never could.

How WEF actually works

WEF has two roles. The source computers are your endpoints. The collector (running the Windows Event Collector service, Wecsvc) subscribes to events and pulls or receives them. There are two modes:

• Collector-initiated (pull): the collector reaches out to each source. Good for a fixed, well-known set of servers.
• Source-initiated (push): sources are told, via GPO, which collector to report to. This scales far better and is the right choice for workstations that come and go.

Transport is WS-Management (WinRM) over HTTP 5985 with Kerberos encryption, or HTTPS 5986. Despite the "HTTP" port, source-initiated traffic is Kerberos-encrypted on the wire — you are not shipping logs in cleartext.

Standing up a collector in three steps

On the collector, enable the service and create the subscription store:

# On the collector
wecutil qc /q

# On every source (usually pushed via GPO, shown here manually)
winrm quickconfig -q

Then point sources at the collector via Group Policy: Computer Configuration → Administrative Templates → Windows Components → Event Forwarding → Configure target Subscription Manager, set to:

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

Add the collector's machine account (or the Network Service reader) to the source's Event Log Readers group so it can read the Security channel. Finally, create a source-initiated subscription on the collector with wecutil cs subscription.xml.

What to actually collect

Forwarding everything is a trap — you'll drown the collector and yourself. Start with the events that matter for detection. Palantir's WEF configuration and the NSA/CISA guidance both converge on a similar core set:

1. Account logon — 4624/4625 (logon success/failure), 4648 (explicit credential use), 4672 (special privileges).
2. Process creation — 4688 with command line auditing enabled, or better, Sysmon Event ID 1.
3. Log tampering — 1102 (Security log cleared), 104 (System log cleared), 7040 (service state changes).
4. PowerShell — 4103/4104 script block logging from the Microsoft-Windows-PowerShell/Operational channel.
5. Persistence — 4698 (scheduled task created), 7045 (new service installed).

Rule of thumb: collect what a responder would grep for at 2 a.m. If you'd never query it during an incident, don't forward it.

The part everyone gets wrong: hardening the collector

A collector that aggregates Security logs from your whole estate is a high-value target. Treat it like a tier-0 asset. Restrict who can log on interactively, don't run other roles on it, forward its logs onward, and monitor the ForwardedEvents channel size so a silent subscription failure doesn't go unnoticed for weeks. A dead WEF subscription is invisible until you need the logs and they aren't there.

Where WinSentinel fits

WEF is plumbing — it moves logs, but it won't tell you if the plumbing broke or was never configured right. On every machine it runs, WinSentinel's Free tier audits the local event-logging posture as part of its 33 modules: it checks that command-line process auditing is on, that PowerShell script block logging is enabled, that the Security log isn't sized to overwrite in an hour, and that log-clear events are actually being generated. That's the source-side readiness that makes forwarding worth anything.

For organizations running a collector across many endpoints, WinSentinel Pro rolls those per-machine logging checks up to the central node, so you can see at a glance which sources have drifted out of a forwarding-ready state — a workstation where someone disabled script block logging, or a server whose Security log auditing was silently reset by a GPO change. You get a fleet-wide answer to "are all my sources still feeding the collector correctly?" instead of discovering the gap during an investigation.

Bottom line

You do not need to buy a SIEM to stop losing evidence to log tampering. WEF is free, built in, and battle-tested. Stand up a hardened collector, forward a focused set of high-signal events, and use WinSentinel to verify every source is actually configured to produce and retain those events. Centralized logging is table stakes for detection — and on Windows, the table stakes are already in the box.