A junior analyst pings you mid-shift with a screenshot: a new value under HKCU\...\Run pointing at a script sitting in AppData, flagged an hour after a phishing email got opened on a laptop in accounting. "Is this bad?" they ask. It's a fair question, and also the 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 was not 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 an attacker roughly three tiers of persistence to choose from, 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 exactly why commodity loaders and opportunistic phishing payloads default to it: it's the mechanism available to an attacker who has precisely 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 and simplicity at the cost of being the first thing any halfway-competent 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 a logon, on a timer, on system idle, or on a specific event, and critically it survives a password change in a way a Run key tied to a live session doesn't. Setting up a task that runs 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 the presence of a SYSTEM-context scheduled task is itself a data point: whoever planted it either already had local admin on that box, or exploited something on it to get there before setting up persistence. That's a materially different incident than a Run key dropped by a payload that never got past standard-user rights.
A Windows service is the most committed option 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, not because of it. Services also survive reboots more reliably than either alternative and start before any user ever logs in, which is exactly why ransomware operators and anyone planning to stay for a while favor them. It's also the loudest of the three from a detection standpoint: a new service is logged (Windows Event ID 7045 among others), and because legitimate software installs are the overwhelming majority of new-service events, security teams that actually review that log get a real signal, not noise.
Line those three up against each other and the persistence mechanism itself becomes a rough timestamp for the attacker's privilege level at the moment they planted it. A Run key means: assume they had user context and probably nothing more, which narrows your scoping question to that one account and that one session. A SYSTEM-level scheduled task or a new service means: assume local admin was already achieved, which means your 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 superficially similar in an EDR console, "a new persistence mechanism," point at completely different incident sizes.
Most introductory malware analysis material treats these mechanisms as a memorization exercise: T1547.001, T1053.005, T1543.003, a MITRE ATT&CK ID each and a one-line description. That's necessary but it isn't the actual skill. The skill is being able to look at which one an attacker used and immediately answer "given this, what do I already know about how far they'd gotten, and what do I still need to go check," in real time, mid-triage, before the rest of the timeline is built.
That's the exact 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 instead of memorizing the individual pieces. If you want the hands-on half before the reading, the free C2 Beacon lab on codelivly.com puts you in front of the traffic-pattern side of the same reasoning.
Top comments (0)