Guided lab: the scheduled task that looks like Windows

There are two candidates. One is on by default; the other is a dedicated operational log for the scheduler itself.

Check Security for 4698, and Applications and Services Logs → Microsoft → Windows → TaskScheduler → Operational for 106. Look at what each contains.

Security 4698, "A scheduled task was created." It carries the full task XML, which means the action, the trigger, the principal it runs as, and who created it, all in one event.

TaskScheduler Operational 106 records registration too, but with less detail. Worth knowing because 4698 requires the object access audit policy to be enabled, and on many estates it simply is not, whereas the operational log is often on.

Either way the log gives you something a task listing never will: who created it and when. That is the difference between "this task exists" and "this task appeared at 09:04 on Tuesday, made by an account that had no business making it".

Every registered task is also a file. Look in the System32 tree.

C:\Windows\System32\Tasks\ holds one XML file per task, in a folder structure mirroring the Task Scheduler tree. The file is plain XML: trigger, action, principal, the lot.

The timestamp matters because it is a filesystem artifact that survives log rotation. If your Security log only goes back 3 days and the task was planted 2 weeks ago, the file creation time is the only thing left telling you when. Build your timeline from artifacts with different lifetimes and you cover more ground than any single source gives you.

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree, and the Tasks key beside it.

TaskCache\Tree mirrors the folder structure; TaskCache\Tasks holds the details keyed by GUID.

It is there for the scheduler's own speed, but for you it is a third independent copy. Tampering usually removes one and forgets another. A task present in the registry but missing from System32\Tasks, or the reverse, is a much stronger signal than either copy on its own, because inconsistency between two views is hard to fake and easy to check.

The name is designed to survive a skim. Look at everything except the name.

Compare the executable's path against where that binary really lives, and check whether the file is signed.

The path, not the name. A real srtasks.exe lives in C:\Windows\System32. This one is in C:\Windows\Temp, which is world-writable and where no Microsoft binary is installed.

Then the signature. Autoruns shows publisher, and an unsigned binary in a Microsoft-named task is not a grey area. Turn on Options → Hide Microsoft entries and anything left in a Microsoft-looking folder is worth a hard look.

The transferable lesson: a detection matching the task name would miss this, and a detection matching the executable path would catch it. Attackers pick names to defeat human review. They have far less freedom over where they can write a file.

Start with Security 4698, or Sysmon Event ID 1 for schtasks.exe and Event ID 11 for file creation under System32\Tasks\.

The tuning problem is the same shape as the Run key one and worse in degree: software installers, Windows Update and management agents create tasks constantly. The rule that survives contact with production is not a longer allowlist of names, because names are the attacker's free variable.

Two conditions that hold up:

1. The action's path. A task whose executable sits in Temp, AppData, ProgramData or a user profile is worth alerting on almost unconditionally.
2. The creating process's ancestry. schtasks.exe spawned by powershell.exe spawned by Word is a different event from schtasks.exe spawned by an MSI.

Notice this is the same conclusion the Run key lab reached from different evidence. When two independent investigations land on "ancestry and path beat name", that is a principle rather than a coincidence.