One real attacker move, a safe way to run it on a machine you own, and the detection that closes the gap — in that order, so you leave with better coverage than you arrived with.
technique T1053.005 · Scheduled Taskseen in APT29where any Windows box
A scheduled task is how an intruder makes their access survive a reboot. schtasks /create registers a task that Windows will run for them later — on a timer, at logon, on their schedule instead of yours. It is one of the oldest and most reliable persistence moves, and it is a single built-in command.
The detection watches for that command running: schtasks.exe creating a task from a user account. Your admins create tasks too, so the rule leaves the automated system tasks alone and flags the ones a person just typed.
The detection watches one thing: the built-in schtasks tool creating a new scheduled task.
This is not hypothetical
The group tracked as APT29 is documented using scheduled tasks to keep a foothold — register the task once, and the access comes back whether or not the original session survives.
It needs no exploit and no special rights: a normal user can schedule a task that runs as themselves. The same command you are about to run — the question is whether your SOC sees a new task appear.
The actor above is named in MITRE ATT&CK’s own Procedure Examples for this technique; the link is where you can read it. Nothing on this page discloses a move an attacker does not already have — it just makes sure the defender has it too.
A scheduled task brings the attacker's access back after a reboot. One schtasks /create and they no longer need the door you closed.
Built-in and unelevated
A user can schedule a task that runs as themselves — no admin needed. That is exactly why it is a favourite, and why it must be watched.
Easy to miss in the noise
Windows creates legitimate tasks constantly. The intruder's task hides in that traffic unless your detection separates the typed ones from the automated ones.
The test
Run the real thing. Safely. On a box you own.
Create a harmless task, watch for the alert, then delete it — the script cleans up after itself.
01
Schedule a harmless task
Run schtasks /create for a task named CyRaySOCTest that does nothing but exit. This is the moment your SOC should notice a new task.
02
Check your alerts
Open your SOC or EDR. Did scheduled-task creation fire?
03
Remove it
The last line deletes the task it created, so nothing is left behind.
test-your-soc-scheduled-task.ps1 · PowerShell · a machine you own
# test-your-soc-scheduled-task.ps1 — run on a machine you own.
# Safe: creates one harmless task that only exits, then deletes it. Runs as you, no admin.
# STEP 1 - the real persistence move: register a scheduled task via schtasks.
schtasks /create /tn "CyRaySOCTest" /tr "cmd /c exit" /sc once /st 23:59 /f
# STEP 2 - open your SOC / EDR. Did scheduled-task creation alert?
# STEP 3 - clean up: delete exactly the task this script created.
schtasks /delete /tn "CyRaySOCTest" /f
The task does nothing but exit, runs as your own account (no admin), and the final line deletes exactly the task the script created. Nothing else on the machine is touched.
Reading the result — honestly
Something fired
Your tooling watches for new scheduled tasks
Good — an intruder wiring up persistence would show up the same way. On to the next one.
Silence
The new task appeared unseen — now you know
Not a verdict on your team; a specific, fixable gap you just found in a minute. The detection below closes it.
Straight with you: we never see your alerts — you’re the judge, which is also why we never touch your data. And a lab isn’t production; a test box often logs differently than the real fleet. "It fired" means your EDR flagged schtasks /create — note that a task created from an XML file or through the Task Scheduler API is a quieter path some rules miss, so treat this as one door of several. Treat a pass as a reason to go check prod, not a finish line.
How to catch it
Missed it? Here’s the fix — take it straight to your SOC.
Copy this to your detection team
The logic is public and every major SIEM already supports it. Here it is in Sigma, the open, vendor-neutral format your team can translate into whatever you run.
proc_creation_win_schtasks_creation.yml
title: Scheduled Task Creation Via Schtasks.EXEid: 92626ddd-662c-49e3-ac59-f6535f12d189status: testdescription: Detects the creation of scheduled tasks by user accounts via the "schtasks" utility.references: - https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/schtasks-createauthor: Florian Roth (Nextron Systems)date: 2019-01-16modified: 2025-10-22tags: - attack.execution
- attack.persistence
- attack.privilege-escalation
- attack.t1053.005
- attack.s0111
- car.2013-08-001
- stp.1u
logsource: category: process_creation product: windowsdetection: selection: Image|endswith: '\schtasks.exe' CommandLine|contains: ' /create ' filter_main_system_user: User|contains: # covers many language settings - 'AUTHORI'
- 'AUTORI'
filter_optional_msoffice: # schtasks.exe /Create /tn "Microsoft\Office\Office Performance Monitor" /XML "C:\ProgramData\Microsoft\ClickToRun\{9AC08E99-230B-47e8-9721-4577B7F124EA}\Microsoft_Office_Office Performance Monitor.xml"
ParentImage: - 'C:\Program Files\Microsoft Office\root\integration\integrator.exe' - 'C:\Program Files (x86)\Microsoft Office\root\integration\integrator.exe' Image: - 'C:\Windows\System32\schtasks.exe' - 'C:\Windows\SysWOW64\schtasks.exe' CommandLine|contains: 'Microsoft\Office\Office Performance Monitor' condition: selection and not 1 of filter_main_* and not 1 of filter_optional_*falsepositives: - Administrative activity
- Software installation
level: low
Scheduled Task Creation Via Schtasks.EXE · SigmaHQ rule 92626ddd-662c-49e3-ac59-f6535f12d189
If your test came back silent, that rule is the whole fix. Drop it into your SIEM, or send your provider this page — “we ran this, nothing fired, here’s the detection.” Either way your coverage is better tonight than it was this morning. That’s the point.
A new one every week
This is technique 04 of many.
Each one is a real attacker move, a safe way to try it, and the detection to close the gap. Run them over a few weeks and you’ll learn more about your real coverage than any dashboard has told you.
Curious how a system catches all of these at once, out of the box? That’s what we build — meet Mobula →
Credit & sources
The technique and the incident are documented by MITRE ATT&CK (T1053.005) and the sources linked above. The detection is expressed in Sigma, the open detection format maintained by the SigmaHQ community, so any team can use it freely; its author is credited above under DRL 1.1.
We show you public attacker tradecraft and public detection logic, and hand you both. Nothing here reveals anything an attacker doesn’t already have — it just makes sure the defender has it too.
CYRAY · MOBULA — SECURITY OPERATIONS, ORCHESTRATED BY AI