Event Log Clearing and Malware Execution: Evidence from Windows Logs

If you’ve worked in cybersecurity or digital forensics for even a short while, you’ve probably realized that Windows event logs are like the system’s memory — they remember almost everything that happens. From user logins and process creations to application crashes and errors, these logs quietly record the life story of a system.

But what happens when someone — say, an attacker — tries to erase those memories?

Or when malware crashes in the middle of doing something shady and leaves traces behind?That’s where event log analysis becomes one of the most powerful skills in our toolkit.

-------------------------------------------------------------------------------------------------------------

Event Log Clearing — When Someone Tries to Erase Their Footprints

When investigating an intrusion, one of the first things I check for is log clearing activity. Why?Because whenever someone tries to cover their tracks, they often attempt to clear the event logs — especially the Security log.

How You Detect It

• Event ID 1102 — Appears in the Security log when it’s cleared.

• Event ID 104 — Appears in the System log when any other log (like Application or Setup) is cleared.

So even if the attacker wipes out the previous entries, these two events show that someone did it — and often, who did it.

Who Can Clear Logs?

Only users with Administrator or SYSTEM privileges can clear event logs. That includes:

• Local Administrators

• Domain Administrators

• The Local SYSTEM account

If your logs show one of these users clearing logs outside of your normal maintenance schedule — especially during an incident — it’s a red flag.

Why It Matters

Attackers clear logs to hide privilege escalation, lateral movement, or malware execution traces. It’s a common tactic in ransomware attacks, where adversaries want to erase evidence before encrypting systems.

And remember, you can’t partially clear logs in Windows — it’s all or nothing. However, advanced attackers have found ways around this.

-------------------------------------------------------------------------------------------------------------

Modern Log Manipulation Tricks (and Why You Should Care)

Old-school tools like WinZapper tried to delete individual events but usually ended up corrupting the logs. Modern attackers are more sophisticated.

For instance:

• DanderSpritz (from the Shadow Brokers leak) includes a module called eventlogedit that can hide specific events by altering log headers. (https://danderspritz.com/)

• Invoke-PhantOm, a PowerShell-based tool, kills all threads of the Event Log Service. It looks like the service is still running, but nothing is being logged — a classic stealth move. (https://github.com/olafhartong/Invoke-Phant0m)

Even more advanced attackers might:

• Suspend the Event Log Service, modify logs, then resume it.

• Directly manipulate logs in memory (RAM) instead of on disk.

• Or flood the logs with noise — harmless events that bury the real ones.

All these attacks require administrative privileges, but the takeaway is simple:

Never assume logs are complete or untouched. Always analyze them critically.

How to Defend Against Log Clearing Attacks

1. Set up alerts for Event IDs 1102 and 104 in your SIEM or monitoring solution.

   • If these occur outside known maintenance windows, investigate immediately.

2. Forward logs to a centralized log server or cloud SIEM.

   • Even if local logs are cleared, your remote copies remain safe.

3. Baseline your environment.

   • Know which admins perform legitimate log maintenance. Any deviation is worth a look.

4. Correlate gaps.

   • If no logs are forwarded for hours or days, that system deserves attention — it might be under manipulation.

-------------------------------------------------------------------------------------------------------------

Evidence of Malware Execution — When the Bad Stuff Crashes

Let’s flip to the other side of the story. Even when attackers don’t clear logs, their malware often leaves evidence behind. In fact, many pieces of malware crash — and those crashes are pure gold for forensic analysts.

Where to Look

Most of the time, you’ll find useful traces in:

• System Event Logs — check for Critical, Warning, and Error events.

• Application Event Logs — especially:

  • Event ID 1000 → Application error

  • Event ID 1001 → Windows Error Reporting (WER)

  • Event ID 1002 → Application hang

Even though the Security log can track process execution (if process auditing is enabled), many organizations keep that feature off due to log volume. That’s why System and Application logs often give you the first real hints of malware activity.

-------------------------------------------------------------------------------------------------------------

Windows Error Reporting (WER): The Hidden Gem

Windows Error Reporting (WER) doesn’t just pop up that annoying “This program has stopped working” message — it actually creates detailed reports when programs crash. These reports are stored as simple text files, often named Report.wer.

You’ll find them in:

• C:\ProgramData\Microsoft\Windows\WER

• %UserProfile%\AppData\Local\Microsoft\Windows\WER

And here’s what makes them valuable:

• Timestamp of execution

• Full executable path

• SHA1 hash of the file

• Loaded DLLs or modules

Sometimes, analyzing a WER file can even reveal malware helper files, injection modules, or failed payloads.

-------------------------------------------------------------------------------------------------------------

Microsoft Defender logs — your first alarm bell

Even the slickest adversary sometimes trips an anti-malware rule. Defender is not perfect, but it’s a very useful source of early indicators. Treat Defender alerts as starting points, not the whole story.

What to check

• Primary log: Microsoft-Windows-Windows Defender/Operational.evtx — look here first.

• Important event IDs (quick list):

  • 1116 — Malware detected

  • 1117 — Malware action taken (quarantine, remove, etc.)

  • 1118 — Malware action failed

  • 1119 — Malware action critical failure

Extra sources Defender writes

• MPLog-*.log (Diagnostics):

  
  

  C:\ProgramData\Microsoft\Windows Defender\Support\MPLog-YYYYMMDD-HHMMSS

  
  

  • Contains process lists, possible code injection flags (“tainted”), file hashes, paths Defender scanned, and SDN queries.

• DetectionHistory (user-facing record):

  
  

  C:\ProgramData\Microsoft\Windows Defender\Scans\HistoryService\DetectionHistory

  
  

  • Shows what the user saw and what action was taken.

• Quarantine:

  
  

  C:\ProgramData\Microsoft\Windows Defender\Quarantine

  
  

  • Holds quarantined files (usually stored in vendor format). Tools like maldump can extract original file contents.

How to use these logs

• Start with event IDs 1116–1119 to find detections and timestamps.

• Use MPLogs to find process context, hashes, and “tainted” notes — sometimes MPLogs include the SHA1/SHA2 which helps pivoting.

• If you find a quarantined item, extract it—hash it, submit to VT/intel, and search your environment for other instances.

Quick hunting keywords for MPLog

• detection, tainted, SDN Query, sha1, sha2, file paths like \Temp\ or AppData\.

Tip: Defender telemetry often outlives other logs on a host (it can go back months). Don’t skip it during incident triage.

-------------------------------------------------------------------------------------------------------------

Process tracking & command-line capture — make attackers visible

If you can capture full command lines for process creation, you go from blind to powerful. Many attacks are just clever command lines; 4688 events tell the story when enabled.

Key Events

• 4688 — New process created (includes executable path, and — if enabled — full command line)

• 4689 — Process exited

Why this matters

• Attackers rely on command shells, PowerShell, WMIC, and weird command arguments. Full command lines let you see attacker tooling, scripts, and flags — all of which are high-value IOCs.

How to enable

• Group Policy path: Computer Configuration → Policies → Administrative Templates → System → Audit Process Creation

  • Enable and turn on Include command line in process creation events (works on Windows 7+ backported).

• If you have EDR, enable process command-line capture there—it’s usually cheaper on storage and easier to query.

Practical hunts

• Find suspicious parent → child chains: powershell.exe launching rundll32, or wmic creating cscript from a weird folder.

• Filter for cmd.exe /c or powershell -EncodedCommand or long -Command lines. Those are often malicious.

Tip: If your environment is noisy, enable detailed command lines on servers (domain controllers, jump boxes) first — highest ROI.

-------------------------------------------------------------------------------------------------------------

WMI Activity logs — catching stealthy persistence

WMI event consumers (filters + consumers + bindings) are a neat persistence trick for attackers. Lucky for us, modern Windows logs a lot of this activity.

Where to look

• Microsoft-Windows-WMI-Activity/Operational.evtx (WMI-Activity/Operational)

• Event IDs of interest: 5857–5861, with 5861 being the most useful.

  • 5861 — A permanent event consumer was created (this often means a lasting persistence mechanism).

  • 5858 — Query errors (useful to see which host/user caused WMI query failures).

  • 5857 — Provider DLL loads (can show dropped/proprietary WMI DLLs).

Why 5861 matters

• It records permanent consumers added to WMI. If an attacker installs a consumer that runs a VBScript or PowerShell on a trigger, 5861 will often reveal the script path or the exact command that will run.

What to hunt for

• New consumers executing scripts from user profiles or Temp folders.

• Filters that trigger frequently (every 20 seconds) — often used to create polling beacons.

• Provider DLLs that look unusual (not standard Microsoft DLLs).

The command-line angle again

• WMI attacks are much easier to find when you have command-line logs. Without them you may only see wmic process call create which is fine, but not as clear as the full command.

Tip: If you can only enable one capability, enable process command-line collection. It makes WMI attacks transparent.

-------------------------------------------------------------------------------------------------------------

Putting it together — how a triage should flow

When you spin up an investigation, do this in order:

1. Defender first — check 1116–1119 and MPLogs for immediate detections and SHA1s. Quarantine may contain the payload.

2. Process timeline — pull 4688/4689 events for the host/time window. Look for parent→child anomalies and suspicious command-lines.

3. WMI-Activity — check for 5861 (new consumers) and 5858/5857 for query errors or odd provider loads.

4. Correlate — match Defender timestamps to process creation and WMI consumer creation. That gives you a timeline: detection → execution → persistence.

5. Extract artifacts — recover quarantined files, collect MPLogs, and capture relevant files (scripts, DLLs, Report.wer if present).

   
   

Remember: defenders win by stitching together multiple weak signals into a strong story.

-------------------------------------------------------------------------------------------------------------

Tools and small commands that help right away

• KAPE — Use it to collect Defender logs, MPLogs, DetectionHistory, Quarantine, WER files, and relevant registry hives quickly during triage.

• EvtxECmd — Great for parsing and mapping evtx entries into normalized CSVs for easy filtering.

• maldump — Use to extract original files from Defender quarantine. (Vendor quarantine formats vary — tools help.)

• Timeline tools — Load your parsed CSVs into Timeline Explorer or your SIEM for grouping and pivoting.

Quick PowerShell tip to search MPLog for a hash or keyword:

Get-ChildItem 'C:\ProgramData\Microsoft\Windows Defender\Support\*.log' -Recurse | Select-String -Pattern "< Enter IP File name >" -List

-------------------------------------------------------------------------------------------------------------

Wrapping Up

logs tell stories — even when someone tries to silence them. From attackers to malware tripping over its own code, there’s always a trace if you know where to look.

In forensics, success isn’t about having perfect data. It’s about knowing how to read the clues that survive.

---------------------------------------------------Dean-----------------------------------------------------