Writing Detection Rules for Common MITRE ATT&CK Techniques

A detection rule that fires 500 times a day isn’t security — it’s wallpaper. The hard part of mapping ATT&CK to your SIEM isn’t picking techniques to cover; it’s writing logic that catches the technique without burying the SOC in noise. The framework gives you the vocabulary. Telemetry, tuning, and intent give you the rules.

This guide walks through how to build detection rules for the ATT&CK techniques that adversaries actually use most — T1078.004 Cloud Accounts, T1059.001 PowerShell, T1055 Process Injection, T1053.005 Scheduled Task, and T1204.004 Malicious Copy and Paste — using Sigma as the portable rule language and ATT&CK v18’s new Detection Strategies model as the authoring framework. The goal is rules that survive contact with production: high signal, mapped accurately, and tuned for the environment they run in.

What Changed in ATT&CK v18 — and Why It Matters for Detection Engineers

ATT&CK v18, released October 28, 2025, replaced the old static Detection field on each technique with structured Detection Strategies and Analytics objects, alongside major updates to Data Components and the deprecation of Data Sources. The Enterprise matrix now contains 216 Techniques, 475 Sub-Techniques, 691 Detection Strategies, 1,739 Analytics, and 106 Data Components. ATT&CK v19 is scheduled for April 28, 2026.

The shift matters because the old model gave you a sentence per technique — something like “monitor process creation for suspicious PowerShell.” That’s not a rule; it’s a hint. Detection Strategies decompose a technique into pseudocode-style analytics tied to specific Data Components (e.g., Process: Process Creation, Command: Command Execution), with platform-aware collection guidance. When you sit down to write a Sigma rule today, you start from an analytic that already specifies the data shape, the field of interest, and the logic primitive. Your job is translation and tuning, not invention.

This is also the model the rest of the industry has converged on. Red Canary, Splunk Security Content, Elastic Detection Rules, and the SigmaHQ repository all map their detections back to ATT&CK technique IDs. Picus Labs analyzed 1,084,718 malware samples in 2025 and mapped 13.3 million observed TTPs to ATT&CK to rank prevalence. The framework is the lingua franca; Sigma is the implementation layer.

The Detection Engineering Workflow, in Order

Every durable detection follows the same path. Skip a step and the rule either misses the technique or fires constantly on benign behavior.

Steps 4 and 5 are where most teams break down. A rule that hasn’t been tested against an emulated execution of its target technique is an assertion, not a detection. A rule that hasn’t been backtested against the environment is a future ticket avalanche.

Detecting T1059.001 — PowerShell Execution

PowerShell remained one of the most consistently abused execution vectors in 2025, despite Cloud Accounts overtaking it as the single most-detected technique in the Red Canary 2025 Threat Detection Report. Adversaries reach for it because it’s signed, native, network-capable, and trivially obfuscated. The detection problem is that legitimate administrators and software also use it constantly.

The first useful primitive is -EncodedCommand. Encoded PowerShell payloads are statistically rare in benign use and overwhelmingly common in malicious scripts dropped by loaders, post-exploitation frameworks, and ClickFix-style lures. A baseline Sigma rule looks like this:

yaml
title: PowerShell EncodedCommand Execution
id: a1b2c3d4-...
status: stable
description: Detects PowerShell processes invoked with the EncodedCommand switch
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - '-EncodedCommand'
      - '-enc '
      - ' -e '
  condition: selection
falsepositives:
  - Legitimate administrative scripts using encoded commands
  - Some software installers and configuration management tools
level: high
tags:
  - attack.execution
  - attack.t1059.001

Two things make this rule survive production. First, the multiple selection variants catch the abbreviated forms (-enc, -e) that attackers use to bypass naive string matches. Second, the falsepositives field is honest — encoded commands do occur in benign automation, which means the rule needs an environment-specific filter list. Add a second selection group that excludes known administrative parent processes (your patching tool, your configuration management agent), then use condition: selection and not filter.

For higher-fidelity coverage of T1059.001, layer additional rules: PowerShell making outbound network connections via System.Net.WebClient, PowerShell parent processes that should never spawn a shell (winword.exe, excel.exe, outlook.exe), and ScriptBlockText containing reflective loading patterns. Each rule maps to the same technique tag but covers a different procedure.

Detecting T1078.004 — Cloud Accounts

Cloud Accounts took the number-one ATT&CK ranking in Red Canary’s 2025 report, with identity-related detections increasing roughly fivefold over the prior year — a function of both genuine threat-landscape shift and improved telemetry coverage. The detection challenge is fundamentally different from endpoint techniques because the signal lives in cloud audit logs (AWS CloudTrail, Microsoft Entra ID sign-in logs, Google Workspace audit logs) rather than process telemetry.

Three primitives carry most of the weight: impossible travel (sign-in from two geographies separated by more than feasible flight time), anomalous session token reuse, and sign-ins from infrastructure-as-a-service IP ranges where end users should never originate. The last is the cleanest detection. A Sigma rule for an Azure AD context flags interactive sign-ins where the source IP belongs to a known cloud provider ASN — adversaries routinely operate from compromised cloud infrastructure or commercial residential proxies, and matching against IP intelligence feeds turns this into a tractable rule.

Cloud detection rules also need to accommodate T1556.006 (MFA bypass via session cookie theft) and T1606.002 (SAML token forgery), both of which surfaced repeatedly in the Salt Typhoon and Velvet Ant campaigns added to ATT&CK v17. A single “suspicious sign-in” rule won’t carry the load — the cloud identity surface needs a layered detection strategy targeting authentication, post-authentication actions (mailbox forwarding rules T1114.003, OAuth grant abuse), and persistence (additional credentials, federated trust modifications).

Detecting T1055 — Process Injection

Picus Labs ranked Process Injection as the single most prevalent technique observed across 13.3 million mapped TTPs in 2025. It’s the workhorse of malware defense evasion: load malicious code into the address space of a legitimate process and inherit its trust. The sub-techniques (T1055.001 DLL Injection, T1055.002 Portable Executable Injection, T1055.012 Process Hollowing, T1055.004 Asynchronous Procedure Call) each have distinct signatures.

Behavioral detection beats signature detection here. The classic indicator is a process opening a handle to another process with PROCESS_VM_WRITE and PROCESS_CREATE_THREAD access rights, captured by Sysmon Event ID 10 (ProcessAccess). A Sigma rule selecting on GrantedAccess: '0x1F0FFF' or specific access mask combinations on cross-process handles, excluding known security tools, flags injection attempts before the payload runs.

Process Hollowing — where an attacker creates a suspended process and overwrites its memory before resumption — leaves a different fingerprint: a child process whose image on disk doesn’t match its in-memory contents, or a process created in a suspended state by an unusual parent. EDR telemetry (CrowdStrike ProcessRollup2, SentinelOne behavioral indicators, Microsoft Defender for Endpoint DeviceEvents) carries this signal more reliably than raw Windows logs. Sigma rules at the EDR layer should select on injection-specific event types rather than trying to reconstruct the behavior from process creation events alone.

Sigma Syntax Reference for Detection Engineers

Sigma’s value is portability. A well-written rule converts cleanly into Splunk SPL, Microsoft Sentinel KQL, Elastic EQL, CrowdStrike CQL, and a dozen other dialects through the sigmac and pySigma toolchains. Mapping accuracy at the tag level matters more than most teams treat it — SnapAttack research has documented widespread precision errors in published rules where techniques are mapped to a tactic only, or to a parent technique when a sub-technique is more accurate. A rule tagged attack.defense_evasion with no technique ID is unsearchable in coverage reports.

Detecting T1053.005 — Scheduled Task

Adversaries create scheduled tasks for persistence and execution because the mechanism survives reboots, runs with elevated privileges, and looks like normal administrative activity. Detection draws from Windows Event ID 4698 (task created), Sysmon Event ID 1 for schtasks.exe process creation, and command-line auditing.

A productive rule alerts on scheduled task creation by non-standard users where the task action points to unusual directories (Temp, AppData, ProgramData, Public). Tuning involves whitelisting legitimate creators — Windows Update, your endpoint management agent, your backup software — by service account name or parent process. The falsepositives field for this rule should be specific: enumerate the actual products in the environment that create scheduled tasks, not a generic “legitimate administrative activity” placeholder.

Detecting T1204.004 — Malicious Copy and Paste

ATT&CK v17 introduced T1204.004 Malicious Copy and Paste in response to the explosion of ClickFix and fakeCAPTCHA campaigns through 2024 and 2025. Red Canary called it “the technique of the year” for 2025 even though it didn’t crack the top-10 ranking for mapping reasons. The procedure: a user is socially engineered into pasting a malicious command (almost always PowerShell) into the Run dialog or a terminal, ostensibly to fix a fake error.

The detection pivot is explorer.exe as a parent process for powershell.exe, cmd.exe, or mshta.exe, particularly when the child process command line contains URLs, encoded payloads, or the strings iex, Invoke-Expression, or IWR. Standard user activity rarely triggers this combination; ClickFix lures trigger it constantly. The same logic also catches the Run dialog launch of mshta.exe against remote HTA payloads, which returned to Red Canary’s top-10 technique list in 2025 after a four-year absence.

Common Pitfalls That Kill Detection Rules

The pitfall behind most of these is treating detection as a one-time authoring task. The rules that hold up are the ones reviewed every release cycle, re-tested against the current set of Atomic Red Team tests, and version-controlled with the rest of the security stack.

Frequently Asked Questions

Should I write rules in Sigma or directly in my SIEM’s query language? Sigma if you have any chance of changing SIEMs, sharing rules across teams, or contributing to the SigmaHQ repository. The conversion overhead is minimal with pySigma, and the portability is real. Native rules only when a feature isn’t expressible in Sigma — usually advanced correlation or platform-specific lookups.

How many ATT&CK techniques should a mature SOC cover? Coverage breadth is less useful than coverage depth on the techniques adversaries actually use against your sector. Use the Picus Red Report 2026 top-10 and the Red Canary Threat Detection Report rankings as a starting prioritization, then layer in techniques mapped to threat groups targeting your industry from MITRE’s Group pages.

How do I handle ATT&CK version upgrades without breaking my detection coverage? Maintain a mapping document that tracks every internal rule against its ATT&CK technique ID and the framework version. When a new version ships (April and October cadence), diff the changelog for revoked, merged, or renamed techniques and update tags. The v17 merge of T1574.002 DLL Side-Loading into T1574.001 DLL is a recent example — rules tagged to the old ID stop showing up in coverage reports against v17 data.

What’s the difference between a detection rule and a threat-hunting query? A detection rule is automated, runs continuously, and fires alerts. A hunt query is human-driven, exploratory, and looks for patterns the analyst suspects but hasn’t seen yet. Productive hunts often turn into detection rules once the pattern stabilizes. Both belong in the same versioned repository.

Where to Take This Next

The work doesn’t end at writing rules — it ends at measurable coverage and tested response. Pull the SigmaHQ repository (currently 350+ rules mapped to ATT&CK), import it into a staging SIEM, and run an Atomic Red Team campaign against a controlled host. The gap between which rules fire and which techniques you executed is your starting backlog. Map that backlog to the ATT&CK Navigator, prioritize by adversary relevance to your sector, and write the missing rules in the order the data tells you.

Detection engineering rewards patience and repetition more than cleverness. The best rules in the SigmaHQ catalog are not exotic — they are simple, well-tested, accurately mapped, and honestly tuned. That’s the bar.