How to prevent lateral movement attacks using Microsoft 365 Defender

It’s been 10 years since the first version of the Mitigating Pass-the-Hash Attacks and Other Credential Theft whitepaper was made available, but the techniques are still relevant today, because they help prevent attackers from gaining a network foothold and using credential-dumping tools to extract password hashes, user credentials, or Kerberos tickets from local memory.¹ With those tools in hand, an attacker could move laterally in the network to obtain the credentials of more privileged accounts. All this leads to their ultimate goal—access to your sensitive business data, the Active Directory (AD) database, crucial business applications, and more.

In this blog post, we’ll look at the three fundamental mitigations for preventing lateral movement and how Microsoft 365 Defender can help your team achieve maximum effectiveness from each mitigation:

1. Restricting privileged domain accounts.
2. Restricting and protecting local accounts with administrator privileges.
3. Restricting inbound traffic using Windows Defender Firewall.

1. Restricting privileged domain accounts

Segmenting privileged domain accounts can be achieved through implementing the tier model. The tier model helps to mitigate credential theft by segregating your AD environment into three different tiers of varying privileges and access. Creating separate tiers cuts off lateral movement from a standard user workstation to an application server or domain controller. Meaning, if a standard user account’s machine is compromised and password hashes are obtained by an attacker, there will be no movement path toward more sensitive accounts and servers. The three tiers are arranged 0 to 2, with 0 being the most restricted:

• Tier 0: All accounts and servers in this tier are either domain administrators or have a direct path to domain administrator privileges. Examples of servers include domain controllers, AD servers, and any management server for applications and agents running on Tier 0 servers. For an account to be considered Tier 0, it does not have to be a member of domain administrators; having privileged access to any Tier 0 server or application (through things like access control lists and User Right Assignments) will also classify an account as Tier 0. 

• Tier 1: In most cases, Tier 1 will contain the most business-critical applications. All accounts and servers in this tier are either running enterprise applications or have permissions on servers running applications. Examples include file shares, application servers, and database servers.

• Tier 2: This tier can be thought of as any account or machine that does not fall into either of the other tiers. This is where normal user workstations will reside, as well as standard user accounts. 

Figure 1: Tier model for Active Directory.

For the tier model to function as intended, the different tiers must be completely segregated from each other. This can be accomplished by creating Group Policy Objects (GPOs) that deny signing in across tiers. No account can be allowed to cross the tier boundaries. For example, an administrator on Tier 0 should be denied access to a Tier 1 or Tier 2 machine. If credentials are exposed to another tier, the password must be reset for that account.

Using Privileged Access Workstations (PAW) also mitigates against lateral movement. Because an account in one tier can only sign in to computers in the same tier, users with more than one account in the domain must use separate computers. A Tier 0 user should use a PAW to access only Tier 0 assets. But the person who owns the Tier 0 account should not use the same machine for checking their email or productivity applications (a Tier 2 activity).

Note: Read-level access to higher tiers is still allowed for all users because this is crucial for AD authentication and for users to access applications.

As explained earlier, if an attacker can harvest the credentials of any of the accounts in the path, they will be able to move laterally to gain the credentials of the sensitive account. One way to spot any lateral movement paths in your environment is to use Microsoft Defender for Identity. By correlating data from account sessions, local admins on machines, and group memberships, Defender for Identity can help prevent this and quickly identify any lateral movement paths for each sensitive account. If the attacker can harvest the credentials of any of the accounts in the path, they will also be able to move laterally to gain the credentials of the sensitive account. 

Figure 2: Lateral movement path view from Microsoft Defender for Identity portal.

By default, Defender for Identity classifies certain groups and their members as sensitive, while providing functionality to add more accounts and groups to the classification if needed. The goal is to break the possible attack paths (see Figure 2) by removing local administrators, denying access, or by separating accounts.

2. Restricting and protecting local accounts with administrator privileges

Local admin access opens up vast credential harvesting and lateral movement possibilities, making local admins a prime target for attackers. To make matters worse, local admin management and monitoring are sometimes overlooked. Often the local administrator password is set once for all machines in the organization during the operating system deployment, including machines used by administrators. When local admin passwords are not randomized across client machines, an attacker can compromise a local account password on one machine and automatically obtain administrator-level access to all client machines in the network.

Fortunately, Microsoft Local Admin Password Solution (LAPS) is an easy-to-deploy tool that fully automates password management for local accounts. Once installed on the machine, LAPS will set the local admin account password to a random string and write it to a confidential attribute of the corresponding computer account in AD. During deployment, your team can specify computers to be managed and which users will be able to retrieve passwords from AD—for example, the helpdesk team accessing a client computer’s credentials.

Microsoft Defender for Endpoint tracks LAPS configuration on endpoints and can be found in Vulnerability management > Security recommendations.

Figure 3: LAPS security recommendations page in the Microsoft 365 Defender portal.

For a detailed report on your devices, run the following query in Advanced Hunting: 

DeviceTvmSecureConfigurationAssessment  
| where ConfigurationId == "scid-84" 
| where OSPlatform == "Windows10" 
| where IsCompliant == 0 
| project DeviceName, OSPlatform

A similar report can be found in Microsoft Defender for Cloud Apps with Defender for Identity integration. It also tracks LAPS deployment from an AD perspective by highlighting computer objects that did not have their LAPS password updated in the last 60 days. Although both reports provide similar information, it is obtained from different sources. Therefore, the two reports can be used to crosscheck LAPS deployment status.  

Defender for Endpoint customers can view all activities being monitored and configure custom detections for suspicious local administrator account behavior. For example, the following query detects local admin usage over the network: 

DeviceLogonEvents 
| where AccountSid endswith '-500' and parse_json(AdditionalFields).IsLocalLogon != true 
| join kind=leftanti IdentityLogonEvents on AccountSid // Remove the domain's built-in admin account 

Your team can also block local admin accounts’ access over the network by adding the Local account and member of Administrators group (S-1-5-114) entity to Deny access to this computer from the network GPO setting. This will further complicate an attacker’s lateral movement, as well as cover any possible extra local admin accounts available on the machine, since LAPS can only cover one account per device.

3. Restricting inbound traffic with Windows Defender Firewall

Our experience has shown that this last mitigation is often overlooked. By simply removing the ability to connect from one computer to another, this mitigation provides a simple and robust way to make lateral movement more difficult for an attacker.

Host-based firewalls may have a reputation for being difficult to manage but blocking inbound traffic on Windows clients using Windows Defender Firewall is not a tedious task. Most client-server applications initiate network communication from the client side and don’t expect any inbound connections initiated from the servers. But for this mitigation to work, Windows Defender Firewall must be set to block all inbound connections (unless specifically allowed by one of the rules). It is key to disable local firewall rules merging, since failure to do so will negate the effect of this mitigation. For details on Windows Defender Firewall configuration, please check the Pass-the-Hash Mitigations whitepaper¹ for a GPO approach or the Microsoft Intune documentation. 

Figure 4: Windows Defender Firewall settings for mitigating lateral movement.

Once initial configuration is done, it’s crucial to identify any applications that were overlooked and did not receive exceptions to accept inbound connections. This is where Defender for Endpoint can help by significantly expanding firewall monitoring and reporting capabilities. Once Windows Defender Firewall is set to block inbound connections on a test group of devices, your team can easily start analyzing firewall logs for any misconfigurations.  

The Reports section in the Microsoft 365 Defender portal has a built-in firewall report with all the information needed. Each report section contains an Advanced hunting button that shows the relevant query and allows you to dive deeper into the data. 

Figure 5: Remote IPs targeting multiple computers report in Microsoft 365 Defender portal’s Reports page.

In this example, the most relevant report is Remote IPs targeting multiple computers. The existing query can easily be adjusted to only include test devices: 

DeviceEvents 
| where DeviceName in ("testdevice1.contoso.com", "testdevice2.contoso.com") 
| where ActionType == "FirewallInboundConnectionBlocked" 
| summarize ConnectionsBlocked = count() by RemoteIP 
| sort by ConnectionsBlocked  

Once IP addresses returned by the query are verified as legitimate applications requiring inbound access to client computers (such as remote management software or any peer-to-peer applications), then the firewall configuration can be adjusted to include these IP addresses as exclusions. For extra reporting flexibility, a Power BI firewall report can be connected to Defender for Endpoint.

Learn more

At Microsoft, we believe that the mitigations outlined in this article can significantly improve your security posture and reduce the threat of lateral movement in your environment. Using Microsoft 365 Defender can help you in the process.

• Begin using Microsoft 365 Defender today.
• Read more about Microsoft Security Experts and Incident Response services.
• Learn Kusto Query Language to use the advanced hunting capabilities in Microsoft Security products. 

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.