Attack Chains, Not Just Attack Surfaces: Why Testing Individual Techniques Misses the Point

Security teams have gotten pretty good at testing against what can hurt them. Can this EDR agent catch this payload? Will my organization fail the phishing simulation? Does this SIEM rule fire on this particular technique?

And, in more mature organizations, this testing happens continuously rather than as a one-off exercise. But no matter how much you validate against these exposures, it doesn't fix the main problem the industry is facing: these are isolated, disconnected testing.

And real attackers, increasingly AI Powered ones, don't test techniques one at a time. They chain them. A phishing email leads to a credential harvest. That harvest leads to an initial foothold.

The foothold leads to privilege escalation, then lateral movement, then data staging, then exfiltration… until the damage is irreversibly done.

Any one of those individual steps might be something a security control is theoretically capable of catching - but there's just too many potential exposures to test for, and even if you were to fix 90%, it's that 10% that's missing that might act as the broken link making an attack path exploitable.

What actually matters is whether the whole sequence gets caught, or whether it slips through the gaps between tools, teams, and alerts that were never really built to talk to each other. That gap, between testing techniques and testing chains, is where a lot of "validated" security postures quietly fall apart.

Most breach and attack simulation programs, even fairly mature ones, are built around a library of individual techniques mapped to a framework like MITRE ATT&CK. Run technique 1234, check if it's detected. Run technique 5678, check if it's blocked. Score it, move on to the next one.

That tells you something real, but not the thing you actually need to know: whether an adversary who strings ten of those techniques together, adapting at each step based on what worked, could walk straight through your environment while every individual control quietly reports "no issue detected".

This isn't just a theoretical concern. According to Filigran's State of Threat Management report , 93% of security leaders say their organization suffered a business-impacting cyberattack in the past 12 months, despite most having validated their defenses at some point along the way.

88% say AI is now accelerating how fast attackers move once they get inside, and 84% point to siloed tools and disconnected testing as a main reason exposures go unnoticed until someone exploits them.

This shows there's a real gap between knowing about a threat and the reality of being resilient against it: Understanding cyber risk exposure has become significantly more complex. You can see the pattern in real incidents too.

When France's tax authority, the DGFiP, was breached in 2025, no single step in the intrusion was particularly exotic.

It was the sequence of initial access, credential abuse, lateral movement, and exfiltration, all carried out in a coordinated chain that turned a handful of individually survivable weaknesses into a major breach. Each control along the way may well have "worked" on its own. The chain still got through.

Attack Chaining is what closes that gap. It's a new type of scenario in OpenAEV that automates multi-stage attack paths end to end, the same way a red team would run them, but continuously and at a fraction of the cost.

Instead of testing techniques as isolated events, Attack Chaining links them into a live sequence: the real output of one action (a harvested credential, an open port, a token, a misconfigured permission) is captured automatically and used to decide what gets attacked next.

Recon reveals a target, a credential dump yields a password, that password unlocks the next machine, and the chain keeps building on whatever it actually finds in your environment, branching in real time on an interactive graph from initial access through to the final objective.

That gets you the realism of a manual red-team engagement without the cost or the wait. A red team is thorough but expensive and periodic - a snapshot taken once or twice a year while the environment keeps changing underneath it.

Attack Chaining runs in minutes, as often as you need it, so instead of a stale report you get an always-current answer to the only question that matters: if an adversary strung these techniques together today, where would they actually get through?

Five capabilities work together to make that possible: These capabilities support two ways of running a chain. In operator-led mode, a human builds the conditional logic and controls execution - deterministic, transparent, and built for scaling precise, repeatable pentesting.

In Autonomous Attack Chaining , that judgment is handed to an AI agent powered by XTM One .

An operator defines only an objective and a scope; a dedicated orchestrator agent plans the attack path itself, executes it, and adapts as it goes — reacting to findings, reordering steps, choosing actions based on what it discovers, and even generating realistic phishing emails or landing pages when the objective calls for social engineering.

The orchestrator can also call on specialist agents for payload creation, code generation, recon, and exploitation, using OpenAEV's built-in agents or bringing its own from XTM One.

Both modes run on the same conditional engine and the same scope controls, and both deliver the same outcome: a realistic, end-to-end attack simulation that runs in minutes instead of weeks, repeatable as often as your environment changes, prioritized around the threat intelligence relevant to your organization — with results feeding straight into a unified exposure score instead of sitting as an isolated report.

The organizations that get breached despite having "passed" their security testing usually didn't fail a control test. They failed a chain test they never ran in the first place.

As adversaries keep moving faster, increasingly with AI assisted tooling shortening the gap between initial access and objective, the cost of only testing techniques in isolation keeps growing too. Attack surfaces are made up of individual weaknesses. Attacks are made of chains.

Testing needs to match the thing it's actually meant to defend against. If you want to go deeper on how this actually gets operationalized, Filigran is hosting a live, technical webinar walking through attack chain testing in practice.

You can register for one of the sessions here: See how to test new CVEs against your environment, confirm what attackers can actually exploit, and fix the exposures that pose the greatest risk.

Learn how to identify exploitable risk faster, prioritize what matters most, and reduce exposure before AI-powered attacks accelerate the threat.