5 steps to avoid credential dumping attacks

Credential dumping is a significant technique that attackers use to gain persistent access in a network. They sneak into a workstation via phishing and then leverage the typical ways that admins manage and monitor a network to find exposed credentials.

Any organization might have vulnerabilities that make them susceptible to credential dumping. Here are five ways to identify those vulnerabilities or limit their risk.

1. Limit credential reuse

First, review how you manage your networks. How many times do you log into different network assets from workstations used for other tasks? How many times do you reuse passwords for online accounts as well as on your networks?

NIST recommends that organizations routinely check user passwords against a database of breached passwords. Any password used in your network that appears in a breached password list makes your network more vulnerable to attack.

Troy Hunt has released a database of over 500 million passwords that have been taken in breaches. You can use various resources to compare these breached passwords to the passwords used in your network. For example, you can install the Lithnet Password Protection (LPP) for Active Directory on your Active Directory domain using a password filter to review the passwords in use on your network. Then use Group Policy to customize the checking of these passwords. You can decide to reject or approve them.

Want to do the same test on your Office 365 passwords? Use this password checking process for Office 365 Azure passwords. Alternatively, you can review them at the mailbox level with this script.

2. Manage local administrator passwords

The importance of managing local administrator passwords can’t be stressed enough. They should not be the same across the network. Consider deploying the Local Administrator Password Solution (LAPS). An additional module that can be installed is the Lithnet LAPS Web App that provides a simple web-based and mobile-friendly interface for accessing local admin passwords.

Attackers know that once they gain access inside a network and harvest the left-behind hash value of a local administrator password that they can then perform lateral movement throughout the network. Having a randomly assigned passwords means that attackers can’t perform this lateral movement.

3. Review and audit use of NTLM

If you are using New Technology LAN Manager (NTLM), attackers can use NTLM hashes to gain access to your network. Relying on LM or NTLM authentication in combination with any communication protocol (SMB, FTP, RPC, HTTP etc.) puts you at risk from this attack. One weak machine inside your organization will provide an attacker a toe-hold into your domain. NTLMv1 and LM authentication protocols are disabled by default starting with Windows 7 / Windows Server 2008 R2, but it’s time to review your settings to ensure that you are mandating NTLMv2. PowerShell can be used to review the use of NTLM in your network.

In Group Policy, set the value as follows:

1. Select “Start”.
2. Select “Run”.
3. Enter GPedit.msc.
4. Select “Local Computer Policy”.
5. Select “Computer Configuration”.
6. Select “Windows Settings”.
7. Select “Security Settings”.
8. Select “Local Policies”.
9. Select “Security Options”
10. Scroll to the policy “Network Security: LAN Manager authentication level”.
11. Right-click on “Properties”.
12. Select “Send NTLMv2 response only/refuse LM & NTLM”.
13. Click “OK” and confirm the setting change.

To set the value with the registry:

1. Open regedit.exe and navigate to HKLM\System\CurrentControlSet\control\LSA. Click on LSA. You may need to add a new registry key if you don’t see LMCompatibilityLevel in the right window pane.
2. Select “Edit”.
3. Select “New”.
4. Select “REG_DWORD”.
5. Replace “New Value #1” with “LMCompatibilityLevel”.
6. Double-click on LMCompatibilityLevel in the right window pane.
7. Enter “5” to represent the changed level. You may need to upgrade the firmware on printers to support NTLMv2 in your network.

4. Manage the access control list for "Replicating Directory Changes"

Attackers know how we use accounts in our domains often better than we do. They can often abuse Microsoft Exchange permission groups. Thus, you’ll want to monitor changes to security groups and access control lists (ACLs) for key features in your domain. Audit and monitor for any changes in ACLs in your domain.

When an attacker modifies the ACL of the domain object, an event is created with ID 5136. You can then query the Windows event log looking for security event ID 5136 in your logs using a PowerShell script:

Get-WinEvent -FilterHashtable @{logname='security'; id=5136}

Then use ConvertFrom-SDDL4, which converts the SDDL string into a more readable ACL object. Server 2016 and later provides an additional audit event that documents the original and modified descriptors.

5. Monitor for unexpected processes interacting with Isass.exe

Finally, monitor for unexpected spikes in the lsass.exe process. Domain controllers use the lsass.exe process as part of the normal process of the domain transactions. Denial of service and malicious traffic can be hiding in those processes. Determining what is normal in your domain controllers is key to monitoring when you are under attack. Run the Active Directory Data Collector on your domain controllers and base-line the normal processes that you see in your network.

Keeping the attackers at bay starts with having a good foundational understanding of your network and it’s use of resources. Take the time to understand so that attackers won’t gain the upper hand.

Remember to keep up to date on the IDG TechTalk channel.