Guided lab: find the Run key before it finds you

This is a lab for people who have read about persistence and have not yet gone looking for any. There is no scoreboard and nothing to submit. Work through the questions, open a hint when you are stuck, and stop when you can explain your answer to somebody else.

You will need a Windows virtual machine you can throw away. Not your laptop, not anything joined to a domain you care about. Everything here is reversible, but the habit of testing on a machine that does not matter is the one worth building first.

What you are simulating

An attacker who already has code execution on a workstation wants to survive a reboot. The cheapest way is a registry Run key. Windows reads these keys at logon and starts whatever they point at, which is a feature that has existed since Windows 95 and is used by legitimate software constantly. That last part is what makes it interesting: the technique hides in a place that is genuinely busy.

[>] BOOT OR LOGON AUTOSTART EXECUTION: REGISTRY RUN KEYS · T1547.001

The keys that matter most:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKLM\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce

HKCU runs for one user and needs no administrative rights. HKLM runs for everyone and does. That difference tells you something about the attacker before you have found anything else.

Set up

Install Sysmon with a configuration that logs registry events, and Atomic Red Team for the emulation. Both are free and public:

Sysmon, from Microsoft Sysinternals
SwiftOnSecurity's Sysmon config, a sane starting point
Atomic Red Team, Red Canary's library of small tests mapped to ATT&CK

Open the Atomic Red Team entry for T1547.001 and read the tests before you run anything. Each one tells you exactly what it will do and how to undo it. Pick one that writes to HKCU. Run it. Then come back here.

The investigation

Without using the registry editor, prove that something was added to a Run key. Which log source told you, and which event did it produce?

Stuck? Where to look

You installed Sysmon for a reason. It logs registry activity as its own event types, separate from anything Windows records by default.

Show me the method

Look in Applications and Services Logs → Microsoft → Windows → Sysmon → Operational. Filter by event ID. Sysmon splits registry activity into three: object created or deleted, value set, and key renamed.

Show the answer

Sysmon Event ID 13, "Registry value set." It records the full key path, the value written, and critically the process that wrote it.

Event ID 12 covers creation and deletion of keys, and 14 covers renames. A Run key entry is usually a value written to a key that already exists, so 13 is the one that fires. If you filtered on 12 and found nothing, that is why.

Which process wrote the value, and what was its parent? Why does the parent matter more than the process itself?

Stuck? Where to look

The event from Q1 names the writing process. To get its parent you need a different event, correlated on the same process GUID.

Show me the method

Take the ProcessGuid from the Event ID 13 and search the log for the Event ID 1 (process creation) carrying the same GUID. That gives you the full command line and the parent.

Show the answer

It will be reg.exe or powershell.exe, depending on which atomic you chose. On its own that means very little, because both run legitimately thousands of times a day.

The parent is what carries the signal. powershell.exe spawned by explorer.exe is a person opening PowerShell. powershell.exe spawned by winword.exe or outlook.exe is a document doing it, and that is worth waking someone up for. Detections built on the child process alone drown; detections built on the ancestry survive.

Now find the same persistence a second way, without touching the event log at all. What did you use, and what can this method see that Sysmon cannot?

Stuck? Where to look

If the logs were rotated, or Sysmon was installed after the attacker arrived, you would still need to answer "what starts on this machine?"

Show me the method

Sysinternals Autoruns enumerates every autostart location Windows has, not just Run keys. Run it, and check the option that hides Microsoft-signed entries.

Show the answer

Autoruns shows current state rather than history, which is exactly the difference. Sysmon tells you what happened and when, but only for the window it was running. Autoruns tells you what is there right now, including persistence planted before your logging existed.

Neither replaces the other. State without history cannot tell you when or by whom. History without state misses everything that predates your sensor.

Windows can log registry changes without Sysmon. Why did you probably see nothing in the Security log?

Stuck? Where to look

The capability exists but is not on by default, and turning it on takes two steps rather than one.

Show me the method

Look up Event ID 4657, and what has to be configured on a specific registry key before it will ever be written.

Show the answer

Event ID 4657, "A registry value was modified." It requires two things: the audit policy for registry access enabled, and a SACL set on the specific key you want audited. Neither is on by default.

This is worth knowing because it is a common interview question and a common production gap. An organisation that believes it is auditing the registry, but never set the SACLs, is auditing nothing. Check rather than assume.

Write a detection. What would you alert on, and what would that alert cost you in false positives?

Stuck? Where to look

Start from the Event ID 13 you found, then think about who else legitimately writes to Run keys on a normal day.

Show the answer

A workable first rule: Sysmon Event ID 13 where TargetObject contains CurrentVersion\Run and the writing process is not a known installer.

Then the honest part. Legitimate software writes Run keys during installation and updates constantly, so the naive version of this rule fires all day. The tuning that makes it usable is not a longer allowlist of process names, which an attacker can simply match. It is ancestry: alert when the writer's parent is a browser, an email client, or an Office application, because software installers are not started by Outlook.

That is the general shape of the lesson. The registry write is the artifact. The process tree is the evidence. Detections built on the artifact alone generate noise; detections built on how the artifact came to exist generate alerts someone will actually read.

Clean up

Roll back the snapshot, or use the cleanup command the atomic gives you. Then run Autoruns once more and confirm the entry is gone. Verifying your own cleanup is the habit, not an optional extra.

What you now know

You found one persistence technique three ways, and you can say what each method sees and misses. That distinction between state and history, and the observation that ancestry beats process name, are the two things that transfer to nearly every other technique you will look at next.

What you are simulating

Set up

The investigation

Clean up

What you now know

Discussion