Lateral Movement is a method used by attackers (or malware) against a network Domain. After an initial device is compromised (typically, a user’s workstation), the attacker extracts passwords from memory, or obtains encrypted password hashes from the system for cracking or direct use (i.e. Pass the Hash). The attacker then attempts to login to other systems using those credentials to search for cached passwords of privileged Domain accounts. Usually, the local Administrator account is targeted as the password is often the same on all systems (due to the common practice of deploying systems from a master image), but service accounts, etc. can also be targeted.
In some cases, an attacker is able to move from having local Administrator access on a workstation to gaining full Domain Admin rights on the Domain in under an hour.
Since Active Directory typically controls access to highly sensitive information, it is important to try and prevent lateral attacks from working. Being able to spot these attacks would also be good.
Limit workstation to workstation communications
It is highly unusual for network users to need to directly communicate with other users’ workstations.
Configure each workstation to use a local firewall to block incoming Windows network traffic (139/TCP, 445/TCP and 137/UDP) from any workstation subnet.
If using a firewall that supports different network zones (such as the Windows Firewall), ensure the appropriate zone profiles are configured, or simply configure all profiles. If your organisation uses VoIP telephones, prevent those subnets from connecting as well to protect against either a malicious internal employee, or in case the attacker is able to convince a user to try changing network connections.
Prevent local users from logging in over the network
If an attacker finds that they cannot directly connect to other workstations to hunt for privileged cached credentials, they may attempt to compromise a server and try to login to workstations from there. To protect against this, configure the User Rights policy ‘Deny access to this computer from the network’ by adding local user accounts.
Use a local Administrator password management tool
Tools, such as Microsoft LAPS, exist that set unique passwords for the local administrator account. By using such tools, when a password exceeds its expiration date the password will be changed automatically when the Group Policy is refreshed. Avoid writing a custom password management system, as it is very difficult to implement such things without error; if an attacker is able to determine a pattern to setting the password, then that defence is gone.
Configure systems via Group Policy
To reduce the risk of credentials being captured, avoid logging into systems where not necessary. Use Group Policies to configure workstations and servers instead of directly logging into them, where possible. Systems may be configured to cache credentials when users login, and this information can be obtained by an attacker and then cracked offline to reveal the plain text password for that user account. If an attacker already has a foothold on a system and a Domain Administrator logs in, the attacker may be able to impersonate the Domain Administrator in order to utilise their privileges within the network Domain.
Use dedicated administrative accounts and workstations
An attacker can only extract privileged password data if it is present on the system. Ensure administrative users have user accounts that are separate from their day-to-day user accounts and configure them so that they cannot login to normal workstations or servers; they should only be used to login to Active Directory servers to manage them, and configure Group Policies to manage other systems.
Dedicated management workstations should not be able to access the Internet or email.
Windows supports several Security Support Providers (SSPs), used to handle authentication requests (including Single Sign On). Until recently (Window 8.1 and Server 2012 R2 or higher), Windows used by default an SSP called ‘WDigest’ – which stored user credentials in plain text in memory, allowing a process with local Administrator privileges to extract the passwords of all logged-in users.
To help address this issue, Microsoft created a new Registry key for ‘WDigest’ to disable storing plain text passwords, which can be applied to Windows, prior to 8.1 and Server 2012 R2 by installing KB2871997 and configuring the following Registry setting:
Registry Path: HKLM\System\CurrentControlSet\Control\SecurityProviders\Wdigest Key Name: UseLogonCredential Key Type: REG_DWORD Key Value: 0
Alternatively, KB2871997 can be configured via Group Policy by installing the PtH.admx/adml files provided with the Microsoft Security Compliance Manager (SCM) via:
Local Policies > Administrative Templates > SCM: Pass the Hash Mitigations > Wdigest Authentication
Apply enhanced credentials protection updates
In addition to the protections added by KB2871997, Microsoft have released an updated that further protects against Pass the Hash (PtH) attacks for Windows 7, Windows 8, Server 2008 R2 and Server 2012.
This update adds support for the TokenLeakDetectDelaySecs Registry setting which can be used to force credentials to be cleared after a user logs off. To set clearing credentials 30 seconds after user logout (the default behaviour in Windows 8.1 and Windows 10), configure the following Registry setting:
Registry Path: HKLM\System\CurrentControlSet\Control\Lsa Key Name: TokenLeakDetectDelaySecs Key Type: REG_DWORD Key Value: 30
Upgrade Windows servers and workstations
With each new version of Windows, Microsoft adds additional security features, including protections for the LSASS service to protect against credential stealing and adding additional logging options. Upgrade servers to Server 2016 and upgrade workstations to Windows 10 and configure them to make use of these new features.
Enable event monitoring and investigate alerts
A centralised logging and monitoring solution provides an opportunity for recording actions and events that take place on systems, and prevents a successful attacker from clearing the event log to hide their actions.
Configure all Windows systems to log events to a centralised system and monitor for account login attempts (both successful and unsuccessful).
Any events that reference local accounts (or Domain Administrator/privileged accounts) and not Domain accounts should be investigated as a matter of priority.
The following Windows event codes are generated by Windows 2008 and later:
- Event ID: 4624: Account login successful
- Event ID: 4625: Account login failed
The corresponding events for Windows 2003 and earlier:
- Event ID: 528: Account login successful
- Event ID: 540: Network account login successful
- Event ID: 529: Login failure – Unknown user or bad password
Other potentially interesting event code are:
- Event ID: 4625: An account failed to login (Windows 2008 and later)
- Event ID: 531: Login failure – Account currently disabled (Windows 2003 and earlier)
A number of options have been presented to hinder Lateral Movement attacks, and some readers might be wondering which option to implement. The answer is “all of them, where possible”. Security is a “defence in depth” game, and every obstacle that an attacker has to work around is worth implementing.
In addition to hindering lateral movement, monitoring for attacks or suspicious behaviour and investigating alerts will help identify more sophisticated attacks, as well as indicating that suspicious activities are occurring.
A Red Team Assessment can be undertaken to determine the effectiveness of the security controls in place during an attack against your network. Whilst the assessment is taking place it also provides an opportunity to determine whether the internal monitoring and response capabilities intended to detect and alert when a potential attack is occurring within your network are effective. Following completion of the assessment you will have a clear view of any additional measures that should be implemented to improve both defence and monitoring capabilities within your network.