I85PREP
⌘ K
ATT&CK Threat Hunting study materials
ATT&CK Threat Hunting study resources

Reconciling a Hunt Report Against a Moved ATT&CK Version

ATT&CK Threat Hunting · Put your knowledge to work in context.

All case studies

Reconciling a Hunt Report Against a Moved ATT&CK Version

Your team is reconciling a hunt report from a manufacturing incident closed three weeks ago. The hunter recorded: an encoded PowerShell command launched through WMI, a scheduled task created to relaunch it at logon, and a base64-obfuscated payload written to disk. The draft mapping lists T1086 (PowerShell), T1047 (WMI), T1053 (Scheduled Task/Job) and T1027 (Obfuscated Files or Information). It was written against ATT&CK v12, while your programme is pinned to v15. A vendor's coverage dashboard, meanwhile, claims 100% coverage of T1059, T1047 and T1053 for your EDR and Windows event pipeline. The CISO wants a one-page answer before tomorrow's board meeting: is the mapping right, and are we actually covered? You have 30 minutes, the report only (no endpoint access), and the environment is Windows 10 and Server 2019 exclusively - no macOS or Linux, so platform tags matter for scope.

1. Produce the corrected v15 mapping for the report and justify every change, including what you would reject or re-scope.

Read the worked answer

The draft mixes ATT&CK versions. Corrected v15 mapping:

  • T1086 → T1059.001 (PowerShell). T1086 was deprecated and no longer exists. The observable is PowerShell execution, so the sub-technique is the correct cell.
  • T1053 → T1053.005 (Scheduled Task). Scheduled Task/Job was split into platform-specific sub-techniques. The at-logon relaunch on Windows is .005; leaving the parent implies cron and systemd coverage you do not have.
  • T1047 (WMI) stays. WMI is a technique in its own right, not a child of T1059. The WMI launch and the PowerShell it launched are two separate procedures and should both be scored.
  • T1027 → T1027.010 (Command Obfuscation). The encoded command is the obfuscation; keep the parent only if your layer cannot score sub-techniques.
  • Reject double-scoring. Do not award one procedure extra cells across tactics to inflate the layer. One procedure, one cell per tactic it genuinely serves.
  • Re-scope by platform. Filter the layer to Windows, so Linux and macOS sub-techniques of T1059 are marked out of scope rather than counted as gaps.

What is still missing and cannot be resolved from the report: whether the payload was pulled in (T1105) and what the base64 blob actually did. Flag both as open questions for the hunter rather than guessing.

2. The vendor dashboard claims 100% coverage of T1059, T1047 and T1053. How do you reframe that for the board, and what evidence would you demand before repeating the number?

Read the worked answer

Treat the claim as a roll-up, not as evidence of detection. A parent-technique score aggregates everything underneath it: T1059 spans PowerShell, cmd shell, Python, VBA, JavaScript, Unix shell and network device CLI. A detection built on PowerShell script block logging (4104) covers T1059.001 only, and only on hosts where that logging is enabled and shipping.

Demand, per sub-technique: the named data component the analytic consumes; the validation performed (Atomic Red Team test ID and date, purple-team observation, or a production true positive); production volume and measured precision over the last 90 days; deployment scope as a percentage of the 6,000 endpoints; and whether the analytic is version-controlled and monitored for data-source failure.

Specific weak points to probe: T1047 coverage usually rests on WMI-Activity/Operational events (5857, 5860, 5861), which are disabled on many builds and are extremely noisy when enabled. T1053 coverage that relies only on 4698 misses service-creation and COM-based persistence that reuses the same execution path.

Board framing: 'We have validated detection for N sub-techniques on Y% of endpoints; M sub-techniques have no usable data source.' Coverage is a claim about validated analytics running on current data - not about a content pack being installed.

3. Given that you only have the report, what is a defensible written conclusion, and what do you ask the hunter for?

Read the worked answer

Separate three different claims: behaviour reported in the source incident, behaviour mapped into ATT&CK, and behaviour observed in your estate. You hold evidence only for the first two. Nothing in the report shows the technique executed on your hosts, so the conclusion must be phrased as 'mapped and not yet tested here', not 'detected'.

The v15 correction does not change the behaviour, so the hunt plan can proceed unchanged in scope: four queries against 4104 script block text for encoded invocations, WMI-Activity events, 4698 task registration plus the task XML, and file-creation events for the base64 blob - all bounded by the 30-day hot retention.

Ask the hunter for: the exact 4104 script block text, the scheduled task XML rather than only the registration event, the WMI filter and consumer names, the file hash and size of the payload, and the host and user context of each step. Those artefacts are what turn a mapping into detection logic and what let a detection engineer write test cases.

Finally, record the limitation explicitly: a single-endpoint narrative with an unanalysed base64 payload bounds the confidence of any coverage statement built on it.