Depending on the type and selected preconditions, certain threats can be identified. This blog article will now introduce one of the most widely used methods for cloud penetration testing, the Assumed Breach Approach. We will show you from which perspective and with which preconditions such a test is carried out.
Assumed Breach - Internal threats in the cloud
Internal and external threats
First, however, we want to look at different types of threats to a company in order to better understand the perspective of the Assumed Breach Methodology. In general, cyber security threats can be divided into two categories.
- external threats
- internal threats
External threats represent the threat that most people responsible for the security of a company are most likely to be aware of. These can be classic attacks by hackers, phishing or ransomware campaigns. The attacker's perspective is that of an outsider and the internal infrastructure is just a black box for them. If a penetration test is carried out from this perspective, we are talking about a classic black box penetration test. In a black box cloud penetration test, the security consultants only interact with a few systems exposed to the internet and attempt to access the internal network via these.
In the case of internal threats on the other hand, a penetration test assumes that an attacker has managed to penetrate the internal infrastructure in a black box attack. The attacker now has access to login data for a user account and can use this to attempt to attack other internal systems. This perspective is often only considered peripherally by those responsible for IT security as an attacker “has to get in first”. However, this is a fatal mistake, as there are many different ways in which an attacker can move from an external threat to an internal one.
Attack methods for the initial compromise
In the following, we would like to briefly discuss a few of the most common ways in which an external attacker can become an internal attacker. In our work as an incident response service provider, it is essential to evaluate how the initial compromise took place. This is often one of the following attack paths:
- Leaks of usernames and passwords: If usernames and passwords from previous data leaks are published on the darknet, attackers can use this information to log into a company network with known access data.
- Insecure user passwords: Weak or easy-to-guess passwords offer an easy target. Attackers often simply exploit weak passwords such as “Sommer2024!” and test them on many of a company's employees. Such an attack is called password spraying.
- Targeted phishing campaigns: In targeted phishing attacks, attackers send fraudulent emails to employees to trick them into disclosing confidential information or opening malicious attachments. Successful phishing attacks can provide the attackers with valid credentials or direct access to a company network.
- Outdated software: Software that is not kept up to date often contains known vulnerabilities that attackers can easily exploit. By exploiting these vulnerabilities, attackers can execute malicious code and infiltrade the corporate network.
All such paths are often no obstacle for an experienced attacker and so an external threat becomes an internal one.
Assumed Breach - The simulation of an internal threat
The Assumed Breach method generally assumes that an attacker has managed to overcome a company's initial protective measures and is in the internal network with valid user data. In a cloud penetration test, this means that the security consultant gains access to low privileged user data with which he can interact with the customer's cloud infrastructure. These can be different types of user accounts.
- Dedicated viewer/reader-only role
- Normal user account
- Service account of a cloud resource, such as a VM
From this perspective, the cloud penetration tester now begins to enumerate the infrastructure and identify misconfigurations. The combination of different misconfigurations can then be used to build vulnerabilities that can be used to advance further in the cloud environment. An attacker can “move” in different directions. "Lateral movement” is when an attacker manages to take over other systems or accounts at the same level. If an attacker succeeds in gaining higher privileges, this is known as “privilege escalation”. In an Assumed Breach Cloud Penetration Test, the security consultant now applies different variants of “lateral movement” and “privilege escalation” with the aim of ultimately becoming the global administrator of the cloud environment. In the end, he interacts and tests all existing resources of a cloud infrastructure and thus obtains complete test coverage.
Differentiation from the external black box test
The most common approach for an external penetration test in the cloud is, as already described, the black box approach. Here, a security consultant receives little to no information about the infrastructure to be tested. This means that for a large part of the test period, the consultant only interacts with a few externally visible resources of the cloud infrastructure.
If the external protection has been carried out very carefully, this can lead to a security consultant not finding a successful attack path into the rest of the cloud infrastructure during the short test period. As can be seen in the graphic below, this can lead to an attacker only being able to test a small part of the infrastructure. This could result in vulnerabilities in internal cloud infrastructures and networks not being identified.
With the Assumed Breach approach on the other hand, an internal threat is simulated as already described. This can now interact with all internal cloud resources and networks during the test period, but also with all externally available ones. In this way, a cloud penetration test using the assumed breach approach always achieves significantly higher test coverage in a given time. It should never be forgotten that a real attacker has no time limit like a cloud penetration test. They can therefore invest significantly more time and resources in identifying external attack paths than is possible in a black box cloud penetration test. For this reason, we recommend that each of our customers refrain from carrying out a cloud penetration test in black box format in the initial scoping discussions and instead pursue an assumed breach approach.