Testing whether agreed objectives can be reached, and how your organisation responds
We answer ‘would we hold up against a real attack?’ with evidence from actually trying.
We set an objective worth protecting, such as customer data or a core system, and go after it as a real attacker would. It runs as an objective-based penetration test, which shows the path to the objective, or as a red team exercise, which also records how your organisation responds.
When a realistic attacker goes after an objective, how does the organisation prevent, detect and respond?
Whether the objective was reached, and where it was noticed and stopped, assessed with a record of every stage.
Expert reviewed
You have security tools, monitoring and response procedures, but nothing to show when someone asks ‘would we actually catch it?’
If one staff PC or account were compromised, would it spread across the company, and where along the way could it be stopped?
A real attacker does not stop at one vulnerability but chains several towards an objective. You want to see that journey, and how you respond along the way.
Your board is asking how well you would hold up against a real attack, or leadership wants a test run like the real thing, without the security team being told.
We first set an objective such as ‘can anyone reach customer data?’ and put our effort into the paths that lead there.
The attack record and your organisation's detection, escalation and response records are laid on one timeline, so where you noticed and where you missed is plain to see.
Within the approved scope, phishing and social engineering, the supply chain, wireless and physical access can all be part of the scenario.
Can an attacker actually reach the objective, and by what path?
Playing the attacker, we chain weaknesses towards the objective and show, with evidence, under which conditions and by which path it was reached, or where the attempt stopped.
Would the organisation notice and stop an attacker going after the objective?
We act as a real attacker going for the objective, and record and assess, stage by stage, when your organisation notices and how it stops and responds.
To train and fix detection technique by technique together with your defenders, see Purple Teaming & Detection Exercises, part of Security Capability Development for People & AI.
We run it to that framework's requirements, led by threat intelligence.
Scenarios built from the threat intelligence relevant to you, run as a red team exercise to test detection and response.
We analyse your attack surface, leaked information and the relevant threat actors to give the TLPT scenarios their basis.
We agree with you the objective and scope, and how much your defenders are told in advance.
We prepare realistic attack scenarios from the objective, the exposure our exposure intelligence has confirmed, and the methods of the threats that have targeted your sector.
Playing the attacker, we move towards the objective and record, at each stage, what we did and how the organisation reacted.
Afterwards we go through the attack record and the response record with the teams involved.
We set out what to strengthen and, if you wish, check again after changes are made.
Keeping it safeWhere an attempt could affect operations, we go ahead ready to stop it at once. The principles every engagement follows, safe conduct and stop conditions, facts kept apart from assumptions, and how material is kept and destroyed, are set out under How we work.
The paths taken, how they unfolded over time, and whether the objective was reached or where the attack was stopped.
What was actually blocked, detected and reported at each stage, and how your organisation responded.
Where detection and response need strengthening, and what to check again after changes are made.
Starting point: one integration account issued to a partner · Defenders: only the head of security and the approver know in advance
| Stage | Result | Evidence |
|---|---|---|
| From the partner account to the build server | Got through | The partner's integration account could reach the build server's job screens, not only the repository it needed. |
| From the build server to deployment rights | Got through | A deployment token sat in plain text in a build job's settings, and with it deployment rights could be taken. |
| From deployment rights to the live service | Stopped | Deployments to the live service require two approvers, so the live service was not reached. |
| Detection along the way | Needs work | The unfamiliar access to the build server was logged, but with no alert rule nobody noticed while it was happening. |
The response assessed here is prevention, detection and response in the cyber-attack scenarios set for the test; whether the organisation notices and responds is this service's question. Whether ransomware could halt your operations and block recovery is examined in Ransomware Resilience Validation; that validation records where detection would occur, but assesses blocking and recovery.
Related research: Offensive Engineering (EXPLOIT) — We research ways to analyse and verify vulnerabilities and their impact from an attacker's perspective.
Tell us what worries you, or what you want checked. A few lines are enough.
We reply with a proposed scope, schedule and cost, and settle them with you.
Once agreed, the work begins. Results and next steps come to you as it runs.
