Windows Event Log Security Hardening: How to Prevent Log Tampering and Detect Log Clearing
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Local Windows Event Logs are inherently vulnerable to tampering by any process with local administrator access -- and local administrator access is what most post-exploitation activity starts from. The security architecture of event log protection therefore requires two layers: making local log clearing harder and more detectable, and forwarding logs to a location the attacker cannot reach. Neither layer alone is sufficient: forwarding without hardening leaves a window between the action and the forward; hardening without forwarding means a sophisticated attacker can still destroy logs given enough time and persistence.
Set Log Sizes Large Enough to Retain History
The default Windows Security event log maximum size is 20 MB on most systems -- on an active domain controller, this fills in hours and begins overwriting old events. Attackers can also abuse this by generating high volumes of audit events to force overwrite of earlier evidence. Set the Security log maximum size to at least 1 GB on DCs and high-activity member servers. Via GPO: Computer Configuration > Windows Settings > Security Settings > Event Log > Maximum security log size. Set to 1048576 KB (1 GB) for DCs, 524288 KB (512 MB) for member servers. Set the retention method to 'Overwrite events as needed' (the default) -- archiving before overwriting creates unmanageable archive files on active systems. The primary retention mechanism should be log forwarding to your SIEM, not local log size. Large local log size provides a local forensic buffer for investigations on the endpoint itself before SIEM data is queried.
Detect Log Clearing Immediately
When a user or process clears the Security event log, Windows writes Event ID 1102 (Security) as the very last event before the log is cleared. When the System log is cleared, Event ID 104 (System) is generated. These events include the account that performed the clearing. Alert on both immediately in your SIEM. In Sentinel: SecurityEvent | where EventID == 1102 | project TimeGenerated, Computer, Account, ActivityID. In Splunk: index=windows EventCode=1102. The alert should be P1 severity -- no legitimate administrative action requires clearing the Security log. Even if an admin claims they cleared the log intentionally, the event is evidence that forensic history was destroyed. Treat it as a potential indicator of compromise until proven otherwise. Common false positive: some backup or compliance tools clear old logs as part of archiving -- if you have such a tool, verify it generates controlled 1102 events and document those as expected.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Restrict Who Can Clear Logs
By default, members of the local Administrators group can clear Windows event logs using wevtutil, the Event Viewer GUI, or PowerShell. You cannot prevent local admins from clearing logs at the OS level without removing their admin rights. However, you can limit which domain accounts are granted local admin rights (reducing the population of accounts that can clear logs), and you can use Protected Event Logging to encrypt log content (making it harder to selectively remove events, though not preventing clearing). For the Security log on DCs specifically: limit interactive and remote admin access to DCs to Tier 0 admin accounts only. Reducing the number of accounts with DC admin access directly reduces the population of accounts that could clear DC Security logs. The most important defensive measure is forwarding: once an event is forwarded to your SIEM and the SIEM is not accessible from the Windows endpoint, clearing the local log does not remove the forwarded copy.
Forward All Security-Relevant Logs to an Unreachable SIEM
Log forwarding is the primary tamper-protection mechanism. Requirements: logs must be forwarded continuously (near-real-time, not batched nightly), to a SIEM that the compromised endpoint cannot reach or modify (different network segment, different authentication domain, write-only access for the forwarding agent), and the forward must happen before an attacker has time to clear the log. Real-time forwarding via Windows Event Forwarding (WEF) or Sysmon forwarding achieves sub-minute forward latency. Winlogbeat (Elastic), Splunk UF, and the Microsoft Monitoring Agent all forward in near-real-time. SIEM access control: the account used by the forwarding agent on the endpoint should have write-only access to the SIEM ingestion endpoint -- it should not be able to delete events, modify index settings, or access other machines' data. A compromised endpoint's forwarding credential should have the minimum necessary access. Immutable log storage at the SIEM layer: major SIEMs support write-once or immutable log storage tiers. Enabling this ensures that even a compromised SIEM admin account cannot delete historical log data.
Enable Protected Event Logging
Protected Event Logging encrypts event log content using a public/private key pair before it is written to the log. Only the private key (stored on a designated forensics system) can decrypt the content. This protects against an attacker who reads log content to find indicators of their own activity that they want to remove -- with encryption, they cannot read the content to selectively delete entries (and individual event deletion is not possible in standard Windows event logs anyway). More practically, Protected Event Logging protects the content of PowerShell script block logging from being read by the compromised account. Enable via GPO: Computer Configuration > Administrative Templates > Windows Components > Event Logging > Enable Protected Event Logging = Enabled. Provide the certificate public key for encryption. The private key for decryption should be stored in a hardware security module or offline system used only for forensic decryption.
The bottom line
Local Windows Event Logs cannot be made fully tamper-proof against local administrators -- the local admin privilege is inherently trusted at the OS level. The correct architecture is: set large local log sizes for forensic headroom, alert immediately on Event ID 1102 and 104 as P1 incidents, forward all security-relevant logs to a SIEM that the endpoint cannot modify, and use Protected Event Logging for the highest-sensitivity log channels. If an attacker clears local logs, the forwarded copies in your SIEM should provide complete coverage of the attack timeline up to the moment of clearing.
Frequently asked questions
Can I prevent Windows Event Log clearing entirely?
Not via any standard security configuration. Any local administrator can clear event logs using built-in Windows tools. You can make it harder by restricting local admin group membership (fewer people can clear), by using Protected Event Logging (content is encrypted so attackers cannot read what they want to delete), and by forwarding in real-time (clearing the local log does not affect forwarded copies). The architectural answer is SIEM forwarding -- accept that local logs can be cleared and ensure the SIEM copy is your primary forensic source.
Does clearing the event log generate a log entry before it is cleared?
Yes -- Event ID 1102 is the last entry written to the Security log before it is cleared, and it includes the account name and timestamp. This creates a small forensic record of the clearing event itself. However, if the attacker clears the log without any of their prior activity having been forwarded to a SIEM, Event ID 1102 (forwarded to SIEM) is the only evidence of the clearing -- the prior activity is gone. This is why real-time forwarding is critical: forwarded events cannot be retroactively deleted from the SIEM even if the source log is cleared.
What is the Event Log service and what happens if an attacker stops it?
The Windows Event Log service (eventlog) collects and stores event log data. Stopping it via 'Stop-Service eventlog' or 'sc stop eventlog' requires local admin rights and stops all event recording. Event ID 6006 (System) is generated when the service stops gracefully. After the service stops, no events are recorded -- an attacker can perform actions with no local log trace. Protect against this: configure a Group Policy software restriction or Service Control Manager hardening to prevent the Event Log service from being stopped by non-SYSTEM processes. In practice, preventing service stops by local admins is difficult without application control.
Which Windows event IDs are most critical to forward to my SIEM?
At minimum: 4624 (logon), 4625 (failed logon), 4648 (logon with explicit credentials), 4662 (object access), 4663 (file access by audited user), 4688 (process creation, requires command line audit enabled), 4698 (scheduled task creation), 4702 (scheduled task modification), 4720 (account creation), 4728/4732/4756 (member added to security group), 4768/4769/4771 (Kerberos auth), 4776 (NTLM auth), 7045 (new service installed), 1102 (Security log cleared), and all Sysmon events. On domain controllers, additionally: 4662 (directory service access), 4742 (computer account changed), 5136 (directory service object modified), 5145 (network share access).
How large should Windows Event Log maximum sizes be set?
NIST 800-92 and CIS benchmarks recommend Security log size of at least 1 GB (1,048,576 KB) and Application and System logs of at least 64 MB each. For DCs with high authentication volume, 2 GB or more for the Security log. The default maximum size (20 MB) holds only minutes of events on a busy system. Set 'Retention method' to Overwrite Events as Needed (not 'Overwrite events older than X days', which stops logging when full). Increase the PowerShell Operational log to 512 MB minimum and the Microsoft-Windows-Sysmon/Operational log to 2 GB if you run Sysmon. Apply via GPO: Computer Configuration > Windows Settings > Security Settings > Event Log.
What are the most important Advanced Audit Policy settings to enable on Windows and how are they different from basic audit policy?
Basic Audit Policy (under Local Policies > Audit Policy in GPO) configures logging at a coarse category level (Audit Account Logon, Audit Account Management). Advanced Audit Policy (under Security Settings > Advanced Audit Policy Configuration) provides subcategory granularity, allowing you to enable only the specific events you need rather than entire categories. For example, 'Audit Account Logon' enables all account logon events; Advanced Audit lets you enable only 'Audit Credential Validation' (Event ID 4776) without also enabling 'Audit Other Account Logon Events'. Key Advanced Audit subcategories: Audit Process Creation (enables Event ID 4688 with command line) under Detailed Tracking, Audit Logon/Logoff subcategories for all logon event types, Audit Privilege Use for Sensitive Privilege Use (Event ID 4673), Audit Object Access for File System and Registry (generate 4663 for file access by audited user), and Audit DS Access for Directory Service Changes (Event ID 5136). Always use Advanced Audit Policy; if both are configured, Advanced Audit takes precedence but the combination can cause unexpected event generation. Verify applied policy with auditpol.exe /get /category:* rather than reading the GPO.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.