Kerberos · Account Events
Application Events
Directory Events
Logon Events
SIEM · Syslog Server · WEF Collector
Logs that only exist on the compromised system are useless after a breach. Get them off the host.
Configuring Audit Policies is one of those steps that gets skipped during deployment because it does not make the system work better in any visible way. It only matters when something goes wrong. And when something goes wrong, the difference between “we can reconstruct what happened” and “we have no idea what happened” is entirely determined by what was logged before the event.
All three Windows Server versions – 2016, 2019, 2022 – support Advanced Audit Policy Configuration, which should be used instead of the basic audit policies under Local Policies. Advanced policies provide significantly more granularity. The basic audit policies are coarse settings that either audit an entire category or none of it. Advanced Audit Policy lets you specify which subcategories within each category are audited, and whether success events, failure events, or both are logged.
Advanced Audit Policy vs Basic Audit Policy
The basic audit policies are in: Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy.
The Advanced Audit Policy Configuration is in: Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies.
Use Advanced Audit Policy. The basic policies are a legacy interface that predates granular auditing. On a domain, configure Advanced Audit Policy through Group Policy. On a standalone server, configure it through Local Group Policy.
Do not mix basic audit policies with Advanced Audit Policy on the same system. When Advanced Audit Policy settings exist, they take precedence over basic audit policy settings. Having both configured creates confusion about which settings are actually in effect. If you are transitioning from basic to advanced, clear the basic audit policy settings when enabling the advanced ones.
Domain Controller Audit Policy
Create a new GPO for domain controller audit policy and give it precedence over the Default Domain Controller Policy. Link it to the Domain Controllers OU. The Default Domain Controllers Policy has basic audit settings that are insufficient for security monitoring. Your new GPO with Advanced Audit Policy settings will override them.
## The GPO should configure these audit subcategories at minimum:
## Account Logon:
Audit Credential Validation: Success and Failure
Audit Kerberos Authentication: Success and Failure
Audit Kerberos Service Ticket: Success and Failure
Audit Other Account Logon Events: Success and Failure
## Account Management:
Audit Computer Account Management: Success and Failure
Audit Other Account Mgmt Events: Success and Failure
Audit Security Group Management: Success and Failure
Audit User Account Management: Success and Failure
## Logon/Logoff:
Audit Account Lockout: Success and Failure
Audit Logoff: Success
Audit Logon: Success and Failure
Audit Other Logon/Logoff Events: Success and Failure
Audit Special Logon: Success
## Object Access:
Audit SAM: Failure
Audit File System: Failure (Success is high-volume)
## Policy Change:
Audit Audit Policy Change: Success and Failure
Audit Authentication Policy Change: Success
Audit MPSSVC Rule-Level Policy Change: Success and Failure
## Privilege Use:
Audit Sensitive Privilege Use: Success and Failure
## System:
Audit Security State Change: Success and Failure
Audit Security System Extension: Success and Failure
Audit System Integrity: Success and Failure
These settings generate a significant volume of events on a domain controller. Plan the event log sizing accordingly. The Security event log on a domain controller should be configured to a minimum of 512 MB to avoid log wrapping that overwrites old events before they can be collected.
Event Log Sizing and Retention
The default event log sizes on Windows Server are too small for environments with meaningful audit logging enabled. Increase them:
## Configure via Group Policy:
## Computer Configuration > Administrative Templates > Windows Components
## > Event Log Service > [Security|Application|System]
## Security log: 1 GB minimum on domain controllers, 256 MB on member servers
## Application log: 256 MB
## System log: 256 MB
## Via PowerShell (run as administrator):
$logs = @("Security", "Application", "System")
foreach ($log in $logs) {
$wevtutil = "wevtutil"
if ($log -eq "Security") {
& $wevtutil sl $log /ms:1073741824 # 1 GB for Security log
} else {
& $wevtutil sl $log /ms:268435456 # 256 MB for others
}
}
Log retention policy should be set to “Do not overwrite events (Clear logs manually)” or “Archive the log when full, do not overwrite events”, not “Overwrite events as needed.” An overwrite policy means old events are silently deleted when the log fills. For security logs, this can mean critical evidence from an incident is overwritten before anyone knows to look for it.
Combine this with a centralized log collection solution so that security events are forwarded off the server and stored in a location the attacker cannot easily access or modify.
Windows Event Forwarding
Windows Event Forwarding (WEF) is a built-in Windows mechanism for collecting events from multiple sources onto a central collector. It requires no third-party software and works with the existing Windows infrastructure. Events from domain controllers, member servers, and workstations can all be forwarded to a single Windows Event Collector (WEC) server.
## On the collector server:
## Enable Windows Remote Management:
winrm quickconfig
## Enable the Windows Event Collector service:
wecutil qc /quiet
## On the source servers:
## Configure via Group Policy:
## Computer Configuration > Administrative Templates > Windows Components
## > Event Forwarding > Configure the server address for WS-Management
## The subscription defines which events to forward and where.
## Create subscriptions on the collector using Event Viewer or wecutil:
The subscription can be configured to forward all security events, or a filtered subset. For environments without a SIEM, forwarding the Security, Application, and System logs from all servers to a WEC collector, and retaining those logs for 90 days, is a reasonable starting configuration that significantly improves incident response capability at no software cost.
For environments that have a SIEM or a syslog-based log management solution, a Windows agent (Sysmon, NXLog, or similar) provides more flexible forwarding options and better filtering. The choice of approach depends on the existing infrastructure, but the requirement – getting logs off the source host and into a centralized, tamper-resistant storage location – is the same regardless of the method.
Sysmon for Enhanced Windows Event Collection
Sysmon (System Monitor) is a free Microsoft Sysinternals tool that logs detailed process creation, network connection, and file system events to the Windows Event Log. The events it generates are significantly more useful for security monitoring than the native Windows audit policy events alone.
## Download Sysmon:
## https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon
## Install with a configuration file:
sysmon64.exe -accepteula -i sysmon-config.xml
## Community configuration files (good starting points):
## SwiftOnSecurity/sysmon-config (GitHub)
## olafhartong/sysmon-modular (GitHub)
Sysmon event ID 1 (Process Create) logs every process that starts on the system, including the full command line. Event ID 3 (Network Connect) logs every outbound network connection with source and destination. Event ID 7 (Image Load) logs DLL loading. These events are the foundation for detecting lateral movement and post-exploitation activity.
Deploy Sysmon via Group Policy Software Installation or a configuration management tool. The configuration file controls what is logged – start with an established community configuration and tune it for your environment based on the noise level and false positive rate.
Key Event IDs to Monitor
These event IDs should be monitored and ideally alerted on in any environment with centralized log collection:
| Event ID | Log | Description | Why It Matters |
|---|---|---|---|
| 4625 | Security | Failed logon | Brute force indicator – high volume from single source is an attack |
| 4648 | Security | Logon with explicit credentials | Lateral movement indicator – pass-the-hash, credential reuse |
| 4672 | Security | Special privileges assigned | Elevated access – admin logon tracking |
| 4720 | Security | User account created | Unauthorized account creation – persistence mechanism |
| 4728, 4732 | Security | Member added to privileged group | Privilege escalation – adding to Admins/Domain Admins |
| 4740 | Security | Account locked out | Brute force or credential stuffing against a specific account |
| 4768, 4769 | Security | Kerberos TGT/TGS requested | Kerberoasting and Pass-the-Ticket detection |
| 4776 | Security | Credential validation | Failed NTLM auth – monitor for high volume |
| 7045 | System | New service installed | Persistence mechanism – attacker-installed services |
| 4104 | PowerShell/Operational | Script block logged | Post-exploitation PowerShell activity |
A high volume of Event 4625 (Failed logon) from the same source IP in a short time window is a brute force attack in progress. A single instance of Event 4720 (User account created) at 3 AM on a production server may warrant immediate investigation. The events above are the ones where the context and volume tell you whether there is a problem.
Log Retention Guidance
Retain security logs for a minimum of 90 days in readily searchable storage, and for 1 year in archive storage. This timeframe is driven by two factors: the average attacker dwell time before detection (historically measured in months), and the investigation timeline after an incident is discovered.
If an attacker establishes persistence in January and the intrusion is discovered in March, you need logs from January to reconstruct how they got in. If those logs were overwritten in February, you can determine what they did but not how they got in – which means you cannot fully remediate because you do not know every access path they established.
The 1-year archive accommodates regulatory requirements in many industries and covers the extended investigation timeline for sophisticated incidents. Store archives in a location that is not directly accessible from the servers being monitored – an attacker who has compromised a server should not be able to delete their own audit trail.