Evil on Schedule: Investigating Malicious Windows Scheduled Tasks

thatdfirdude
4 days ago
10 min read

Welcome back! It’s been a while! My goal with this post, although very basic, is to demo how powerful Scheduled Tasks can be and how you should be reviewing these in every incident.

In nearly every incident, you’ll see persistence. Why? Well… it's simple, a threat actor wants to maintain their access. Whether this is to sell access at a later date, if they’re an initial access broker or if they’re still in the early stages of their kill chain. There are MANY ways that a threat actor can maintain persistence, such as the Windows registry, services, autorun items, startup items, installing software, scheduled tasks and many many other ways. In this instance, we’ll be discussing how and why threat actors use Scheduled Tasks to maintain persistence. Now, you may be saying “This is 2025, aren’t we seeing crazy 0-days, rootkits, shells, dead-drop C2s, and novel ways of maintaining persistence?”. Well, yeah, but more often than not, you’re going to see traditional methods of persistence used in most instances! Why? Because it works! It's native to Windows, it doesn’t require a threat actor to waste an 0-day for a basic intrusion incident and play all of their cards in one hand.

The Rundown

Scheduled Tasks allow programs, scripts, or commands to run automatically on a set schedule or trigger (time, logon, boot, event, etc.).
They are native to Windows, blend in with legitimate system activity, and provide persistence without requiring extra tools.
Scheduled Tasks can be created in numerous ways, such as schtasks.exe, PowerShell cmdlets, WMI, the Task Scheduler GUI, or through malicious executables and scripts.
Existing scheduled tasks can also be modified by a threat actor.
Scheduled Tasks can be found in the TaskScheduler/Operational Event Log as Event ID 106 (task registered), Event ID 140 (task updated), and Event ID 141 (task deleted).
Scheduled Tasks can also be logged in the Security Log as Event ID 4698 (task created), but this requires advanced audit policy and is not enabled by default.
Scheduled Tasks can be named anything. Do not trust the task name—always validate the command line, path, and action being executed.
Review the trigger and interval to determine how often the task will run; short, repeating intervals (for example, every 5 minutes) are a red flag.
Investigate how the scheduled task was invoked—via schtasks, PowerShell, WMI, or another process—and review the parent process.
Scheduled Task event logs can be cleared by a threat actor, which is why log forwarding and EDR/Sysmon telemetry are critical.
Scheduled Task files are stored as XML in C:\Windows\System32\Tasks, but can also be placed in sub-directories within this folder. Reviewing these XML files directly reveals the trigger, principal, and action.
Baseline what normal scheduled tasks look like in your environment so that anomalies stand out quickly.

So, what exactly is a Scheduled Task? It’s kind of in the name, it's a task that executes a specific interval or at a “schedule”. For example, these tasks can run at a specific time, daily, weekly, monthly, at task creation, at user logon, or even when a system event occurs or when the system is powered on! Choose your own adventure!

Now one thing I want to call out is that a scheduled task can also be modified or updated by a threat actor! They do not explicitly have to create a scheduled task! However, this blog will be focused on the creation of a task. In my experience, I’ve seen many use cases for a scheduled task. Yes, it can be used for persistence, but it can also be used for lateral movement and actions on objectives! For example, a ransomware operator creates a remote scheduled task on 500 systems that executes a file named “encryptor.exe” located in the SYSVOL directory or ADMIN$ and even a threat actor modifying Group Policy to push out a malicious scheduled task on all systems! These can be extremely powerful.

There are also many ways to create a scheduled task. For example, using the PowerShell cmdlet, using the task scheduler GUI, using the traditional command prompt or Windows Terminal, scripting, etc. etc. There are many ways that the task itself can be created and you’ll often see this initiated in numerous ways, depending on the threat actors TTPs (Tactics, Techniques and Procedures). In some instances, you may see a scheduled task be created as part of the malicious execution of an executable and in others, you may literally see the TA use the Windows Task Scheduler GUI (graphical user interface) to create this.

When picking apart Scheduled Tasks at a root level or “technical level”, there are many features and specific details surrounding what exactly these can do; however, from an incident response perspective, understanding this at a high-level will be most efficient in terms of knowing where to identify the tasks and identifying what the task does as quickly as possible. There are often three critical parts of a scheduled task; Cyber Triage has a blog that discusses this and is a great read, which can be found here. For this blog, we’ll primarily focus on the Trigger and the Action. The Trigger of a scheduled task can be when the task will run or what will cause it to execute (time, at boot, user logon, system event, etc.) whereas the Action is what will happen once the trigger is met (execute this program, run this script, etc.). Pretty straightforward, right?

Scheduled Tasks Locations

On a modern Windows system, scheduled tasks are often found in numerous locations. More commonly, these can be found in the following locations. Note that these may vary between different versions of Windows.

C:\windows\tasks
C:\windows\system32\tasks
C:\windows\system32\config\SOFTWARE
- HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks
- HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree
%localappdata%\Microsoft\Windows\PowerShell\ScheduledJobs

Event Logs

Scheduled tasks also appear in the Windows Event logs as well! Luckily, in modern Windows systems, these have a dedicated or custom Event log called TaskScheduler and will use the Event ID (EID) 106. The event log will contain when it was created, who it was created by, the action, trigger, and all data about the task! As you can imagine, this is a great place to look for malicious scheduled tasks! If you have a timeframe of activity, head straight to the TaskScheduler Event log, plug in the EID 106, and see what you have!

Shown below is the raw event log for a sample of this!

Security Event Log

Scheduled Tasks will also appear in the Security Event log, if configured, under the EID 4698. Remember, EID 4698 is not enabled by default, so be sure to review your Group Policy or Local Configuration Policy.

Other

Because there are many ways to execute a scheduled task, these can appear anywhere you have command line auditing configured or process execution! Think of telemetry such as your EDR, sysmon, PowerShell logs, WMI logs, etc! This is why Command Line Auditing and Process tracking is critical!

Scheduled Task file and Format

Opening a scheduled task file can be pretty straightforward. These can easily be opened within your favorite text editor. Once opened, you’ll see these within a common XML format, which will describe the trigger, action, principal (user or privileges) and a bit more information. Go ahead, navigate to C:\Windows\System32\Tasks and take a look! You’ll likely have a lot of scheduled tasks running on your own system and even folders with additional tasks within the parent Tasks folder. This is why it's important to timeline and identify pivot points in your investigation to identify the malicious task. For example, focusing on your TOI or Timeframe of Interest, a user of interest, specific event, etc. Creating an “artifact constellation” and a forensics timeline can easily identify evil!

Let’s open up a random task file that I have on my own PC for an “AMD Installer”. Here, we’ll see

Registration Info - Includes the date, author, and a description of the task
Triggers - If any, this will describe specific events that need to be met before the task can execute
Principal information - Who created the task, the run level and the logon type it uses
Settings for the task - Such as specific specifications to terminate the task, if it's enabled or not (always check this as well when conducting investigations. You’ll want to make sure you accurately report if a task is enabled or not);
and likely the most important setting, the Actions, which will describe what the task does - Specifically, the Command and Arguments

What you’ll see most often, is a Time Trigger element within the task file. For example, start the task on 2025-08-17 at 08:00:00 and "Repetition" or “repeat” the execution of this every 30m. Shown below is an example of this. As we can see, this task specifies a start time, if its enabled, how often it will run, and if there’s any delays after it executes.

According to Microsoft’s documentation, the "Repetition" element will specify the amount of time between each restart of the task. Specifically, the format is described as P<days>DT<hours>H<minutes>M<seconds>S. In this example, the task will run every day. This is a great example of a complex Time Trigger Interval described by Microsoft - PT5M specifies 5 minutes and P1M4DT2H5M specifies one month, four days, two hours, and five minutes. The P represents the “Period” (such as years, months, days), the D represents the days, the T is a time separator, which is followed by the hours, minutes and seconds, represented by H, M, and S.

Microsoft actually has extensive documentation that breaks each and every part of a Scheduled Task down, which can be viewed here.

Investigating a Scheduled Task

Let’s jump right in and take a look at some malicious scheduled tasks and break these down! Of course I won’t be able to cover every way to create a scheduled task, but we’ll review a few that you’ll often come across when investigating general incidents and intrusions, such as ransomware or persistence from initial access brokers.

We’ll take a look at a few examples below!

First, we have a simple interval-based task that will be executed daily. With everything we mentioned above, lets see if you can break down this task and understand what it's doing.

What are some of the main parts of this task that your eyes or “investigative mindset” went straight to? Did you go straight to the Trigger and see that this will start at 12:00:00 on 2025-08-17? Did you notice that this will run every day at that time? What is the task doing? Did you notice that it's using notepad.exe to open a file named “example1.txt”? What would your next steps be?

Let’s move on to a more common one focusing on persistence! What’s unique about this one? How is it triggered?

Did you identify that this will trigger at user logon?

Let’s take a look at a more complex one! Identify what this one is doing!

What’s unique about this? It must be just the Windows Telemetry Updater, right? I mean, its running from C:\Windows\System32\Tasks\Microsoft\Windows\Update\TelemetryUpdater. That seems legit enough? Hmm. Running every 5 minutes? Its running a file named svchost32.exe from C:\ProgramData\System. Is that the legitimate location for svchost32.exe? The command contains the word “miner” and seems to be passing parameters to a specific URL over port 333. What could this ever be?!

Yes, they are often this simple and it takes the mindset and a solid timeline to identify these pivot points and immediately identify key focuses of the task. Remember earlier in the blog I mentioned that we’ll often focus on the Trigger, Principal and Action? Can you see why now?

Creating a Scheduled Task

As mentioned above, there are many ways that a TA can create a scheduled task. They can use native tools such as Command Prompt, Terminal, PowerShell, integrate it into their own scripts, use the Task Scheduler GUI, etc. However, we often see this as part of a malicious script or command line provided by the threat actor. Let’s take a look at a few below.

Schtasks - Command Line invocation

One common example may be to see “schtasks.exe” executed from their own tool, which will be logged in the Command Line from the tool. A great example is something such as this

schtasks /create /sc minute /mo 5 /tn "Microsoft\Windows\Update\TelemetryUpdater" /tr "C:\ProgramData\System\svchost32.exe --url=stratum://fakepool.local:3333 --user=guest --pass=x" /ru SYSTEM

What is this task doing? If you saw this command line, can you now pick this apart? Microsoft has more great documentation on the schtasks.exe executable here. Breaking this apart, we can infer that the command line will use schtasks.exe to create a task that will run every 5 minutes named “TelemetryUpdater”, located in C:\Windows\System32\Tasks\Microsoft\Windows\Update” and will run with the command line

 C:\ProgramData\System\svchost32.exe --url=stratum://fakepool.local:3333 --user=guest --pass=x" as the user “SYSTEM”.

Specifically, the command uses the following parameters

/create - This will specify that a task should be created
/sc - This specifies the schedule type; such as minute, hourly, daily, weekly, onstart, onlogon, onevent, etc.
Minute - represents this will run in the “minutes” type
/mo - Is the modifier; this specifies how often it will run, which in this case, is 5 minutes
/tn - Is the Task Name, which contains the URI or path of the task file, which often starts in C:\Windows\System32\Tasks
/tr - This is the Task Run, which is the command line or program that the task will run. It requires the full path
/ru - This is the user that the task should run as

PowerShell

PowerShell of course also supports creation/execution of a scheduled task using supported cmdlets. Specifically, this uses the cmdlet “New-ScheduledTask”. As you may have guessed, Microsoft has documentation on this here.

PowerShell can be used to specify the same parameters such as the action, trigger, task name, and more. A great example of this is shown below. You should be a pro at this now and have a good understanding of what this command will do!

You may also see base64 obfuscation as well!

Powershell -NoP -W Hidden -Enc JEFjdGlvbiA9IE5l... <DEFANGED>

WMI

Yes, if you saw PowerShell, you’re probably guessing that WMI can also be used to create a task! This can be invoked using PowerShell and the Get-WmiObject cmdlet!

$Task = Get-WmiObject -Namespace "root\cimv2" -Class Win32_ScheduledJob $Task.Create("C:\Users\Public\updater.exe --url=stratum://fakepool:4444 --user=guest", "********050000.000000-000")

As you may have guessed, there are numerous ways to detect malicious use of this here! Your mind should start flowing with investigative techniques, artifacts, logs, telemetry and signatures that you can use to detect these!

Hopefully with this writeup, you have a solid foundation of what consists of a scheduled task, where to find them, and the important parts to quickly identify “evil”.

Takeaways

Attackers don’t always create new tasks — they may modify existing ones to blend in.
Don’t trust the task name — always check the path and the action being executed.
Logs can be tampered with — TaskScheduler logs can be cleared, so forward logs and rely on EDR/Sysmon telemetry for resilience.
Know your pivot points — triggers, actions, principals, and parent processes often reveal intent.
Event hunting matters — look for Event ID 106 in TaskScheduler and 4698 in the Security log (if advanced auditing is enabled).
Check the trigger — short, repeating intervals (e.g., every 5 minutes) are strong red flags.
Inspect the XML directly — task files in C:\Windows\System32\Tasks are plain XML; open them to review command lines and arguments.
Multiple creation methods exist — schtasks.exe, PowerShell, WMI, or even the GUI. Detect across all of them, and focus on command-line arguments.
Non-standard directories are suspicious — watch for binaries in C:\ProgramData\, C:\Users\Public\, %TEMP%, or renamed “system-like” executables.
Baseline normal tasks — understand what scheduled tasks your environment should have so anomalies stand out quickly.