How to detect scheduled task manipulation

Understanding the threat

Scheduled task manipulation is when an actor creates, modifies, disables, or deletes scheduled jobs so the system will execute code at a time or on an event of the attacker’s choosing. Attackers use this for persistence and recurring execution because scheduled tasks blend into normal administration and survive reboots. Windows records scheduled task creation, modification, deletion, enable and disable events (for example, event IDs 4698, 4702, 4699, 4700, and 4701), which are commonly monitored for this technique.

Log360 ingests Windows security logs, tracks registry and file change logs, and can detect suspicious scheduled task activity through built-in detection rules. It correlates scheduled task events with context, such as user account, executable path, or time of creation or modification, enabling you to catch unexpected or malicious tasks early.

Category

Endpoint

MITRE ATT&CK® mapping

T1053 | Scheduled Task/Job

Scenario

A service account with local administrative rights is compromised. The attacker uses schtasks.exe /create to register a new task named UpdaterService that runs daily at 3:15am. The task executes a malicious binary stored in C:\ProgramData\Updater\update.exe. Because backups run around 2am and no one reviews logs until later in the day, the attacker expects the task to go unnoticed, allowing the malicious binary to run regularly and maintain persistence. Meanwhile, the Windows security event log records event ID 4698, capturing details like task name, account used, and the task XML.

Why this happens

• The attacker wants to establish persistence that survives reboot and avoids detection.
• Using a plausible name (UpdaterService) and a legitimate-looking schedule reduces suspicion.
• Running tasks during non-working or off hours reduces the chance of human review or alert.
• The attacker exploits weak separation of privileges: a compromised service account granted rights to register scheduled tasks.

What can go wrong

• Persistent malicious code execution, possibly a backdoor, data exfiltration, or repeated malware deployment
• Lateral movement if the task executes credential dumping or network scanning tools
• Disabling or replacing of legitimate tasks , disrupting system or business processes
• Detection and forensic gaps if auditing is disabled or logs are not collected, making it hard to spot the change or trace attacker actions

Prerequisites for detection using Log360

• Windows auditing policies must be configured to log scheduled task events (object-access or Task Scheduler auditing) to generate events such as 4698, 4702, 4699, 4700, or 4701.
• Endpoint or server logs (including security logs, the registry, and the file system where Task Scheduler stores definitions) must be forwarded to Log360 via an agent, WEF, or appropriate log forwarding.
• File system or registry monitoring should include the Task Scheduler directories and registry keys where task definitions are stored (for deeper context in case tasks are created via alternate methods).
• A baseline for work-hours and an administrative task allowlist (e.g., vendor update tasks and known automation) should be defined so anomaly detection rules don’t generate too many false positives.

Detecting scheduled task manipulation using Log360

• Once Windows logs are being collected in Log360, open the console and go to Security > Manage Rules > Rule Library. Search for the scheduled task rules and enable these four: Suspicious Modification Of Scheduled Tasks, Suspicious Scheduled Tasks Created During Non Working Hours, Delete Important Scheduled Task, and Uncommon One Time Only Scheduled Task At 00\\:00.
• After turning them on, fine-tune each rule so it reflects how your environment normally behaves. Set your working hours, identify which accounts are allowed to create or update tasks, and add any trusted maintenance tasks to the safe list. This helps the alerts focus on activity that is actually unusual.
• When an alert appears, review the details carefully. Look at who created or changed the task, the task name, the command or executable it launches, and when it is scheduled to run. Tasks that use uncommon accounts or point to files stored in locations like ProgramData, Temp, or a user profile often need closer inspection.
• If the activity looks suspicious, gather the task’s XML, check the executable or script it runs, and confirm whether any related files or registry entries were dropped on the system. Remove or disable the task if it is malicious, then review recent logins and account activity to understand how the attacker gained the ability to create it.

Next steps

• Review existing scheduled tasks across critical systems from time to time so you can spot entries that were introduced without approval.
• Update your baseline after OS upgrades, policy changes, or major application installs so legitimate new tasks do not appear suspicious.
• Use scheduled task alerts alongside process creation, file integrity, registry, and network activity logs to catch persistence or command-and-control patterns that may not be obvious from Task Scheduler events alone.