A common persistence detection watches for one thing: schtasks.exe creating a task. It is a sound rule for the case it names. The trouble is that "schedule a task" has more than one spelling, and the rule knows one of them.
So we ran the same persistence two ways, on a machine we own, and watched what each produced.
First the textbook way: schtasks.exe with its /create flag. The process log shows schtasks.exe, /create on the command line, exactly what the rule expects. Anyone watching for it sees it.
Then Register-ScheduledTask from PowerShell, which drives the Task Scheduler's COM interface directly. Same outcome — a task registered to run the attacker's code later. But schtasks.exe never runs, so there is no process event for it to produce. Our process log held the first attack's schtasks.exe event and nothing at all from the second. Same persistence, nothing to match.
The task landed both times. Security 4698 fired twice, and TaskScheduler/Operational 106 fired twice. The ground truth was sitting there the whole run. The detection missed the second one not because the evidence was absent, but because it was watching the name of a tool instead of the act of scheduling.
There is a sharper version of the same blind spot. The rule excludes tasks created by NT AUTHORITY\SYSTEM, so it stays quiet during ordinary background activity. That account is exactly what an intruder is running as once they have escalated — so the textbook attack, run after escalation, is waved through by design.
The lesson is not that the rule is bad. It is that a detection anchored to one tool's name inherits that tool's blind spots. Persistence is an outcome. Assert the outcome — a task was registered, read from 4698 — not the name of whichever program registered it this time.
Worth trying on Monday: run Register-ScheduledTask on a lab box and see whether anything in your console notices.