From Intelligence to Detection: Operationalising MITRE ATT&CK.

This is the post where theory meets practice.

Over the previous four posts in this series, we've covered what CTI is, where intelligence comes from, how to think analytically, and how to profile threat actors. All of that is foundation. This post is about the operational bridge — how you take threat intelligence, run it through established frameworks, and produce detections that actually improve your security posture.

The frameworks we'll cover — MITRE ATT&CK, the Diamond Model, the Cyber Kill Chain, and the Pyramid of Pain — are well-known. What's less well-known is how to use them together as a practical system rather than treating each one as a standalone reference. And the connecting discipline — detection engineering — is what turns framework knowledge into defensive capability.

Let's build the pipeline.

Step 1: Start with threat actor TTPs (your input)

Your intelligence work from earlier in this series produces threat actor profiles. Each profile identifies the techniques your adversaries use — their tactics, techniques, and procedures. These are your inputs.

If you don't have formal threat actor profiles yet, start with the threat reporting you consume. Take the last five threat intelligence reports relevant to your organisation. Identify the techniques described in each. That's your starting dataset.

Every technique should map to MITRE ATT&CK. If the report describes “the attacker used PowerShell to execute a download cradle” (a short one-liner that pulls a payload from a remote host and runs it in memory), that's T1059.001 (Command and Scripting Interpreter: PowerShell). If it describes “credentials were dumped from LSASS memory,” that's T1003.001 (OS Credential Dumping: LSASS Memory).

Practical tip:You don't need to be perfect. ATT&CK mapping involves judgment calls — the same activity might map to multiple techniques, and different analysts might map it differently. Consistency matters more than precision. Pick the most specific sub-technique that fits and move on.

Common mistake:Stopping at the tactic level (“the attacker achieved Persistence”) rather than the technique level (“the attacker used T1053.005 — Scheduled Task”). But technique and sub-technique are often still too abstract on their own. Two intrusions can both map to T1053.005 and look nothing alike in practice — one drops a scheduled task via schtasks.exefrom a user shell, another registers it through a COM interface from a signed binary. If you lose the procedure — howthe technique was actually used — you lose the detail detection engineering needs. Capture the technique ID, and capture the specific procedure alongside it.

Step 2: Assess your detection coverage (your gap analysis)

For each ATT&CK technique in your priority list, answer three questions:

Question 1: Do we have the data?
Every ATT&CK technique requires specific telemetry to detect. T1059.001 (PowerShell) requires Windows PowerShell logging or Script Block Logging (Event ID 4104). T1003.001 (LSASS credential dumping) requires Sysmon Event 10 (ProcessAccess) with handle-access masks that indicate memory read against lsass.exe— generic process monitoring isn't enough. If you don't collect the right data, detection is impossible regardless of your rules.

Check the ATT&CK Data Sources field for each technique. Map these to your actual telemetry. Where you have the data: proceed to detection rules. Where you don't: data source enablement becomes your first priority.

Question 2: Do we have a detection rule?
For each technique where you have the data, check whether you have a specific detection rule. Not a general alert that might incidentally catch it — a purpose-built rule designed to detect this technique.

Sources for detection rules:

• Your existing SIEM rule library
• The SIGMA rule repository (github.com/SigmaHQ/sigma) — community-maintained, platform-agnostic
• Vendor detection content (Elastic Detection Rules, Splunk Security Essentials, etc.)
• Your own custom rules from previous incidents

Question 3: Have we validated the detection?
A detection rule that exists but hasn't been tested is not a detection — it's a hope. Validation means simulating the technique in a test environment and confirming the rule fires correctly.

Tools for validation:

• Atomic Red Team— pre-built test cases mapped to ATT&CK techniques
• CALDERA— MITRE's automated adversary emulation platform
• Manual testing— executing the technique in a lab environment and checking detection

Rate each technique: Green (validated detection with telemetry), Yellow (rule exists but unvalidated, or telemetry gaps), Red (no detection or no telemetry).

Step 3: Prioritise your gaps (your work queue)

You now have a list of red and yellow items. You can't fix everything at once. Prioritise based on:

Threat relevance: Techniques used by your top-priority threat actors rank higher. If three of your five tracked actors use T1059.001, it ranks above a technique used by one.

Detection feasibility: Some techniques are easier to detect than others. T1059.001 with proper logging is very detectable. T1550.002 (Pass the Hash) in a complex Active Directory environment is harder. Start with high-relevance, high-feasibility items.

Impact of miss:What happens if you don't detect this technique? If it's an early-stage technique (initial access, execution), missing it means the attacker operates freely. If it's a late-stage technique (exfiltration), missing it means data loss.

Step 4: Build detections (your output)

For each priority gap, build a detection rule. Let me walk through a concrete example.

Scenario:Your threat actor profile indicates use of T1053.005 — Scheduled Task/Job: Scheduled Task for persistence. You have Windows Event logs but no specific detection.

Step 4a: Understand the technique.
What does T1053.005 look like? An attacker creates a scheduled task using schtasks.exe, PowerShell, or the Windows API. The task executes a payload on a schedule or at system startup.

Step 4b: Identify detection opportunities.

• Windows Security Event 4698 (Scheduled Task Created)
• Sysmon Event 1 (Process Creation) for schtasks.exe execution
• Command-line arguments containing suspicious patterns (execution from temp directories, encoded commands, etc.)

Step 4c: Write the SIGMA rule.

title: Suspicious Scheduled Task Creation via schtasks.exe
id: 00000000-0000-0000-0000-000000000000  # generate your own with uuidgen
status: experimental
description: Detects schtasks.exe creating a scheduled task that points at a payload in a user-writable directory
references:
    - https://attack.mitre.org/techniques/T1053/005/
author: CTI Team
date: 2026/05/12
tags:
    - attack.persistence
    - attack.t1053.005
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        Image|endswith: '\schtasks.exe'
        CommandLine|contains: ' /create'
    selection_path:
        CommandLine|contains:
            - '\Temp\'
            - '\AppData\Local\'
            - '\Users\Public\'
            - '\ProgramData\'
    condition: selection_img and selection_path
falsepositives:
    - Legitimate software installers creating tasks that reference user-profile paths
    - Administrator scripts staging binaries from ProgramData
level: medium

A few notes on the rule above, since readers will (rightly) copy and adapt it:

• Generate your own id. Every SIGMA rule needs a unique UUID (uuidgen on macOS/Linux). The placeholder is only there so the YAML parses.
• Naming convention. In SIGMA, identifiers prefixed filter_ are, by convention, exclusion selectors that get negated in the condition. The selectors above are inclusion selectors, so we name them selection_* to avoid confusing anyone maintaining the rule later.
• Why process_creation and not Event 4698. Event 4698 (A scheduled task was created) is the other obvious place to look, but its TaskContentfield is a full XML blob — matching path strings inside it is imprecise and noisy. Anchoring on schtasks.exeprocess creation (Sysmon Event 1 or Windows 4688 with command-line auditing enabled) gives you the command line directly. For a production programme you'd want both: this rule for the command-line path, plus a second rule parsing Event 4698's TaskContent XML properly.

Step 4d: Test the rule.
In a test environment, create a scheduled task matching the detection criteria. Verify the SIGMA rule (converted to your SIEM syntax) fires correctly. Also create legitimate scheduled tasks to check false positive rates.

Step 4e: Deploy and tune.
Deploy to production. Monitor for false positives over 1-2 weeks. Tune the rule (adjust paths, add exclusions for known-good tasks) until the false positive rate is manageable.

Step 5: Use the Diamond Model for investigation support

While ATT&CK drives your detection programme, the Diamond Model drives your investigation process. When a detection fires:

Vertex 1 — Victim: Your organisation (known).
Vertex 2 — Infrastructure: The C2 server, phishing domain, or delivery infrastructure (often partially known from the detection).
Vertex 3 — Capability:The malware, tool, or technique used (known from the detection and ATT&CK mapping).
Vertex 4 — Adversary: Often unknown initially.

Pivot along edges:

• Capability → Infrastructure: What infrastructure is associated with this malware family? (Check threat intelligence platforms, VirusTotal, community reporting.)
• Infrastructure → Victim: Who else has this infrastructure targeted? (Check threat feeds, ISAC sharing, peer contacts — the HUMINT sources from Post 2.)
• Capability → Adversary: Which tracked groups use this tool? (Check ATT&CK group mappings, vendor reporting.)

Each pivot expands your understanding and generates new investigative leads. The Diamond Model ensures you systematically explore every analytical avenue rather than following a single thread.

Step 6: Apply the Pyramid of Pain to prioritise your programme

David Bianco's Pyramid of Pain should guide your overall programme priorities:

Bottom of the pyramid (low value, trivially changed by adversaries):

• Hash values (MD5, SHA256 of malicious files)
• IP addresses
• Domain names

These are your IOCs. They have value for immediate, tactical detection — blocking a known-bad IP prevents that specific attack. But the adversary changes them in minutes.

Middle of the pyramid (moderate value, moderate cost to change):

• Network artefacts (URI patterns, JA3 fingerprints)
• Host artefacts (registry keys, file paths, named pipes)
• Tools (Cobalt Strike, Mimikatz, specific malware families)

These require more effort for the adversary to change. Detecting Cobalt Strike's default Malleable C2 profile forces the adversary to customise their tooling.

Top of the pyramid (highest value, most costly to change):

• TTPs — the behaviours themselves

Detecting “lateral movement via WMI” forces the adversary to change their operational methodology. That's expensive, risky, and time-consuming.

Your programme should aim to climb the pyramid over time. Start where you are — most teams start with IOCs — but deliberately invest in moving toward TTP-level detection. Every SIGMA rule you build against an ATT&CK technique is a step up the pyramid.

The Cyber Kill Chain as a balance check

Use the Kill Chain periodically — quarterly is sufficient — to check the balance of your detections across the attack lifecycle:

If your detections are concentrated in one or two phases, you have a blind spot. A balanced detection programme covers multiple phases, ensuring that an adversary who evades one detection layer encounters another.

Making it sustainable

This pipeline — intelligence → ATT&CK mapping → gap analysis → detection building → validation → deployment — is an ongoing process, not a one-time project. Threats evolve. Your environment changes. New techniques emerge.

Sustainability requires:

• Regular cadence: Monthly detection sprint where new intelligence feeds into new detections.
• Cross-team collaboration: CTI and detection engineering working together, not in silos. Shared tools, shared metrics, shared priorities.
• Measurement:Track coverage metrics that matter. “Percentage of priority techniques with validated detections” is meaningful. “Number of SIEM rules” is not.
• Automation where possible: The mapping and gap analysis steps are tedious and automatable. This is a core function of Liberty91's platform— maintaining the bridge between intelligence and detection coverage so teams can focus on the analytical and engineering work that requires human skill.

The frameworks are excellent. The tradecraft is well-established. The techniques for building detections are mature. What most organisations lack is the operational pipeline that connects them — the bridge between “we know what the adversary does” and “we can detect when they do it.” Building that bridge is how CTI creates measurable security value.

And that's worth more than all the ATT&CK Navigator heatmaps in the world.

This is Part 5 of the “CTI from the Trenches” series. ← Previous: Threat Actor Profiling for Defenders | Next: The Tools and Platforms That Actually Help → (coming soon)