Home
VAPT Web Application PentestAPI PentestMobile App PentestInfrastructure PentestAI & LLM PentestOT / ICS PentestIoT PentestPenetration TestingAll VAPT services
Red Team Red Team EngagementAdversary SimulationAssumed BreachPurple TeamingSocial Engineering
CompanyResourcesBlogFree Consultation

What your SOC should catch during a Red Team engagement

A Red Team measures your SOC, not your estate. What each phase should trigger, what happens when analysts catch the operators, and how the verdicts are built.

Joel Aviad OssiJoel Aviad OssiRed Team Lead, RedTeam Security
7 min read
A dark console holding a row of brass signal lamps, one lit green among unlit ones, with a brass stopwatch beside them and a red thread running past the lamps to a small steel vault at the far end.

Key takeaways

  • A Red Team engagement measures detection and response, not exposure. Every operator step ends with one of three verdicts: detected, logged only, or missed.
  • Logged only is the verdict to take seriously. The sensor was in place and the response path was not, and no purchase corrects that.
  • The through phase decides the exercise. Credential access, lateral movement and directory changes leave traces on hosts and identity systems, not on the perimeter.
  • A detection during the exercise needs a decision made in advance: let it run, deconflict, or reset the foothold. Write the three answers into the rules of engagement.
  • The detection gap analysis is built by reconciling the operators' timestamped log against the SOC's tickets, with time to ticket and time to action per step.

A Red Team engagement measures the SOC, not the estate

A penetration test asks what is exposed. A Red Team engagement asks a different question: whether anyone notices when a determined operator moves from the outside to a named objective. The defenders are not told it is running. The estate is the ground the exercise is run across, and the thing being measured is what your monitoring and your people do while it happens. That is why the central document in the pack, as the UAE rules that expect a Red Team set out, is a detection gap analysis rather than a findings list.

That analysis gives each step the operators took one of three verdicts. Detected: an alert reached a person, and that person acted before the operators took the next step. Logged only: an alert or a record was raised, and nobody acted on it in time. Missed: nothing was raised at all, whether or not the event sits somewhere in raw logs. Each step is identified against MITRE ATT&CK, so this year's verdicts can be compared with last year's and with another provider's.

Two of the three verdicts are failures, and the middle one is the one to take seriously. A missed step is a sensor or a rule gap, and it is fixed by adding one. A logged-only step means the sensor is in place and the response path is not. That is a question about shifts, escalation and authority, and it is not answered by buying anything.

What each phase leaves behind, and where

The operators move through the same three phases the kill chain on this site draws: in, through and out. Each phase leaves a different kind of trace on a different sensor, and a SOC that watches the perimeter measures well in the first phase and barely at all in the second. The table sets out what should fire in each, without assuming the estate already has all of it. If it does not, the detection floor a Red Team needs comes first, and the exercise waits.

The through phase is where the exercise is decided. Credential access, lateral movement and privilege escalation all happen inside the network, on hosts and on identity infrastructure. The signals are authentication logs, endpoint telemetry and directory changes, none of which a firewall sees. NIST SP 800-137 describes continuous monitoring as a capability that spans the organisation rather than its edge, and this phase is the practical test of whether yours does.

Read the last column. It names where each signal comes from, so a missed step can be traced to a sensor that is absent or a rule that does not exist, rather than written up as a general failure of monitoring.

What a SOC should see in each phase of a Red Team engagement, with the ATT&CK technique the operator step maps to and the sensor the signal comes from.
PhaseOperator step (ATT&CK)What should fireSource of the signal
InPhishing with a payload (T1566)A mail gateway verdict, then an endpoint alert on the process the attachment startsMail security, endpoint detection
InCommand and control beacon (T1071)Outbound connections to a recently registered domain on a regular intervalProxy and DNS logs
ThroughCredential dumping (T1003)Access to LSASS memory from an unsigned processEndpoint detection
ThroughLateral movement over SMB or WinRM (T1021)Workstation-to-workstation logons and remote service creationWindows event logs, identity platform
ThroughPrivileged group change (T1078)New membership of a privileged group outside change controlDirectory audit log
OutExfiltration over the C2 channel (T1041)A large or unusual outbound transfer from a host that never sendsProxy, data loss prevention where present

One chain, drawn against the SOC

The figure draws a chain of the kind a Red Team runs, with the SOC as the fourth column, so the verdicts can be seen where they happen. The operators deliver the pretext, the social engineering component is one member of staff opening a file, and everything after that is a question about the estate rather than the person. The step the chain turns on is not the click. It is that nothing on the workstation stops an unsigned process starting under the user's session.

Watch the two arrows into the SOC column. The first is a low-severity endpoint alert closed as noise, which is the logged-only verdict in the shape it actually takes: the record existed, a person saw it, and closing it took less than a minute. The second is a credential access alert that opens a ticket. That step counts as detected only if the ticket is triaged before the operators finish the next one. In the drawn chain it is not, so the verdict is decided by time rather than by the rule.

That is the part a SOC dashboard hides. Alert volume and mean time to acknowledge are measured against the queue. A Red Team measures them against the operators' clock, and the reconciliation in the last section is how the two are set side by side.

Both arrows into the SOC column are records. Only one becomes a ticket, and the verdict on that step is decided by how long the ticket waits.

When the SOC catches the operators

A detection during the exercise is the best outcome the engagement can produce, and it needs a decision made in advance about what happens next. The SOC treats the alert as real, because to the analysts it is: they do not know the source, and the moment they are told, the measurement stops. Escalation runs up the incident process it would follow for any intrusion until it reaches someone in the control group, the small set of people who know the exercise is running and whose names are in the rules of engagement.

The control group then chooses one of three answers, and the choice is recorded with a timestamp. Let it run: the SOC's containment proceeds and the operators lose the foothold, which is the truest measurement of all. Deconflict: the SOC is told that this incident is the exercise, so real incidents are not starved of attention, and the step is still scored as detected with the time to that point. Reset: the operators are granted a fresh foothold to test the rest of the chain, in the manner of an assumed breach exercise, because a chain stopped at step two says nothing about steps three to eight.

What the decision must not do is depend on who is on shift. Write the three answers into the rules of engagement, with who is allowed to choose each, before the first email is sent.

A catch mid-exercise is a result, not an interruption. The path from alert to control group is agreed before the exercise so the choice never depends on who is on shift.

Reconciling the operator log with the SOC's tickets

The detection gap analysis is built after the exercise from two records that were kept apart during it. The operators keep an attribution log: every action, its ATT&CK identifier, the host, the account and a timestamp to the second. The SOC keeps what it always keeps: alerts, tickets and the notes on them. Reconciliation places each line of the first against the second and asks what the SOC held at the moment the operators took their next step. NIST SP 800-115 treats that correlation as part of the analysis that follows a test rather than an optional extra, and here it is the whole product.

Written generically, as an example, two lines of a reconciliation read like the table below. The first is a step the sensor saw and the process lost. The second is a step no rule surfaced, which is the cheaper of the two to fix. The measurements that matter are in the middle columns: how long from the operator's action to a ticket, and how long from the ticket to a person acting, both set against the interval before the operators' next action.

Each logged-only and missed row becomes a detection to build, and the replay closes it: the operators repeat the step with the defenders watching until it fires, which is what a purple team session does by design. Then keep the rules working, because detection content built against one chain decays, as the piece on detection decay sets out.

Two example lines of a reconciliation between the operator log and the SOC record, constructed to show the shape and not taken from any engagement.
Operator action (ATT&CK)SOC recordTime to ticketTime to actionVerdict
Read cached credentials from memory (T1003), 10:42:15Endpoint alert at 10:42:20, ticket opened at 10:519 minutesNone before 11:30, by which point the operators held a privileged accountLogged only
Added an account to a privileged group (T1078), 11:14:03No alert. The change appears in the directory audit log and nothing surfaced itNoneNoneMissed

Where the SOC sits in Dubai and Abu Dhabi, and why it changes the rules of engagement

Whether the SOC is in-house or contracted changes who an alert reaches, and in the UAE that is a question for the contract as much as for the runbook. If a managed provider runs your monitoring, the control group needs a named person on their side as well as yours, or the provider's escalation ends at a phone nobody in your organisation answers at two in the morning. For an institution supervised by CBUAE, the detection gap analysis is the part of the pack that speaks to the monitoring expectation, and it does so in Dubai and Abu Dhabi alike, because the licence follows the institution rather than the office.

In Dubai, entities held to the DESC Information Security Regulation, and the suppliers holding their data, have monitoring controls that a logged-only column evidences as present and unattended. That is a more useful finding for an assessor than a missed column, because it points at the process rather than at procurement. In Abu Dhabi, healthcare providers under ADHICS and federal entities under the UAE Information Assurance Standards are answering a controls framework, and the same reconciliation evidences the monitoring family directly, step by step. Free-zone or mainland status changes your licensing and contracting, not the expectation attached to the data you hold. For UAE buyers in either emirate, the practical step is the same: put the control group, the provider's escalation contact and the three answers into the rules of engagement before the exercise starts.

Frequently asked questions

Should the SOC be told about a Red Team engagement?

The analysts should not. The exercise measures what they do when they believe an intrusion is real, and telling them stops the measurement. A small control group does know: named people in the rules of engagement who can receive an escalation, confirm the activity is the exercise, and decide whether to let containment run, deconflict, or reset the operators' foothold.

What happens if the SOC detects the Red Team?

The alert is handled as a real incident and escalated until it reaches the control group. The control group chooses one of three answers agreed in advance: let containment run and the operators lose the foothold, deconflict so the SOC can return to real work, or grant a fresh foothold so the rest of the chain can still be tested. The step is scored as detected, with the time to ticket and the time to action recorded.

What is a detection gap analysis in a Red Team report?

It is the document that sets the operators' attack path beside the SOC's own record and gives each step a verdict: detected, logged only, or missed. Each step is identified against MITRE ATT&CK so verdicts can be compared across years. It is built by reconciling the operators' timestamped log against the SOC's alerts and tickets, and it is the part of the pack that evidences whether monitoring produces something a person acts on.

What is the difference between detected and logged only?

Detected means an alert reached a person who acted before the operators took their next step. Logged only means an alert or a record was raised and nobody acted on it in time, so the sensor worked and the response path did not. Missed means nothing was raised at all. Logged-only steps are the ones to prioritise, because they are not fixed by adding a sensor.

The engagements this applies to

Joel Aviad Ossi, Red Team Lead at RedTeam Security
Joel Aviad OssiRed Team Lead, RedTeam Security

Joel Aviad Ossi is Red Team Lead at RedTeam Security, the Dubai-licensed trading brand of WebSec FZCO. He scopes and runs objective-based engagements across the UAE.

Let's talk about your security

Tell us the objective you want tested. We will come back with a scope, a timeline and a quote, under NDA from the first conversation.

Email [email protected]
IFZA Business Park, Building A2
Nadd Hessa, Dubai Silicon Oasis
Dubai, United Arab Emirates