Hunting Registry Run-Key Persistence with KQL and Splunk: From Write to Execution

A new Windows Run-key value may be routine software setup or an attempt to persist at logon. Hunt the change, identify its author, and look for execution before declaring a compromise.

By Amit Vijayan · Technique & Investigation · Reviewed September 30, 2026

Why it matters

Persistence investigations often fail when a configuration change is treated as proof that a payload ran. This workflow separates the registry write, the referenced target and subsequent process activity. It extends our process-focused threat hunting series with a configuration-to-execution investigation.

Hypothesis: an unexpected process configured a Run or RunOnce value that references an unapproved command or file. The hunt seeks evidence supporting or contradicting that hypothesis; it does not automatically classify every change as malicious.

Enlarge the evidence poster

The expanded poster can be scrolled horizontally on smaller screens. The same information is explained in the investigation steps below.

Telemetry and prerequisites

For Microsoft Defender XDR, this example uses DeviceRegistryEvents, which requires Defender for Endpoint data. Verify available ActionType values in your portal. The selected fields preserve the value, previous data and writing process. Missing telemetry is a visibility limitation, not a clean bill of health.

For Splunk, collect the Sysmon Operational channel with registry value-set events enabled. Sysmon Event 13 identifies a registry value being set; process-creation Event 1 can support investigation of the writer and subsequent execution. Confirm your collection filters, field extraction and retention before relying on the search.

Safety and validation: these are read-only starting points. Test and adapt them only in authorized environments. They have been reviewed against documentation but have not been executed against your tenant. Replace the example index and map fields to your deployment. Restrict access to command lines that may contain sensitive data.

KQL: retrieve candidate Run-key changes

DeviceRegistryEvents
| where Timestamp > ago(24h)
| where RegistryKey endswith @"\Software\Microsoft\Windows\CurrentVersion\Run"
    or RegistryKey endswith @"\Software\Microsoft\Windows\CurrentVersion\RunOnce"
| project Timestamp, DeviceId, DeviceName, ActionType,
    RegistryKey, RegistryValueName, RegistryValueData,
    PreviousRegistryValueData, InitiatingProcessAccountName,
    InitiatingProcessFileName, InitiatingProcessCommandLine,
    InitiatingProcessId, InitiatingProcessCreationTime
| order by Timestamp desc
| take 200

The suffix filter targets the two named keys, including paths with a preceding registry hive or architecture-specific segment. It is not a comprehensive hunt for every autostart mechanism. Because the query does not constrain ActionType, inspect the returned action before describing a row as a new value. The latest 200 rows are a triage sample; remove or paginate the cap when scoping the full population.

Splunk SPL: retrieve registry value-set candidates

index=YOUR_SYSMON_INDEX EventCode=13 earliest=-24h latest=now
| eval target=lower(TargetObject)
| where like(target,"%currentversion%run%")
| table _time Computer User Image ProcessGuid TargetObject Details
| sort 0 - _time
| head 200

This deliberately broad text filter can also match similarly named paths. Verify that each TargetObject belongs to the exact Run or RunOnce key and identify its value name before keeping it in scope. The field called Computer may be named differently in your ingestion pipeline. Details can be incomplete for some data types; retrieve the raw event and authorized registry evidence when necessary. These KQL and SPL searches use different sources and are not expected to produce identical counts.

A step-by-step investigation

1. Preserve the original event. Record event time, device identity, registry path, value name, value data, writer process and account. Retain raw evidence and note collection gaps. Resolve time-zone differences before correlating systems.
2. Explain the writer. Pivot to the writing process using device identity and ProcessGuid where available, or process ID plus creation time. A PID alone can be reused. Review its parent, command line, installation context and the associated change record.
3. Resolve the target safely. Interpret quoting, arguments and environment variables without executing the command. Determine the referenced file path and collect approved metadata, hash, signature and provenance. A familiar filename or valid signature alone is not proof of authorization.
4. Seek execution evidence. Search process telemetry around the relevant logon and beyond the write. Compare the resolved target and command line. A registry value can remain unused, reference a missing file or be removed before execution; document those alternatives.
5. Scope related behavior. Check descendants, file writes and network activity using process identity and time. Search for the same target hash, value data or writer across the estate, then compare affected devices with software deployment records.
6. Reach a bounded conclusion. State whether you observed only configuration, verified execution, or corroborating malicious activity. Keep unknowns explicit and assign follow-up owners.

Two worked examples

Both examples are fictional teaching scenarios, not reports of real incidents.

Expected deployment: an approved installer creates a vendor updater Run value on a scheduled set of workstations. The package source, file signature, deployment record and observed target execution agree. Document the evidence and create a narrow exception with a review date.

Escalation candidate: a script launched from a user download folder writes a Run value referencing a newly created executable. Subsequent logon telemetry shows that file starting and contacting an unapproved destination. Preserve the evidence and escalate the combined sequence. The writable folder or network destination alone does not establish maliciousness.

Tuning and response

Baseline by software package, writer, target, device group and change window. Avoid permanent exclusions based only on a value name such as Update. Review exceptions after product changes and retain enough sampled events to detect a previously approved path changing behavior.

Coordinate containment with the incident lead and system owner when corroborating evidence warrants it. Preserve registry and file evidence before authorized removal. Removing a value addresses one mechanism; investigate the initial execution path, related accounts and other persistence. Do not reboot or launch an unknown target simply to see whether it runs.

ATT&CK mapping and key takeaways

MITRE ATT&CK T1547.001 covers Registry Run Keys / Startup Folder. Apply the mapping when the evidence supports abuse of this mechanism, not merely because a legitimate application writes a Run value.

• A registry change, a referenced file and observed execution are separate facts.
• Correlate with stable process identity and deployment context.
• Report collection gaps and untested assumptions alongside findings.

Continue with PowerShell investigations with KQL and Splunk or browse the Knowledge Base.

Sources reviewed September 30, 2026: Microsoft DeviceRegistryEvents schema, Microsoft Sysmon documentation and MITRE ATT&CK T1547.001, linked above.