Using Infrastructure Analysis to Get Ahead of Attacks in Cyber Defense: Part 1

Introduction

There is a military parlance that is often heard in cybersecurity: “getting left of boom.” Originally (and in the book of the same title by Doug Laux), the term referred to infiltrating a terrorist cell and thwarting a planned attack, and therefore being to the left, in terms of a timeline, of the attack. It’s not a bad metaphor for information security; being able to disrupt adversary actions before they cause damage is a worthwhile, if challenging, objective. In this 3-part blog series, we’ll see how you can use various tools and data sets to help your organization move (or stay) to the left of “booms” that an adversary may be planning against you.

The popular models that frame many cybersecurity activities—MITRE’s ATT&CK, Lockheed Martin’s Cyber Kill Chain, and the Diamond Model in particular—provide useful references for orienting ourselves around the various data sets and techniques we’ll be examining. While at a high level these models have some overlap, in that they all describe how cyber attacks unfold and how to analyze them, they each contribute some unique facets of analysis, so it’s smart to be familiar with all of them. There are other valuable analytic models too, such as Analysis of Competing Hypotheses (ACH), which won’t be part of this blog but which also have much to offer.

Both ATT&CK and the Cyber Kill Chain describe various steps an adversary may take in preparing and executing an attack. Many of these steps involve Internet-based observables, which have some important properties for analysts and other blue team members. “Internet-based observables” in this case refers to components of online infrastructure such as domain names, IP addresses, server content such as tracking codes, SSL/TLS certificates, and various data points that are associated with them. Among these useful properties:

• Any attack, other than one based purely on physical access or extremely unlikely/rare passive monitoring techniques, depends on Internet-based infrastructure.
• Many devices in the protected environment are capable of logging, and sometimes alerting, on these kinds of indicators.
• The observables have metadata associated with them that are broadly available, and that can help the analyst characterize a given observable, and connect it to others.
• Some of them, particularly domains and IP addresses, are the objects that form the basis of deny lists; they are where “the rubber meets the road” in terms of taking explicit defensive actions.

The Cyber Kill Chain

The Cyber Kill Chain describes seven steps: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control, and Action on Objectives. The reconnaissance, weaponization, exploitation, and installation stages are unlikely in most cases to include internet-based observables, but the other three stages definitely do:

• Delivery: phishing emails containing links to adversary infrastructure or malicious attachments; watering hole attacks; compromise of public-facing servers or services
• Command and Control: loaders or trojans acquiring additional attack components; malware “phoning home” to receive instructions; exfiltration of data in preparation of later-stage activities; establishment of control channels
• Action on Objectives: exfiltration of intellectual property, strategically valuable information, etc.

The ATT&CK framework

The tactics, techniques, and procedures (TTPs) described in the ATT&CK framework, similarly, include many steps that involve Internet observables. Like the Kill Chain, ATT&CK describes some areas that will involve these sorts of indicators and others that won’t. Some of the ATT&CK tactics and corresponding techniques that involve adversary infrastructure include:

• Resource Development: phishing for credentials, acquiring and configuring infrastructure
• Initial Access: phishing, drive-by compromise
• Persistence: traffic signaling
• Command and Control: multiple techniques
• Exfiltration: multiple techniques
• Impact: various network attack techniques

Not all of the listed techniques will always result in usable network observables, but many will, provided that you are logging the necessary data.

The Diamond Model, with its four principal components (adversary, victim, capabilities, infrastructure), also offers important insights into where you can plan your hunting and response activities. The “Infrastructure” feature is obviously where a lot of the Internet observables come into play, but it’s not the only one. You can use what you learn from the infrastructure to gain important insights about the adversary. Part 2 of this series will go into more depth about how the Diamond Model can help.

Limitations of Frameworks

Frameworks like ATT&CK and the Kill Chain are useful for organizing your mental model of how an attack may take shape. It has been said, and bears repeating, that adversaries do not use these frameworks as checklists. Many, if not most, attacks are able to skip some of the steps, because of specifics of how the victim environment is configured. This raises the question of threat modeling, which also plays a role in both how you will carry out hunting and forensics, but in how you might mentally (or on paper) create a customized version of ATT&CK and/or Kill Chain.

Threat Modeling and Internet Observables

Every organization’s exposure to attack is different, and so should be their threat modeling. Your organization may have a minimum of public-facing services, for example. And those public-facing services you have may be managed by a cloud provider. Your workforce may be primarily online (knowledge workers) or not (service industry, manufacturing/industrial, etc). However, unless public-facing services are a major part of your operation—for example, if you are a SaaS/IaaS/PaaS provider—then you should consider a lot of your threat modeling to look at outbound, rather than inbound, traffic. In the old days, inbound traffic was where the threats were thought to be concentrated, so a lot of shops did a lot more logging of denied (and to some extent allowed) inbound traffic than outbound. Logging outbound traffic used to be fairly uncommon because it was generally assumed to be benign, the volume of the traffic was high, and all that log data has to live somewhere.

Such assumptions may look laughably naive or even negligent today, but vestiges of the thinking behind them remain. For example, many organizations don’t log the recursive DNS queries from the protected environment. Many do not log their web proxy traffic, either—or they may log policy violations only. But foregoing those log sources starves the analytic “engine” of important fuel. Odds are that if and when something gets popped in your environment, there is going to be forensically critical traffic that makes DNS lookups, and exits via one of your already configured allowed outbound services. And smart attackers will know how to avoid triggering firewall policy violations.

All of this is to say that your threat model needs to contemplate how the attacker will make use of the outbound services from your protected networks, and how you can thwart or, at minimum, detect such traffic. If the enemy is going to hurt you, the last thing you want to do is to miss an opportunity to at least get important information about their operations.

It’s not realistic to think that you can always stay to the left of the early stages of an attack. If the adversary is using OSINT techniques and data to plan their moves, there’s nothing (or very nearly nothing) you can do to detect or prevent that. Once they reach the delivery (kill chain) or resource development (ATT&CK) phases, though, they start relying on external infrastructure, and from that point forward, you have a chance to get a claw into them before they reach their ultimate objective.

Key Takeaways

• It is possible to get ahead of attacks, or later-stage components of attacks by applying analysis of adversary infrastructure and actions
• Various stages of an attack rely on adversary Internet infrastructure that includes observables such as domains and IP addresses that cannot be fully obscured by the attacker
• Threat modeling can help you identify not just what your exposures are, but where you can expect to mine your log data for useful adversary observables
• The availability of this threat data is fully dependent on obtaining, storing, and accessing various kinds of logs

In the next installment of this series, we’ll look at some of the specific ways you can “move left” of specific parts of an attack, or specific attacks within a larger campaign.