Assumed Breach Assessments

The premise behind assumed breach: the attacker is already inside

The initial compromise is rarely the biggest hurdle for a motivated attacker. One careless click in a phishing email, one compromised component in the supply chain or a single weak password is enough, and the first foot is in the door. The decisive question is therefore not whether someone gets in, but: what can they do once they are inside? Modern security strategies have long acknowledged this: assume breach is an established mindset. An assumed breach assessment turns that mindset into a concrete, measurable test.

That is exactly the question an assumed breach assessment answers. We take the compromise as a given, skip the initial attack phase and concentrate the entire testing time on what matters afterwards: lateral movement through the network, privilege escalation and the path to your business-critical systems. This makes the blast radius of a single compromised workstation measurable, before a real incident shows it to you.

How attackers get that first access in the first place is what we test in a dedicated initial access assessment. In an assumed breach we deliberately leave that phase out and invest the time where most of the insights are waiting: inside your internal network.

The starting position: a standard user on a standard client

We begin with the same starting position as a real attacker after a successful phishing campaign: a standard user account without special permissions and a regular client from your standard image. No admin rights, no exceptions, no special configuration.

This starting position is chosen deliberately, because it matches exactly the scenario of a taken-over employee workstation. Everything we reach from there, a real attacker can reach too, after successfully deceiving a single person in your organisation.

For you this means minimal preparation effort: you provide a user account and a device, the same way any new employee would receive them on day one. Nothing more is needed for us to start.

What we test

From this position we work systematically through your internal infrastructure, the way an attacker would:

• Privilege escalation: starting from the standard user, we attempt to gain elevated permissions, locally on the client and in the domain.
• Active Directory: attack paths in your central identity infrastructure, from misconfigurations to overly broad permissions.
• Network segmentation: does the separation between client, server and guest networks hold against an attacker actively looking for crossings?
• Server and client infrastructure: vulnerabilities across both domains, from vulnerable services to insecure configurations.
• Network shares: analysis for sensitive, unprotected data that hands an attacker their next step.
• WLAN security: assessment of your wireless infrastructure.
• AV/EDR effectiveness: the configuration and effectiveness of your endpoint protection under real attack conditions.

The goal is not the longest possible list of isolated vulnerabilities, but the connected attack path: which findings can be chained into a route that ends at your crown jewels, the systems and data whose loss would genuinely hurt your business? These are exactly the paths you can close in priority order after the assessment, before someone else finds them.

Two test modes: measure detection or maximise findings

An assumed breach assessment runs in one of two modes, depending on which question you want answered.

Offensive against active XDR and SOC

We test against your fully armed defences: XDR active, SOC in normal operation. This measures how effective your detection really is. Which of our steps are detected, how quickly, and what actually triggers a response? On request we simulate the techniques of known APT groups, so the result matches the threat picture of your industry. The outcome is an honest assessment of your detection and response capability, measured against a real attack instead of a tabletop scenario.

White-box without countermeasures

We work without active countermeasures and with an open exchange of information. The focus is entirely on uncovering technical vulnerabilities: maximum findings per testing day instead of stealth and patience. This mode is the right fit when you want to harden your internal infrastructure as thoroughly as possible. In a short time, this produces a complete picture of the technical attack surface of your internal network.

Which mode fits depends on your objective: do you want to know whether your SOC detects a real attack, or do you want to fix as many vulnerabilities as possible? Both modes use the same starting position and the same methodology, but differ in approach: offensively we work quietly and patiently, in white-box mode quickly and broadly. We clarify what fits your objective together during scoping.

The most efficient entry into red teaming

A full red teaming assessment starts with the initial access phase: phishing campaigns, convincing domains, prepared hardware. That is maximally realistic, but it costs time that does not flow into the analysis of your internal defences.

Assumed breach flips that ratio. Because the initial compromise is skipped, every testing day flows directly into results: more uncovered attack paths, more concrete measures per day invested. That is why assumed breach is the most efficient entry into red teaming for many organisations, and often the logical first step before a full assessment across all vectors makes sense.

Where a classic penetration test ends and red teaming begins is something we explain in detail in our overview of pentesting across the DACH region.

What you get

An assumed breach assessment does not end with raw tool output, but with results that technical teams and management can work with directly:

• Detailed report: every attack path with a risk assessment, documented for both technical teams and management.
• Prioritised recommendations: concrete measures sorted by impact and effort.
• Management debrief: a personal presentation of the key findings for leadership and the CISO.
• Replay workshop: on request a joint re-run of the attacks with your blue team to close the gaps.

Frequently asked questions

Assumed breach or full red teaming: which one when?

A full red teaming assessment tests the entire attack chain including initial access via phishing, social engineering or physical access, and also measures how your blue team responds. An assumed breach assessment skips the initial compromise and focuses on everything that happens afterwards. If you are testing offensively for the first time or want as many internal findings per testing day as possible, assumed breach is the more efficient entry point. Once your defences have matured, a full red teaming assessment delivers the more realistic overall picture.

How does an assumed breach assessment differ from an internal pentest?

An internal penetration test catalogues as many vulnerabilities in the internal infrastructure as possible, breadth before depth. An assumed breach assessment consistently takes the attacker's perspective: we start from a realistic compromise, chain individual vulnerabilities into complete attack paths towards your most critical systems and, on request, additionally test whether your SOC detects the attacks.

What access do you need from us?

Typically a standard user account without special permissions and a standard client, the same one your employees use, is enough. That matches exactly the starting position of a genuinely compromised workstation. We clarify the technical details of provisioning together during scoping.

How long does an assumed breach assessment take?

Usually one to three weeks, depending on the size of the environment, the chosen test mode and the objective. We define the exact scope together during scoping.

Will our SOC or blue team be informed in advance?

That depends on the chosen mode. In the offensive test against active XDR the SOC deliberately stays uninformed, only a small circle is in the know, so that the detection measurement is meaningful. In white-box mode we work transparently with your team. Who is informed and when is defined during scoping.