Windows Scheduled Task Persistence: How to Find and Remove Malicious Tasks Used by Attackers and Malware
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Scheduled tasks are a top-five persistence mechanism across commodity malware, ransomware, and advanced threat actors because they are simple, reliable, and blend easily with hundreds of legitimate Windows scheduled tasks. During incident response, finding attacker-created tasks among hundreds of legitimate Windows and application tasks requires a systematic approach: enumerate all tasks, identify anomalies, correlate with Event IDs to determine when tasks were created and by whom. This guide provides the enumeration commands, the detection signals, and the safe removal process.
Enumerate All Scheduled Tasks
PowerShell full enumeration: Get-ScheduledTask | Select-Object TaskPath, TaskName, State, @{Name='RunAs';Expression={$.Principal.UserId}}, @{Name='Actions';Expression={$.Actions | ForEach-Object { $.Execute + ' ' + $.Arguments } | Join-String -Separator '; '}}, @{Name='Triggers';Expression={$.Triggers | ForEach-Object { $.CimClass.CimClassName } | Join-String -Separator '; '}} | Export-Csv C:\tasks-audit.csv -NoTypeInformation. This exports every task with its name, run-as user, executable path, arguments, and trigger type. Review the CSV and look for: tasks running as SYSTEM or as a high-privilege user that were not present before the suspected compromise date, tasks with unusual executable paths (PowerShell encoded commands, scripts in TEMP directories, executables in user profile paths, long random-looking filenames), tasks in unusual paths (legitimate Windows tasks are mostly under \Microsoft\Windows; attacker tasks sometimes hide there but also commonly appear at the root \ path or in custom folders), and tasks with triggers set to 'AtLogon' or 'AtStartup' for non-standard executables.
Identify Suspicious Task Patterns
Common attacker task patterns to search for in the CSV: PowerShell encoded commands: Action contains 'powershell' and '-encodedcommand' or '-enc' -- legitimate scheduled tasks rarely use encoded PowerShell. Scripts in temp directories: Action path contains \AppData\Local\Temp, \Windows\Temp, or unusual %ProgramData% subdirectories. Obfuscated names: task names or file names that are random strings (example: 'cFbxqMnpJk.exe') or mimic legitimate Windows task names with slight variations (example: 'WindowsUpdater' instead of 'Windows Update'). Missing binary: the executable in the task action no longer exists on disk -- the original malware was deleted but the scheduled task remains (it will fail to execute but reveals the former malware path). Run-as SYSTEM with user-writable path: Action runs a file in a directory writable by standard users -- privilege escalation via task hijacking. SYSTEM with current working directory set to a user-controlled location. Filter for all of these patterns: $tasks | Where-Object { $_.Actions -match '-enc|-encodedcommand|appdata.*temp|\temp\' }.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Correlate with Event ID 4698 and 4702
Event ID 4698 (Windows Scheduled Task Created) and 4702 (Windows Scheduled Task Updated) in the Security event log record task creation and modification, including the task XML definition and the account that created it. These events are only generated when 'Audit Object Access' is enabled for the target system -- confirm this: auditpol /get /subcategory:'Other Object Access Events'. If not enabled, enable it via GPO and forward going forward. For historical investigation without 4698 events: task creation timestamps are not stored in the task XML, but the file creation time of the task definition file in C:\Windows\System32\Tasks\ provides a timestamp approximation. Examine: Get-ChildItem C:\Windows\System32\Tasks -Recurse | Where-Object { $_.CreationTime -gt (Get-Date).AddDays(-30) } | Select-Object Name, CreationTime, FullName | Sort-Object CreationTime -Descending. Any task definition file created during or after the suspected compromise window is a candidate for investigation regardless of its name.
Safely Disable and Remove Malicious Tasks
Do not delete tasks until you have documented them and, ideally, copied the task XML for forensic record: Export-ScheduledTask -TaskName 'SuspiciousTask' -TaskPath '' > C:\forensics\suspicious-task.xml. Then disable immediately: Disable-ScheduledTask -TaskName 'SuspiciousTask' -TaskPath ''. Disabling stops execution while preserving the task definition for investigation. After investigation is complete, delete: Unregister-ScheduledTask -TaskName 'SuspiciousTask' -TaskPath '' -Confirm:$false. Also check: if the task runs a script or binary that still exists on disk, that file must also be removed as part of malware cleanup. If the task runs a PowerShell encoded command, decode the command before deletion: [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String('encodedstring')) to understand the full payload. For tasks embedded deep in \Microsoft\Windows\ paths mimicking legitimate tasks: verify against a known-good baseline (a clean VM of the same OS version) before assuming they are malicious -- some legitimate Microsoft tasks have unusual names.
Implement Ongoing Detection
Forward Event ID 4698 and 4702 to your SIEM and create detections. Alert when: a scheduled task is created or modified by a non-administrative user account (any standard user creating a SYSTEM-run task is suspicious), a scheduled task action contains PowerShell with encoded commands, a scheduled task action references an executable in a user-writable temp directory, or a scheduled task is created outside of a known-good change window. KQL for Sentinel: SecurityEvent | where EventID in (4698, 4702) | extend TaskXml = EventData | where TaskXml contains 'powershell' and (TaskXml contains 'encodedcommand' or TaskXml contains '-enc ') | project TimeGenerated, Computer, SubjectUserName, TaskXml. Also run a weekly automated scan with the Get-ScheduledTask PowerShell enumeration piped to a comparison against a known-good task baseline -- any new task outside the baseline warrants investigation.
The bottom line
Scheduled tasks are one of the first persistence mechanisms to check during incident response. The enumeration takes 2 minutes; the analysis depends on the environment but is straightforward with the anomaly patterns described here. For ongoing defense, alert on Event ID 4698 filtered for non-admin creators and encoded PowerShell actions. A scheduled task baseline comparison run weekly catches new persistence before the next incident.
Frequently asked questions
How do attackers hide malicious scheduled tasks in the Windows task library?
Common hiding techniques: placing the task in the \Microsoft\Windows\ folder hierarchy with a name similar to legitimate Windows tasks (WindowsDefenderUpdate, MicrosoftEdgeUpdate). Using Unicode characters or visually similar characters in task names that look identical to legitimate names but differ at the byte level. Creating tasks with legitimate-sounding names in the root \ folder. Setting the task to run only once at a future date (avoids periodic execution that would appear in Task Scheduler history). Removing the task after first execution so it does not persist to discovery.
Can a standard user create a scheduled task that runs as SYSTEM?
Not directly -- creating a task with RunAs=SYSTEM requires administrator privileges. However, a standard user can create a task that runs as themselves, which is a concern if the user account has access to sensitive resources. Some privilege escalation vulnerabilities (in Task Scheduler itself, or in the action binary) can turn a standard user task into SYSTEM execution. The general rule: any task running as SYSTEM should have been created by an administrative account -- Event ID 4698 shows the creating account.
What is the difference between a scheduled task and a service for persistence purposes?
Both are common persistence mechanisms. Services run continuously as background processes and restart automatically after failure (configurable). Scheduled tasks run on a trigger (time, event, or startup) and then exit. Attackers prefer scheduled tasks for intermittent payloads (beaconing, ransomware re-trigger) because they generate less obvious continuous process presence. Services are preferred when the payload needs to run continuously (RAT agent, backdoor). Both should be audited: services via Get-Service and sc query, tasks via Get-ScheduledTask.
Should I check scheduled tasks on domain controllers specifically?
Yes -- scheduled tasks on domain controllers are highest priority because they run with DC-level access and are a preferred target for persistence after domain compromise. Check all DCs with: Invoke-Command -ComputerName (Get-ADDomainController -Filter * | Select-Object -ExpandProperty Name) -ScriptBlock { Get-ScheduledTask | Where-Object { $_.TaskPath -notlike '\Microsoft\Windows\*' -or $_.Principal.UserId -eq 'SYSTEM' } | Select-Object TaskPath, TaskName, @{N='Action';E={$_.Actions.Execute}} }. Any task not in the Microsoft Windows path on a DC warrants immediate investigation.
What Event IDs should I monitor for scheduled task creation and modification?
Event ID 4698 (a scheduled task was created) and Event ID 4702 (a scheduled task was updated) in the Security log are the primary indicators -- they include the task XML, which contains the action, trigger, and principal. Event ID 106 in the Microsoft-Windows-TaskScheduler/Operational log (task registered) and Event ID 140 (task updated) provide additional detail including the task definition at the time of registration. Correlate 4698 with the creating account: tasks created by non-admin accounts, tasks created during off-hours, and tasks with actions containing encoded PowerShell or known LOLBAS binaries should all be high-priority alerts in your SIEM.
How do attackers use scheduled tasks as a persistence mechanism after gaining initial access and what makes them hard to detect?
Scheduled tasks are attractive for persistence because they survive reboots, execute under any user context including SYSTEM, can be hidden from the Task Scheduler GUI using COM object manipulation, and are a built-in Windows feature (no dropped malware required). Common attacker patterns: creating a task that runs a PowerShell stager at logon using the AT or SCHTASKS command, registering a task with an XML definition that includes Base64-encoded payloads in the task action, using the 'Run only when user is logged on' trigger to avoid detection during off-hours scanning, and using a task name that mimics legitimate Windows tasks (MicrosoftEdgeUpdateTaskMachineUA, WindowsDefenderScheduledScan). Detection challenges: tasks can be registered without creating a visible GUI entry by calling the ITaskScheduler COM interface directly. Defend by comparing the current task list from SCHTASKS /query /fo LIST /v against a known-good baseline from your imaging process, and alerting on any task not in the baseline. Sysmon Event ID 11 (file creation) in the C:\Windows\System32\Tasks\ directory provides reliable detection regardless of the registration method used.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.