Recover Windows Event Logs After They Are Cleared

If a Windows event log is cleared on a server, the first question is usually simple: can I get it back?

The honest answer is uncomfortable: sometimes yes, but only if the events were copied somewhere else before the clearing happened. If the only copy lived inside the local .evtx file and that log was cleared, normal administration tools will not magically rebuild the missing history. You may still find evidence in backups, forwarded events, EDR telemetry, domain controller logs, firewall logs, or application logs, but the local event log itself should be treated as damaged evidence.

This is why event log recovery is mostly a prevention problem. You do not want to design the audit process after the log is gone.

Quick answer

If Windows event logs were cleared, first preserve the machine, check for log-clear events, and search central sources such as Windows Event Forwarding, SIEM, EDR, domain controller logs, VPN logs, firewall logs, and backups. Local recovery is limited unless the .evtx files were backed up or exported before clearing. To prevent permanent loss, forward important events off the host, export critical logs on a schedule, alert on log clearing, and monitor for event gaps.

What can actually be recovered

After a Windows log is cleared, recovery depends on where the events existed before the clearing action.

Usually recoverable:

Events already forwarded to a Windows Event Collector
Events already ingested by a SIEM or EDR platform
Archived .evtx exports
Server backups or snapshots that captured old event log files
Related logs on other systems, such as domain controllers or VPN gateways
Application logs stored outside Windows Event Log

Usually not recoverable from the local host alone:

Events that existed only in the cleared local log
Events that were never forwarded, exported, backed up, or collected
A complete timeline if multiple telemetry sources were also disabled or unavailable

That does not mean the investigation is over. It means the local host is no longer the source of truth. Build the timeline from independent systems.

Step 1: Preserve the current state

Do not start randomly cleaning, rebooting, or reinstalling the machine. Preserve what remains first.

On the affected host, export the current state of the important logs. This does not recover deleted history, but it saves what is still present.

$caseId = Get-Date -Format 'yyyyMMdd-HHmmss'
$outDir = "C:\IR\EventLogs-$caseId"

New-Item -Path $outDir -ItemType Directory -Force | Out-Null

wevtutil epl Security "$outDir\Security-current.evtx"
wevtutil epl System "$outDir\System-current.evtx"
wevtutil epl Application "$outDir\Application-current.evtx"
wevtutil epl "Windows PowerShell" "$outDir\WindowsPowerShell-current.evtx"
wevtutil epl "Microsoft-Windows-PowerShell/Operational" "$outDir\PowerShellOperational-current.evtx"

wevtutil epl exports a log to an .evtx file. Keep the export read-only after collection and copy it to a secure evidence location.

If the server is important, also collect basic host context:

$outDir = "C:\IR\EventLogs-latest"

Get-ComputerInfo | Out-File "$outDir\computer-info.txt"
whoami /all | Out-File "$outDir\whoami-all.txt"
ipconfig /all | Out-File "$outDir\ipconfig-all.txt"
Get-Date | Out-File "$outDir\collection-time.txt"

Small details matter later. Time zone, collection time, host name, IP address, and logged-on identity help when comparing events across systems.

Step 2: Check whether the clearing was recorded

Windows can record log-clearing activity, depending on the log and configuration. Check these events first.

Security log clear events:

Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id      = 1102
} -MaxEvents 20 |
    Select-Object TimeCreated, Id, ProviderName, Message

System log events from the Windows Event Log provider:

Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Microsoft-Windows-Eventlog'
    Id           = 104
} -MaxEvents 20 |
    Select-Object TimeCreated, Id, ProviderName, Message

Audit policy changes:

Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id      = 4719
} -MaxEvents 20 |
    Select-Object TimeCreated, Id, ProviderName, Message

If these events exist, record the account, timestamp, and host context. If they do not exist, do not assume nothing happened. The log may have been cleared before you looked, auditing may not have been enabled, or the activity may need to be reconstructed elsewhere.

Step 3: Search forwarded events

If Windows Event Forwarding is configured, the collector may still have copies of events that were cleared from the source machine.

On the collector server, check the ForwardedEvents log for the affected computer:

$computerName = 'SERVER01'
$startTime = (Get-Date).AddDays(-7)

Get-WinEvent -FilterHashtable @{
    LogName   = 'ForwardedEvents'
    StartTime = $startTime
} |
    Where-Object { $_.MachineName -eq $computerName } |
    Select-Object TimeCreated, MachineName, Id, ProviderName, Message |
    Sort-Object TimeCreated

If this returns events from before the local log was cleared, export them:

$computerName = 'SERVER01'
$startTime = Get-Date '2026-06-15 00:00:00'
$endTime = Get-Date '2026-06-16 00:00:00'
$outFile = "C:\IR\SERVER01-forwarded-events.csv"

Get-WinEvent -FilterHashtable @{
    LogName   = 'ForwardedEvents'
    StartTime = $startTime
    EndTime   = $endTime
} |
    Where-Object { $_.MachineName -eq $computerName } |
    Select-Object TimeCreated, MachineName, Id, ProviderName, LevelDisplayName, Message |
    Export-Csv -Path $outFile -NoTypeInformation -Encoding utf8

This is the main reason to use event forwarding. If a local administrator clears logs on the source server, the collector should already have received important events.

Step 4: Compare with domain controller and identity logs

A server may lose its local logs, but authentication often leaves evidence on domain controllers and identity systems.

For Active Directory environments, check domain controller Security logs for logon activity involving the affected server or administrator account. These event IDs are common starting points:

4624 successful logon
4625 failed logon
4634 logoff
4648 explicit credential use
4672 special privileges assigned to new logon
4720 user account created
4728 member added to a privileged global group
4732 member added to a privileged local group

Example query on a domain controller:

$adminAccount = 'CONTOSO\admin.user'
$startTime = Get-Date '2026-06-15 00:00:00'
$endTime = Get-Date '2026-06-16 00:00:00'

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4624, 4625, 4648, 4672
    StartTime = $startTime
    EndTime   = $endTime
} |
    Where-Object { $_.Message -like "*$adminAccount*" } |
    Select-Object TimeCreated, Id, ProviderName, Message

This does not prove exactly what happened on the affected server, but it can show who authenticated, when they authenticated, and from where.

Step 5: Look for gaps, not only events

A missing event stream is itself useful evidence. If a server normally sends events every few minutes and then goes silent during the exact period under review, that gap matters.

On a collector, this simple check shows the first and last forwarded event for each machine in a time window:

$startTime = (Get-Date).AddHours(-24)

Get-WinEvent -FilterHashtable @{
    LogName   = 'ForwardedEvents'
    StartTime = $startTime
} |
    Group-Object MachineName |
    ForEach-Object {
        $events = $_.Group | Sort-Object TimeCreated

        [pscustomobject]@{
            MachineName = $_.Name
            FirstEvent  = $events[0].TimeCreated
            LastEvent   = $events[-1].TimeCreated
            Count       = $events.Count
        }
    } |
    Sort-Object LastEvent

For high-value servers, alert when the collector has not received events for longer than expected. No telemetry can be as important as a critical alert.

Step 6: Restore from backups or snapshots

If you have server backups or snapshots from before the clearing event, you may be able to recover old .evtx files. Do this carefully:

Do not overwrite the current server logs.
Restore to an isolated recovery location.
Preserve file timestamps and backup metadata.
Keep a note of which backup the logs came from.
Open recovered .evtx files read-only for review.

PowerShell can read exported or recovered .evtx files with Get-WinEvent -Path:

$evtxPath = 'D:\RecoveredLogs\Security.evtx'

Get-WinEvent -Path $evtxPath -MaxEvents 50 |
    Select-Object TimeCreated, Id, ProviderName, Message

If the recovered file contains events missing from the live server, export the relevant range:

$evtxPath = 'D:\RecoveredLogs\Security.evtx'
$startTime = Get-Date '2026-06-15 00:00:00'
$endTime = Get-Date '2026-06-16 00:00:00'

Get-WinEvent -Path $evtxPath |
    Where-Object {
        $_.TimeCreated -ge $startTime -and
        $_.TimeCreated -lt $endTime
    } |
    Select-Object TimeCreated, Id, ProviderName, Message |
    Export-Csv -Path 'C:\IR\recovered-security-events.csv' -NoTypeInformation -Encoding utf8

This is recovery from backup, not recovery from an already-cleared active log.

Prevention: forward important logs before an incident

Windows Event Forwarding is built into Windows. It uses a collector server and subscriptions to receive selected events from source computers. Microsoft describes WEF as a way to read administrative and operational events from devices and forward chosen events to a Windows Event Collector.

On a collector server, the setup usually starts with:

wecutil qc

That configures the Windows Event Collector service. In production, use Group Policy or endpoint management to configure source computers and subscriptions. The exact subscription design depends on the environment, but high-value categories usually include:

Security logon and privilege events
Audit policy changes
Event log service events
PowerShell operational events
Task Scheduler events
Service installation or service state changes
Defender or EDR-related events

On a source computer, confirm WinRM is available if your WEF design requires it:

winrm quickconfig

Do not stop at “the subscription exists.” Test that events arrive on the collector, then test what happens when the source host is offline, rebooted, or stops sending events.

Prevention: scheduled event log exports

For smaller environments without a SIEM, scheduled exports are better than having no backup at all. This is not as strong as real forwarding because an attacker with enough access may target the export location too, but it gives you another copy.

Example export script:

$date = Get-Date -Format 'yyyyMMdd-HHmmss'
$server = $env:COMPUTERNAME
$dest = "\\fileserver\secure-eventlog-archive\$server\$date"

New-Item -Path $dest -ItemType Directory -Force | Out-Null

wevtutil epl Security "$dest\Security.evtx"
wevtutil epl System "$dest\System.evtx"
wevtutil epl Application "$dest\Application.evtx"
wevtutil epl "Microsoft-Windows-PowerShell/Operational" "$dest\PowerShellOperational.evtx"

The archive share should be write-only for servers if possible. Administrators on the source server should not be able to delete old archives. If the same compromised account can clear the local log and delete the backup, the backup design is weak.

Prevention: alert on log clearing

Once forwarding is in place, create alerts for log clearing and audit policy changes. A simple local check is useful for testing:

$events = Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 1102, 4719
    StartTime = (Get-Date).AddDays(-1)
} -ErrorAction SilentlyContinue

if ($events) {
    $events |
        Select-Object TimeCreated, Id, ProviderName, Message |
        Format-List
}

In production, this logic belongs in the SIEM, EDR, or monitoring platform, not only on the local server.

Also alert on collection gaps:

$threshold = (Get-Date).AddMinutes(-30)

Get-WinEvent -FilterHashtable @{
    LogName   = 'ForwardedEvents'
    StartTime = (Get-Date).AddHours(-2)
} |
    Group-Object MachineName |
    ForEach-Object {
        $last = ($_.Group | Sort-Object TimeCreated | Select-Object -Last 1).TimeCreated

        if ($last -lt $threshold) {
            [pscustomobject]@{
                MachineName = $_.Name
                LastEvent   = $last
                Status      = 'No recent forwarded events'
            }
        }
    }

This catches a different problem: not the suspicious event itself, but the disappearance of telemetry.

What I would do after discovering cleared logs

My practical response checklist:

Preserve current logs and host context.
Check for log-clear and audit policy events.
Search Windows Event Forwarding or SIEM data.
Check EDR or Defender telemetry.
Query domain controller authentication events.
Review VPN, firewall, RDP gateway, and jump host logs.
Check change tickets and approved maintenance records.
Look for telemetry gaps.
Recover .evtx files from backups or snapshots if available.
Document what is confirmed, what is missing, and which evidence source supports each conclusion.

Avoid claiming certainty from one source. A cleared local log is a reason to widen the investigation, not a reason to close it.

References

Microsoft Learn: Use Windows Event Forwarding to assist in intrusion detection
Microsoft Learn: Windows Event Collector
Microsoft Learn: Get-WinEvent
Microsoft Learn: wevtutil

Local Windows event logs are useful, but they are not a complete audit strategy. If the worst case happens and logs are cleared, recovery depends on the copies you already made somewhere else. Build that backup path before you need it.

Quick answer#

What can actually be recovered#

Step 1: Preserve the current state#

Step 2: Check whether the clearing was recorded#

Step 3: Search forwarded events#

Step 4: Compare with domain controller and identity logs#

Step 5: Look for gaps, not only events#

Step 6: Restore from backups or snapshots#

Prevention: forward important logs before an incident#

Prevention: scheduled event log exports#

Prevention: alert on log clearing#

What I would do after discovering cleared logs#

References#

💬 Comments