The execution techniques have not changed. The list around them has

There is a claim that circulates in endpoint security, which is that attackers have been using the same handful of techniques for a decade and the industry keeps selling new products to address them.

It is half right, and the half that is wrong is the more interesting part.

What the data actually shows #

Red Canary's ranking of the most prevalent techniques, drawn from more than 110,000 threats across over 4.5 million endpoints, identities and cloud assets, puts the top ten roughly here.

Split that list in two and the picture sharpens considerably.

The endpoint half has barely moved #

PowerShell, the Windows command shell, WMI, ingress tool transfer and obfuscation are the same techniques that were near the top years ago. PowerShell has now placed high for the fifth year in a row.

That persistence is not a failure of the industry. It is a property of the tools. Every one of those techniques runs on something that is signed by Microsoft, present on a default install, and genuinely required by something in your estate. Deployment scripts shell out to PowerShell. Inventory agents query Windows through WMI. Installers are written in the things installers are written in.

An attacker using PowerShell is not exploiting a flaw. They are using the machine as designed, which is exactly why the technique does not age out. There is no patch cycle that removes it, because there is nothing broken.

The half that changed is the half nobody predicted #

The top of the list now belongs to identity and cloud. Cloud accounts sit at number one. Data from cloud storage, email forwarding rules and email hiding rules are all in the ten, and malicious copy and paste is a user driven technique that barely registered a few years ago.

None of those are endpoint execution problems. An attacker signed in as a real user, reading real files from real storage, and quietly forwarding mail, has not run anything you could refuse. The control that addresses that is conditional access, session policy and mail governance, and no amount of application control will touch it.

So the claim that nothing has changed holds for the endpoint and fails for the estate. Both halves are worth being precise about, because the two halves need different controls and conflating them is how budgets get spent on the wrong layer.

Which half application control is for #

Application control addresses the execution half. It has nothing useful to say about a compromised cloud account, and any vendor implying otherwise is selling past the evidence.

Within that half, the obvious move is also the wrong one. If the top techniques run on powershell.exe, cmd.exe and wmic.exe, the tempting conclusion is to block them, and that conclusion breaks the business by lunchtime. These binaries are load bearing. Your build pipeline, your deployment tooling and your monitoring agents are all standing on them.

The answer is scope rather than absence, and where possible upgrade rather than either.

Under a user mode App Control policy, PowerShell is not blocked. It drops into Constrained Language Mode, which leaves it able to do the ordinary administrative work your scripts rely on while removing the capability that makes it attractive as an attack tool. That is a genuinely different outcome from a block, and it is the reason the coverage detail matters. The same policy option is what decides whether scripts are evaluated at all, which what App Control for Business actually is sets out.

The rest is estate work rather than policy work. Older builds of these binaries that nobody needs any more are a surface you can simply remove. Tools installed on machines whose users have never opened them do not need to be there. A signed utility that is only required by one team does not need to be allowed everywhere.

Why the list stays long #

There is a reasonable question underneath all of this, which is why the abused binary lists keep growing if the techniques are so stable.

Research catalogues what can be abused. It is real work and it is worth reading. But a catalogue of everything abusable on a default Windows install is describing a machine nobody curated, and most estates are considerably more generous than a default install, because a decade of software has been added and very little has ever been taken away.

The length of the list is a consequence of decisions not made. Which is the argument for making them, and the model we set out in the approach.

What this means in practice #

Treat the two halves as two programmes with two owners. Identity and cloud techniques need identity and cloud controls, and putting them on the endpoint team's roadmap guarantees neither gets done.

Stop trying to remove the interpreters, and start deciding their scope. Which version, which machines, which users, and what the interpreter is permitted to do once it starts.

The first three of those are answerable from observed execution rather than from assumption, which is what PoliEze collects and enriches before any rule is written. The platform covers how that becomes a policy.

And treat the stability of the execution half as good news, because it is. A technique list that does not change is a control problem you can actually finish. The identity half will keep moving. The endpoint half has been the same binaries for years and will be the same binaries next year, which means the work you do there holds its value.

Sources #

• Top ATT&CK techniques, Red Canary Threat Detection Report
• AI and browser threats stand out in the 2026 Threat Detection Report, for the scale of the data set and PowerShell's placement
• PowerShell, Red Canary's technique page