Windows Persistence Detection: How Attackers Stay Hidden (Real Cases & MITRE Mapping)
- DFIRHive
- Nov 1
- 10 min read
If there’s one thing every investigation eventually circles back to, it’s persistence.
Attackers don’t just want to get in — they want to stay in. It’s one of the first things they think about once they have a foothold: “How do I make sure I can come back, even if they find me?” That’s what persistence is all about.
In the MITRE ATT&CK framework, it’s listed under TA0003 — Persistence, and it often goes hand in hand with Command and Control (TA0011).After all, staying inside a system is pointless unless you have a way to reach it again.
Persistence isn’t loud or dramatic. It hides in the background — a scheduled task, a registry key, a startup script, or sometimes, a new account that looks almost legitimate. We don’t always see it at first glance, but it’s what allows an attacker to quietly maintain control for weeks or even months.
We’ve seen it time and again — in APT29’s phishing campaigns, APT28’s use of task schedulers, Volt Typhoon’s long-term access into critical systems, and even in Kraken’s multi-layered botnet infrastructure.
Each of these operations had one thing in common: the attackers didn’t just compromise a system — they made sure it would remember them.
So, let’s break down how persistence really works — the methods attackers use, what they look like in Windows logs, and how those small traces can help us spot them before the damage is done.
Command & Control — The Attacker’s Connection Home
Before persistence, attackers need a way to talk to the compromised system — a C2 (Command-and-Control) channel. It’s how they send new payloads, exfiltrate data, or trigger follow-up actions.
Case 1 — APT29 (Cozy Bear): Living C2 Inside Trusted Cloud Traffic
APT29’s campaigns, documented by Google TAG , shows how refined their C2 operations have become.
Instead of deploying obvious malware, they rely on legitimate cloud APIs and encoded communications.
In one 2022 campaign, a malicious DOCX delivered an HTA dropper that executed BEATDROP, a downloader written in C that communicated through Trello’s API.
Each infected host was assigned a unique victim ID and registered on a Trello board controlled by the attackers — effectively turning Trello into their C2 management platform.
From there, BEATDROP fetched commands and payloads (such as Cobalt Strike Beacons) entirely through HTTPS, masking all traffic as normal SaaS activity.
Case 2 — Volt Typhoon: C2 Without Malware
While APT29 hides within cloud APIs, Volt Typhoon (a China-nexus group) takes it a step further — no malware at all.
According to Microsoft’s report, Volt Typhoon achieved persistent C2 access using living-off-the-land binaries (LOLBins) such as PowerShell, wmic, and netsh.
They hijacked existing legitimate tools to tunnel data out of networks, even creating reverse proxies through compromised edge devices like routers and firewalls.
In other words, the C2 was the network itself.
Case 3 — FIN7 & Ransomware Operators: Beaconing Through Cobalt Strike
Groups like FIN7, LockBit, and BlackCat have standardized Cobalt Strike and Brute Ratel for C2 operations. Unlike APT campaigns, these are monetization-driven — beacon intervals are shorter, and payloads often run directly on endpoints.
Cobalt Strike’s flexibility allows them to:
Rotate domains frequently
Chain redirects through content delivery networks
Use HTTPS and DNS beacons to evade simple firewall detection
How to Detect Command & Control
Whether it’s APT29 hiding in cloud traffic or Volt Typhoon blending into legitimate binaries, defenders must rely on behavioral correlation — not static indicators — to expose persistence and control channels.”
Detection:
Source | Indicator | Description |
Sysmon 1 (Process Create) | Suspicious command-line flags (-enc, -nop, hidden windows) | Common in encoded PowerShell or mshta C2 loaders |
Sysmon 3 (Network Connect) | Outbound HTTPS/DNS to rare or recently registered domains | Possible C2 over web or DNS protocols |
Security 5156 (Filtering Platform) | Allowed outbound connections from non-standard parent processes | Example: Outlook spawning PowerShell or mshta |
Proxy / Firewall Logs | Consistent beaconing intervals (every 30–90 seconds) | Indicates automated C2 heartbeat traffic |
EDR / Memory Scans | Mapped ntdll.dll, injected threads, or self-signed TLS certs | Indicators of in-memory C2 frameworks |
Threat Intel Feeds | Known Trello, OneDrive, Dropbox, or CDN abuse patterns | Matches with cloud-based C2 infrastructure |
Persistence:
Once an attacker has a foothold, the next priority is simple — don’t lose it.
Persistence ensures continued access even if credentials are reset, systems reboot, or security tools are updated. Some techniques are noisy, like creating new users or services; others quietly blend into system behavior through scheduled tasks or registry keys.
Here are a few persistence mechanisms that frequently appear in investigations — and how real-world threat groups have used them.
Scheduled Tasks & Services
Scheduled Tasks were built for maintenance — attackers simply use them to make their malware persistent and reboot-resistant.
Case 1 — APT28 (Fancy Bear): Zebrocy’s Scheduled Task Auto-Reload
APT28, also known as Fancy Bear, used this technique in its 2020 Zebrocy campaign analyzed by QuoIntelligence.
After a NATO-themed spear-phishing document executed, the malware dropped a copy of itself to:
%AppData%\Roaming\Service\12345678\sqlservice.exe
Next — “the malware creates a new scheduled task, and it is executed with the /s parameter.” That task quietly relaunched the implant and performed HTTP POSTs about once per minute to:
hxxp://194.32.78[.]245/protect/get-upd-id[.]php
Each minute, the task invoked the binary, keeping the backdoor alive even after restarts or crashes. To defenders, it looked like ordinary Windows automation.
Case 2 — APT41: Persistence by Modifying SYSTEM Tasks
Google Cloud / Mandiant documented how APT41 — a China-nexus group — achieved stealth persistence not by creating new tasks, but by editing trusted Windows tasks already running as SYSTEM.
The attackers used a literal command captured by investigators:
SCHTASKS /Change /tn "\Microsoft\Windows\PLA\Server Manager Performance Monitor" ^
/TR "C:\windows\system32\rundll32.exe SHELL32.DLL,ShellExec_RunDLLA C:\windows\system32\msiexec.exe /Z c:\programdata\S-1-5-18.dat" ^
/RL HIGHEST /RU "" /ENABLE
They replaced legitimate task actions with malicious loaders, turning Windows itself into their persistence engine. Other modified tasks included:
\Microsoft\Windows\Ras\ManagerMobility
\Microsoft\Windows\WDI\SrvSetupResults
\Microsoft\Windows\WDI\USOShared
Because those tasks already executed at startup under SYSTEM privileges, APT41 gained high-level persistence without creating anything visibly “new.”
How to Detect Scheduled Task Persistence:
Persistence via Scheduled Tasks often looks legitimate — especially when attackers mimic Windows maintenance jobs or modify existing system tasks.
Detection requires correlating process creation, task configuration changes, and unusual file paths across multiple data sources.
Detection:
Source | Indicator | Description |
Sysmon 1 (Process Create) | schtasks.exe / schtasks /Change / schtasks /Create executed by user apps | Task scheduler invoked by winword.exe, mshta.exe, explorer.exe or other non-admin parents — suspicious creator/parentage. |
Sysmon 11 (File Create) | Writes to C:\Windows\System32\Tasks\* or task XMLs in user folders | New/modified task XMLs — indicates task creation or action replacement (APT41-style). |
Task Scheduler Operational (106 / 140 / 141) | Task created / action changed / task enabled | Direct Task Scheduler log of creation/modification — catches /Change operations. |
Windows Security 4698 / 4699 / 4700 | Scheduled task created / deleted / enabled | Alert on tasks with system-like names pointing to %AppData% / %ProgramData% or unsigned binaries. |
Network / Proxy Logs | Consistent periodic outbound connections (e.g., 30–90s or ~1/min) | Regular beaconing from scheduled executions (example: Zebrocy ≈1/min to 194.32.78[.]245). |
MITRE Mapping: Windows Service Persistence — T1543.003
Registry Run Keys & Startup Folders
Registry-based persistence feels old-school, but it still works flawlessly.Attackers often add entries under:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
This ensures their payload executes automatically every time the user logs in.
Case — Lumma Stealer
Trend Micro’s analysis of the Lumma Stealer campaign revealed a straightforward persistence method built entirely on native Windows features.
Delivered through GitHub releases posing as legitimate software, the stealer achieved re-execution at every logon by abusing two common autostart mechanisms.
After infection, investigators observed “persistence being established through the Startup folder”, while registry entries under the Run key were also used to auto-launch the payload.
Persistence paths noted in the report:
%AppData%\Microsoft\Windows\Start Menu\Programs\Startup\
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
The combination of GitHub-based delivery and trusted Windows autostart mechanisms ensured reliable, low-profile persistence.Every time the user signed in, Lumma Stealer relaunched — no privilege escalation or complex loader needed.
Detection:
Source | Indicator | Description |
Sysmon 13 (Registry Set) | New or modified values under HKCU\...\Run | Detect Run-key autostart additions. |
Sysmon 11 (File Create) | New executables or shortcuts in %AppData%\...\Startup\ | Monitor Startup-folder file creation. |
Security 4688 / 4698 | reg.exe or PowerShell modifying Run keys | Identify user-level persistence creation. |
MITRE Mapping: Boot or Logon Autostart Execution — T1547.001
Account Creation & Privilege Abuse
Creating or abusing privileged accounts remains one of the simplest — yet most effective — persistence methods attackers use after gaining administrative access.
Case — Conti Ransomware
In The DFIR Report’s detailed analysis of a Conti intrusion (source), investigators observed the operators creating a new privileged account on a domain controller during post-exploitation.
After gaining domain administrator privileges through credential dumping, the attackers ran the following commands:
net user /add /Y nuuser 7HeC00l3stP@ssw0rd
net localgroup administrators nuuser /add
The newly created nuuser account was immediately added to the Administrators group, granting full control across the domain. Because the commands were executed directly on the DC, the account inherited domain-wide admin rights — effectively giving the attackers a persistent, legitimate way back into the network.
Conti affiliates used this account to enable RDP and remote management access, ensuring they could reconnect even after their tooling was removed or other credentials were rotated.
Other Documented Examples
Lorenz Ransomware (NCC Group, 2023): Created local admin accounts for persistence across reboots.
LockBit 3.0 (Sophos, 2023): Added new user accounts to the Administrators group as fallback access.
APT41 (Mandiant): Created local service-style accounts on high-value systems to maintain long-term footholds.
Detection:
Source | Indicator | Description |
Security 4720 | New user account created | Trigger on unexpected new accounts, especially with service-like names (nuuser, HelpDeskAdmin, etc.). |
Security 4732 / 4733 | User added / removed from Administrators group | Detect privilege escalation via group membership changes. |
Security 4724 | Password reset for existing accounts | Attackers may reuse dormant accounts instead of creating new ones. |
Sysmon 1 (Process Create) | net user, net localgroup, or PowerShell New-LocalUser commands | Visibility into built-in account creation utilities. |
Sysmon 10 (Process Access) | Token manipulation events after account creation | Indicates privilege abuse or escalation. |
Security 4624 (Logon) | First logon from new account via RDP / Network | Correlate with creation event to confirm malicious use. |
MITRE Mapping: Create Account — T1136
RDP — Maintaining Remote Access After Cleanup
Attackers often combine credential theft or backdoored local accounts with exposed RDP ports to maintain access. Unlike general account persistence, RDP-based persistence involves enabling remote logons, adding users to “Remote Desktop Users,” and leaving port 3389 open for reentry.
Case 1 — NetSupport intrusion
DFIRReport’s NetSupport case documents an attacker creating a local user named WDAGUtilityAccount2 (a look-alike of the legitimate WDAGUtilityAccount) and adding it to privileged groups.
The investigation captured the exact commands used:
net user WDAGUtilityAccount2 Decryptme1488@ /add
net localgroup Administrators WDAGUtilityAccount2 /add
net localgroup "Remote Desktop Users" WDAGUtilityAccount2 /add
Case 2 — CISA advisory: account creation + RDP exposure
A CISA advisory describes attacker scripts that created user accounts, disabled host firewalls, and opened port 3389 to enable RDP access — showing how account creation and RDP exposure are combined operationally. This pattern supports sustained remote access after exploitation.
Detection:
Source | Indicator | What to look for |
Security 4720 | New user account created | Alert on unexpected account creations — review creator, source IP, and timestamp. |
Security 4732 / 4733 | User added to Administrators / Remote Desktop Users | High-priority when unknown users are granted privileged group membership. |
Security 4724 | Password reset for existing account | Attackers may reset an old account instead of creating a new one. |
Security 4624 (Logon) | Remote interactive logon (Type 10) by new account | Correlate first RDP logon with creation event. |
MITRE Mapping: T1136 — Create Account; T1098 — Account Manipulation (when elevating privileges)
Multi-Layered Persistence — Kraken Botnet
The Kraken Botnet, analyzed by Avertium, illustrates how modern threats layer multiple persistence mechanisms to stay reliable.
Active since October 2021, Kraken combines data-stealing, crypto-mining, and C2 capabilities within a modular Windows framework. Its persistence strategy reflects a growing trend among botnets — using redundant autostart methods to ensure that even if one mechanism is removed, another immediately restores the malware.
Kraken’s persistence layers include:
Registry Run keys
Scheduled tasks
Service entries
All of these point to the same payload, guaranteeing that a single cleanup step won’t fully remove the infection. This resilience makes Kraken a case study in defense evasion through redundancy.
Detection:
Source | Indicator | Description |
Sysmon 1 (Process Create) | reg.exe, schtasks.exe, or sc.exe executed together | Detect chained persistence commands. |
Sysmon 13 (Registry Set) | New Run key referencing same binary path | Registry-based autostart. |
Sysmon 11 (File Create) | Payload drop in %ProgramData% or %AppData% | Confirms file persistence source. |
Security 4698 / 7045 | New task or service creation | Identifies layered autostart mechanisms. |
MITRE Mapping: Multiple Persistence Mechanisms — T1053, T1543, T1547
Impact: When Persistence Turns into Damage
Persistence often bridges the moment of breach to full-scale impact. It’s what enables attackers to escalate privileges, dump credentials, and deploy ransomware well after the initial compromise.
Case 1 — Volt Typhoon (2023)
According to a Detected Activity advisory, Volt Typhoon gained long-term, covert access within U.S. critical-infrastructure networks. They leveraged living-off-the-land binaries and native Windows tools to remain undetected, conducting credential access, system discovery, and sustained persistence ahead of potential disruptive operations. (itpro.com)
Case 2 — McLaren Health Care / Hospital Ransomware (2024)
McLaren reported that their systems were accessed between July 17 and August 3, 2024; the breach was discovered on August 5. The incident impacted over 743,000 patients whose health-insurance or personal data may have been exposed. This timeline reflects how persistence in a network turned into a significant data-breach event. (bleepingcomputer.com)
Case 3 — From IceID to DagonLocker in 29 Days
An incident timeline published by The DFIR Report describes how threat actors leveraged IceID (an initial access banker) and moved through to DagonLocker ransomware in just 29 days. This illustrates how quickly persistence can evolve into full-scale impact when access is maintained. (thedfirreport.com)
Persistence isn’t just staying in the network — it’s buying time. And time turns into severity when adversaries are allowed to wait.
MITRE Mapping: Impact — TA0040
Turning Persistence Against the Attacker
Persistence isn’t just an attacker’s tactic — it’s a trail of evidence. Every scheduled task, Run key, or new account is a clue that says, “I needed to stay here.” For defenders, those traces are not annoyances — they’re early warnings.
Note: Correlate Sysmon ProcessGuid with Security Logon IDs — it ties execution traces to user sessions and shows which process survived reboot. That’s how we prove persistence and catch long-term dwell time.
References
Where They Stayed
Every intrusion leaves a mark.
It’s rarely loud — often just a quiet reminder that someone wanted to stay.
And that’s where detection begins.
Comments