System Configuration: Persistence & Shutdown
- Mar 30, 2024
- 4 min read
Updated: 4 days ago
Two questions sit at the heart of almost every malware investigation: how did it survive a reboot? And when did the machine actually go offline?
The first question leads you into one of the most abused corners of the Windows operating system — autostart locations. The second leads you to a single registry value that quietly timestamps every clean shutdown the machine has ever had.
Neither topic is glamorous. Both are essential.
-------------------------------------------------------------------------------------------------------------
The Persistence Problem
Here's the challenge with Windows autostart locations: there are a lot of them.
Security researchers have catalogued well over 50 distinct places — called AutoStart Extension Points or ASEPs — where a program can register itself to survive a reboot. A piece of malware only needs one of them to work.
The good news is that the most commonly abused ASEPs live in the registry, which at least consolidates the search. The most popular persistence locations on the planet are the Run keys — a small family of registry entries whose entire purpose is to launch applications automatically when a user logs on.
Notice that distinction: these keys fire at user logon, not at system boot. That's an important nuance when you're trying to understand the execution timeline of a compromised system.
-------------------------------------------------------------------------------------------------------------
Reading the Run Keys: Normal vs. Suspicious
When you pull up a Run key and see its contents, you're essentially looking at a list of everything that launches the moment a user signs into Windows. Most of it will be mundane — cloud storage clients, hardware utilities, update checkers. The skill is spotting the thing that doesn't belong.
The services key is a harder problem.
A well-used Windows system can have 500+ service entries. No analyst manually reads all of them — and attackers know this. Malicious services are often named to sound boring and official. What gives them away isn't the name: it's the executable path.
Legitimate Windows services do not run from %TEMP% folders.
They do not live in random subdirectories with names that don't correspond to their supposed function. The path is almost always the tell.
-------------------------------------------------------------------------------------------------------------
Windows Services: Persistence with System Privileges
Services are the second most common malware persistence mechanism in the wild — and arguably the more dangerous one. Unlike Run keys, which fire at user logon, services start at system boot, often before any user account is active, and run with elevated privileges in the background.
The registry entry that governs all of this is:
SYSTEM\<CurrentControlSet>\ServicesEvery service and every device driver on the system has a subkey here. The key values tell you the service's display name, the path to its executable (ImagePath), its start type, the privileges it requires, and its dependencies.
For persistence hunting, the two start values that matter are
0x02 (Automatic — starts at boot)
0x00 (Boot start driver — starts even earlier).
The problem is volume. A heavily used Windows system can have 500 or more service entries. Manual review is impractical. The Registry Explorer Services plugin pulls all entries into a filterable table — filter for Start values of 0x02 and 0x00, then scrutinize the ImagePath values for anything pointing outside of expected system directories.
-------------------------------------------------------------------------------------------------------------
Shutdown Information: The Machine's Last Words
Shift gears entirely. After the complexity of autostart analysis, this one is refreshingly simple — but it earns its place in every investigation.
The registry records the last time the system shut down cleanly. This single timestamp, stored at:
SYSTEM\<CurrentControlSet>\Control\Windows...can answer questions that nothing else can quite answer as directly.
How long has this machine been running?
Was it powered on during the period being investigated?
Did the user shut it down before handing it over — and if so, when?
Does the shutdown time coincide suspiciously with an event you're investigating?
-------------------------------------------------------------------------------------------------------------
Why Shutdown Time Matters More Than It Looks
The Shimcache dependency is the one that makes shutdown time forensically critical beyond just confirming basic facts.
Shimcache — the Application Compatibility Cache — is one of the most useful program execution artifacts in Windows forensics. It records applications that have been run on the system, and it's written to disk only when the machine shuts down cleanly.
If the machine has been running for three weeks without a shutdown, Shimcache's registry entry is three weeks out of date. The most recent execution data lives only in memory. You need the shutdown time to know whether Shimcache is trustworthy, incomplete, or essentially useless for the period you care about.
Similarly, when capturing a memory image from a live system, knowing how long the machine has been running tells you how far back in time that memory might stretch. A machine that booted this morning has shallow memory. A machine that's been running for a month has deep, rich volatile data that could be invaluable — if you capture it before the next reboot wipes it.
-------------------------------------------------------------------------------------------------------------
Putting It Together
Autostart locations and shutdown information seem like opposite ends of the spectrum — one is about things that persistently run, the other is about a single moment in time. But they're connected by the same underlying investigation logic: understanding the lifecycle of the machine.
What was running on this system
how did it survive reboots
when was the machine last powered down — these questions together tell you whether you're looking at a healthy system, a compromised one, or a machine that someone tried to clean up in a hurry before handing it over.
The registry will tell you. You just have to know where to look — and now you do.
-------------------------------------------------------------------------------------------------------------
Full Series Below
Comments