External attacks represent over 80% of data breaches today, establishing them as public enemy #1 to IT organizations. These types of attacks have consistently represented the lion’s share of all data breaches because of the perceived value of the data held within organizations today. The data is so valuable, that criminal organizations now employ development teams who build rootkits, trojans, malware, and tools to be used as part of an attack – even testing these against current security solutions to ensure “success.”

Using a methodology that includes expanding their attack surface within your organization until they reach valuable data, organizations must have a solid understanding of how attacks occur – and how they can stop them.

There are several threat activities that occur before any kind of lateral/horizontal movement within your network, that are all part of what is known as the intrusion kill chain. These include reconnaissance (the gathering of information and possible exploits), weaponization (combining exploits and deliverable payloads), delivery (leveraging phishing emails and compromised websites), installation (actual insertion of malware on an endpoint), and command & control (where a channel is established to further manipulate endpoint remotely).

While the intrusion kill chain is an important part of the overall attack, this paper focuses on identifying and stopping lateral movement as part of the horizontal kill chain. That is, the actions taken by a threat actor to move laterally within your network looking for systems, applications, and data of value that they can either further exploit to continue the movement or utilize to exfiltrate valuable data.

But with the data breaches taking weeks, months, and even years to be detected, how can you know when an attack is happening, let alone stop one?

The good news is that attacks intent on expanding their access within your network in an effort to find, access, and steal data, tend to follow a very similar pattern — so similar, that each part of the horizontal kill chain is pretty well-defined:

Obtain Credentials > Authenticate > Control > Persistence > Stealth

In this section of the paper, we’ll cover each of the parts of the horizontal kill chain, and then look at ways to detect, prevent, and stop threat actors.

Attackers need to be able to move as much as possible through the network. The more endpoints (that is, workstations and servers) accessed, the higher the likelihood of finding and exfiltrating data. Initially, the goal is to obtain local admin access — usually by either examining local groups and attempting logons to local accounts or through pure patience using a keylogger and waiting for an account with elevated privileges to log on.

Once local admin access has been obtained, there are many credential artifacts found in the endpoint’s memory that attackers leverage. This can include password hashes (for use in a pass-the-hash attack), Kerberos tickets (which can be cracked), logon session credentials (which are stored in clear text), and domain credentials (which can be cracked).

Tools like mimikatz (which requires local admin privileges) can be used to search through an endpoint’s memory to find and obtain these artifacts, allowing the credential data to be used by other hacker tools to establish authentication to additional systems.

Once credentials have been obtained (or enough credential artifacts to facilitate authentication), the next step is to laterally move within the network. This is usually accomplished via Server Message Block (to access file systems), remote desktop, PowerShell remoting, and even Windows Management Instrumentation (WMI) and Remote Procedure Call (RPC).

Once an attacker has gained entry to another system, the goal is, once again, to gain control. The credentials providing initial authentication may not have elevated privileges on this new endpoint. This causes an attacker to repeat some of the same work found in the first two steps in the kill chain, as well as leverage native and downloadable hacking tools, to identify and authenticate as a local admin on each successive endpoint they access.

Attackers see each compromised endpoint as a foothold — a machine that should be theirs to control for as long as it’s needed. Should their access be discovered and removed, the chances of an attack being successful are dramatically lowered. So, it’s necessary to modify an endpoint’s configuration to ensure access is possible.

Using similar tactics to malware, attackers utilize scripts that run upon system reboots or user logons to put malware, tampered files, scheduled tasks, malicious services, registry entries, and any created accounts back into place — essentially repeating all the work done up to that point to ensure persistent access to the endpoint.

This step is more about methodology than any additional work. To keep from being detected, threat actors “live off the land” (that is, use native tools that should garner less attention), deliver payloads directly to memory (to avoid running exes that may raise suspicion), and even redirect malicious traffic over allowed ports.

Before you can stop an attack, you need to detect one. The good (and bad) news is detection happens anywhere from the point of intrusion to the point of data access. It’s good, because the opportunity is there to potentially stop an attack early in the kill chain. The bad of it is, it’s also possible that you may not find out until after data has been exfiltrated.

This makes it critical to detect and react as early in the kill chain as possible, having proactive response measures in place to stop any further malicious actions from that point on.

There is a common thread that exists throughout an attack — a single action that occurs and resides at the epicenter of all kill chain actions — logons. No attacker wants to simply access whatever random endpoint they can compromise using phishing or vulnerabilities and stop there. They need to move to another system, and another, and another… continuing until they reach a system with data of value.

And, for every jump from endpoint to endpoint, a logon must occur. Without the logon process, no part of the attack can be successful; as shown in the table below, every part of the kill chain involves the attacker needing to log on.

This makes the logon an obvious point of opportunity for IT organizations to both audit and leverage to stop horizontal movement. What’s needed is to first audit logons at both the local endpoint and against the domain, looking for logon anomalies, such as:

• Logon times: Users that normally work business hours Monday through Friday don’t normally log on at 7am on a Sunday.

• Multiple logons: A single user logging onto multiple machines at the same time or within a concurrent timeframe may indicate an issue.

• Unusual endpoints: If a user has never logged onto a given endpoint previously, it may be a red flag.

• Unusual IP address: A user from your HR team doesn’t normally logon from the sales team office.

• First times: Attackers sometimes establish persistence by creating multiple users accounts (so if one is discovered, more accounts are lying in wait). An account logging on for the very first time should be scrutinized.

While it’s technically possible via event log consolidation, properly finding the anomalies will also require some level of analytics to cross-reference logons with one another. Leveraging third-party solution may be part of the answer to quickly identify potential threat activity.

To stop an attacker, you need to take away their most precious attack asset: the ability to logon with compromised credentials. By eliminating their ability to logon remotely, you effectively kill any lateral movement and, therefore, the attack. Sure, you still need to address where their foothold is, what malware is installed (and needs to be removed), etc. But to actually halt the attacker’s actions, the first step is to prevent them from authenticating.

You have a few options here to prevent logons:

1. Restrict or eliminate remote logons: Only allowing accounts to log on locally to an endpoint, or allowing only a limited set of accounts to log on remotely, is an effective means to thwart attackers. However, many servers need SMB access enabled, or are permanently remote, making this not always a viable option.

2. Reactively disabling accounts: If you’re a DIY IT pro, launching a script based on specific audit log findings that disables the account in question could be a temporary solution to stop an attacker. But disabling an account also, well... disables the account, which could impact much more than a single user if you’re talking about a service account, an administrative account, etc.

3. Leveraging third-party solutions: There is a greater ability to identify and respond to anomalous logon behavior when using a solution designed to monitor and analyze all logon activity. By matching intelligent analysis with logon policies around the previously mentioned anomalies, solutions can selectively disable an account’s ability to logon. They can also address response-related issues, such as notifying response team members and providing detail on the chain of endpoints on which specific credentials were utilized.

Example: Restrict User Login to an Authorized IP Address Range