The Attack Life Cycle

The Attack Life Cycle

March 22nd, 2018

This is a modified version of a post I wrote at work, to help employees better understand what we're up against, and how we react. Many other blog posts exists that cover the same concept, but I figured an explanation targeted at non-infosec experts might be useful to others.

---

"We take the privacy and security of our users very seriously." So begins the public announcement of every corporate breach. It's almost farcical. But we do, don't we? We spend a lot of time and effort on closing security tickets, on undergoing security reviews, and requesting (and waiting for) ACLs to be opened. And our information security team is called the Paranoids for a reason; for a long time, our informal motto was: "Yes, we worry."

But worrying about and spending time on security tasks is not sufficient to actually protect our users. It's too easy to get caught up in busy work that ultimately does not move the needle, yet feel like we've taken things very seriously.

To better serve our users, as well as to respect the time and energy of all teams in our organization, we need to understand more closely what threats we are facing, and what defense- and detection mechanisms are available and feasible. Within Information Security, this is known as developing a Threat Model.

If you are operating at any reasonable scale, then you are well aware that we are not facing erratic, anonymous, and unpredictable threats. Instead, we know that our adversaries are dedicated human beings with specific objectives, operating in targeted campaigns. This is a core understanding and defines not only our responses, but our anticipation, prevention, and detection of these attacks.

In this blog post, I want to explore the concept of the "Attack Life Cycle" to help people better understand how our adversaries operate. This understanding helps to guide us in the identification and prioritization of the work we do, the work we oftentimes ask other teams to do.

High Level Stages

Our presence on the internet, our name and brands are an attractive target for dedicated attackers, including those funded by e.g. nation states or other large organizations. The attacks on our systems are not executed at random. As noted above, our adversaries have specific goals, and they will use different methods to accomplish those goals, reacting to our defenses. If one attack vector is closed, they will pursue a different method.

However, most attack scenarios do follow a specific sequence, a life cycle broken into distinct stages. You may have seen the following graphic from Mandiant (a prominent cybersecurity consulting firm, often called in to analyze high profile breaches):

As you can see here, the process is divided into five or six distinct stages:

1. Initial Reconnaissance

Here, the attacker researches the target by e.g. performing network scans, identifying the software used and exposed, probe for known vulnerabilities, and in general gather any and all data about the systems, company, operations, as well as the people. In addition, this stage also includes collecting information about the people who work in the target organization, their positions, their access, their routines.

2. Initial Compromise

Attackers identify and exploit a vulnerability that allows them to gain access to some systems. This can take the form of triggering a Remote Code Execution (RCE) by way of a weakness in a library known to be used on the target systems (remember ImageTragick?), or it may involve tricking an employee into revealing their access credentials by way of phishing, or by installing malware on an employees laptop via a watering hole attack.

2a. Establish Foothold

Once a way into the systems is found, the attackers have to find a way to keep their access, to keep the system compromised. Typically, they will install a persistent backdoor, allowing them to access the system at will, without relying on the exploit they may have used initially.

Since this happens immediately after the initial compromise, these two steps are sometimes grouped together.

3. Escalate Privileges

The initial compromise usually does not yield sufficient privileges to accomplish their objective, nor even to move within the infrastructure or organization, so the attackers will typically attempt to gain elevated privileges. In practical terms, consider a vulnerability in e.g. PHP, whereby an attacker gained access to a the web server as 'nobody', the Unix user running the http server. In order to access e.g. a private database on the system, or to gain access to a private key protected by Unix permissions, the attacker would try to chain an additional local privilege escalation vulnerability such as DirtyCow to become 'root'.

Another example of escalating privileges might be to install a key logger on an employee's laptop to gain access to the password used to authenticate to another system.

4. Internal Recon and Lateral Movement

It is rare that an attacker manages to immediately compromise the final target. Think of the way that a web application might work: the web server exposed to the internet may not have access to an internal data store or the end-user database you're after. But the server may have access to a service that contains access credentials to reach into the database.

In the first step (Initial Reconnaissance), the attacker collected all the information she could get from the outside, but now she has to identify the next steps, the next target on the way to the final objective. Hence, she will perform Internal Reconnaissance, again perhaps scanning the network (now from the initially compromised host with possibly elevated access), identifies systems of interest ("Oh, look, a CI/CD service that's able to build and deploy software to all systems. Interesting!"), or collects access credentials.

With the gained knowledge, the attacker can then try to further broaden her access, hop from one system to the next, repeating the previous steps in order to further elevate privileges as needed.

5. Complete Mission

This is the final stage. The attacker has accomplished her objective. This may involve the disruption of a specific service, the (ongoing) covert collection of information such as e.g. eavesdropping on communications, or stealing specific data or information.

Depending on the objective, this final step may include additional steps, such as the exfiltration of data or maintaining persistent access for any possible future missions.

Defense and Detection

The attack life cycle we described above is generic in nature, and the specifics vary from attacker to attacker, from objective to objective. However, they all do follow this general model. That, in turn, allows your defenders to prioritize their efforts and focus on exactly those specific stages.

In the past, I've used the following diagrams to illustrate how the attack life cycle impacts you, and how you can focus your defenses on interrupting this cycle at every step:

An uninterrupted attack life cycle.

Specific defenses deployed attempt to disrupt the attack life cycle at every step.

Within the company, we have had a number of major and successful initiatives targeted at each of the major stages in the attack life cycle, including efforts to explicitly limit the attack surface and harden the exposed systems as I've previously talked about at the O'Reilly Security Conference in 2017. Other projects included changing the interpreter of a common programming language to prohibit certain dangerous call (e.g. system() shell-outs), to replace the use of long-lived access credentials with time-limited, multi-factor authenticated tokens to prohibit lateral movement, and the like.

Each of these efforts individually but especially in combination require the attacker to significantly up their game; the level of effort and the costs incurred by the adversary moves up, forcing them to either shift their tactics, shift their goals, or e.g. burn a zero-day exploit when previously a common attack vector could have been successful. Indeed, the attackers are performing a cost-benefit analysis throughout their attack cycle, utilizing the cheapest, easiest, most efficient methods. When we force their hand, we are often able to determine the terms of engagement and may be more easily able to detect and deter them.

Attacker economics aside, it is important to point out that all of the projects you will pursue to interrupt the attack life cycle will, while likely be started by your Infosec team, require the help of all teams in your organization to complete. One way that anybody on any team can help disrupt the attack life cycle of your dedicated adversaries is by keeping on top of their OS and software updates, by prioritizing the security tickets you may open against them, but perhaps most importantly: by keeping your Infosec team honest and focused. To do that, they need to understand how the work required of them relates to disruption of the attack life cycle.

As mentioned in the beginning of this post, it's easy to get lost in trying to secure all the things. There are a myriad of ways in which you can strengthen your posture, and infinitely many options to spend energy on security related tasks. But you need to stay focused. The work requested needs to directly be applicable to the prevention, interruption, or detection of attacks and their life cycle. Ask your Infosec team to justify their demands; tell them when they missed something or you think they're not focusing on the right parts. You are their eyes and ears, you are the subject matter experts of your product, your software, your stacks. Your information security team needs your help, because they do take the privacy and security of your users seriously, and yes, they worry.

March 22nd, 2018

---

Related: