Windows persistence collapses to a few places: audit first, then diff

The scenario is fictional. Commands and event IDs come from the book and aren't tested here; use a test environment first. Detection only.

On Linux we audited keys and cron. Windows follows the same logic. Remember one line from part 7:

09:13:05 Sysmon E13 Run key "Updater" created 

That was 23 seconds after lsass was read.

What you'll learn

• Persistence points grouped into a few families
• Auditing that catches the moment of write
• Baseline diffs for inventory
• Why you preserve before you clean

Persistence families

Enable auditing first

auditpol /set /subcategory:"Other Object Access Events" /success:enable /failure:enable auditpol /set /category:"Account Management" /success:enable /failure:enable # Sysmon: include registry (13), WMI (19/20/21), file create (11) in the config 

By default these aren't recorded: not "no logs", just "not logging".

Baseline diff

Save a normal-time list of Run keys, startup items, services, tasks and WMI subscriptions; diff later. Autoruns-style output works well.

Normal vs. attack

Attacks come from powershell/rundll32/unfamiliar binaries, use generic names like Updater, run from C:\Users\Public\, and appear seconds to minutes after intrusion.

Preserve, then clean

Export and hash the key/task/WMI object first, trace the origin, then remove (book examples):

Unregister-ScheduledTask -TaskName "SystemUpdater" -Confirm:$false Remove-WmiObject -InputObject $filter; Remove-WmiObject -InputObject $consumer 

Keep monitoring for re-planting.

Defense priorities

Baseline plus periodic diff; minimal write rights on persistence points; FIM and Sysmon everywhere; application control against unsigned execution from temp paths.

Next: the history that survived history -c.

Adapted from chapter 26 of my Japanese book on server defense.