Anatomy of a breach

There are a set of frameworks available that describe the typical progression of an adversary when compromising assets. There is, for instance, the Lockheed Martin Kill-Chain, which is quite popular (https://www.lockheedmartin.com/content/dam/lockheed-martin/rms/documents/cyber/LM-White-Paper-Intel-Driven-Defense.pdf).

Over the years, more refined and generic frameworks have also been established, such as the MITRE ATT&CK framework (https://attack.mitre.org), or the Unified Kill Chain (https://www.csacademy.nl/images/scripties/2018/Paul-Pols---The-Unified-Kill-Chain.pdf).

The kill chain as defined by Lockheed Martin does have some limitations and only models a subset of adversaries. Later in the book we will do a more in-depth analysis and see how these frameworks can help you build strategies for your operations and cyber defense.

Not following any of these frameworks in particular, let's discuss the anatomy of a possible breach that a red team can emulate.

Establishing a beachhead

The initial entry point of an adversary is called the beachhead. Many offensive teams use this military reference for the initial entry point of a breach. The term beachhead refers to troops that storm a beach and establish a foothold to enable support lines and supplies. In information security, the adversary will leverage the initially created foothold to explore the surroundings, receive supplies in the form of implants, pivot to nearby areas, and move forward towards achieving mission objectives.

For defenders, being able to backtrack and identify the beachhead is a critical skill to acquire. A mature blue team will have built automation to backtrack an adversary. Unfortunately, many organizations do not possess the muscle, skills, or tools to successfully, within a reasonable timeframe, reverse the attack path an adversary took to find the beachhead. This includes scenarios such as log files having been deleted after a long period. These are the findings offensive operations will highlight.

Without understanding the entry point and mitigating the vulnerability and variants of the vulnerability, any eviction attempt is flawed. The red team is there to help the blue team build up the skills required to reveal the beachhead and any possible variants.

Achieving the mission objective

The common process of acquiring a target or fulfilling a mission objective revolves around two core phases, which are reconnaissance followed by exploitation, then by another round of reconnaissance from the new point of view, eventually getting the adversary closer and closer to the objective. At times, it might be only one loop, reconnaissance and exploitation, that leads to direct accomplishment of the mission objective.

This simplified view of an attack looks like this:

Figure 1.4: The Recon | Exploit | Objective loop

The number of cycles varies depending on the complexity or severity of the attack. For instance, a SQL injection would probably have only one or two rounds, while an adversary that pivots through an infrastructure might circle through the cycle numerous times, including going off in the wrong direction until eventually reaching the mission objective.

Breaching web applications

A lot of resources are spent on red teaming and lateral movement within an organization, and it sometimes appears that companies are not doing enough to protect the outside attack surface. This includes basic application-level vulnerabilities that enable an adversary to download customer data directly without having to breach the internal corporate network at all.

The cycle of reconnaissance and exploitation might in fact be only one cycle!

Weak credentials

No book would be complete without pointing out that passwords are flawed. Public-facing web applications and systems without multi-factor authentication do not provide an appropriate level of protection. Chapter 7, Hunting for Credentials, is dedicated to this important topic.

Lack of integrity and confidentiality

What is the first rule of most security agencies? Look for clear text!

A lot of good progress has been made over the years when it comes to integrity and confidentiality. Technologies such as TLS are becoming more widely adopted to protect users. Tools such as FireSheep (https://codebutler.com/2010/10/24/firesheep) were extremely helpful in raising awareness of what an adversary in a coffee shop can achieve by leveraging insecure protocols.

Still, there is a long way to go. Things look quite bad when it comes to integrity and confidentiality, especially once an adversary is inside the corporate perimeter. Many organizations live under the false belief that (for some magic reason) communication on the intranet or within a data center is safe from being exploited.

Cyber Kill Chain® by Lockheed Martin

In the introduction to this section, we highlighted Lockheed Martin's framework for modeling intrusion along a kill chain. There is a lot of documentation and literature available around the Kill Chain, so I won't be repeating it here. We will look at some of these ideas more closely about measuring the offensive program again in Chapter 3, Measuring an Offensive Security Program. For now, let's rather dive into a practical example of what a cloud service disaster might look like.

Anatomy of a cloud service disaster

Let's look at a typical scenario of how an organization that leverages a cloud service provider such as AWS, Google Cloud, or Microsoft Azure might be breached. This is an example scenario to show what steps an adversary might take and to highlight the unique opportunities for adversarial emulation an offensive security team can provide.

The following diagram shows how a cloud service might be compromised:

Figure 1.5: Attack graph of a cloud service compromise

This scenario is a very common attack graph that applies to the majority of organizations. Let's look at the various steps of the graph in more detail:

1. The initial step of the adversary involves creating a payload to send the victim, who is a DevOps engineer in your organization working on building and deploying the main product your organization produces.
2. The DevOps engineer receives the email and opens the attachment, which contains a macro that is executed and establishes a beachhead. The adversary now performs a credential dump and loots the machine for secrets, passwords, and other interesting documents. As fortune has it, the adversary discovers SSH or Windows Remote Management credentials for a production jumpbox.
3. Using the stolen credentials, the adversary pivots to the production jumpbox.
4. Once the adversary runs the code on the production jumpbox, they look for credentials again. This time, the adversary is focused on finding cookies that allow them to log in to the production management console of the cloud service provider.
5. Using the stolen cookies, the adversary performs a Pass the Cookie attack (supplying the cookie in a browser session) to log in to the production management console.
6. At this point, the adversary has full access to all resources in the account and is poised to delete or encrypt all the data stored in the systems, or worse, the adversary could delete the entire cloud service.