In Part 1 we looked at cyber attack models and discussed some of the pros and cons of different variants. This time we’ll walk through a fictitious attack as it traverses the middle phases that most attack models have in common: Delivery, Exploitation, Installation, and Command & Control (C2 or CnC). Along the way, we’ll look at ways your network architecture can help make life more difficult for attackers, what types of monitoring controls you might wish to consider for these phases, and finally examine some indicators that you may not have considered. Before we begin, let’s discuss two subjects: indicators and how network architecture can aid in cyber defense.
Before we move forward, let’s discuss indicators, or indicators of compromise (IOCs) as they’re often called. These are among the most fundamental elements of threat intelligence. They are the remnants, or forensic artifacts, of an intrusion found on a network or in a host which, when taken together, describe a cyber attack (who, what, where, when and how). These observables (using the terminology of CybOX) can be:
- Measurable events, such as a registry key or a file being created, a DNS query or an HTTP GET request being received, or an IDS rule firing; or,
- A stateful property, such as a hash value of a file, a specific registry key value, or a regular expression match.
The authors of the seminal paper on the Cyber Kill Chain described types of indicators:
- Atomic indicators: elements that cannot be broken down further without losing contextual meaning. These include IP addresses, domain names, URLs, registry settings, email addresses, HTTP user agents, and file names);
- Computed indicators: derived from data in an incident. These include hash values and regular expressions.
- Behavioral indicators: “collections of computed and atomic indicators, often subject to qualification by quantity and possibly combinatorial logic.”
What are common indicators? Here is one view that lists the following many common IOCs. How these IOCs are encoded for cyber threat intelligence sharing is a topic for another day.
By looking for indicators in each stage of an attack, our chances of detecting of attack increase. And detection is vital.
Network Architecture and Cyber Defense
Security and usability play opposing roles in a constant balancing act that plays out everywhere in technology. This is true in networks too. Some security features will have clear impact on usability, others will have minimal impact. Let’s look at a few architectural and service design features that can aid in defense against cyber attacks — some by preventive measures, but others that leave telltale signs (aka indicators).
Force Traffic through Service Endpoints (Routing and/or Firewalls)
While you could enforce this with a firewall, defense-in-depth is always best. For additional control, you could eliminate a default route to the Internet from your network core. Instead, you could inject routes for your DMZ service endpoints into the network core. For example, if the IP address (e.g., load-balanced VIP) of a proxy is injected into the network core, anything attempting to reach the Internet from your internal network can be blackholed in your network core. I do not know if anyone actually uses this technique, but it could be an effective belt-and-suspenders approach.
DNS and DHCP Controls
- All servers and endpoints must use local DNS servers. Only internal DNS servers must be permitted to query DNS servers in your DMZ, and only those DMZ servers must be permitted to reach the Internet.
- All DHCP server responses that transit layer 3 boundaries must be filtered such that only packets from your known good DHCP servers are permitted to pass.
How does all of this help? Several years ago, a piece of malware installed a DHCP server on endpoints that pushed DNS configuration changes to the local resolver, pointing it to remote DNS servers that could provide malicious replies (described here). DNS Changer came later. The solution is the same — contain the badness with proper architecture and network controls, and affected endpoint behavior will provide adequate IOCs for incident response.
Proxy authentication should be table stakes in today’s environment. It is one thing for malware to be proxy-aware (in the simplest manner), but if you force your attacker to have to gather and deliver user credentials in a manner completely transparent to the user, you’ve raised the bar considerably. Remember the balancing act between security and usability? This is one area where the rubber meets the road. I would even go so far as to advise that normal proxy authentication not be transparent to the user. Using Windows SSO, for example, will result in credentials being provided for malware just the same as a normal browser request. I recommend a proxy configuration issues a ‘407 Proxy Authentication’ challenge instead of a ‘401 Authenticate’ challenge to the browser so that it will prompt the end user for credentials.
What about configuration of the browser itself? I recommend using Proxy Auto-Config files instead of simple registry settings. This forces malware to have to retrieve the PAC file, analyze it, and direct requests to the proper endpoint. Not rocket science for a skilled attacker, but again, this is about making things incrementally more difficult. What about attacks that modify the PAC file, such as the ones described here and here. These attacks to alter the browser configuration to use an alternate (and malicious) proxy can be easily blocked by not permitting direct access to Internet resources except through your carefully configured service endpoints (as described above).
Let’s describe some pertinent aspects of this environment that create hurdles for the attacker to get past in order to reach the valuable information assets of the corporation.
Sample Attack Analyzed
Let’s put all of this to work and walk through a fictitious attack on a fictitious corporation, but assuming the above countermeasures have been deployed. For this example, we’ll restrict our examination of the attack to three phases, more or less common to all of the attack models we looked at in part 1.
The following diagram visually describes the steps of an attack from the Delivery through the Command & Control phase (essentially common to all of the cyber attack models discussed in part 1).
- Phishing e-mail is delivered.
- User clicks on bad link (assumes link vs. attachment); as part of the URI delivery to the proxy, the user should be prompted for authentication credentials.
- The proxy queries the DMZ DNS server(s) to resolve the A RR (hostname from the URI). If instead, an IP address is provided, this step will be skipped.
- Proxy retrieves the bad payload.
- Proxy delivers to the client; assuming installation, the client is now compromised with the dropper file (single-stage is shown, but it could be two-stage).
- When the dropper executes, one of the following steps will execute depending on whether or not it is proxy-aware.
- Step 6a is executed if the dropper file is not proxy-aware and attempts to reach a C2 server addressable via a fully-qualified domain name (FQDN). The internal DNS server will forward the query to a DMZ DNS server, which will recursively query to return the A resource record associated with the FQDN. Whether it has the IP address already, or retrieves it via DNS query, the dropper file will be unable to form the connection to the C2 server because of network architecture (firewall rules or routing prevents direct Internet access). Either FULL STOP, or the dropper has to try to use a proxy at this point (see step 6b). Also, see “URL Obsfuscation” below.
- Step 6b is executed if the dropper is proxy-aware. To achieve this, the dropper would need to achieve some form of the following: i) Run a keystroke logger and properly identify/capture the user’s credentials (or somehow get a cached copy); ii) Read proxy-related registry entry; iii) Pull Proxy Auto-Configuration (PAC) file; and, iv) Properly parse the PAC file.
- If the dropper file delivers the URI to the proxy with an FQDN as the target for the C2 server, DNS will be queried by the proxy.
- Connectivity is established to the C2 server.
- The attacker connects to the C2 server and can now issue commands or take remote control of the infected endpoint, proceeding to the next phase — Act on Objectives (AoO), which in itself may constitute new attacks. The first infected host is just the starting point. To retain persistence, the attacker will likely aim to achieve C2 connectivity to many more hosts.
If at this point you don’t have a clue that your environment has been compromised, it may take you a long time to figure it out. If the statistics are correct — and we have no reason to doubt them — most attacks go unnoticed for months. Good for the attacker; very bad for the defender. Our job is to identify the means whereby we can detect, deny, disrupt, degrade, or deceive the attacker. Let’s walk through those steps again, and this time attempt to identify countermeasures or IOCs that will aid in our defense.
- Phishing e-mail delivery: possible countermeasures include reputation-based filtering; IOCs might include sender address (IP and domain) and SMTP agent identifiers — both admittedly low probability.
- User clicks: training and awareness are crucial, but humans will never be perfect. Most organizations are happy to achieve less than 10% click rates on phishing tests.
- Proxy queries DNS or receives an IP address: I recommend blocking all URIs that do not contain FQDNs; this takes some sophistication though (see “URL Obfuscation” below). DNS queries can be passed through reputation-based filters or other creative forms of analysis (e.g., OpenDNS NLPrank).
- Malicous download: this is where your content analysis engines earn their keep (e.g., BlueCoat, Fireeye, Palo Alto Wildfire, et al).
- Client installation and execution: many payloads are uniquely crafted for an attack, making traditional AV/AM mostly useless. Instrumenting endpoints with better detection tools may be necessary, even ones that rely on big data analysis to find patterns to compromises (e.g., Tanium, CounterTack). For attacks that modify client behavior, IOCs should include hash values of key configuration files through file integrity monitoring.
- Dropper attempts outbound communication:
- If the dropper is not proxy-aware, it will query internal DNS servers for external FQDNs or attempt to connect directly to an external IP address. If all outbound communication is directed to a proxy, your internal DNS servers should not see queries for external FQDNs (or perhaps only in very specific cases); looking for queries for external resources is a key IOC with a high-degree of confidence. Attempts to reach outside resources without using a proxy should result in blackholed traffic or blocked traffic (at a firewall) — again, important IOCs of attempted C2 communication.
- If the dropper is sophisticated enough to use your proxy, including properly authenticating to it, then you can look for abnormalities in HTTP User Agent strings as an IOC. As a countermeasure, again, you should block attempts to use an IP address (see “URL Obfuscation” below).
- DNS queries: if used, you are again left with analysis of DNS queries and reputation-based filtering.
- C2 traffic: look for geographical irregularities, for one. For example, if you only do business in certain regions, and you restrict or ban international connectivity by employees (e.g., on vacation), then you may find useful means of winnowing out expected traffic, leaving unusual patterns to stand out.
- Since this is completely outside of your domain of visibility, there is nothing you can do to detect this.
Whenever IOCs depend on URLs, obfuscation must be dealt with correctly. All URLs follow a standard format:
We’re not accustomed to seeing URLs with usernames and passwords, so if we’re not careful we can be easily fooled with URLs like:
In this URL, “www.mybank.com” is the username and “login.html” is the password, but unless we notice the at-sign and what follows, we might easily be fooled. By the way, not all browsers will now support this, and others may provide a warning.
If we wish to block access to URLs using IP addresses as the host portion of the URL (or recognize , then we have to be able to recognize all of the various forms in which IP addresses can be represented.
www.google.com. 181 IN A 22.214.171.124 Decimal: 126.96.36.199 Binary: 101011011.11000010.1111001.10010 Octal: 0255.0302.0171.022 Hexadecimal: 0xad.0xc2.0x79.0x12 or 0xadc27912 DWORD: (((((173 * 256) + 194) * 256) + 121) * 256) + 18 = 2915203346 Mixed: 0xad.0302.0x79.18
The current version of Firefox will resolve all of these except for binary and will warn for the condensed version in Hexadecimal (without periods). Your browser may behave differently.
URLs can be encoded using:
- Escape Encoding
- Unicode Encoding
- UTF-8 Encoding
An attacker can even use a cross-site scripting error on another site to redirect to a site represented as a URL-encoded variable!
There are number of resources available for exploring this topic further. The takeaway is that identifying an IP addresses as an IOC in a URL (or a malicious URL in general) is not as straightforward as you might have imagined. You’ll need intelligent software!
By using your knowledge of your own network and its architectural features, and by thinking carefully about what traces an attacker might leave because of those features, you may be able to find high-confidence indicators to help you detect an attack earlier in the cyber kill chain (or whatever attack model you choose to adopt). An attacker will undoubtedly attempt to obscure some of those traces, making it more difficult for you to find them, so the challenge remains. Good hunting!