What a malware's persistence mechanism actually tells you about the attacker

A junior analyst pings you mid-shift with a screenshot: a new value under HKCU...\Run pointing at a script in AppData, flagged an hour after a phishing email got opened on a laptop in accounting. "Is this bad?" they ask. Fair question, wrong one to lead with, because the value by itself says almost nothing. What actually matters is which persistence mechanism the attacker reached for, because that choice wasn't random. It was constrained by what they already had access to at the moment they made it, and reading that constraint backwards tells you how far they'd already gotten before this alert ever fired.

Windows gives roughly three tiers of persistence, and each one costs something different to set up and reveals something different about what came before it.

A Run key (HKCU\Software\Microsoft\Windows\CurrentVersion\Run or its HKLM sibling) is the cheapest option there is. Writing to the HKCU branch needs nothing beyond the privileges of whatever user context the payload is already running in, no elevation, no admin token, nothing. That's why commodity loaders and opportunistic phishing payloads default to it: it's what's available to an attacker who has exactly one thing, code execution as a regular user, and nothing else yet. It's also the most heavily watched artifact in Windows telemetry, so it buys speed at the cost of being the first thing any decent EDR product flags.

A scheduled task is a step up in both capability and what it implies. schtasks.exe or the Task Scheduler API can register a job that fires on logon, on a timer, on idle, or on a specific event, and it survives a password change in a way a Run key tied to a live session doesn't. A task running as the current user still needs nothing more than that user's own rights, but a task configured to run as SYSTEM needs local admin at creation time. So a SYSTEM-context scheduled task is itself a data point: whoever planted it already had local admin before persistence entered the picture, not because of it.

A Windows service is the most committed of the three, and the most revealing. sc create needs admin rights, full stop, and a service installed to run at boot means the attacker had that admin token before persistence ever entered the picture. Services survive reboots more reliably than either alternative and start before any user logs in, which is why ransomware operators favor them. It's also the loudest of the three: a new service gets logged (Windows Event ID 7045 among others), and because legitimate installs are the overwhelming majority of new-service events, a team that actually reviews that log gets a real signal.

Line those three up and the persistence mechanism becomes a rough timestamp for the attacker's privilege at the moment they planted it. A Run key means assume user context and nothing more, which narrows your scoping question to that one account and session. A SYSTEM-level task or a new service means assume local admin was already achieved, which means the scoping question isn't "did they get more access," it's "what did they already do with the access they had before you ever saw this alert." Two artifacts that look the same in an EDR console, "a new persistence mechanism," point at completely different incident sizes.

Most introductory malware analysis material treats these as a memorization exercise: an ATT&CK ID and a one-line description each. That's necessary but it isn't the actual skill. The skill is looking at which mechanism got used and immediately answering what you already know about how far they'd gotten, mid-triage, before the rest of the timeline is built.

That's the ground Codelivly's Malware Analysis Book for Beginners covers: malware families, the persistence choices they actually make, and how C2 traffic patterns fit into reading the whole picture. The free C2 Beacon lab on codelivly.com puts you in front of the traffic-pattern side of the same reasoning if you want the hands-on half first.