Lesson 10 — Investigating DeviceRegistryEvents
Registry events show what configuration keys and values were created, modified or deleted on a Windows endpoint.
Microsoft Defender for Endpoint exposes this activity through DeviceRegistryEvents, allowing analysts to investigate persistence, startup changes, security tampering and configuration abuse.
This lesson explains how to connect registry activity with the process, command line, user and timeline that caused it.
What you will learn
This lesson explains how to investigate Windows registry activity using DeviceRegistryEvents.
Learning objectives
After completing this lesson, you should be able to investigate registry activity using Defender for Endpoint telemetry.
- Explain what DeviceRegistryEvents records.
- Interpret registry keys, value names, value data and action types.
- Identify the process and user responsible for a registry change.
- Recognise persistence, startup abuse and security tampering.
- Correlate registry activity with process, file and timeline evidence.
The problem this solves
A registry change can be legitimate administration, application configuration or attacker persistence.
DeviceRegistryEvents connects the change to the process, command line, user and device that caused it.
What is DeviceRegistryEvents?
DeviceRegistryEvents is the Advanced Hunting table used to investigate Windows registry activity observed on endpoints.
It records creation, modification and deletion of keys and values together with the initiating process and related context.
Do not judge a registry path alone. Identify what changed, which process changed it and what happened immediately before and after.
How registry activity becomes evidence
Why registry telemetry matters
The Windows registry stores configuration for the operating system, applications, users and security controls.
Attackers can abuse it for persistence, execution, privilege escalation and defence evasion.
Timestamp
The timestamp shows when the registry operation occurred.
Correlate it with process creation, file activity and alerts to place the change within the attack sequence.
DeviceName
DeviceName identifies the endpoint where the registry activity occurred.
Check whether the device is high value, risky or involved in related incidents.
RegistryKey
RegistryKey identifies the path that was affected.
The path can reveal startup configuration, services, security settings or application behaviour.
RegistryValueName
RegistryValueName identifies the specific value changed within the key.
Unexpected value names may indicate persistence, hijacking or configuration abuse.
RegistryValueData
RegistryValueData shows the content written to the value.
Executable paths, script commands, URLs and suspicious arguments can expose attacker intent.
ActionType
ActionType describes what happened to the key or value.
Common actions include creation, modification and deletion.
Common registry actions
| Action | Investigation meaning |
|---|---|
| RegistryKeyCreated | A new registry key appeared. |
| RegistryValueSet | A value was created or modified. |
| RegistryValueDeleted | A registry value was removed. |
| RegistryKeyDeleted | An entire key was removed. |
Registry hives
Common hives include HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER and HKEY_USERS.
Machine-wide changes may affect every user, while user-specific changes may target one profile.
HKLM versus HKCU
HKLM changes often require elevated privileges and affect the system.
HKCU changes can provide user-level persistence without administrative access.
Run keys
Run and RunOnce keys can automatically launch programs when a user signs in.
Unexpected executable or script paths in these locations should be investigated immediately.
Startup persistence
Attackers may use registry locations associated with startup, logon or shell execution.
Correlate the value data with file existence and process execution.
Services
Service configuration is stored in the registry.
New or modified service image paths can indicate persistence or privilege escalation.
Image File Execution Options
Image File Execution Options can be abused for debugging, redirection or persistence.
Unexpected debugger values deserve close review.
Shell and userinit changes
Shell and userinit values influence what starts during user logon.
Modification can provide powerful persistence and may affect every session.
File association hijacking
Registry changes can alter which program opens a file type.
Attackers may use this to execute malicious code when a user opens a common document or shortcut.
COM hijacking
COM registration changes can redirect legitimate applications to attacker-controlled code.
Review class identifiers, in-process server paths and initiating processes.
Security control tampering
Attackers may change registry values related to antivirus, firewall, logging or security policies.
Unexpected changes by script engines or unknown binaries should be treated seriously.
Example persistence sequence
InitiatingProcessFileName
This field identifies the process responsible for the registry action.
It often provides the strongest clue about whether the change was legitimate administration or malicious activity.
InitiatingProcessCommandLine
The initiating command line can reveal reg.exe commands, PowerShell registry operations or script-based changes.
Read it together with the key path and value data.
Initiating process account
Account fields identify the user or security context responsible for the registry change.
Determine whether the process ran as a standard user, administrator, service account or SYSTEM.
Integrity and privilege
Machine-wide registry changes often require elevated rights.
Unexpected high-integrity or SYSTEM activity may indicate privilege escalation or service abuse.
reg.exe
reg.exe is a legitimate Windows utility for registry management.
Its command line, parent process and target key determine whether its use is expected.
PowerShell registry changes
PowerShell can create and modify keys and values through cmdlets and providers.
Review scripts, encoded commands and whether the activity aligns with approved administration.
Scripted configuration changes
Deployment tools and management platforms may legitimately modify the registry at scale.
Validate the source process, account, change window and expected target devices.
Registry deletion
Deletion may represent cleanup, security control removal or normal software uninstallation.
Use timeline context to determine the purpose.
Registry value data types
Registry data may be stored as strings, expandable strings, binary data or numeric values.
Understanding the type helps interpret how Windows or an application will use the value.
Environment variables
Expandable strings may include variables such as %TEMP% or %APPDATA%.
Resolve the final path when determining what will execute.
Example tampering sequence
Pivot to DeviceProcessEvents
Investigate the process that created, modified or deleted the registry value.
Review its command line, parent process, user, hash and child processes.
Pivot to DeviceFileEvents
Check whether the registry value references a newly created or suspicious file.
This can connect persistence configuration with the payload stored on disk.
Pivot to DeviceNetworkEvents
Determine whether the initiating process communicated externally or laterally.
This can connect registry persistence with command-and-control or payload delivery.
Pivot to the Device Timeline
The timeline shows registry activity alongside process, file, network and logon events.
Use it to reconstruct what happened before and after the change.
Search across devices
Use the key path, value name, value data and initiating process to search for the same pattern elsewhere.
This helps determine whether the activity is isolated or part of a broader campaign.
Baseline expected activity
Many enterprise tools modify the registry legitimately.
Maintain awareness of normal management, deployment and application behaviour to reduce false positives.
Registry investigation workflow
Common mistake
A common mistake is treating every run key change as malicious.
Legitimate applications and management tools also use startup locations.
Another common mistake
Do not ignore the value data or initiating process.
These fields usually explain what will execute and who created the persistence.
Agent Foskett investigation tip
Follow the key and value back to the process that created them, then confirm whether the referenced payload executed or changed security behaviour.
Best practices
- Review the full registry path.
- Read the value name and data.
- Identify the initiating process and user.
- Check for referenced files or scripts.
- Correlate process, file and timeline activity.
- Search for the same change across devices.
Agent Foskett takeaway
Registry telemetry explains how Windows configuration changed and whether that change created persistence or weakened security.
DeviceRegistryEvents helps analysts connect keys and values with the process, user and payload responsible.
Related Agent Foskett learning
Continue learning
Microsoft Defender for Endpoint DeviceRegistryEvents
DeviceRegistryEvents records registry key and value creation, modification and deletion, including registry paths, value names, value data, action types, initiating processes, command lines and user context.
Module 2 Endpoint Telemetry — DeviceRegistryEvents Lesson 10
This Agent Foskett Defender for Endpoint Academy lesson explains how analysts investigate persistence, run keys, service configuration, startup abuse, security control tampering and suspicious registry changes.
