Why do ransomware gangs create scheduled tasks and local admin accounts?

They do it to preserve execution after reboot and to run with higher privileges without needing repeated user interaction. Those mechanisms let the malware survive disruption, complete encryption, and sometimes remove evidence. In practice, they are persistence and privilege-escalation controls disguised as normal Windows administration.

Why This Matters for Security Teams

Scheduled tasks and newly created local admin accounts are not just noisy post-exploitation activity. They are a practical way for ransomware operators to turn a single foothold into durable control. A task can relaunch payloads after reboot, while a local admin account can bypass friction that would otherwise slow encryption, lateral movement, or cleanup. That combination often defeats detection built only around obvious malware names rather than attacker behaviour. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful baseline for tying endpoint hardening, privileged access, and audit logging together.

The security mistake is treating these actions as ordinary administration unless they are proven otherwise. Attackers often create them after compromising a standard user, then use them to escalate, persist, and evade basic response actions. That is why defenders need identity-aware monitoring, not only endpoint alerts. The presence of a task or account is not the issue by itself; the issue is whether it was created through approved change, from an expected source, and with tightly bounded purpose. In practice, many security teams encounter these artifacts only after encryption has already started, rather than through intentional privilege and persistence monitoring.

How It Works in Practice

Ransomware crews use scheduled tasks because Windows will execute them automatically, often under a chosen account context and at a chosen trigger time. That gives an operator a reliable way to restart malware, run scripts, or chain commands after a reboot or service disruption. Local admin accounts serve a similar purpose from the identity side: they provide persistent privileged access that can outlive the original compromised session and may blend into routine support activity if governance is weak.

In practice, defenders should watch for the full sequence, not just the artifact. Common indicators include new task creation, modification of existing tasks, unusual command lines, service-stop activity, and account creation followed by local Administrators group membership. Good detection usually combines endpoint telemetry, Windows event logs, SIEM correlation, and change-management context. The threat patterns described in the ENISA Threat Landscape align with this operational reality: attackers routinely mix persistence, privilege, and evasion to keep control long enough to finish the extortion phase.

• Alert on scheduled tasks created outside approved administration windows or by unusual parent processes.
• Review new local administrators for join date, source host, ticket reference, and business justification.
• Correlate task creation with credential use, remote logon, and lateral movement indicators.
• Preserve audit trails so incident responders can see when persistence was established and by whom.

For identity teams, the key question is whether privileged access is standing, ephemeral, or unauthorized. If local admin creation is possible without strong approval and monitoring, ransomware operators can turn one compromised endpoint into a repeatable execution path. These controls tend to break down when endpoint logging is incomplete on roaming laptops because defenders lose the account and task-creation evidence needed for reliable correlation.

Common Variations and Edge Cases

Tighter control over scheduled tasks and local admin creation often increases operational overhead, requiring organisations to balance recovery speed against privilege reduction. That tradeoff becomes sharper in IT support, software deployment, and incident response, where legitimate admins may need to create temporary tasks or break-glass accounts. Best practice is evolving toward more explicit approval, shorter duration, and stronger logging rather than blanket prohibition.

There is no universal standard for every environment, but the safe pattern is clear: separate ordinary administration from privileged maintenance, and require traceability for both. In some environments, attackers do not create a brand-new account; they instead enable an existing disabled account, rename a task, or use a legitimate admin tool to stage persistence. That is why defenders should look for intent and lineage, not only object type. Where remote management tools are heavily used, scheduled tasks can be legitimate at scale, so baselines matter. The difference between benign automation and attacker persistence is usually source, scope, timing, and whether the action fits a recorded change.

Identity governance is especially important when ransomware operators abuse local groups to simulate normal administrative practice. Mature organisations map these behaviours to privileged-access policies, harden creation rights, and review task execution against the principle of least privilege. For broader attack-pattern mapping and hunt planning, security teams should also track how these behaviours fit within established adversary techniques rather than treating them as isolated Windows events.

Related resources from NHI Mgmt Group

• Why do local accounts create more IAM risk than centrally managed identities?
• Why do application-local accounts create more NHI risk than centrally managed identities?
• Why do static SSH keys and shared admin accounts create compliance risk?
• Why do local admin rights create a governance problem for IAM and PAM teams?