This simulation shows a typical path — from first reconnaissance to reaching the objective. Real engagements usually run over days to weeks, not minutes.
Simplified illustration of a realistic attack path. Actual duration, sequence, and vectors depend on the agreed scope.
Download an anonymized sample report and see for yourself how thoroughly we document an attack chain.
An exposed account, an unguarded door, one phishing email: each often rated 'medium' on its own. Only the chain — phishing, stolen credentials, physical access, lateral movement — reveals the real business impact, the same path a real attacker would take.
Module-based pentests are usually scheduled and known in advance. Red Teaming additionally tests whether your SOC or blue team notices a real, unannounced attack at all — and how fast they respond.
Modules systematically cover the breadth of your attack surface. Red Teaming pursues one defined objective using every realistically available means — exactly like a real, motivated attacker would.
| Aspect | Module-based pentest | Red teaming |
|---|---|---|
| Guiding question | Where are the vulnerabilities? | How far does an attacker get? |
| Scope | Single system / single vector | Entire organization, one defined objective |
| Awareness | Known and scheduled | Covert, usually only C-level informed |
| Tests detection & response | Not the focus | A core part of the engagement |
| Best suited for | Compliance evidence, annual cadence | Security maturity beyond compliance |
| Physical access | Only if booked separately | Included in the attack chain by default |
The two aren't mutually exclusive: most of our red team clients have already run module-based pentests with us or other providers and now want to know whether their detection actually holds up in a real incident.
A red team takes whichever route works, and it is rarely the most elegant one. So we plan every engagement across several vectors at once and switch as soon as one stops leading anywhere. Which of them are used is set in the scope.
Targeted emails to a single department, calls in the name of IT support, prepared USB sticks or a QR code on the notice board. In most engagements this is the fastest way to a first foothold.
Tests: awareness, reporting behaviour, MFA rolloutWe follow someone in through the side entrance, copy an access card in passing, or leave a device in a meeting room that calls home. The physical pentest page explains how this works in detail.
Tests: access control, reception, how staff treat strangers Physical pentestForgotten VPN portals, weak passwords on service accounts, group permissions that reach too far. Inside the network, the path to the objective almost always runs through Active Directory.
Tests: hardening, segmentation, AD tiering Active Directory pentestA captured password is usually a cloud login these days. We check conditional access rules, MFA exceptions, legacy protocols, and which further doors a compromised mailbox opens.
Tests: conditional access, MFA gaps, cloud logging
Objective, boundaries, authorized contacts, and escalation paths are defined together — including a letter of authorization.
OSINT, footprinting, and planning of realistic attack paths — passive, without leaving traces.
Through phishing, vishing, or physical access, we establish an initial, persistent foothold.
Lateral movement up to the agreed objective — with complete, logged evidence of every step.
Full reconstruction of the attack chain, business impact assessment, and prioritized recommendations.
A joint debrief with your blue team — what was detected, what wasn't, and why.
The goal isn't simply 'getting in' — it's proving whether your organization detects and stops a real attack.
The classic approach starts from outside with no prior knowledge. It is the most realistic option, and the most expensive one. Depending on maturity and budget there are three further variants we run regularly.
From internet research to the objective, with no prior knowledge and no announcement. Measures the whole system including detection and response.
Organisations with their own SOC or an MDR provider who want to know whether it holds up in a real incident.
We start with what an attacker would have after successful phishing: a regular employee account and a laptop on the network. This skips the initial access phase and puts the budget into the path to the objective.
A first test of internal detection, or when phishing has already been tested separately.
Attack and defence sit in the same room. We run one technique after another, your team checks live whether and where alerts fire, and detection is tuned on the spot.
Teams building a SIEM, or closing the gaps found by a red team in a structured way.
For financial entities heading towards a TLPT under DORA: red teaming along the TIBER-EU phases, with a threat intelligence lead-in, a control team on your side and matching documentation. Processes and roles get a full rehearsal before the mandatory test.
DORA pageBanks, insurers and payment providers that the supervisor has selected for a TLPT, or that expect to be.
A red team uses the methods of real attackers, but not their freedoms. Before the first email goes out there is a set of rules both sides sign. These points are part of every engagement we run:
Names the client, scope, time window and the authorised operators. On every physical job our people carry it with them, together with a phone number where a contact can confirm the assignment.
One or two people on your side who are in the know and reachable throughout the engagement. They know what we are doing, can escalate, and decide in doubt whether an alert is real or ours.
Either side can stop at any time. We pause on our own as soon as we find traces of a real attacker, would put a production process at risk, or people could get hurt.
No deleting, no encrypting, no denial of service, no changes to production data. Where a real attacker would deploy ransomware, we drop a marker file and document the access.
We do not copy out real customer or personnel data. Access is proven through screenshots, hash values or test records placed in advance. Captured credentials are stored encrypted and deleted after the project.
Employees' private devices and home connections, third-party systems outside the scope, and safety-relevant OT controls are excluded unless you explicitly release them.
Every action is recorded with timestamp, source and target. That lets your SOC map every alert to a step afterwards and tell our activity apart from a real one.
If your SOC reports an incident during the engagement, the white cell checks with us within minutes whether it came from us. If it did not, we pause and you treat it as a real incident.
The live simulation above shows the attack from our side. For you, the mirror question matters: which of it did your detection see, and when? That is why the report sets each attack phase against what actually reached the SOC.
| Phase | Our action | What the SOC saw | Verdict |
|---|---|---|---|
| Recon | OSINT, passive reconnaissance, external port scan | Nothing. With passive reconnaissance that is expected. | Neutral |
| Initial access | Phishing to six employees, two sets of credentials captured | One person reported the email after 40 minutes. The ticket saw no follow-up. | Detected, no response |
| Physical foothold | Tailgating, rogue device in a meeting room | Nothing. The device ran until the debrief. | Not detected |
| Internal access | Network scan, Kerberoasting | SIEM alert on unusual Kerberos requests, closed as a false positive | Detected, misjudged |
| Privilege escalation | Lateral movement to three servers | EDR blocked one tool. The operator switched methods, no further alert. | Partially detected |
| Objective | Domain admin, marker file placed | Only at the debrief | Not detected |
Simplified, anonymised example based on typical results. This comparison is where the real recommendations come from. Next to the patch, the list then holds items like “take alert X seriously” or “change the visitor process”.
The report is written for two readers: management, who want to know where things stand in ten minutes, and the security team, who need to trace and reproduce every step.
View the anonymised sample reportTwo pages: objective reached or not, by which route, what it would have meant in a real incident, the three most important measures.
The full path in chronological order, with times, screenshots and the decisions we made along the way. The dead ends are in there too.
Each phase set against the alerts, tickets and responses of your SOC, like the scorecard above.
Every weakness with a CVSS rating, plus the question: would fixing it have broken the chain at this point? That often orders priorities differently than the score alone.
All techniques used with their ATT&CK ID, so your team can tune detection rules precisely and compare against threat intelligence.
Sorted by effort and effect, split into immediate actions, organisational changes and longer-term projects.
IPs, domains, hashes and hostnames of our infrastructure, so you can search your logs afterwards and separate our traces from foreign ones.
red team engagements delivered
vectors tested per engagement (human, physical, technical)
engagements with undetected access to the objective
physical pentests delivered, the foundation of our attack chains
Red teaming is not mandatory for everyone anywhere. In several places, though, it is the way to actually prove the effectiveness review that is required.
Art. 26 obliges financial entities designated by the supervisor to run a threat-led penetration test under TIBER-EU every three years. Everyone else falls under Art. 25 with regular testing, for which red teaming is the most demanding form.
DORA pageArt. 21 requires policies and procedures to assess the effectiveness of risk management measures. A red team delivers exactly that assessment, including the human factor and detection.
NIS2 pageClause 9 of the standard requires information security to be monitored, measured and evaluated. In an audit, a red team report is solid evidence that effectiveness was reviewed independently.
ISO 27001 pageOperators of critical infrastructure prove every two years that their measures reflect the state of the art. Red teaming does not replace that review, but adds the attacker's view of the whole system.
KRITIS pageThe terms from the simulation and the report, without the jargon.