Adversary simulation · Dubai
A full-scope simulated attack aimed at one asset you name, through technology, people and physical access. Shows whether your team detects and stops a real intruder.
Organizations we secured
A Red Team assessment is an objective-based engagement in which operators attempt to reach a specific, named asset inside your organisation using the methods a real intruder would, while your defenders are not told it is happening. What it measures is whether an attack would be detected and stopped, not how many vulnerabilities exist.
The vulnerabilities used along the way are incidental. The finding is the path, and what your controls did about it. Which is also why it is rarely the right first purchase: against an estate with no detection capability it confirms what you could have written down in advance.
Three different questions, and buying the one that answers a question you were not asking is the most expensive mistake in this market.
| Dimension | Vulnerability assessment | Penetration test | Red Team engagement |
|---|---|---|---|
| What is scoped | Named hosts, applications or IP ranges, usually the whole estate instead of a sample. | Named systems, applications or IP ranges, agreed in writing before anything starts. | Everything standing between an outsider and one named objective, including people and, where you agree to it, buildings. |
| Objective | Find and rate the known weaknesses across everything in scope, as completely as the tooling allows. | Find, validate and rate as many weaknesses as that scope contains. | Reach the crown jewel you named, and record what noticed on the way. |
| Is the Blue Team told | Yes. It is a scheduled, announced scan inside an agreed window. | Usually yes. It is a scheduled test inside a known window. | No. Only a small white team knows, and it holds the authorisation letter. |
| Typical duration | Hours to a few days, and normally run on a repeating cycle. | Days to a few weeks, set by the size of the scope. | Six to ten weeks, kickoff to report walkthrough. |
| Techniques allowed | Authenticated and unauthenticated scanning, with a person verifying what it reports. Nothing is exploited. | Technical exploitation inside the agreed scope, in the agreed hours. | Whatever a relevant adversary would use and the rules of engagement permit: phishing, exposed services, supplier paths, physical entry where it is in scope. |
| What you get at the end | A prioritised list of known vulnerabilities with severity, checked for false positives. | A findings report with severities, evidence and remediation steps. | An attack narrative, the attack path, a detection gap analysis, MITRE ATT&CK mapping and technical findings. |
| What it proves | Which known weaknesses were present across the estate on the day it ran. | That a given system can or cannot be broken by a skilled tester. | Whether your people, process and tooling together notice a determined intruder, and act in time. |
| When to choose it | You need breadth and repeatability, or a regulator asks for a testing cycle between the deeper engagements. | You already know which systems worry you, or a customer or regulator has asked for a scoped test. | You have monitoring and an incident process, and the open question is behavioural, not technical. |
They are a ladder, and most organisations here climb it: a vulnerability assessment cycle running continuously, a penetration test against whatever changed, and a Red Team annually or when a regulator asks. Purple Teaming is not a fourth rung. It is the session that closes a Red Team engagement, which is why it is not in the table.
If the budget covers one this year: cannot say what is exposed, buy the penetration test. Can say, and the open question is whether anyone would notice, the rest of this page is about that.
The product of a Red Team assessment is a measurement of detection and response, so it only returns a useful answer where detection and response already exist. If nobody is reading the alerts, we will reach the objective in the first fortnight, and you will have paid for a ten week exercise to learn something a five day one would have told you.
So we say it plainly, and we say it before a proposal goes out: an organisation with no detection tooling, no central logging or no incident process should buy a penetration test first. Not because a Red Team would fail, but because it would succeed so easily that nobody learns anything worth the invoice.
This gate is not a sales filter. It is the difference between a report that changes what your security operations team does on Monday and a report confirming the estate is soft, which you already suspected.
The attack chain in the next section is the same in every case. What changes is where the exercise starts, how wide it runs, and whether your defenders are watching while it happens.
Type 01
Your teams are told nothing. We pick the scenarios, choose the way in, and work from outside the perimeter toward the objective. Only the white team knows an engagement is running, and it holds the authorization letter throughout.
Type 02
The scenario is built from the modus operandi of adversaries that actually target your sector and this region, so the techniques are the ones your own threat model names. The intelligence work happens first and is agreed in writing before any testing starts.
Type 03
The engagement starts from a foothold you grant us: one ordinary workstation and one ordinary user account, as though a phishing email had already landed. Nothing is spent on getting in, so the budget goes on what happens next.
Type 04
We attack while your Blue Team watches with their tooling open. Each technique is announced, run, then run again after they tune, so the feedback loop closes in minutes instead of weeks. It bolts onto any engagement above and it also stands alone.
Nothing here is improvised on the day. Each phase has an owner on our side, a boundary written into the rules of engagement, and an output the next phase depends on.
We agree the objective in the language of your business: the payment approval path, the patient record, the controller on the plant floor. The rules of engagement name what is out of bounds, the hours we may work, and what counts as proof of access.
The white team is named, the authorisation letter is signed by somebody with the authority to sign it, and the attribution channel is tested. Nothing is pointed at anything until all of that exists.
Open sources first: what your organisation publishes about itself, what your staff publish about their work, what your suppliers and your job adverts give away. Most of the useful material is already public.
Then the external surface itself, mapped without touching it hard enough to be interesting. The output is a picture of where you are reachable and who is worth approaching.
One route in, chosen because it is realistic. Clever is not the point. That may be a payload behind a pretext your staff would plausibly accept, an internet-facing application, or a supplier connection that carries more trust than it should.
Delivery is tested against the controls in front of it and never assumed to work. Routes that failed are recorded too, because a control that stopped us is a finding worth having.
From the first foothold the work is quiet: understanding the estate, collecting credentials, and moving between segments and identities toward the objective rather than sprinting at it.
Every technique is logged against its MITRE ATT&CK identifier as it happens, with a timestamp your SOC can line up against their own telemetry afterwards.
Getting data out is a control in its own right, and the one most often assumed and least often tested. We test whether your egress path notices, using a channel a real intruder would pick.
Nothing is encrypted, altered or genuinely taken. Reaching the objective means proving we could act on it, not acting.
Every account, implant and piece of tooling is removed, and the list is handed over so your team can verify the estate is clean instead of taking our word for it. The infrastructure is torn down at the end.
The attribution log is reconciled against your incident tickets, and the engagement closes with a walkthrough on a call.
An exercise indistinguishable from a real intrusion carries real operational risk, and most of it lands on you. These are the six controls we put around it, published because you should be asking every provider the same six questions before you sign.
Two to four named people on your side who know the engagement is running when nobody else does. They hold the authorisation letter, the exclusion list and the authority to halt it with one message. Chosen for being reachable, not senior.
A channel open for the whole engagement that does not run through anything being tested, so your SOC can ask is this you at three in the morning and get an answer. Without it the exercise becomes a real incident response at your cost.
Infrastructure stood up for one engagement and one client: dedicated domains, redirectors, command and control, mail. Nothing shared, nothing reused, and destroyed outright at the close, because attacker infrastructure left running is a liability for whoever it still points at.
We start quiet and get louder in deliberate steps, which gives your Blue Team the most chances to catch something and tells you where on that scale they sit. The order matters: alerting them cannot be undone.
Signed before anything starts, naming the scope, the objective, the excluded systems, the permitted hours and who may know. Operators carry it during physical work, so a guard doing their job correctly can end the exercise with one call and be right to.
Reaching the objective means proving we could act, not acting. Nothing encrypted, deleted or genuinely taken, production changes agreed in advance or not made, and denial of service out of scope unless you ask in writing.
The centre of the deliverable is the detection gap analysis: the route we took, set beside your own telemetry, every step marked detected, logged only, or missed entirely, with the reason it went that way. That is the part that changes what your team does next, and the part no scanner produces at any price.
Because every technique carries its MITRE ATT&CK identifier, one document serves two rooms. Risk and audit read the narrative and the executive summary, and report against the framework they already use. Engineering reads the path and the findings, and writes rules. Nothing arrives as an attachment alone: the pack is walked through with both audiences.
Where the engagement supports a UAE regulatory testing obligation, the scoping evidence and reporting trail are assembled in the form an examiner expects. Which wording applies depends on your licence and sector, and we agree it with your compliance team in writing beforehand.
Read the UAE regulation explainerThe questions below are the ones that come up in almost every scoping call. If yours is not here, ask it directly and we will answer it in writing.
A red team assessment is a goal-driven simulation of a real attack against one asset you name, run while your defenders are not told. Rather than testing a list of systems, we agree a single objective with you, such as reaching a payment approval path, and work toward it using whatever the rules of engagement allow.
The vulnerabilities used along the way are incidental. The finding is the path we took and what your controls did about it at each step. Because nobody in the SOC knows the exercise is running, what gets measured is how the organisation behaves on an ordinary day.
The exercise follows the six phases described above, from planning and reconnaissance through exploitation, post-exploitation and exfiltration to clean closure. Every technique is logged against its MITRE ATT&CK identifier as it happens.
A red team assessment answers the behavioural questions a scan cannot touch: whether anyone notices an intruder who is not trying to be seen, whether an alert reaches a human, and whether that human acts in time.
It also tests segmentation the way an intruder tests it, by looking for the way around a boundary rather than checking that a rule exists. A scan reports which known weaknesses were present on the day it ran. It cannot say what your people and process would have done about them.
The evidence covers people, process and tooling together, which is where real incidents are decided. That is why the detection gap analysis, not the list of technical findings, sits at the centre of the report.
Four UAE regimes shape who buys a red team assessment: the CBUAE for banks, the ISR standard from DESC for Dubai government entities, ADHICS for Abu Dhabi healthcare, and the UAE IAS from NESA, now SIA, for critical infrastructure. The wording differs by regime and by licence, so we agree which applies with your compliance team in writing beforehand.
Banks and other institutions licensed by the Central Bank of the UAE. Their supervisory testing obligations are typically what brings a red team assessment onto the table.
Dubai government entities and their material suppliers, under the ISR standard published by the Dubai Electronic Security Center.
Healthcare providers in Abu Dhabi, under the Department of Health standard, where the named objective is usually the patient record.
Critical infrastructure and government under the Information Assurance Standards published by NESA, now SIA. A tender that says NESA means the IAS.
Whatever the regime, the readiness test is the same: you need monitoring, central logging and an incident process, and an asset whose loss would be serious. Without those a penetration test is the better purchase.
A full-scope red team assessment takes six to ten weeks from kickoff to report walkthrough. An assumed breach start is shorter because nothing is spent getting in. Each engagement is quoted individually, because the driver is the objective and the scope rather than a fixed calendar.
Roughly the first fortnight. The objective, rules of engagement and authorisation letter are agreed, then open-source and external reconnaissance builds the picture of where you are reachable.
The middle block. Exploitation, post-exploitation and exfiltration run at a deliberate tempo, starting quiet and getting louder in steps so your Blue Team has the most chances to catch something.
The last stretch. The report pack is written, walked through with both audiences, and closed with a Purple Team debrief. An optional retest follows once the fixes land.
Once a year is the common cadence for a red team assessment, and it is what most testing obligations assume. A material change to the estate argues for running one sooner.
Detection work that has not landed yet argues for waiting. Running again before the fixes from the last engagement are in place measures the same gaps twice and teaches nothing new.
Between assessments, a continuous vulnerability assessment cycle and a penetration test against whatever changed carry the load. That is the ladder described in the comparison above, and most organisations here climb it in that order.
The SOC learns from a red team assessment exactly which steps of a real intrusion its telemetry saw, which it logged without alerting on, and which it missed entirely, with the reason each went that way. That is the detection gap analysis, and it is the centre of the report.
Because every technique carries its MITRE ATT&CK identifier and a timestamp, your analysts can line our log up against their own telemetry and see where the chain went dark. The mapping also lets you track coverage from one engagement to the next.
Then the Purple Team debrief replays the missed steps with your defenders in the room until each one produces an alert your analysts wrote themselves. The debrief is where the improvement happens, not the PDF.
Yes, a red team assessment can be built around a specific threat actor, and usually it should be. This is the threat-intelligence-led shape: we research the adversaries that plausibly target your sector and region, then build the scenario from their documented tradecraft rather than our own preferences.
The intelligence work happens first and is agreed with you in writing before any testing starts. That sequence, intelligence then scenario then execution, is the one TIBER-EU and Advanced Red Teaming are built around, and we work to it without claiming accreditation under either.
If your board is asking whether a campaign in the news would have worked here, this is the version to buy. The adversary simulation page describes how the actor is chosen and how the scenario is approved.
A red team assessment works against your defenders without telling them and measures what happens. A purple team exercise works with them in the room, announcing each technique, running it, and running it again after they tune. One measures, the other builds.
Purple teaming is not a fourth rung on the testing ladder. It is the session that closes a red team assessment, which is why it does not appear in the comparison table above. It can also stand alone for teams that already know their gaps and are buying detection engineering time.
The two are strongest run together. The assessment produces the list of missed techniques, and the purple session turns each one into an alert before the next assessment measures again.
A penetration test asks what is broken inside a scope you have named. A red team assessment asks whether anyone would notice an intruder working toward one objective, through technology, people and physical access. They answer different questions, and the comparison table above sets them side by side with a vulnerability assessment.
A penetration test is scheduled, usually announced, runs for days to a few weeks, and returns findings with severities and remediation steps. A red team assessment runs for six to ten weeks unannounced and returns an attack narrative, an attack path and a detection gap analysis.
If the budget covers one this year and you cannot say what is exposed, buy the penetration test. An organisation with no detection tooling, no central logging or no incident process should do the same, because a red team assessment against it succeeds so easily that nobody learns anything worth the invoice.
A red team assessment is scoped in a session that ends with a written objective and rules of engagement, and authorised by a letter signed by somebody with the authority to sign it. Nothing is pointed at anything until both exist.
An NDA precedes the first detailed conversation. The scoping session names the objective in the language of your business, what is out of bounds, the hours we may work, and what counts as proof of access. A white team of two to four reachable people is named and the attribution channel is tested.
You receive weekly written updates through the white team. Everything else on your side runs as normal, because the measurement depends on your defenders not knowing. The white team can halt the exercise with one message at any point.
You receive the full report pack: attack narrative, attack path graph, detection gap analysis, MITRE ATT&CK mapping, executive summary, technical findings and the artefact inventory. It is walked through with both audiences, followed by a Purple Team debrief and an optional retest.
Yes, a red team assessment includes social engineering where the scope permits, because it is how a large share of real intrusions begin. That means phishing and targeted pretexts, telephone pretexting, and physical entry where a scenario calls for it and you have agreed to it in the rules of engagement.
It tests process and controls, never named individuals. The report describes the pretext and what the controls around it did. It does not name the person who clicked.
During physical work our operators carry the signed authorisation letter, so a guard doing their job correctly can end the exercise with one call and be right to. That outcome is a finding worth having, and it goes in the report.
A red team assessment is designed to run against production, because that is the only estate whose detection and response is worth measuring. The rules of engagement are written to make damage rare: no destructive actions, no denial of service unless you ask in writing, and production changes agreed in advance or not made.
Reaching the objective means proving we could act, not acting. Nothing is encrypted, altered or genuinely taken, including during the exfiltration phase, where we test whether your egress path notices rather than moving real data.
If something does break, we stop and the white team hears within minutes on the attribution channel. We help restore it, and the incident goes in the report. At closure every account, implant and piece of tooling is removed and listed so your team can verify the estate is clean.
Tell us the objective you want tested. We reply with a scope, a timeline and a quote.
