How to Read a MITRE ATT&CK Technique Page and Write a Detection Rule From It

An ATT&CK technique page has approximately 8 sections. Four are directly useful for detection rule writing.

Section 1: Description (read for behavior, not for rule logic) The description tells you what the attacker is doing and why. It is written in threat intel language, not detection language. Read it to understand the behavior, then translate: 'what observable event does this create on the endpoint or in a log?'

For T1053.005: 'Adversaries may abuse the Windows Task Scheduler to perform task scheduling for initial or recurring execution of malicious code.' The detection question becomes: what Windows events are generated when a scheduled task is created, modified, or executed?

Section 2: Sub-techniques (choose one to start) ATT&CK breaks broad techniques into sub-techniques for specificity. Detection rules should target sub-techniques, not parent techniques: the parent is too broad to produce useful queries. T1053 (Scheduled Task/Job) has five sub-techniques. T1053.005 (Windows Scheduled Task) is the most relevant for Windows environments.

Section 3: Procedure Examples (your ground truth for what real attacks look like) This is the most valuable detection engineering section. Procedure examples show specific tools, commands, and methods that real threat actors have used for this technique in confirmed campaigns. These are your tuning examples: they tell you what malicious execution looks like versus the benign equivalent.

For T1053.005, procedure examples include:

• APT29 using schtasks /create with randomized task names and encoded PowerShell commands
• FIN7 creating scheduled tasks via at.exe (legacy)
• Ransomware groups creating tasks in C:\Windows\System32\Tasks with executable paths pointing to %TEMP%

Section 4: Detection (your rule starting point) The Detection section explicitly recommends data sources and observable behaviors. It does not give you a complete SIEM query, but it identifies: what to collect, what fields to examine, and which values distinguish malicious from benign.

For T1053.005, the detection section recommends:

• Monitor Windows Event ID 4698 (a scheduled task was created)
• Examine the task XML for suspicious executable paths, encoded arguments, and unusual authors
• Monitor C:\Windows\System32\Tasks and C:\Windows\SysWOW64\Tasks for new file creation

Once you have read the four relevant sections, translate the technique into detection rule components by answering three questions:

Question 1: What is the observable event? Not 'the attacker creates a scheduled task': the behavior you can detect as a data point. In log terms: what Event ID, what log file, what system call, what file modification?

For T1053.005: Windows Security Event ID 4698 (Scheduled task created), with the task XML in the event data.

Question 2: What data source captures it? Which log source must be enabled and forwarding to your SIEM for this detection to work?

For T1053.005: Windows Security audit log (requires 'Audit Other Object Access Events' policy to be enabled). File system monitoring on C:\Windows\System32\Tasks via Sysmon Event ID 11 (file created) as a supplementary source.

Question 3: What distinguishes malicious from benign? This is the tuning question. Hundreds of legitimate applications create scheduled tasks. Your rule needs to alert on malicious task creation without generating noise from software updaters, backup agents, and Windows itself.

For T1053.005, the distinguishing characteristics from real attacker campaigns:

• Task executable path in %TEMP%, %APPDATA%, %PUBLIC%, or C:\Users directories (benign tasks almost always run from C:\Windows, C:\Program Files, or C:\Program Files (x86))
• Encoded base64 in the task command arguments
• Task author is None or a non-standard string
• Task created by a user account rather than SYSTEM or a software installer
• Randomized 8-16 character task name (attacker-generated names lack the product branding of legitimate task names)

Splunk SPL:

index=windows EventCode=4698
| rex field=_raw "<Command>(?P<command>[^<]+)</Command>"
| rex field=_raw "<Author>(?P<author>[^<]+)</Author>"
| rex field=_raw "<TaskName>(?P<taskname>[^<]+)</TaskName>"
| where (
    match(lower(command), "\\(temp|appdata|public|users\\\\[^\\\\]+\\\\)")
    OR match(command, "[A-Za-z0-9+/]{20,}={0,2}")
    OR isnull(author) OR author=""
  )
| table _time, host, user, taskname, command, author
| sort -_time

This query:

1. Filters for Event ID 4698 (scheduled task created)
2. Extracts the command, author, and task name from the raw event XML
3. Alerts when the command path is in a user-writable directory, contains base64-encoded content, or has no author field

Microsoft Sentinel KQL:

SecurityEvent
| where EventID == 4698
| extend TaskXml = tostring(EventData)
| extend Command = extract(@"<Command>([^<]+)</Command>", 1, TaskXml)
| extend Author = extract(@"<Author>([^<]+)</Author>", 1, TaskXml)
| extend TaskName = extract(@"<TaskName>([^<]+)</TaskName>", 1, TaskXml)
| where Command has_any ("\\Temp\\", "\\AppData\\", "\\Public\\")
      or Command matches regex @"[A-Za-z0-9+/]{20,}={0,2}"
      or isempty(Author)
| project TimeGenerated, Computer, Account, TaskName, Command, Author
| sort by TimeGenerated desc

Sigma rule (portable across SIEM platforms):

title: Suspicious Scheduled Task Creation - Temp/AppData Path or Encoded Command
id: a8b5f7c2-3d4e-5f6a-7b8c-9d0e1f2a3b4c
status: test
description: Detects scheduled task creation with command paths in user-writable directories or base64-encoded arguments
references:
    - https://attack.mitre.org/techniques/T1053/005/
tags:
    - attack.persistence
    - attack.t1053.005
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4698
    filter_paths:
        CommandPath|contains:
            - '\Temp\'
            - '\AppData\'
            - '\Public\'
    filter_encoded:
        CommandArgs|re: '[A-Za-z0-9+/]{20,}={0,2}'
    condition: selection and (filter_paths or filter_encoded)
falsepositives:
    - Legitimate software installers that temporarily place executables in Temp during installation
level: high

After deploying the rule, run it against 30 days of historical data before enabling live alerting. Any results that are known-good software create your exclusion list.

Common legitimate false positives for T1053.005:

• Windows Defender definition updates (creates tasks with encoded update paths)
• Adobe Creative Cloud updater (creates tasks in AppData)
• Browser auto-update tasks (Chrome, Firefox)
• Corporate software deployment agents (SCCM, Intune)

Exclude these by hash (most stable), or by executable path AND signing certificate (for software that updates its hash frequently). Never exclude by task name alone: attackers copy legitimate task names to blend in.

The Sigma approach: If you write the rule in Sigma format, it is portable across SIEM platforms: the same rule generates Splunk SPL, Elastic DSL, or KQL through the sigma-cli converter. This is the recommended format for rules you want to maintain across a team or share with the community.

Next steps after this technique: Once T1053.005 is deployed and tuned, repeat the process for the next highest-priority technique in your threat model. Most organizations following this methodology work through ATT&CK's top 20 most commonly exploited techniques before moving to more obscure sub-techniques. The CISA Top Routinely Exploited Techniques advisory is the best starting point for prioritizing which techniques to address first.