Lion Cipher Lab

Detect scheduled-task persistence in Windows event logs

• SOC Analyst / Blue Team
• Intermediate
• ~50 min
• Free · no account required

Why it matters

When an attacker gets a foothold on a Windows machine, the very next thing they want is to survive a reboot, a logoff, and the user closing the laptop lid — they want PERSISTENCE. And the scheduled task is one of the most popular ways to get it, catalogued by MITRE ATT&CK as technique T1053.005, because it is close to perfect cover: the Task Scheduler is a signed, built-in, always-running part of Windows; every real machine already has dozens or hundreds of legitimate tasks from Windows itself and from installed software; and a task can be told to run any command at logon, at boot, on a…

What you'll learn

• explaining what a scheduled task is, why attackers abuse it for persistence (MITRE ATT&CK T1053.005), and why it hides so well among a machine full of legitimate tasks
• proving the default-blind gap: creating a benign-but-suspicious task on your own machine and confirming NO Security-log Event ID 4698 is written, because the audit subcategory is off out of the box
• turning on the right telemetry: enabling the 'Audit Other Object Access Events' subcategory with auditpol, and enabling the Microsoft-Windows-TaskScheduler/Operational log — and knowing exactly which events each one gives you
• reading scheduled-task events in Event Viewer and with Get-WinEvent / wevtutil: 4698 (created), 4702 (updated), 4699 (deleted), 4700/4701 (enabled/disabled), and TaskScheduler/Operational 106 (registered), 140 (updated), 141 (deleted)
• extracting the high-signal detail from 4698 — the TaskContent XML carrying the author, the exact command line, arguments and the trigger — which is what turns 'a task was created' into 'a task that runs powershell at logon was created by a local user'
• writing a Sigma detection rule for the malicious pattern (an action that launches a script interpreter or lives in a suspicious path) and understanding Sigma's logsource / detection / condition structure
• testing the rule for real: converting its logic to a Get-WinEvent filter (or running sigma-cli), watching it FIRE on the malicious task and STAY SILENT on a legitimate Windows maintenance task — the true-positive and true-negative that validate a detection
• judgment: tuning on author/path/interpreter instead of the bare event to survive installer false positives, and pairing 4698 with process-creation and file/registry telemetry so a single evadable event ID is not your whole defence

Steps in this lab

1. What a scheduled task is, why attackers love it, and what you are about to detect
2. BEFORE: create a benign-but-suspicious task and watch NO 4698 appear
3. Turn the telemetry on: auditpol subcategory + the TaskScheduler operational log
4. AFTER: recreate the task and read 4698 — the command line is right there in the XML
5. Write the Sigma rule: describe the malicious shape, not the bare event
6. TEST the rule: it must FIRE on the malicious task and stay SILENT on a benign one
7. Do it better — tune honestly, know the evasions, and build a program not a tripwire

Open the full interactive lab →