Adversary Simulation and Red Teaming: How Realistic Attack Testing Works

Technical review by Volodymyr Garbar, CISO & Tech Lead
Updated: 6 October 2026

Adversary simulation services test how an organization responds to realistic attack behavior across multiple stages of an intrusion, rather than checking individual vulnerabilities in isolation. Depending on the objective, an exercise can test technology, security controls, detection and response, people, and the paths an attacker could use to reach a defined target.

This is where the line between penetration testing and red teaming starts to matter.

A penetration test might ask whether a particular network, application, or cloud environment can be compromised. An adversary simulation can start with a different question: could an attacker with a particular objective get from initial access to something the organization really cares about without being stopped?

That might mean reaching sensitive data, compromising privileged identities, moving between network segments, or testing whether the security team detects the activity along the way.

Q-Sec runs goal-based red team and adversary simulation engagements mapped to MITRE ATT&CK, with scenarios built around the organization's environment, threat model, and testing objectives.

Free playbook

Not sure whether you need a penetration test or a broader attack simulation?

The PCI DSS Penetration Testing Playbook helps establish whether a conventional pentest covers the question you need answered before moving to a broader adversary simulation.

Get the PCI DSS Penetration Testing Playbook

What is adversary simulation?

Adversary simulation is a controlled security exercise that reproduces realistic attacker behavior to test whether an organization's preventive, detection, and response controls work against the attack techniques being simulated.

Instead of testing vulnerabilities one at a time, the exercise follows attacker behavior across an attack path.

Initial access might lead to credential access. Credentials might provide a route to another system. That system might expose a more privileged identity. Eventually, the exercise either reaches its agreed objective or runs into controls that stop the attack.

MITRE ATT&CK is commonly used to structure this work because it organizes adversary behavior into tactics, techniques, and sub-techniques based on real-world observations. MITRE also publishes adversary emulation plans showing how threat intelligence about known groups can be turned into practical testing scenarios.

The objective is not to demonstrate how clever the red team is.

You want to know which parts of the attack were prevented, which were detected, which were missed, and how much progress an attacker could make before someone noticed.

Adversary simulation vs. adversary emulation vs. red teaming

Adversary simulation is the broader practice of reproducing realistic attack behavior; adversary emulation recreates the known behavior of a specific threat actor or threat profile; red teaming gives an authorized offensive team an objective and tests whether it can achieve that objective against the organization's defenses.

The terms are often used loosely in the industry, so the label on the proposal matters less than what the provider actually intends to do.

MITRE makes a similar distinction. Its adversary emulation model starts with cyber threat intelligence about specific adversaries, while red teaming applies an adversarial mindset toward an operational objective without necessarily reproducing one known threat actor.

NIST describes a red team exercise as a simulated adversarial attempt conducted under real-world conditions to assess an organization's security capabilities.

In practice, the boundaries can overlap. A red team may use ATT&CK techniques associated with several threat groups. An adversary emulation can include red team operators. A provider might call the whole engagement an adversary simulation.

Ask what is actually being simulated.

That answer is more useful than arguing about terminology.

How does an adversary simulation work?

An adversary simulation typically starts with an agreed attack objective and threat scenario, then progresses through reconnaissance, initial access, execution, persistence, privilege escalation, credential access, lateral movement, and other techniques needed to reach that objective.

Not every exercise uses every stage. It should not.

If the scenario assumes that credentials have already been compromised, spending three days trying to phish an employee does not necessarily teach you anything useful.

A typical engagement can look like this:

This is one reason adversary simulation tends to make more sense after basic vulnerability management and penetration testing are already working reasonably well.

If an attacker walks through an exposed critical vulnerability in the first hour, you have learned something useful. But you probably did not need a multi-stage red team exercise to learn it.

For organizations still at that stage, network penetration testing services or a more focused penetration test may be the better starting point.

What does a red team test?

A red team exercise can test technical controls, identity security, monitoring and detection, incident response, security processes, and human behavior as parts of the same attack scenario.

The technical work can include things such as initial access, credential attacks, privilege escalation, lateral movement, persistence, command and control, and access to target systems.

But getting into a server is only half the story.

Suppose the red team gains access and the EDR generates an alert within two minutes. The SOC investigates it, isolates the host, disables the compromised identity, and closes the attack path.

From an offensive perspective, compromise happened.

From a defensive perspective, several controls just proved that they work.

NIST's definition of a red team reflects this broader purpose: the team emulates adversarial attack capabilities to demonstrate both the impact of successful attacks and what works for defenders in an operational environment.

That second part is easy to forget.

What is automated red teaming?

Automated red teaming uses software to execute predefined or dynamically selected adversary behaviors against an environment, often mapped to frameworks such as MITRE ATT&CK. It is useful for repeatable security control and detection testing, but it does not replace a human-led red team exercise.

Automation is particularly useful when the question is repeatable: does our EDR detect this behavior? Does this analytic fire? Did the control still work after last week's configuration change?

MITRE's CALDERA is one example. MITRE describes it as an automated adversary emulation system that can perform post-compromise adversarial behavior using ATT&CK-based adversary models.

That is useful work. It is also different from giving a human red team an objective and letting them work out how to reach it.

Human operators can change direction when something unexpected happens. They can decide that an obvious route is too noisy, combine weaknesses that were not part of a predefined sequence, or abandon one attack path and try another.

Automation gives you repeatability. Human red teaming gives you adaptation.

In practice, organizations can use both rather than treating this as an either-or decision.

What are adversary emulation tools?

Adversary emulation tools help security teams reproduce attacker techniques in a controlled environment so they can test security controls, detection logic, and response processes against known adversary behavior.

MITRE ATT&CK provides the behavioral framework rather than the attack tool itself. Its adversary emulation plans take publicly available threat intelligence and turn it into sequences of behaviors that red teams and defenders can use for testing.

Tools can then execute some of those behaviors.

The important part is not how many ATT&CK technique IDs appear in the final report. A simulation should start with a useful security question and select techniques that help answer it.

Running fifty techniques because a platform can run fifty techniques gives you activity. It does not automatically give you a useful adversary simulation.

Adversary simulation vs. penetration testing

Penetration testing usually looks for exploitable weaknesses within a defined technical scope, while adversary simulation tests whether an attacker can achieve an objective across multiple systems, controls, and stages of an attack.

The overlap is real. Both can involve reconnaissance, exploitation, privilege escalation, credential access, and lateral movement.

The difference is mostly in the objective and boundaries.

NIST defines a red team exercise as a simulated adversarial attempt under real-world conditions intended to assess the security capabilities of the organization and its systems.

So a red team is not simply a penetration test with more expensive tooling.

And a penetration test is not the inferior version. Quite often, it is exactly what the organization needs.

If you need to assess a defined infrastructure scope, our guide to Network Penetration Testing Services explains how internal and external network assessments work. If you are still choosing a provider, the Penetration Testing Vendor Evaluation guide covers scope, tester expertise, reporting, retesting, and proposal comparison.

When do you need adversary simulation services?

Adversary simulation services make the most sense when an organization already has established security controls and wants to test whether those controls hold up against a realistic multi-stage attack.

This distinction saves some money.

If you have never penetration-tested an internet-facing application, have unresolved critical vulnerabilities, or are still establishing basic vulnerability management, starting with a full red team engagement can be unnecessary.

There are easier ways to discover that an unpatched server is vulnerable.

Adversary simulation becomes much more useful when you want answers to questions such as:

• Can an attacker move from an initial foothold to a critical business system?
• Will our SOC detect credential access or lateral movement?
• Can a compromised account lead to higher privileges?
• Do our segmentation controls actually stop an attacker?
• How far could ransomware-like behavior progress before containment?
• Can the security team reconstruct the attack from available telemetry?
• Do technical controls and incident-response processes work together when something is actually happening?

NIST's description of red teams captures this nicely: the exercise should show both the impact of successful attacks and what works for defenders in the operational environment.

That means being stopped can be a perfectly useful result.

If the red team reaches the first objective and gets blocked there, you have learned where the defenses worked. If nobody notices the team for four days, you have learned something else.

Both are evidence.

What should an adversary simulation include?

A well-scoped adversary simulation should define the attack objective, threat scenario, target environment, permitted techniques, safety limits, communication rules, detection-testing goals, and criteria for ending or escalating the exercise.

The rules matter because this is deliberately intrusive testing.

There should be clear agreement on what operators can touch, what they must not touch, which actions require approval, who knows about the exercise, and who can stop it if something unexpected happens.

Some exercises intentionally keep the defensive team unaware. A small control or white team can know what is happening while the blue team responds normally. NIST describes the white team as the group that helps enforce the rules of engagement and ensures red team activity stays within predefined boundaries.

For a Q-Sec red team and adversary simulation engagement, the scenario can be mapped to MITRE ATT&CK and built around a defined business objective rather than a generic list of techniques. Q-Sec’s current penetration testing model explicitly includes goal-based, multi-phase adversary simulation designed to test people, process, and technology together.

What do you get after a red team exercise?

A red team report should reconstruct the attack path, show which techniques succeeded or failed, identify prevention and detection gaps, document evidence, and explain what the organization should change as a result.

A conventional vulnerability list is not enough here.

The useful part is the story of the attack: where it started, which controls were encountered, which ones worked, which ones did not, when defenders detected activity, and how close the team came to the agreed objective.

A useful report can include:

• exercise scope, assumptions, and rules of engagement;
• attack objectives and scenario;
• timeline of red team activity;
• ATT&CK techniques used;
• initial access and attack paths;
• privilege escalation and lateral movement;
• controls that prevented or detected activity;
• activity that was not detected;
• evidence supporting important findings;
• business impact of successful attack paths;
• remediation and detection recommendations;
• an executive summary for leadership.

I would also expect a debrief between offensive and defensive teams where appropriate. A table saying T1021 – detected is much less useful than understanding what generated the signal, who saw it, what they did with it, and whether the response actually interrupted the attack.

How long does an adversary simulation take?

An adversary simulation usually takes longer than a narrowly scoped penetration test because the team needs time to plan the scenario, operate across multiple attack stages, observe defensive responses, and reconstruct the attack afterward. The exact timeline depends heavily on scope and objectives.

This is one area where I would not invent a universal “two weeks” or “four weeks” answer just to give Google a number.

A focused assumed-breach exercise can be relatively short. A broader engagement involving reconnaissance, initial access, multiple systems, stealth requirements, and detection testing needs more room.

The proposal should therefore tell you more than the final delivery date. Ask how much time is allocated to scenario design, active operations, analysis, and reporting.

Q-Sec’s standard targeted penetration testing engagements typically run 2–4 weeks depending on scope, while its broader adversary simulation offering is scoped around the specific attack scenario and objective.

How to choose an adversary simulation provider

Choose an adversary simulation provider based on its offensive expertise, ability to build realistic scenarios, understanding of your technology and threat model, safety controls, reporting quality, and ability to work with your defensive team after the exercise.

A long list of tools is not much of a selection criterion.

I would want the provider to explain:

1. What are we trying to prove or disprove? There should be an objective beyond “run a red team.”
2. How will you choose the attack scenario? Threat intelligence, business context, and the organization's actual environment should influence it.
3. Who will conduct the exercise? Ask about experience with your identity systems, cloud platforms, endpoints, network architecture, and defensive stack.
4. How will you keep the exercise safe? Rules of engagement, stop conditions, production constraints, and escalation contacts should be clear.
5. Will you test detection as well as prevention? If that matters to you, put it in the scope.
6. How will results be reported? You need the attack path and defensive lessons, not a pile of screenshots.
7. What happens afterward? Debriefing, remediation work, detection improvements, and follow-up validation can be as valuable as the exercise itself.

If a proposal spends three pages describing offensive tooling but never clearly explains the objective, I would keep asking questions.

Adversary simulation and red teaming with Q-Sec

Q-Sec provides goal-based red team and adversary simulation services designed to test realistic attack paths across people, processes, and technology.

Engagements can be mapped to MITRE ATT&CK and built around the systems and security questions that matter to the organization. Depending on scope, testing can cross external infrastructure, internal networks, Active Directory, cloud environments, Microsoft 365, applications, APIs, and human attack vectors rather than stopping because one system belongs to a different testing category.

Q-Sec can also combine offensive testing with optional SOC detection validation. That gives the exercise another useful dimension: not only whether the attack path worked, but also what the defensive side saw while it was happening.

For organizations that are not ready for a full adversary simulation, a targeted penetration testing engagement can validate a narrower set of systems first.

FAQ

What is adversary simulation?

Adversary simulation is controlled security testing that reproduces realistic attacker behavior across multiple stages of an attack. It tests whether security controls can prevent, detect, and respond to the techniques used in the scenario.

What is the difference between adversary simulation and red teaming?

Adversary simulation reproduces realistic attacker behavior, often using threat intelligence and ATT&CK techniques. Red teaming is usually objective-driven: an authorized offensive team attempts to achieve a defined goal while testing how the organization's defenses respond. The two approaches can overlap.

What is the difference between adversary emulation and simulation?

Adversary emulation is more specific: it uses threat intelligence about known adversaries and their behavior to reproduce that threat. Adversary simulation is a broader term and does not necessarily imitate one particular threat actor.

Is adversary simulation the same as penetration testing?

No. Penetration testing generally focuses on finding and validating exploitable vulnerabilities within a defined technical scope. Adversary simulation follows a realistic attack scenario toward an objective and can test prevention, detection, response, people, and processes along the way.

Can red teaming be automated?

Parts of it can. Automated red teaming and adversary emulation tools can execute repeatable attacker behaviors and are useful for testing controls and detections. Human operators are still important when the exercise requires adaptation, judgment, stealth, or changing attack paths.

What is MITRE ATT&CK used for in adversary simulation?

MITRE ATT&CK provides a common language for describing adversary tactics and techniques. Red teams can use it to design scenarios, map activity during an exercise, and connect testing to behaviors observed in real-world threat intelligence.

When should a company run an adversary simulation?

Adversary simulation is most useful when basic vulnerability management and penetration testing are already established and the organization wants to test a broader question: whether realistic attacker behavior can bypass its controls and reach an important objective.

Does a successful red team have to reach its objective?

No. Being blocked or detected is useful evidence too. A red team exercise should show both where an attacker can make progress and which defensive controls successfully interrupt that progress. NIST explicitly includes demonstrating what works for defenders in the purpose of a red team.