A stolen employee account could expose customer records. A compromised payment system could put transactions at risk. And a ransomware attack could disrupt the services customers depend on every day.
Financial institutions prepare for these threats through security controls, incident response plans and regular testing. The challenge is understanding how those defences would perform against the techniques attackers actually use.
Adversary emulation helps answer that question.
By recreating selected attacker behaviours in a controlled environment, financial institutions can assess whether their security teams recognise suspicious activity, investigate it effectively and respond before it causes significant damage.
We'll cover how to select relevant threats, design an adversary emulation exercise and measure the defensive capabilities that matter to banks, insurers, payment providers and other financial organisations.
What Is Adversary Emulation?
Adversary emulation is a security testing method that recreates the known behaviours of real attackers to evaluate an organisation's ability to prevent, detect and respond to them.
The exercise begins with threat intelligence, which is information about the methods, objectives and activities of cyber attackers.
Security teams use that intelligence to identify specific behaviours worth testing.
These behaviours are commonly described as tactics, techniques and procedures (TTPs).
- A tactic is what an attacker wants to achieve,
- a technique is how they approach it, and
- a procedure describes how they carry it out in a particular situation.
For example, an attacker may use stolen credentials to access an employee account, change its authentication settings and retrieve sensitive customer information.
An emulation exercise could recreate selected parts of that sequence using authorised test accounts and synthetic records.
The goal is to understand which activities the organisation can identify and where its response needs improvement.
MITRE’s Adversary Emulation Library provides reusable plans based on documented attacker behaviour, including comprehensive scenarios and smaller exercises focused on particular techniques.
How Does It Differ From Penetration Testing?
Traditional penetration testing focuses on finding and demonstrating exploitable security weaknesses within an agreed scope.
Adversary emulation follows a threat-informed sequence of activity and examines how defensive controls and responders perform throughout it.
For a financial institution, this can reveal whether a suspicious account change generates useful telemetry, whether analysts connect it to subsequent activity and whether containment happens before sensitive operations are affected.
Adversary emulation can support red-team assessments or collaborative purple-team exercises, where offensive testers and defenders work together to identify and correct weaknesses.
The format should reflect the capability the organisation wants to evaluate.
Which Cyber Threats Should Financial Institutions Emulate?
The most useful exercise starts with a threat relevant to the institution's services, technology and exposure.
According to ENISA’s Threat Landscape 2026, unauthorised access accounted for 46% of events in its finance and banking dataset for 2025. Distributed denial-of-service (DDoS) activity accounted for 38.9%, followed by fraud and impersonation at 14.8%.
These figures reflect ENISA’s collected incidents and reporting. They are useful sector indicators rather than predictions of an individual institution's likelihood of attack.
Financial institutions can combine this information with their own incident history, threat intelligence and critical business services to choose scenarios.
The FBI's Bybit advisory provides a concrete example for cryptocurrency exchanges and custody providers.
For insurers, Aflac's June 2025 incident disclosure illustrates the relevance of social engineering and sensitive records. Separately, the joint Scattered Spider advisory documents attacker techniques involving help-desk impersonation and account recovery. The sources should not be interpreted as attributing Aflac's incident to that group.
Historical adversaries can also provide useful techniques, provided the exercise explains their relevance to the current environment.
How to Design an Adversary Emulation Exercise
An effective exercise connects a realistic attack sequence to specific defensive decisions and measurable outcomes.
The following five steps provide a practical structure.
1. Start With a Critical Financial Service
Identify the business function you want to protect and the consequences of its compromise.
For a retail bank, that might be unauthorised access to payment infrastructure. An insurer may prioritise claims records, while an investment firm could focus on systems processing sensitive client instructions.
Define a specific objective the exercise can test.
Can the security team identify an unauthorised account change, investigate access to synthetic customer records and contain the affected identity without disrupting legitimate service?
This gives the technical team a clear investigation objective while making the business outcome relevant to the service owner.
2. Select Relevant Attacker Techniques
Use documented threat behaviour to build a controlled sequence.
MITRE ATT&CK provides a common framework for describing attacker techniques and mapping them to defensive activity.
For an identity-based intrusion scenario, relevant techniques could include:
- Valid Accounts (T1078): Using an existing account to access systems.
- Device Registration (T1098.005): Registering a device in ways that can help maintain account access.
- Data from Cloud Storage (T1530): Accessing information stored in cloud services.
- Exfiltration to Cloud Storage (T1567.002): Transferring data to a cloud destination controlled or used by the attacker.
Choose the behaviours that match the documented threat and the organisation's environment.
Each should have a defined purpose. If a technique cannot be meaningfully reproduced or observed, record that limitation.
3. Define the Evidence and Response You Expect
For each stage, decide which security records should be available and what defenders need to establish.
An unusual account recovery event, for instance, may generate identity audit records. Subsequent access to customer information may appear in application or cloud audit logs.
The security team should be able to connect those events and determine whether further investigation or containment is necessary.
Before the exercise, confirm that the environment contains the required evidence sources. Otherwise, you may struggle to distinguish an ineffective detection from a missing log or integration problem.
4. Set Safe Testing Boundaries
Agree on the scope, permitted activity, participating systems and people authorised to approve or stop the exercise.
For financial institutions, that includes understanding dependencies on payment processors, outsourced technology providers and other third parties.
Use synthetic customer information and controlled destinations. You can assess ransomware response decisions without deploying destructive malware or interrupting production services.
The exercise should also distinguish between actions executed against real controls and evidence supplied for participants to investigate.
A hosted simulation can demonstrate investigation skills and team coordination. But it does not automatically establish that the institution's production monitoring systems would detect the same activity.
5. Run the Exercise, Document Gaps and Retest
Record how the scenario develops and how defenders respond. Pay attention to when suspicious activity becomes visible, what evidence analysts investigate and how long important decisions take.
If the team misses an event, establish why. A missing identity log requires a different improvement from an alert that was visible but incorrectly dismissed.
Assign each finding an owner and a corrective action, then repeat the relevant part of the scenario after changes have been made.
This turns the exercise into evidence of improvement that security leaders can review.
Example: Emulating an Identity-Based Attack Against an Insurer
Consider an insurance provider concerned about attackers gaining access to claims information through compromised employee accounts.
The institution wants to assess whether its security team can detect suspicious account recovery, investigate access to sensitive records and contain an affected identity while keeping the claims service operational.
The exercise uses an isolated environment with test accounts and synthetic claims data.
Include an authorised user whose normal activity resembles part of the suspicious pattern.
This helps assess whether analysts can distinguish malicious behaviour from legitimate access rather than automatically treating every unusual event as compromise.
The exercise should also test communication with the service owner. A technically correct containment decision can still create unnecessary disruption if responders do not understand the business process involved.
At the end, the institution should know which behaviours were recognised, which evidence supported the investigation and whether the team could make an effective response decision.
How to Measure Adversary Emulation Results
A successful exercise should give security leaders evidence they can use to improve defensive readiness.
Useful measurements include:
Record any controller assistance and distinguish independently completed tasks from coached outcomes.
Avoid reducing the entire exercise to a single readiness percentage. A team may identify several minor behaviours while missing the one that allows sensitive records to leave the environment.
After remediation, repeat the relevant behaviours to confirm whether the improvement works.
How Does Adversary Emulation Support DORA and TIBER-EU?
Financial institutions operating in the European Union also need to consider the relationship between security testing and regulatory resilience requirements.
The Digital Operational Resilience Act (DORA) establishes requirements for managing information and communication technology risks across covered financial entities.
For designated entities, its advanced testing framework includes threat-led penetration testing (TLPT).
TIBER-EU, or Threat Intelligence-based Ethical Red Teaming, provides a framework for conducting controlled, intelligence-led testing of critical or important financial functions.
The European Central Bank's updated TIBER-EU framework aligns with DORA's technical standards for TLPT.
Adversary emulation can support preparation by helping teams develop investigation skills, assess response processes and address identified weaknesses.
However, a hosted lab simulation or internal emulation exercise does not automatically qualify as a formal TIBER-EU or DORA TLPT assessment.
Those engagements have specific governance, scope, provider and oversight requirements that must be considered separately.
What Should Financial Institutions Look for in an Emulation Provider?
Before selecting a provider, ask them to explain how a proposed exercise connects to your institution's threats and services.
Focus on four practical questions:
- Threat relevance: Which documented attacker behaviours does the scenario reproduce, and why do they matter to our institution?
- Technical realism: What tools, evidence and response actions will participants use, and how closely does the environment represent our workflows?
- Measurable outcomes: Will the exercise show what the team detected, investigated, contained and missed?
- Improvement: Can we use the findings to identify training needs, update response processes and verify progress through further exercises?
An existing scenario may be appropriate for developing team readiness against a recognised threat.
More specialised testing may be needed when the objective depends on the institution's actual architecture, production controls or financial transaction workflows.
Choose the format based on what you need to demonstrate.
Develop Stronger Incident Response Readiness With TryHackMe
Financial institutions need security teams that can recognise relevant attacker behaviour and respond effectively when critical services are at risk.
Adversary-informed practice gives teams an opportunity to develop those skills and identify weaknesses before a real incident puts them to the test.
TryHackMe Live Breach Exercises put security teams through realistic attacks based on named threat actors, with hands-on investigation and incident response using supported SIEM and EDR tools.
Teams work through the attack lifecycle, make containment and eradication decisions, and receive performance reporting that helps identify where further development is needed.
The exercises run on TryHackMe infrastructure, allowing teams to practise without introducing attack activity into their production environment.
For banks, insurers and other financial organisations, this provides a practical way to strengthen investigation skills, team coordination and response decision-making alongside broader security assurance programmes.
Ayomide Joseph A.
