Threat-led testing and real adversary behaviour
Most organisations do not need a state-aligned espionage scenario, and buying one is the most common form of threat intelligence theatre. The adversaries that will actually reach you are a ransomware affiliate working from purchased access, a commodity infostealer harvesting browser sessions, and an opportunistic scanner looking for an exposed cluster. Threat-led testing means choosing the profile that fits your sector and exposure, then emulating how that profile behaves rather than performing a set of impressive techniques.
What makes testing threat-led rather than generic?
The scenario is derived from evidence about who targets organisations like yours and how they behave, and it constrains the testers rather than expanding them. A generic engagement asks the team to reach an objective by any means. A threat-led engagement asks them to reach it while behaving like a specific profile: using the access routes that profile uses, the tooling it favours, and the pace at which it operates.
That constraint is the point, because it makes the detection result meaningful. If your monitoring is tuned to catch loud commodity tooling and the emulated adversary uses built-in administrative utilities and legitimate credentials, you learn something specific about your blind spot. If the team simply used whatever worked, you learn about that team's preferences.
The test for whether a scenario is genuinely threat-led: can the supplier say why this adversary would target you, what it would want once inside, and which of its documented behaviours they will and will not emulate? Absent those three answers, you have a generic engagement with a threat actor name printed on the cover.
Where does the intelligence come from, and when is it theatre?
From sector-specific reporting on targeting and observed behaviour, from your own incident history, and from what your sector's information sharing arrangements circulate. National cyber security agencies publish advisories describing techniques observed in real intrusions, and those are usually more useful for scenario design than commercial actor profiles, because they describe procedures rather than attribution.
It becomes theatre in three recognisable ways. A slide of threat actor logos with no argument connecting them to your sector or your exposure. Indicator lists presented as intelligence, which are useful for blocking and useless for scenario design because infrastructure changes constantly. And attribution as the product, where the report explains which group is which rather than what any of them would do to you.
Your own history is the most underused source. Every phishing report your staff filed, every alert that turned out to be real, and every incident a supplier disclosed to you describes the adversary that actually reaches organisations of your kind and size. Read a year of it before commissioning a scenario, and the argument about which profile to emulate usually settles itself.
The honest position for most organisations is unglamorous. Your likely adversary is financially motivated, buys or steals access rather than developing it, uses legitimate credentials and built-in tooling to avoid detection, and monetises through extortion or fraud. Designing to that profile is cheaper and more useful than designing to a nation state, and it covers most of what a sophisticated actor would do in your environment anyway.
Which adversary profile should you emulate?
Pick by exposure rather than by prestige. The profiles below cover the realistic range for a commercial organisation, and the last column is what to check in your own telemetry before the engagement, because a profile whose behaviour you cannot see at all is a pipeline problem before it is a testing question.
| Profile | Plausible objective | Behaviour worth emulating | Telemetry to check first |
|---|---|---|---|
| Ransomware affiliate with bought access | Encrypt or exfiltrate, then extort | Credential access, backup discovery, mass file access | Backup system access logs and unusual file read volume |
| Infostealer and session theft | Resell working access to your systems | Cookie and token reuse, no malware on the endpoint | Sign-ins from new devices with valid session tokens |
| Insider with legitimate access | Take data on the way out, or misuse authority | Slow, in-hours, entirely legitimate tooling | Bulk export and unusual query volume on data stores |
| CI/CD and supply chain intruder | Reach production via the build system | Pipeline modification, secret access, dependency injection | Pipeline run and repository audit logs, forwarded anywhere |
| Opportunistic cluster abuse | Run compute for profit, quietly | Exposed API, deploy a workload, sustained egress | Workload creation events and outbound flows per pod |
| State-aligned espionage | Long-term access to specific information | Patience, credential theft, minimal tooling | Long-retention identity logs and privileged access review |
How does a technique taxonomy help, and where does it mislead?
A shared taxonomy of adversary techniques, such as the MITRE ATT&CK matrices, does two useful jobs. It gives testers and defenders the same vocabulary, so a report entry can be matched against a detection rule without argument. And it turns coverage into an inventory you can accumulate across engagements rather than a fresh opinion each time.
It misleads when it becomes a score. Coverage counted as a proportion of techniques implies that techniques are equally weighted and that your adversary picks uniformly, and neither is true. It is also gameable: a single rule can be claimed against many techniques, and a heatmap coloured by intent rather than by tested evidence is easy to produce and worthless. Colour a technique only when an execution has produced an alert that was re-tested afterwards.
The subtler problem is granularity. A technique describes a category; an adversary uses a specific procedure within it, and your detection may cover one procedure and miss the rest. Credential access from a browser store and credential access from a process memory dump sit in the same neighbourhood and require different telemetry. Track procedures where the difference matters, and accept that your map is coarser than reality everywhere else.
Does the container layer have its own adversary behaviour?
Yes, and it is documented well enough to emulate precisely, which makes it one of the better value scenarios available. Exposed container platform components attract automated abuse continuously, and the commonest observed outcome is unauthorised compute usage: a workload deployed for mining, sized to avoid throttling, with sustained outbound connections to a pool. It is unglamorous and it is the behaviour your cluster is most likely to meet.
The technique sequence is stable. Discovery of the cluster and its resources from inside a workload. Credentials taken from the container environment, including the mounted service account token and any cloud metadata reachable from the pod network. Execution through the container administration interface, meaning exec into an existing pod rather than dropping a binary. Deployment of a new container as a persistence and execution mechanism, often into a namespace nobody watches. And escape to the host where the security context permits it, which converts a workload compromise into node compromise and access to every other workload's secrets on that node.
Emulate that sequence rather than inventing something exotic, and pair each step with the telemetry check from the table above. The three questions that decide the outcome are whether workload creation is alerted, whether a service account calling APIs it has never called before is noticed, and whether egress can be attributed to a pod. If all three answers are no, an opportunistic actor can operate in your cluster indefinitely, and that is worth knowing before you commission a scenario about a nation state.
When do you need a regulated threat-led test?
When a supervisor tells you to, and effectively never otherwise. Several jurisdictions operate frameworks in which intelligence-led testing of critical functions is arranged with regulator involvement, using providers that meet the framework's own requirements for independence and competence, with the scope agreed rather than chosen. The European framework for financial entities and the equivalent United Kingdom scheme are the best known, and comparable arrangements exist in other financial centres.
These exercises are heavier than a commercial red team by design. Scoping alone runs for months, the critical functions in scope are determined jointly rather than by you, the threat intelligence provider is external in every scheme, and the evidence package is produced for a supervisor as well as for you. The value is real and the overhead is not optional.
Who may run the attack itself diverges between the two best-known schemes, and the difference changes what you have to procure. CBEST in the United Kingdom requires two separate CREST-accredited suppliers, one accredited for threat intelligence and one for the simulated attack. Under DORA Article 27 and the TIBER-EU framework as updated by the Eurosystem in February 2025 to align with it, a financial entity may use its own internal red team for up to two of every three testing cycles, with every third test run by an external tester, so the testing provider need not be a separate firm at all. DORA also treats accreditation as one of two routes rather than a requirement: testers must either be certified by an accreditation body in an EU member state or adhere to formal codes of conduct or ethical frameworks, and no European body accredits TIBER-EU providers itself.
One preparation step pays off whether or not an obligation applies to you: mapping your critical business functions to the systems, identities and third parties they depend on. Regulated frameworks require it, commercial engagements benefit from it, and the exercise routinely surfaces a dependency nobody had documented, which is worth the effort even if no test follows.
The practical guidance is simple. Do not buy this voluntarily as a badge, because a commercial threat-led engagement gives you the same technical learning at a fraction of the coordination cost. If you are in scope of an obligation, treat the framework requirements as the specification and start the internal preparation, particularly log retention and function mapping, a year before the test window rather than during it. Whether you are in scope is a question for counsel and your regulator, not for a testing supplier.
Common questions
- What is threat-led penetration testing?
- Testing where the scenario is derived from evidence about who targets organisations like yours and how they behave, and where that evidence constrains the testers rather than expanding them. The team must reach its objective using the access routes, tooling and pace of a specific adversary profile, which is what makes the detection result meaningful rather than a statement about the testers' preferences.
- Which threat actor should we emulate?
- Choose by exposure, not prestige. For most commercial organisations the realistic profiles are a ransomware affiliate operating from purchased access, session and credential theft with no malware on the endpoint, an insider using entirely legitimate tooling, a build system intruder reaching production through CI/CD, and opportunistic abuse of an exposed cluster. State-aligned espionage is rarely the right first scenario.
- Is MITRE ATT&CK coverage a good security metric?
- As an inventory yes, as a score no. Counting covered techniques implies they are equally weighted and that adversaries choose uniformly, and it is gameable by claiming one rule against many techniques. Colour a technique only when an execution produced an alert that was re-tested afterwards, and track specific procedures where telemetry differs, such as credentials taken from a browser store versus from process memory.
- How do attackers behave inside Kubernetes clusters?
- Predictably. Discovery of cluster resources from inside a workload, credentials taken from the container environment including the mounted service account token and reachable cloud metadata, execution through exec into existing pods rather than dropped binaries, deployment of new containers for persistence, and escape to the host where the security context allows. The commonest observed outcome of an exposed cluster is unauthorised compute for mining.
- What is the difference between a red team and a threat-led test under a regulator framework?
- Scope authority and overhead. In regulated frameworks the critical functions in scope are determined jointly with a supervisor, the threat intelligence provider is always external, scoping runs for months, and the evidence package serves the regulator as well as you. Who runs the attack differs by scheme: CBEST in the United Kingdom requires a second, separately CREST-accredited supplier, while DORA and TIBER-EU let a financial entity use its own red team for up to two of every three cycles. A commercial red team gives similar technical learning with far less coordination, which is why the regulated version is rarely worth buying voluntarily.
- Where should threat intelligence for a scenario come from?
- Sector-specific reporting on targeting and observed behaviour, national agency advisories describing techniques seen in real intrusions, your own incident history, and your sector's information sharing arrangements. Treat indicator lists as blocking material rather than scenario design, since infrastructure changes constantly, and treat attribution-focused reporting as background rather than as the specification for a test.
