Red teaming
A penetration test asks whether your systems can be broken into. A red team exercise asks whether anyone would notice, how fast, and what they would do about it.
ROOT64 / VERIFIED
This is a test of your people and your tooling, not just your code
A red team works towards a specific objective you define — reaching a particular data set, a payment path, a domain administrator account — using whatever combination of technical, human and physical routes the rules of engagement allow.
Your security team is usually not told. That is the point: the measurement is how your existing detection, escalation and response actually behave under pressure, not how they behave when everyone knows a test is running.
Success is not "we got in". Success is a clear picture of which of our actions generated an alert, which alerts were investigated, how long each step took, and where the process broke.
Red teaming is not a first engagement
If you have never had a penetration test, a red team exercise will find the same basic issues at several times the cost. Fix the known ground first.
You need some form of monitoring in place. Measuring detection where there is nothing to detect with produces an expensive report saying so.
Where an organisation is not ready, we say so and propose the engagement that is actually useful instead.
Scope
Techniques available, subject to the rules of engagement
- Open-source intelligence on the organisation and its people
- Phishing and pretexting against agreed target groups
- External exploitation for initial access
- Payload delivery and endpoint control evasion
- Persistence, privilege escalation and lateral movement
- Credential access and internal reconnaissance
- Objective actions — controlled access to the agreed target data or system
- Physical site access, where separately authorised
Hard limits, always
- Destructive actions, ransomware simulation on live data, or anything that impairs a production service
- Real customer or employee personal data — access is proven and evidenced, never collected
- Targeting individuals outside the agreed group, or any activity against a third party
- Any technique the signed rules of engagement do not explicitly permit
How the exercise runs
Every step is authorised, evidenced and designed to leave your team with a clear next action.
-
Objectives and authorisation
You define the crown jewels. We agree the rules of engagement, the deconfliction process, a named trusted agent inside your organisation and the conditions under which the exercise stops immediately.
-
Threat profile
We select the adversary behaviour to emulate based on your sector and realistic threat, and map planned actions to MITRE ATT&CK techniques so coverage can be measured afterwards.
-
Reconnaissance
Passive intelligence gathering on the external footprint, supply chain and people.
-
Initial access
The agreed route in — phishing, an external weakness, or an assumed-breach starting position if you would rather spend the budget on the internal phase.
-
Operate
Persistence, escalation and lateral movement towards the objective. Every action is timestamped and logged for later comparison against your alerts.
-
Objective
Controlled proof that the target was reachable. Evidence, not extraction.
-
Purple team debrief
We sit with your defenders, replay the timeline against their tooling, and identify what fired, what did not, and what should have.
-
Report and remediation plan
Attack narrative, ATT&CK coverage map, detection gap analysis and prioritised improvements for both controls and process.
What gets measured
- Time to detect
- From our first in-scope action to the first alert that fired on it.
- Time to escalate
- From that alert to a human treating it as an incident rather than noise.
- Time to contain
- From escalation to our access being meaningfully disrupted.
- Detection coverage
- Percentage of executed ATT&CK techniques that produced any telemetry, an alert, or an investigated alert. These are three very different numbers.
What you receive
Included in every engagement
- Full attack narrative with a timestamped action log
- MITRE ATT&CK coverage and detection gap matrix
- Detection and response timing analysis
- Purple team workshop with your defenders
- Prioritised improvements split into control changes and process changes
- Executive briefing suitable for the board
- Optional re-run after remediation to measure the change
Standards and methodology
Testing follows published methodology rather than an in-house checklist, so coverage is reviewable and comparable between engagements.
- MITRE ATT&CK
- TIBER-EU (as a structural reference)
- CBEST (as a structural reference)
- NIST SP 800-115
Common questions
Should our security team know?
Usually not, beyond one or two trusted agents who hold the authorisation and the deconfliction line. If they know, you are measuring a rehearsal.
What if we detect and block you early?
That is a good outcome and the report says so plainly. Depending on the rules of engagement we either stop, or reset to an agreed position and continue, so the rest of the chain still gets tested.
Is this legal?
Only with signed authorisation from someone empowered to give it, covering every asset in scope. We do not begin without it, and we will not test infrastructure you do not control without the third party's written consent.