Assumed Breach: Objectives, Methodology, Test Scenarios and Use Cases

At a time when cyber attacks are increasing in frequency, sophistication and impact, traditional defensive approaches, while necessary, are no longer sufficient.

To effectively protect information systems and anticipate attacks, businesses need to adopt an offensive posture. This proactive approach encompasses practices such as pentests, Red Teaming and Assumed Breach assessments.

In this article, we detail the principles and objectives of Assumed Breach assessments. We also look at the testing methodology and use cases for common scenarios.

Comprehensive Guide to Assumed Breach

From Penetration Tests to Assumed Breach Assessments: Why an Offensive Approach is Essential?

Penetration testing has long been the cornerstone of security assessments. They consist of identifying and exploiting vulnerabilities in an organisation’s systems in order to correct them before they are discovered by attackers. Although essential, these tests remain focused on coverage: their objective is to discover as many potential weaknesses as possible in a limited period of time.

Red Teaming, on the other hand, offers a more targeted and realistic approach. They simulate complex attacks carried out by advanced adversaries, combining hacking, social engineering and physical intrusion techniques. These exercises test all the organisation’s defences, including the detection and response of the Security Operations Centre (SOC) teams.

However, as organisations strengthen their security perimeters, attackers are looking to bypass these defences and exploit more subtle vectors. This is where Assumed Breach comes in, an even more targeted and pragmatic approach, based on the assumption that the initial intrusion has already taken place. This methodology offers an essential response to a world where the ‘when’ the organisation will be compromised is more realistic than the ‘if’.

What is Assumed Breach?

The Assumed Breach approach is based on the assumption that an organisation has already been or will inevitably be compromised.

Unlike penetration testing, which seeks to identify as many potential vulnerabilities as possible, Assumed Breach focuses on specific scenarios of successful attacks.

This enables to measure an organisation’s ability to detect, respond to and contain an active threat.

Indeed, Assumed Breach exercises represent a logical progression in offensive cybersecurity practices. Rather than focusing on how to get into the system, this approach starts on the inside, assuming that an attacker already has an access point. This can include:

• Internal network access via a VPN or access server.
• Using a simulated user workstation as a starting point.
• A compromised account with standard or elevated rights.

Assumed Breach exercises enable to accurately assess:

• Detection capabilities: Can security teams identify malicious activity once the perimeter has been breached?
• Incident response: How long does it take to contain and neutralise an active threat?
• The resilience of critical systems: Can existing protections limit the impact of a compromise?

Why Adopt an Assumed Breach Approach?

Address the limitations of penetration testing

Traditional penetration tests offer a global view of potential vulnerabilities, but are often limited in time and budget.

As a result, they prioritise maximum coverage to the detriment of depth in specific scenarios.

Assumed Breach fills this gap by focusing on targeted attacks and the real impact an attacker could cause.

Overcome the constraints of Red Teaming

One of the main challenges of Red Teaming is its high cost. Simulating a full attack requires considerable resources in terms of time, personnel and budget. These simulations, while effective, can also be time-consuming to plan and complex to execute.

Assumed Breach exercises, on the other hand, get round these constraints by starting directly where Red Teaming aims to arrive: at the heart of the network. This approach eliminates the need to breach perimeter defences and focuses on the later stages of the attack, such as lateral movement, privilege escalation or data exfiltration.

In this way, Assumed Breach simplifies logistics, reduces costs and maximises the effectiveness of offensive tests, without compromising their realism or impact.

Simulate realistic scenarios

Assumed Breach simulations enable to reproduce common threat situations, such as:

• Theft of sensitive data after a user workstation has been compromised.
• Lateral movement in the network to reach critical systems.
• Exploitation of unpatched vulnerabilities.

By focusing tests on credible scenarios, security teams can identify specific gaps in their current defences and prioritise corrective actions.

Assumed Breach Assessment Methodology

Defining the objectives of the assessment

Before starting an Assumed Breach assessment, it is essential to clarify expectations and priorities. These objectives may vary depending on the organisation’s level of cyber security maturity.

For example, a company may want to assess the robustness of its internal defences by simulating advanced attack scenarios. Others may want to test the responsiveness of their teams to an intrusion in progress.

Another common objective is to assess the potential impact of a compromise on critical assets, such as sensitive databases or cloud infrastructures. These results must be aligned with the company’s strategic challenges to maximise the value of the assessment.

Choosing the Assumed Breach scenario

The choice of scenario determines the relevance of the exercise. Each scenario is designed to reflect realistic threats adapted to the organisational context. This may include:

• The compromise of a user account to test SSO systems and permissions management.
• A simulated physical intrusion to test the security of access to premises.
• A targeted attack on a web application or DevOps infrastructure.

This choice is based on a prior analysis of the risks specific to the company and its potential vulnerabilities.

Recon and mapping

Once the initial access has been simulated, the testers concentrate on identifying the strategic targets. This phase includes mapping the internal network, analysing user account permissions, and looking for misconfigured systems or services.

Databases, application servers and cloud access points are among the prime targets. The aim is to quickly identify exploitable weaknesses that could allow lateral movement or privilege escalation.

Exploitation and lateral movement

In this phase, the testers implement the tactics needed to exploit the vulnerabilities discovered. This may include taking control of privileged accounts, gaining access to critical systems or exfiltrating sensitive data.

They also simulate lateral movements to assess the ability of security systems to detect and contain an advance into the internal network. The aim is to reproduce the post-compromission stages of a real attack.

Reporting and recommendations

The exercise concludes with the submission of a detailed report. This document includes a full analysis of the vulnerabilities discovered, the tactics used and the simulated impact on the organisation.

Concrete recommendations are proposed for each problem identified, prioritised according to criticality. This report is a valuable tool for guiding technical and decision-making teams in improving their security posture.

Assumed Breach Scenarios and Use Cases

The Assumed Breach approach explores different compromise scenarios that reflect the real threats to which organisations are exposed.

Here are some detailed examples, with case studies to illustrate their application.

Compromising a user account via SSO

Scenario: An attacker has obtained an employee’s credentials through phishing or information leaks. The attacker uses this access to compromise the Single Sign-On (SSO) portal and gain access to third-party applications.

Use Case: A compromise in a company using Microsoft 365

• Context: A company uses Microsoft 365 with an integrated SSO portal for its employees. An attacker obtained the credentials of an unprivileged user via a phishing attack.
• Exploitation: The attacker accessed sensitive documents on SharePoint, used Teams to send messages containing malicious links to other users, and explored the permissions of third-party applications.
• Objectives: Identify whether misconfigured applications allow data exfiltration, and test the detection capabilities of the security system.

In this type of scenario, the expected result may concern, among other things:

• Discovering flaws in the permissions management of third-party applications.
• Improving access management configurations (multi-factor authentication, for example) and detection logs.

Pivoting on the network from a compromised machine

Scenario: An attacker takes control of a user workstation and uses this access to explore the internal network and reach critical systems.

Use Case: Compromise of a user workstation using a malicious file

• Context: An employee downloads an Excel file containing a malicious macro from a phishing email. Once the file has been opened, the malware establishes a C2 connection.
• Exploitation:
  • Reconnaissance: The attacker analyses the network segments accessible from the compromised workstation.
  • Lateral movement: The attacker attempts to exploit vulnerabilities in servers or connected workstations to gain higher privileges.
  • End goal: Access a database containing sensitive information.

Here, the objective may involve, among other things:

• Identifying gaps in network segmentation.
• Validating the ability of EDR systems to detect lateral movements.

Exploiting DevOps environments

Scenario: An attacker targets the DevOps infrastructure to compromise the development chain.

Use Case: Intrusion into a private Git repository

• Context: A company hosts its source code in an internal Git repository. An attacker, having compromised a developer account, gains access to the repositories and searches for secrets or API keys.
• Exploitation:
  • Search for access keys embedded in the code.
  • Access to poorly secured test or pre-production environments.
  • Injection of malicious code into a CI/CD pipeline to deploy a malware in production.

In this type of scenario, the expected result may concern, among other things:

• Identifying risky practices, such as storing secrets in the code.
• Implementing robust controls to secure CI/CD pipelines.

For more information on this scenario, you can read our article, which describes a mission halfway between pentest and Assumed Breach: White box audit of a CI/CD pipeline on AWS.

Compromising an exposed server

Scenario: An attacker exploits a known vulnerability on a public server to access the internal network.

Use Case: Exploitation of a poorly configured web application

• Context: An organisation hosts a web application which has not been updated for several months. An SQL injection vulnerability is exploited to obtain shell access (web shell) to the server.
• Exploitation:
  • The attacker uses the shell to explore the connected backend infrastructure.
  • He pivots to databases or other internal applications.
  • If possible, they deploy ransomware to maximise the impact.

Here, the objective may involve, among other things:

• Identifying configuration flaws in the WAF.
• Strengthening patch and update management processes.

Physical intrusion and theft of an internal device

Scenario: An attacker gains physical access to the premises to compromise a terminal or install a malicious device.

Use Case: Intrusion during a company visit

• Context: During a meeting on company premises, an attacker physically connects to an unattended terminal or installs a malicious device such as a Raspberry Pi.
• Exploitation:
  • Access to the internal network via the installed device.
  • Exploring local systems to harvest credentials or exploit vulnerabilities.
  • Deployment of a C2 tool for remote control.

In this type of scenario, the objectives may be as follows:

• Test physical security and access control procedures.
• Implement increased supervision of devices connected to the network.

Carry Out an Assumed Breach Assessment with Vaadata, a Company Specialised in Offensive Security

Vaadata is a company specialised in offensive security. We provide penetration testing, red teaming and Assumed Breach exercises to assess and strengthen our clients’ cyber resilience.

ISO 27001/27701 certified and CREST accredited, we are committed to industry best practices and to providing services in line with the most stringent security standards.

These certifications guarantee a rigorous approach and delivery that meets our clients’ expectations.

Author: Amin TRAORÉ – CMO @Vaadata