Cyber Security Strategy

Lateral Movement (ID: TA0008) - The adversary is trying to move through your environment.

Lateral Movement consists of techniques that adversaries use to enter and control remote systems on a network. Following through on their primary objective often requires exploring the network to find their target and subsequently gaining access to it. Reaching their objective often involves pivoting through multiple systems and accounts to gain. Adversaries might install their own remote access tools to accomplish Lateral Movement or use legitimate credentials with native network and operating system tools, which may be stealthier.

Lateral Movement Techniques

Exploitation of Remote Services
Internal Spearphishing
Lateral Tool Transfer
Remote Service Session Hijacking
SSH Hijacking
RDP Hijacking
Remote Services
Remote Desktop Protocol
SMB/Windows Admin Shares
Distributed Component Object Model
SSH
VNC
Windows Remote Management
Replication Through Removable Media
Software Deployment Tools
Taint Shared Content
Use Alternate Authentication Material
Application Access Token
Pass the Hash
Pass the Ticket
Web Session Cookie

Strategies to prevent Lateral Movement

Use Standard User Accounts: Enforce that all users have a standard user account. Administrators across all platforms should log in with their standard accounts as normal practice. They should only log in with administrative rights when they need to perform administrative tasks. Sounds reasonable. Doesn’t always happen.

Enforce the Principle of Least Privilege: If a user does not need access to systems, applications or data, remove it. As a first step remove administrator rights on desktops for all users.

Implement Application Allow listing: Implement policy to allow known good applications and log all other applications and launch attempts. If possible, restrict launching of end user applications with known critical security vulnerabilities.

Implement Multifactor Authentication: Implement multi-factor authentication for access to internal systems, applications and even data. While implementing static multi-factor based on whether a system or application is good, getting too restrictive can become frustrating for users. Look for solutions that can also restrict access based on the risk associated with the environment or activity. For example, if someone tries to launch a sensitive application after hours for the first time, or tries to run a sensitive command on the Unix server that is missing critical patches, step up the security and trigger to re-authenticate with multi-factor.

Note: SMB can provide a convenient MFA bypass for adversaries, handing them a foothold that will allow for remote code execution without any additional authentication factor. Depending on the environment, SMB may also provide adversaries the ability to disable security controls (including MFA) and improve their position in the network.

In many environments that implement MFA using 3rd party provider, an attacker may remove the MFA restriction with their SMB-based shell. They achieve this by enabling ‘Restricted Admin Mode’. This seems counterintuitive, but works for many MFA clients because restricted admin mode changes the supported Windows logon types and takes the MFA provider out of the picture. The setting is controlled via a single registry key: “HKLM\System\CurrentControlSet\Control\Lsa\DisableRestrictedAdmin” and setting it to 0 is all that is required in many cases. This single change gives the adversary the option of single-factor RDP access to machines that would have otherwise been protected with an MFA prompt.

You need to enable the Windows firewall in all profiles (domain, private, public) in the Servers and configure it to block inbound traffic by default. Through a simple Windows Firewall rule, distributed via Group Policy and applied to the workstations OU, all inbound communication on ports 139 and 445 could be denied by default. Further,

Deny all SMB communication between workstations
Deny most SMB communication from workstations to servers (wherever not required)

This would ensure -

Lateral movement with SMB between workstations would be unlikely
Malware which spreads via SMB is also unlikely to move through the workstations

Use Context-Based and Adaptive Access Controls: At some point people need access to do their jobs, but continue to lock down when they have access, and from which location they have access. Restricting access based on static elements like time of day or subnet is good, but restricting access dynamically based on risk (i.e. does a ticket exist for the access, does this request adhere to a normal access patterns, have I received recent alerts from my threat detection layers, etc.) adds greater protections.

Implement mitigations against Mimikatz: When Mimikatz first came out, Microsoft patched against that first version of code using KBKB2871997 (for Windows 7 era hosts, way back in 2014). https://support.microsoft.com/en-us/help/2871997/microsoft-security-advisory-update-to-improve-credentials-protection-a

Since then, this protection has been integrated into Windows 8.x, Windows 10 and Server 2016+. However, what you'll find is that these protections only protect against the initial vector. Mimikatz and Microsoft are in an ongoing game of "cat and mouse" over this issue, and newer versions of Mimikatz have newer attacks.

Mimikatz Specific Defenses -

Update Active Directory's Functional level. Many of the Enterprise Protections aren't available unless the AD Functional Level is set to some modern version (Windows 2016)

Disable the debug right for local administrators on all servers and workstation. To disable this setting in Group Policy, navigate to Security Settings / Local Policies / User Rights Assignments / Debug Programs.

By default, this is not configured - enable it, and don't add any users or groups to it (or add only the group(s) that truly need it)

Disable the WDigest protocol across the board. It's disabled by default in Windows 8 and newer.

Enable LSA protection (RunAsPPL registry key). This provides some protection of the memory used by the LSASS process. To enable this, in the registry, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA and set "RunAsPPL" to "1"

Note: This one does have some risk, as it tries to apply protections to other components that LSASS might call (like 3rd party authentication code). This is the first mitigation that carries risk - this can break things! Fortunately Microsoft has some audit settings that can be deployed in advance to assess if you have a problem in this area first. More details on this, and the setting in general can be found here: https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection

Disable storage of plain text passwords in AD. To disable this, in Group Policy navigate to: Computer Configuration / Security Settings / Account Policies / Password Policy, and set "Store Passwords using reversible encryption" to "Disabled":

Enable Restricted Admin Mode (“DisableRestrictedAdmin” and “DisableRestrictedAdminOutboundCreds” registry keys). This sets up your RDP session to NOT store credentials in the memory of the target host. To start a session in Restricted Admin Mode, run your RDP session as:

mstsc /restrictedadmin /v:targethost

You can also control this behaviour with registry keys:

In HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa, set the DWORD value DisableRestrictedAdmin to "0" to enable restricted mode (this setting does not exist by default)

also

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa, the DWORD value to create and set is DisableRestrictedAdminOutboundCreds:

Default value = doesn’t exist = 0 = Admin Outbound Creds are enabled
Value =1 == Admin Outbound Creds are disabled
More can be found on these settings here: https://blogs.technet.microsoft.com/kfalde/2015/01/10/restricted-admin-mode-for-rdp-in-windows-7-2008-r2/

Enforce “Enable Restrict delegation of credentials to remote servers” via group policy. This sets "restricted admin mode" as the default for all RDP sessions that are initiated by domain members that are in scope for that GPO. The GPO seeting is:

Computer Configurations > Policies > Administrative Templates > System > Credential Delegation, Then Set Restrict Delegation of credential to remote servers to "Enable" and "Require Restricted Admin"

Enforce NLA (Network Level Authentication) for RDP sessions. To enforce this in Group Policy:

For Servers:
Computer Configuration/Policies/Administrative Templates/ Windows Components/Remote Desktop Services/Remote Desktop Session Host/Security
Enable: Require user authentication for remote connections by using Network Level Authentication

For Clients:
Computer Configuration/Policies/Administrative Templates/Windows Components/Remote Desktop Services/Remote Desktop Connection Client
Enable: Configure server authentication for client and in the drop-down menu choose “Do not connect if authentication fails”

Disable password caching. By default Windows will cache the last "x" number of authentications (including the password hashes), in case no Domain Controllers are available. You can disable this in Group Policy at:

Computer Configuration -> Windows Settings -> Local Policy -> Security Options -> Interactive Logon: Number of previous logons to cache -> 0

Note: This might mess things up for people with laptops, who will want to login while away from the office. You can set up your VPN client to force a VPN connection before login, but that'll still cause you headaches if you need to authenticate to a wireless hotspot first. Often that is mitigated by telling people to allow tethering to their cellphone, and then in written policies and technical controls forbid the use of free/public hotspots such as hotel or coffee shop wifi. This is a simple and effective mitigation, but it needs some thought and communication in advance to make it work in many organizations. Please ONLY use this option if you could beforehand socialize the problems and solutions with laptop users in advance.

Restrict Service or other Purpose-created Admin accounts to specific stations or servers. This one doesn't stop Mimikatz from stealing credentials from the machine, but what it does do is prevent the re-use of those credentials for lateral movement to other targets, which is usually the whole point of the attack.

Implement Strong Password Policy Management: Require strong passwords, and that they should be changed frequently. Deny password reuse. Log failed authentication requests.

Automate Password Management: Require unique passwords across all privileged systems and accounts. Eliminate hard coded passwords in service accounts and scripts. Implement SSH key management tools.

Segment Networks: Group assets, including application and resource servers, into logical units that do not trust one another. Segmenting the network reduces the “line of sight” access attackers must have into your internal systems. For access that needs to cross the trust zones, require a secured jump server with multi-factor authentication, adaptive access authorization, and session monitoring.

Consider Micro-Segmentation: Where possible, go beyond standard network segmentation. Segment based on context of the user, role, application and data being requested.

Implement Threat and Advanced Behavior Monitoring: Somewhere along the line accounts have access to stuff. Implement base security event monitoring and advanced threat detection (including user behavior monitoring) to more accurately and quickly detect compromised account activity as well as insider privilege misuse and abuse.

References:

https://www.beyondtrust.com/blog/entry/10-steps-stop-lateral-movement-data-breaches

https://www.netwrix.com/windows_server_hardening_checklist.html

https://isc.sans.edu/forums/diary/Mitigations+against+Mimikatz+Style+Attacks/24612/

https://blog.palantir.com/restricting-smb-based-lateral-movement-in-a-windows-environment-ed033b888721