ANAVEM
Languagefr
Windows security monitoring dashboard displaying Event ID 5139 registry deletion events in Event Viewer
Event ID 5139InformationMicrosoft-Windows-Security-AuditingWindows

Windows Event ID 5139 – Microsoft-Windows-Security-Auditing: Registry Value Deleted

Event ID 5139 logs when a registry value is deleted on Windows systems with object access auditing enabled. Critical for security monitoring and compliance tracking.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
18 March 202612 min read 0
Event ID 5139Microsoft-Windows-Security-Auditing 5 methods 12 min
Event Reference

What This Event Means

Windows Event ID 5139 represents a security audit event that documents registry value deletion operations within the Windows operating system. This event generates when the Windows Security Reference Monitor detects that a registry value has been successfully removed from the Windows Registry database. The event requires object access auditing to be enabled through Group Policy or local security policy configuration.

The event structure includes comprehensive details about the deletion operation, including the full registry path of the deleted value, the security identifier (SID) of the user account that performed the action, the process name and ID responsible for the deletion, and timestamp information. This granular logging capability makes Event ID 5139 particularly valuable for security monitoring, compliance auditing, and forensic analysis scenarios.

In Windows Server 2025 and Windows 11 24H2 environments, Microsoft has enhanced the event logging to include additional context about the deletion source and improved correlation capabilities with other security events. The event integrates with Windows Defender Advanced Threat Protection (ATP) and Microsoft Sentinel for advanced threat detection scenarios, where registry value deletions might indicate persistence mechanism removal or anti-forensics activities by threat actors.

Organizations implementing zero-trust security models particularly benefit from monitoring Event ID 5139, as registry modifications often represent privilege escalation attempts or system configuration changes that could impact security posture. The event also plays a crucial role in change management processes, providing audit trails for administrative actions and software lifecycle management activities.

Applies to

Windows 10Windows 11Windows Server 2019/2022/2025
Analysis

Possible Causes

  • Administrative deletion of registry values through Registry Editor (regedit.exe)
  • Software uninstallation processes removing application-specific registry entries
  • Group Policy processing that removes obsolete or conflicting registry values
  • PowerShell scripts or batch files executing registry deletion commands
  • System maintenance utilities cleaning up orphaned or invalid registry entries
  • Malware or threat actors removing registry values to hide persistence mechanisms
  • Windows Update or feature update processes removing deprecated registry values
  • Third-party system optimization tools performing registry cleanup operations
  • Application crashes or improper shutdowns triggering automatic registry cleanup
  • Security software removing malicious or suspicious registry modifications
Resolution Methods

Troubleshooting Steps

01

Review Event Details in Event Viewer

Start by examining the specific details of Event ID 5139 to understand what registry value was deleted and by whom.

  1. Open Event Viewer by pressing Win + R, typing eventvwr.msc, and pressing Enter
  2. Navigate to Windows LogsSecurity
  3. Filter for Event ID 5139 by right-clicking the Security log and selecting Filter Current Log
  4. Enter 5139 in the Event IDs field and click OK
  5. Double-click on a 5139 event to view detailed information including:
    • Subject (user account that performed the deletion)
    • Object Name (full registry path of deleted value)
    • Process Information (executable and process ID)
    • Access Request Information (requested access rights)
  6. Note the Logon ID to correlate with logon events (4624/4625) for additional context

Use PowerShell for more efficient filtering:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5139} -MaxEvents 50 | Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap
02

Correlate with Process and Logon Events

Cross-reference Event ID 5139 with related security events to build a complete picture of the deletion activity.

  1. Extract the Process ID and Logon ID from the 5139 event details
  2. Search for process creation events (4688) with matching Process ID:
$ProcessId = "0x1234"  # Replace with actual Process ID from 5139 event
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} | Where-Object {$_.Message -like "*$ProcessId*"} | Select-Object TimeCreated, Message
  1. Identify the logon session using the Logon ID:
$LogonId = "0x5678"  # Replace with actual Logon ID from 5139 event
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625} | Where-Object {$_.Message -like "*$LogonId*"} | Select-Object TimeCreated, Id, Message
  1. Check for related registry events around the same timeframe:
$StartTime = (Get-Date).AddHours(-1)
$EndTime = Get-Date
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5136,5137,5138,5139,5140,5141; StartTime=$StartTime; EndTime=$EndTime} | Sort-Object TimeCreated
  1. Document the timeline and context for further investigation or reporting
03

Enable Advanced Registry Auditing

Configure comprehensive registry auditing to capture more detailed information about registry modifications.

  1. Open Group Policy Management Console or Local Group Policy Editor (gpedit.msc)
  2. Navigate to Computer ConfigurationWindows SettingsSecurity SettingsAdvanced Audit Policy ConfigurationAudit PoliciesObject Access
  3. Configure Audit Registry policy:
    • Enable Success and Failure auditing
    • Apply the policy using gpupdate /force
  4. For specific registry key monitoring, configure SACL (System Access Control List) entries:
# Example: Monitor HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
$RegistryPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
$Acl = Get-Acl $RegistryPath
$AccessRule = New-Object System.Security.AccessControl.RegistryAuditRule("Everyone", "Delete,SetValue,CreateSubKey", "None", "None", "Success,Failure")
$Acl.SetAuditRule($AccessRule)
Set-Acl $RegistryPath $Acl
  1. Verify auditing is active by checking the audit policy:
auditpol /get /subcategory:"Registry"
  1. Test the configuration by deleting a test registry value and confirming Event ID 5139 generation
Pro tip: Use Sysmon (System Monitor) alongside Windows auditing for enhanced registry monitoring with additional context and filtering capabilities.
04

Implement Automated Monitoring and Alerting

Set up automated detection and response for suspicious registry value deletions using PowerShell and Windows Task Scheduler.

  1. Create a PowerShell monitoring script:
# Save as Monitor-RegistryDeletions.ps1
param(
    [string]$LogName = "Security",
    [int]$EventId = 5139,
    [int]$MaxEvents = 100
)

$Events = Get-WinEvent -FilterHashtable @{LogName=$LogName; Id=$EventId; StartTime=(Get-Date).AddMinutes(-5)} -ErrorAction SilentlyContinue

foreach ($Event in $Events) {
    $EventXML = [xml]$Event.ToXml()
    $SubjectUserName = $EventXML.Event.EventData.Data | Where-Object {$_.Name -eq "SubjectUserName"} | Select-Object -ExpandProperty "#text"
    $ObjectName = $EventXML.Event.EventData.Data | Where-Object {$_.Name -eq "ObjectName"} | Select-Object -ExpandProperty "#text"
    $ProcessName = $EventXML.Event.EventData.Data | Where-Object {$_.Name -eq "ProcessName"} | Select-Object -ExpandProperty "#text"
    
    # Define suspicious patterns
    $SuspiciousKeys = @(
        "*\\Run*",
        "*\\RunOnce*",
        "*\\Winlogon*",
        "*\\Services*",
        "*\\Policies*"
    )
    
    foreach ($Pattern in $SuspiciousKeys) {
        if ($ObjectName -like $Pattern) {
            $AlertMessage = "ALERT: Suspicious registry deletion detected`nUser: $SubjectUserName`nRegistry: $ObjectName`nProcess: $ProcessName`nTime: $($Event.TimeCreated)"
            Write-EventLog -LogName "Application" -Source "Registry Monitor" -EventId 1001 -EntryType Warning -Message $AlertMessage
            # Send email or trigger additional response actions here
        }
    }
}
  1. Register the script as a scheduled task:
$Action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-ExecutionPolicy Bypass -File C:\Scripts\Monitor-RegistryDeletions.ps1"
$Trigger = New-ScheduledTaskTrigger -Once -At (Get-Date) -RepetitionInterval (New-TimeSpan -Minutes 5) -RepetitionDuration (New-TimeSpan -Days 365)
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable
Register-ScheduledTask -TaskName "Registry Deletion Monitor" -Action $Action -Trigger $Trigger -Settings $Settings -User "SYSTEM"
  1. Create a custom event source for alerts:
New-EventLog -LogName "Application" -Source "Registry Monitor"
  1. Configure Windows Event Forwarding (WEF) for centralized monitoring in enterprise environments
  2. Integrate with SIEM solutions using Windows Event Collector or third-party agents
05

Forensic Analysis and Incident Response

Perform comprehensive forensic analysis when Event ID 5139 indicates potential security incidents or unauthorized modifications.

  1. Collect comprehensive event data for analysis:
# Export security events for forensic analysis
$StartDate = (Get-Date).AddDays(-7)
$EndDate = Get-Date
$ExportPath = "C:\Forensics\SecurityEvents_$(Get-Date -Format 'yyyyMMdd_HHmmss').evtx"

wevtutil epl Security $ExportPath /q:"*[System[TimeCreated[@SystemTime>='$($StartDate.ToString('yyyy-MM-ddTHH:mm:ss.fffZ'))' and @SystemTime<='$($EndDate.ToString('yyyy-MM-ddTHH:mm:ss.fffZ'))']]]"
  1. Analyze registry deletion patterns and correlate with system changes:
# Analyze Event ID 5139 patterns
$RegistryDeletions = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5139; StartTime=$StartDate; EndTime=$EndDate}

$Analysis = $RegistryDeletions | ForEach-Object {
    $EventXML = [xml]$_.ToXml()
    [PSCustomObject]@{
        TimeCreated = $_.TimeCreated
        User = ($EventXML.Event.EventData.Data | Where-Object {$_.Name -eq "SubjectUserName"})."#text"
        RegistryPath = ($EventXML.Event.EventData.Data | Where-Object {$_.Name -eq "ObjectName"})."#text"
        Process = ($EventXML.Event.EventData.Data | Where-Object {$_.Name -eq "ProcessName"})."#text"
        ProcessId = ($EventXML.Event.EventData.Data | Where-Object {$_.Name -eq "ProcessId"})."#text"
    }
}

$Analysis | Group-Object User, Process | Sort-Object Count -Descending | Format-Table Name, Count
  1. Check for registry backup and recovery options:
# Check for System Restore points
Get-ComputerRestorePoint | Sort-Object CreationTime -Descending | Select-Object -First 10

# Examine registry transaction logs
Get-ChildItem "C:\Windows\System32\config\" -Filter "*.LOG*" | Sort-Object LastWriteTime -Descending
  1. Document findings and create incident timeline:
# Generate incident report
$ReportPath = "C:\Forensics\RegistryDeletionReport_$(Get-Date -Format 'yyyyMMdd_HHmmss').html"
$Analysis | ConvertTo-Html -Title "Registry Deletion Analysis" -PreContent "

Registry Deletion Incident Analysis

Generated: $(Get-Date)

" | Out-File $ReportPath
  1. Implement containment measures if malicious activity is suspected:
    • Isolate affected systems from network
    • Preserve evidence using disk imaging tools
    • Reset compromised user credentials
    • Apply additional monitoring and access controls
Warning: During forensic analysis, avoid making changes to the system that could overwrite evidence. Use read-only analysis tools and maintain proper chain of custody documentation.

Overview

Event ID 5139 fires whenever a registry value gets deleted on Windows systems with object access auditing configured. This security audit event captures detailed information about registry modifications, including the specific value deleted, the user account responsible, and the process that performed the deletion. The event appears in the Security log and requires proper audit policy configuration to generate.

This event serves as a critical component of Windows security monitoring, particularly in enterprise environments where registry changes need tracking for compliance or forensic purposes. Unlike registry key deletion events, 5139 specifically tracks individual value deletions within existing keys. The event provides granular visibility into system modifications that could indicate legitimate administrative actions, software uninstallation, or potentially malicious activity attempting to remove traces or disable security features.

Security teams rely on this event to monitor unauthorized registry modifications, track software removal activities, and maintain audit trails for compliance frameworks. The event captures both successful deletions and provides context about the security principal and process involved, making it valuable for incident response and forensic investigations.

Frequently Asked Questions

What does Windows Event ID 5139 mean and when does it occur?+
Event ID 5139 indicates that a registry value has been successfully deleted from the Windows Registry. This security audit event occurs when object access auditing is enabled and captures detailed information about registry modifications, including the user account responsible, the specific registry path affected, and the process that performed the deletion. The event is essential for security monitoring, compliance tracking, and forensic investigations in enterprise environments.
How do I enable auditing to generate Event ID 5139?+
To generate Event ID 5139, you must enable object access auditing through Group Policy. Navigate to Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies → Object Access, then enable 'Audit Registry' for both Success and Failure events. Additionally, you may need to configure System Access Control Lists (SACLs) on specific registry keys you want to monitor. Apply the policy using 'gpupdate /force' and verify with 'auditpol /get /subcategory:Registry'.
Can Event ID 5139 indicate malicious activity?+
Yes, Event ID 5139 can indicate malicious activity, particularly when registry values are deleted from security-critical locations such as Run keys, Winlogon entries, or service configurations. Threat actors often delete registry values to remove persistence mechanisms, disable security software, or cover their tracks during anti-forensics activities. Suspicious patterns include deletions by unexpected processes, deletions during off-hours, or bulk deletions of security-related registry values. Always correlate with other security events and user activity for proper context.
What information is included in Event ID 5139?+
Event ID 5139 contains comprehensive details including the Subject (user account SID, name, domain, and logon ID), Object information (registry key path and value name), Process details (name, ID, and executable path), Access Request information (access rights requested), and timestamp data. The event also includes the Logon ID which can be correlated with logon events (4624/4625) to understand the session context. This detailed information makes it valuable for security analysis and incident response activities.
How can I filter and analyze Event ID 5139 events efficiently?+
Use PowerShell's Get-WinEvent cmdlet with FilterHashtable for efficient filtering: 'Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5139; StartTime=(Get-Date).AddDays(-1)}'. For advanced analysis, parse the XML event data to extract specific fields like user names, registry paths, and process information. You can also use Windows Event Forwarding (WEF) to centralize events from multiple systems, or integrate with SIEM solutions for automated analysis. Consider using Sysmon alongside native Windows auditing for enhanced registry monitoring capabilities with better filtering and correlation features.
Documentation

References (2)

Emanuel DE ALMEIDA
Written by

Emanuel DE ALMEIDA

Senior IT Journalist & Cloud Architect

Microsoft MCSA-certified Cloud Architect | Fortinet-focused. I modernize cloud, hybrid & on-prem infrastructure for reliability, security, performance and cost control - sharing field-tested ops & troubleshooting.

Discussion

Share your thoughts and insights

You must be logged in to comment.

Loading comments...