Coverage Gap: proc_creation_win_schtasks_creation — Schedule.Service COM Object Bypass

Rule UUID

92626ddd-662c-49e3-ac59-f6535f12d189

Example Telemetry

Control test — Sysmon EID 1 (rule fires as designed):

Image: C:\Windows\System32\schtasks.exe
CommandLine: schtasks.exe /create /tn SigmaTest_Control /tr "cmd.exe /c whoami" /sc once /st 23:59
ParentImage: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
User: JAMES-VM\william
UtcTime: 2026-08-22 17:48:52.960

Alternative test — Sysmon EID 1 query after COM-based registration (no schtasks.exe event exists):

Image: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
CommandLine: powershell.exe -ExecutionPolicy Bypass -File sigma-alt-schtasks-com.ps1
User: JAMES-VM\william

Security EID 4698 (fires after enabling Object Access audit policy):

TimeCreated: 8/22/2026 11:43:43 AM
EventID: 4698
Task Name: \SigmaTest_Alternative3
Subject: JAMES-VM\william
ClientProcessId: 13136
TaskContent: <full task XML including cmd.exe and /c whoami>

Description

During lab validation on Windows 11 (build 26100) with Sysmon active, I confirmed the rule fires correctly against a standard schtasks.exe /create invocation. I then registered an equivalent scheduled task using the Schedule.Service COM object via PowerShell (New-Object -ComObject Schedule.Service → Connect() → NewTask() → RegisterTaskDefinition()). The task registered successfully. No schtasks.exe process was spawned at any point, so the rule's Image|endswith: '\schtasks.exe' clause never evaluates true. The rule does not fire. Confirmed structurally via field-by-field comparison, not just by absence of output.

This technique has documented real-world use in Latrodectus campaigns and DarkHotel tradecraft.

I then checked the three alternate telemetry layers:

Microsoft-Windows-TaskScheduler/Operational EID 106 fires for the COM-registered task, but this log is disabled by default on this build. The only SigmaHQ rule targeting EID 106 for task creation is win_taskscheduler_rare_schtask_creation.yml (b20f6158), which currently carries status: unsupported.

Security EID 4698 also fires with full task XML inline, but requires Object Access > Other Object Access Events audit policy which is not enabled by default. win_security_susp_scheduled_task_creation.yml (3a734d25, status: test) does cover EID 4698, but its condition requires both a suspicious command match and a suspicious path match. A payload without a suspicious path reference will not satisfy both clauses.

Question: should proc_creation_win_schtasks_creation.yml reference win_security_susp_scheduled_task_creation.yml in a related: field as a documented compensating control? And separately, is there appetite for revisiting the status: unsupported on b20f6158 given the active real-world use of this technique?

Full reproduction, raw telemetry, and field-level analysis: https://github.com/WiLL75G/sigma-rule-validation-scheduled-task-com