Les Miserable Persistence Hunting Through Scheduled Tasks

Most published guidance explains how to catch newly created Windows scheduled tasks through command-line activity, process creation, registry changes, or event logging. This talk asks the harder question of what to do about tasks already sitting on machines. The speaker argues that scheduled tasks are a common secondary persistence method across threat groups, and that the relevant Windows event IDs are disabled by default, so existing tasks need a separate hunt.

The walkthrough uses PowerShell on a fresh Windows build seeded with one simulated malicious task. Grouping task actions by executable and filtering on folder location, arguments, author and run-as user surfaces many legitimate tasks that look suspicious, including Amazon EC2 startup scripts and Microsoft tasks with inconsistent metadata. The planted task is finally found through an unusual local administrator author pointing to an executable running from a temp directory. The speaker then tried several routes to load the XML task files into Elasticsearch, including JSON, NDJSON and a Logstash parser, before converting to CSV and building dashboards for timelines, settings and principals.

The main takeaways are that creation dates and other task metadata can be set to anything, so a date alone does not prove a task is new, and that hidden and disabled tasks ship by default and offer cover for persistence. Knowing what normal looks like on your own builds matters more than any single filter. The speaker closed with open questions about mimicking Microsoft's hidden tasks and whether tasks can enable privilege escalation.