Restrict Lateral Movement

Overview

Lateral movement occurs when an attacker who has compromised one system is able to compromise another system on the network by using an existing compromised system as a jump off point. For example, a standard user’s workstation is compromised, and the attacker runs a tool to extract locally cached credentials. One of these sets of cached credentials allows the attacker to gain access to a file server. Once the attacker gains access to the file server, cached credentials stored on that server give them access to a domain controller.

There are a variety of methods that you can use to restrict lateral movement. Some of the techniques that can be used to guard against privilege escalation can also be used to reduce the chances that an attacker can perform lateral movement. Techniques that you can use to restrict lateral movement include but are not limited to:

• Code integrity policies
• Network segmentation
• No common accounts or passwords
• Login script sanitation
• Apply software updates and patches

Network segmentation

You can restrict lateral movement by segmenting critical workloads onto separate networks and VLANS and then controlling which traffic can cross those boundaries. Network segmentation allows you to limit which hosts can communicate with sensitive servers.

For example, you might block traffic from workstations on your organization’s internal network to servers except on the specific ports required by the workstations. You could also configure segmentation through firewalls so that you allow a file server to communicate with workstations on the ports required by file sharing, but not allow communication between the file servers and workstations on any other port, including those used for administrative activities such as the ports used by RDP, PowerShell Remoting, or SSH. You can also segment the network so that sensitive servers can only allow communication using administrative protocol from a select set of computers that are locked down and configured as PAWs.

No common accounts or passwords

Organizations should avoid common local accounts being created on systems. This not only includes disabling the built-in administrator account and instead of using a unique alternative, but also ensuring that a common account isn’t added to multiple systems with the same credentials. For example, a standard account is created across all systems that have a specific application installed.

Organizations should avoid using a common password for separate accounts. For example, audits of the security configurations of some organizations have found that even though they create separate custom accounts to be used for services on separate computers, those custom accounts are configured with a single common password. A red team or attacker who can determine that password will have an easier time performing lateral movement than an attacker or red team in an environment where every password is complex and unique.

Local Administrator Password Solution (LAPS) can be used to ensure that the passwords of the local administrator accounts on all computers in an Active Directory environment have a unique password. This allows organizations to avoid the common trap of having a standard local administrator account password across all computers in the organization.

Login script sanitation

Logon scripts can often include sensitive information, with some logon scripts even including passwords in cleartext. An attacker who gains access to a computer may have access to any scripts that run on that computer. Those scripts may be accessible over the network using non-privileged credentials. Logon scripts should not contain sensitive information such as account passwords. Where possible, logon scripts should be replaced by group policy or configuration management tools such as System Center Configuration Manager or Microsoft Intune.

Apply software update and patches

Attackers will use any technique available to perform lateral movement within an organization. This includes exploiting vulnerabilities in operating systems and applications that have been patched by the vendor but haven’t yet been patched by the organization.

While exploit code exists for some vulnerabilities before vendors patch those vulnerabilities, exploit code is more commonly available for vulnerabilities after the vendor patches those vulnerabilities. This is partly because security researchers and attackers can reverse engineer a software update to determine what vulnerability the software update addresses and are then able to build a tool to exploit that vulnerability, rather than having to discover the vulnerability through their own research.

Organizations should ensure that operating systems, applications, device drivers, and firmware have all appropriate software updates applied in a timely manner as this will restrict attackers from using known exploits to perform lateral movement.