The most common MITRE ATT&CK techniques in the SOC

Ten of the most common techniques in real incidents reduce to six recurring questions. The work is not ten playbooks — it is six predicates, and the telemetry to answer them.

Red Canary publishes a yearly Threat Detection Report. The 2026 edition, their eighth, is built from more than 110,000 confirmed threats detected across 4.5 million endpoints, networks, cloud infrastructure, identities and SaaS applications. Potentially unwanted programs and authorised testing are filtered out, and each detection is mapped to the ATT&CK technique it evidences. It is the closest public proxy we know for what actually reaches a SOC queue and turns out to be real.

These ten are not a long tail. Over the last five years Red Canary detected at least one of the ten most prevalent techniques in 46 percent of all detections, and at least one of the top twenty in 63 percent. A small number of techniques carry a disproportionate share of the work.

We went through the top ten and asked one question of each: what would an investigation have to prove before it could close a case of this kind without waking anybody up? The answer each time is a hypothesis, a proof contract and a bill of telemetry. Doing it ten times showed something we did not expect to be so clear — ten techniques do not need ten investigations.

The top ten in the 2026 report

1. T1078.004 · Valid Accounts: Cloud Accounts
2. T1059.001 · Command and Scripting Interpreter: PowerShell
3. T1059.003 · Command and Scripting Interpreter: Windows Command Shell
4. T1530 · Data from Cloud Storage
5. T1105 · Ingress Tool Transfer
6. T1114.003 · Email Collection: Email Forwarding Rule
7. T1047 · Windows Management Instrumentation
8. T1204.004 · User Execution: Malicious Copy and Paste
9. T1564.008 · Hide Artifacts: Email Hiding Rules
10. T1027 · Obfuscated Files or Information

Two things stand out before any analysis. Identity and email techniques hold four of the ten places, and they are the ones a SIEM rule alone can rarely settle. And the two most common techniques are legitimate tools used well: a cloud account and PowerShell are innocent until the surrounding facts say otherwise. The direction of travel is identity as well — Red Canary detected 850 percent more identity threats in 2025 than in 2024, and identity went from a fifth of their detection volume to 53 percent in a single year.

Ten techniques, ten questions

An Oryen investigation does not ask "is this malicious?". It takes one investigable hypothesis, almost always the benign one, and tries to prove it — with a kill condition named in advance, so the hypothesis can be wrong in a specific way rather than vaguely doubted.

• T1078.004 · Cloud Accounts. This sign-in is the account's own user, working normally. Kill condition: a success from an unfamiliar location or ASN, in a session that also touches an authentication factor.
• T1059.001 · PowerShell. This execution is administration or tooling. Kill condition: encoded or remotely fetched content, or a parent process with no business starting a shell.
• T1059.003 · Windows Command Shell. This cmd.exe run belongs to a known job. Kill condition: a shell whose parent is a document, a browser or a mail client.
• T1530 · Data from Cloud Storage. This read sits inside the principal's normal working set. Kill condition: breadth or volume outside the account's own baseline, or a principal that has never touched this store before.
• T1105 · Ingress Tool Transfer. This download is a sanctioned tool from a sanctioned source. Kill condition: a binary written by an interpreter and executed within minutes.
• T1114.003 · Email Forwarding Rule. The mailbox owner created this rule knowingly, and the destination is internal. Kill condition: an external destination, or creation during a session with an authentication anomaly.
• T1047 · Windows Management Instrumentation. This WMI call is a management tool doing its job. Kill condition: remote process creation from a host that is not a management server.
• T1204.004 · Malicious Copy and Paste. The user typed this themselves, for their own reasons. Kill condition: a command reaching the run dialog or a terminal within seconds of a browser visit.
• T1564.008 · Email Hiding Rules. This rule is housekeeping. Kill condition: a rule that moves or deletes mail matching security, finance or invoice keywords, or that targets a folder the owner never reads.
• T1027 · Obfuscated Files or Information. This content is obfuscated because its vendor ships it that way. Kill condition: anything unsigned, or signed by a publisher this environment has not seen before.

The last one is awkward, and worth saying out loud. Obfuscation is a property of an artefact, not an act by an actor, so there is no clean behavioural hypothesis to test. The only workable question is about the carrier: who shipped this, and is it what it claims to be. A contract for T1027 leans almost entirely on danger checks, and it escalates more often than the other nine. We would rather say so than pretend the technique automates as cleanly as PowerShell does.

The evidence bill

A proof contract is a checklist: closing facts that must all be TRUE, danger checks that must all be FALSE. Write the contracts for all ten techniques and the same predicates keep reappearing.

• The principal is behaving like itself. The account's own history, not a population average. Serves every identity- and mailbox-shaped case: T1078.004, T1530, T1114.003, T1564.008.
• The device is known and owned. Inventory says this host exists, has an owner, and is managed. Serves the five execution techniques, and narrows the cloud sign-in and cloud storage cases as well.
• The parent process is expected for this child. Serves T1059.001, T1059.003, T1047, T1105 and T1204.004 — five of the ten, on one predicate.
• The artefact is signed by a publisher this environment already trusts. Serves T1105, T1027 and most PowerShell cases.
• No authentication anomaly in the same session. The most reused danger check in the set, and the one that most often flips a verdict.
• Nothing persisted in the same window. A scheduled task, a service, a run key, a mailbox rule. Serves all ten.

Six predicates carry most of the closing work for ten techniques. That is the argument for keeping predicate meanings global and versioned rather than writing a playbook per alert type: "no authentication anomaly in the same session" means the same thing in every environment on earth. What changes between environments is only which log answers it, and that is a binding, not a rewrite.

It also explains why per-scenario playbooks are so expensive to maintain. Ten playbooks contain the same check ten times, in ten places, drifting apart at ten different speeds.

Where the facts come from

Every predicate above is a claim about your telemetry, and it can only resolve if the telemetry is there.

• Identity provider sign-in logs answer the identity predicates. The field that matters most is the MFA outcome, and it is the one most often absent or ambiguous.
• EDR process events, with parent and full command line, answer the execution predicates. Without the command line, PowerShell cases cannot close.
• Cloud storage data-plane logs answer T1530, and they are the gap we see most. Object-level events are usually off by default and charged per event, in every major cloud and in the document platforms too. A technique sitting fourth on this list is routinely impossible to investigate because nobody enabled the log.
• Mailbox audit logs answer the two mail rule techniques, and rule-creation events have to be switched on deliberately.
• Asset inventory answers ownership, and threat intelligence answers reputation on sources and destinations.

Now apply the second rule — unknown blocks. An UNKNOWN fact can stop a close; it can never enable one. So the absences translate directly into behaviour you can predict before you buy anything:

• MFA outcome missing, and the four identity and email techniques cannot close.
• Script block logging off, and PowerShell and T1027 cannot close.
• Object-level cloud logging off, and T1530 cannot close at all.
• Mailbox auditing off, and both mail rule techniques cannot close.

This is the useful output of the exercise. Coverage stops being a number in a slide and becomes a list of named techniques you can and cannot yet close, with the specific log that would change each one.

Prevalence is not queue volume

We said at the top that we would keep these apart, so: Red Canary ranks confirmed threats, not alert volume. They are different measurements and a technique can be large in one and invisible in the other.

The report does publish volume at the category level, which is where the identity numbers above come from. What nobody publishes is an alert queue broken down by technique, and we are not going to invent one. What can be said without those numbers is that the techniques near the top of this list are common precisely because the underlying activity is common and overwhelmingly benign. PowerShell, cmd.exe, WMI and cloud sign-ins happen constantly in every environment. That is exactly why they are useful to an adversary, and exactly why they generate the detections an analyst spends the day dismissing.

So the ranking does double duty. Read as threats, it says where the real ones are. Read as work, it says roughly where the hours go. The techniques worth automating first are the ones that score on both — and on this list, most of them do.

What the ranking is actually good for

Not as a to-do list. A top ten of confirmed threats is a description of last year, and the eleventh technique is not safe.

It is useful as a test of an approach. If ten of the most common techniques in real incidents reduce to six recurring predicates and a handful of telemetry sources, then the unit of work is the predicate, not the playbook. Build the predicates once, with global meaning and human-approved contracts on top of them, bind them to each environment as configuration, and let the third rule do the rest: close only what is proven, on fresh evidence, with the contract attached.

Everything else on the list escalates. That is not the system failing. That is the system telling you the truth about what it knows.

Six predicates, not ten playbooks. And a case you cannot close honestly is worth more than one you closed by guessing.

References

• Red Canary, 2026 Threat Detection Report — the top techniques and the full report. Every number quoted above comes from this edition: the ranking, the 46 and 63 percent shares of all detections, the 850 percent rise in identity threat detections, and the shift from 20 to 53 percent of detection volume.
• MITRE ATT&CK — technique identifiers and names.
• The hypotheses, proof contracts, predicates and telemetry mapping are Oryen's own work. They are not drawn from either source, and any error in them is ours.