Windows audit policy and Sysmon: a logging baseline

When something goes wrong on a Windows network, the first questions are always the same: which account logged on where, what ran, what changed, and where did it connect? With default settings, Windows answers few of them. Process creation isn't logged, command lines aren't captured, the Security log wraps within hours on a busy server, and nothing leaves the host.

This guide builds a logging baseline in four layers: advanced audit policy, a few extra settings, Sysmon, and forwarding.

Layer 1: advanced audit policy

First, make advanced audit policy authoritative. Under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options, enable Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings.

Then configure subcategories under Security Settings > Advanced Audit Policy Configuration > Audit Policies. A solid starting point, broadly aligned with Microsoft's baseline recommendations:

Check the effective policy on a host:

auditpol /get /category:*
auditpol /get /subcategory:"Process Creation"

For a lab, you can set individual subcategories directly (GPO remains the source of truth in production):

auditpol /set /subcategory:"Process Creation" /success:enable

Layer 2: the settings that make events useful

Command lines can contain secrets (passwords passed as parameters). That is a reason to restrict who reads the logs and to fix those scripts, not to leave command-line logging off.

Also watch for evidence destruction: 1102 (Security log cleared) and 104 (another log cleared, in System) should always alert.

Layer 3: Sysmon

Sysmon (System Monitor, from Microsoft Sysinternals) is a free driver and service that records detailed process, network, file and registry activity to Applications and Services Logs > Microsoft > Windows > Sysmon > Operational. Since 2026 it is also a built-in optional feature of Windows 11 and Windows Server 2025, off by default and configured with the same XML; the Sysmon deployment guide covers choosing between the two. Its most useful events:

Sysmon is only as good as its configuration: an empty config logs very little, a naive one floods your SIEM. Start from a maintained community configuration, such as the SwiftOnSecurity sysmon-config or Olaf Hartong's sysmon-modular, then tune for your environment.

# Install with a configuration
Sysmon64.exe -accepteula -i sysmonconfig.xml
# Update the configuration later
Sysmon64.exe -c sysmonconfig.xml
# Show the active configuration
Sysmon64.exe -c

Deploy Sysmon through your software distribution tool, pin the version, and monitor that the Sysmon64 service is running: stopping it is an obvious attacker move (Sysmon logs event 4 for service state changes and 16 for configuration changes).

Layer 4: get the events off the host

Local logs can be cleared by anyone with admin rights. Forward them.

Windows Event Forwarding (WEF) is built in and needs no agent:

1. On a collector server: wecutil qc to configure the Windows Event Collector service.
2. Create source-initiated subscriptions (XPath queries selecting the event IDs above).
3. By GPO on sources: Administrative Templates > Windows Components > Event Forwarding > Configure target Subscription Manager = Server=http://wec01.corp.example:5985/wsman/SubscriptionManager/WEC,Refresh=60.
4. Grant the Network Service account read access to the Security log on sources, by adding it to the Event Log Readers group through Restricted Groups or Group Policy Preferences.

From the collector, ship ForwardedEvents to your SIEM. If you already run a SIEM or EDR agent, point it at the same event IDs instead; the important thing is that events leave the host within minutes.

What good looks like

A quick way to test the baseline is to ask the questions from an imaginary incident and see whether your logs answer them:

• Who logged on to server X last Tuesday, from where? 4624 with logon type and source IP, forwarded.
• What did that session run? 4688 with command lines, Sysmon 1, PowerShell 4104.
• Did anything touch LSASS? Sysmon 10 filtered on lsass.exe.
• Was persistence added? 4697 / 7045 (service), 4698 (scheduled task), Sysmon 13 on Run keys.
• Where did it connect? Sysmon 3 and 22.
• Did someone try to hide it? 1102, 104, Sysmon 4/16, Defender 5001/5007.

Checklist

• Advanced audit policy forced to override; subcategories set as above
• Command-line capture in 4688 enabled
• Security log sized for days, not hours; clear-log events alerted
• Sysmon deployed with a maintained, tuned configuration
• Events forwarded (WEF or agent) and retained centrally
• Incident questions answered end-to-end in a tabletop test

Logging doesn't prevent anything, but every other control on this map is easier to trust when you can see it working, and see the moment it stops.