Fix Security Event Log Tampering Detected Error

Cause 1: Scheduled log rotation clearing the security log

The most common reason for the Security Event Log Tampering Detected error (Event ID 1102 or 1104) is a scheduled task or script that clears the Security log as part of routine maintenance. I've seen this on servers where an admin set up a wevtutil or Clear-EventLog PowerShell command to run nightly, thinking it helps performance. It doesn't. The Security log is meant to be archived, not cleared.

What's actually happening here is that Windows logs Event ID 1102 every time the Security log is cleared, whether by a person or a script. The operating system treats any clear as a potential tampering event, even if it's legitimate. So the error isn't false—it's correct. The fix is to stop clearing the log and instead archive it.

How to find the culprit

Open Event Viewer → Windows Logs → Security.
Look for Event ID 1102. Its details include the user account and process that cleared the log.
If the user is SYSTEM or a service account, it's likely a scheduled task or third-party tool. Check Task Scheduler for tasks running wevtutil cl Security or Clear-EventLog -LogName Security.

The real fix is to change your log management to use archiving instead of clearing. Open an elevated command prompt and run:

wevtutil sl Security /rt:true /ms:209715200

That sets the Security log to retain events up to 200 MB. When it fills up, older events are overwritten—no clear event, no tampering alert. If you need longer retention, forward logs to a central collector using Windows Event Forwarding, not by clearing the local log.

If you really must clear the log (you don't), stop the task and delete it. Then acknowledge the old 1102 events in Event Viewer by right-clicking Security log → Properties → uncheck 'Overwrite events as needed', apply, then re-check it. That clears the current log without triggering a new 1102 event.

Cause 2: Antivirus or security scanner triggers the alert

Some security software—especially older versions of McAfee, Symantec, or CrowdStrike—call the Windows API to clear the Security log during a scan. They do this because they think a full log is a sign of trouble. It's lazy coding. The result is you get a tampering alert from Windows even though the scanner is supposed to be protecting you.

The key difference from Cause 1 is the process name. In the Event ID 1102 details, the process will be something like McShield.exe, SymEvent.exe, or csfalcon.exe. You can also check the System log around the same time for events from the antivirus service.

What to do

Update the software to the latest version. Many vendors fixed this in recent releases.
Change the scanner settings to not touch the Security log. Look for options like 'Clear event log on scan' or 'Audit log management' and disable them.
If there's no such setting, create a firewall rule blocking the scanner's process from calling wevtutil or the EventLog API. Use Process Explorer to see what API calls the scanner makes, then block them via Windows Defender Application Control. That's advanced, but it works.

The second you stop the scanner from clearing the log, the 1102 events stop. But you'll still see the old ones in the log. That's fine—just filter them out by right-clicking the Security log → Filter Current Log → enter 1102 in the Event IDs box and exclude them from your view. The events stay for forensics but won't bother you.

Cause 3: Malware or unauthorized user manually cleared the log

If you ruled out log rotation and antivirus, you have to consider someone—or something—is deliberately tampering with the audit trail. Malware like ransomware often clears the Security log after encryption to hide its tracks. An insider might do it too.

The tell here is the account name in Event ID 1102. If it's a user account like jdoe or Administrator and the process is mmc.exe (Event Viewer) or cmd.exe, it's manual action. If it's SYSTEM with a process like powershell.exe and you don't have a scheduled task, that's suspicious—likely a malware process running as SYSTEM.

How to confirm

Check Event ID 1102 for Subject User Name and Process ID.
Cross-reference the Process ID with the System log or Task Manager from that time. Was it a known process?
Run a full offline scan with Windows Defender or a second-opinion scanner like Malwarebytes.

The fix is two-part:

Clean the malware using the scanner. Boot from a USB if needed—malware can hide from a running Windows scan.
Harden the system so it's harder to clear the log in the future. Restrict who can clear the Security log: go to secpol.msc → Security Settings → Local Policies → User Rights Assignment → 'Manage auditing and security log'. Remove everyone except Administrators and SYSTEM. By default, even users can clear it—that's a design flaw.

After you clean it, the 1102 event might still appear if the malware is still running at the system level. Check the System log for Error 7031 or 7034 from the EventLog service—malware sometimes crashes it. If you see those, the log clearing is a side effect of a service crash, not a deliberate act. Fix the service.

Quick-reference summary

Cause	How to identify	Fix
Scheduled log rotation	Event ID 1102 shows SYSTEM or service account, process is `wevtutil` or `powershell.exe`	Stop clearing the log; set archive size or enable circular logging
Antivirus/security scanner	Event ID 1102 shows scanner process (e.g., `McShield.exe`)	Update scanner; disable log-clearing setting; block API calls via WDAC
Malware or unauthorized user	Event ID 1102 shows unknown process or user account, plus other suspicious events	Offline malware scan; restrict 'Manage auditing and security log' rights

One last thing: if you see Event ID 1104 instead of 1102, that means the Security log was overwritten because it reached its maximum size. Same causes, same fixes. The 1102 event is a clean clear; 1104 is a passive overwrite. Both count as tampering in the system's view, but 1104 is usually benign and just means you need to increase the log size. Don't worry about 1104 unless it happens every hour. Then check the log size and the fill rate—something is generating too many events.