Over the years I’ve seen a lot of misconfigurations or a lack of configurations when it comes to protecting Windows credentials, hashes or Kerberos tickets. The main difficulty here comes from the fact that the Windows domain is complex and the multitude of features that it offers come with many security implications, especially when there is a lack of maturity in the service management process.
This is why constant monitoring and auditing is required in order to maintain a decent level of security, and there is no easy or single solution that you can truly rely on. In fact the principle of defense in depth is key in any domain infrastructure that aims to maintain a high security level.
The purpose of this post is to present the multitude of control mechanisms that should be considered by any organization using an Active Directory Domain Infrastructure and seeking to protect cached credentials and avoid Network attacks that are commonly performed by attackers with tools such as Mimikatz, Rubeus, Metasploit and other.
Usually local system accounts are used by system administrators to perform local tasks and therefore these accounts should only be used locally and should not be used to perform actions remotely. The “Apply UAC restrictions to local accounts on network logons” group policy setting controls whether local accounts can be used for remote administration via network logon. Enabling this option will prevent attackers from performing remote actions even if they have the correct credentials for a local account.
Moreover, it is also recommended to avoid using privileged domain accounts such as a member of the Enterprise Admins or Domain Admins to perform simple tasks on network computers. In order to prevent privileged accounts and only allow the accounts with the minimum amount of privileges to perform these actions the group policy setting “Deny access to this computer from the network” should be configured.
When WDigest authentication is enabled on a system, Lsass.exe (Local Security Authority Subsystem Service) retains a copy of the user’s plain-text password in memory. Thus, an attacker can dump the LSASS memory and view the password.
Previous to Windows Server 2012 R2, WDigest authentication is enabled by default. Even on newer systems it is recommended to disable WDigest authentication by configuring a group policy object to change the following registry to 0 on all network computers:
"SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential"
Now, it should be mentioned that this setting can be re-enabled by an attacker and can still result in credential compromise, so it is recommended to implement log monitoring (a SIEM solution would be ideal) and to look out for “Authentication package: WDigest” in Event ID 4776 and Event ID 4624.
SMB Signing is a mechanism that helps secure the client-server communication by using signatures to ensure that the SMB message was not tempered with while in transit. The signature also confirms the sender’s and receiver’s identities.
SMB Signing is required in order to protect against SMB Relay attacks which are very common and will result in gaining remote access to the targeted system. SMB Signing should be enforced on both client computers and servers. In order to apply this setting to your entire infrastructure, Group Policy can be leveraged:
Normally when you connect via RDP to a remote system you are passing your credentials to the target machine and these credentials are stored locally for the duration of the session. This means that credentials can be retrieved from cache if an attacker has access to that machine. This will lead to further lateral movement.
The Restricted Admin mode available in RDP will use the NT Hash or Kerberos Ticket instead of the actual credentials. It has been pointed out that Restricted Admin mode comes with a tradeoff, it allows for a Pass-The-Hash attack against the Remote Desktop protocol itself because it uses network logons instead of interactive logons. But such an attack can already be done in most cases against SMB so you are basically enabling Pass-The-Hash on one more port (RDP) in order to protect user credentials by not storing them in memory. You must consider this tradeoff when deciding to implement this feature.
A more in depth article explaining how Restricted Admin mode works can be found here:
Members of the Protected Users group cannot authenticate by using NTLM, Digest Authentication, or CredSSP, instead they use Kerberos Ticket Granting Tickets (TGTs) to authenticate. This way credentials will no longer be cached, so it will help protect against Pass-The-Hash attacks. To use this feature the primary domain controller needs to be run on Windows 2012 R2 domain functional level and devices need to run on Windows 2012 R2, Windows 8.1 or newer versions.
Another benefit of using the Protected Users group is that the Kerberos TGTs are valid no more than 4 hours for the group members, so if you are logged in for more than 4 hours you will be required to reauthenticate to the Domain Controller to get a new ticket.
This security group is mandatory in order to ensure that privileged accounts do not leave behind “breadcrumbs” cached in the server’s memory that can be later found by malicious actors.
Starting with Windows 7 Microsoft implemented a patch (KB2871997) to prevent Pass-The-Hash for all the local computer accounts that are members of the local Administrators group, except for the default Administrator account.
Pass-The-Hash still works but only for the default local Administrator (RID 500) and for domain accounts that are members of the local Administrators group. So it is recommended to keep the default Administrator account disabled and create a separate account (different RID) that will be used for administrative tasks and cannot be used for Pass-The-Hash attacks.
It is important to mention that if the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy exists (by default it doesn’t exist) and is set to 1, then Pass-The-Hash can be performed against all members of the local Administrators group. This setting can sometimes be enabled as a workaround to different problems, so it is recommended to configure it properly through a Group Policy Object. More details about the KB2871997 patch can be found here:
It is also recommended to use different credentials for the local accounts of each Windows system (see Local Admin Password Solution in Chapter 10).
Introduced in Windows 10 Enterprise and Windows Server 2016, Credential Guard uses Virtualization-Based Security (VBS) to isolate secrets so that only privileged system software can access them. Credential Guard protects the NTLM password hashes, the Kerberos Ticket Granting Tickets, and the credentials stored locally.
Without Credential Guard secrets such as hashes are stored in memory in the Local Security Authority (LSASS) and any program running with privileged access can access them. When using Credential Guard two separate processes will be used: LSASS and LSAIso. The latter is an isolated LSA process that is protected by VBS and can only be accessed by LSASS, which means that other programs can’t access the LSAIso process and can’t access stored credentials.
Enabling Credential Guard should be done domain wide in order to reduce the chances of privilege escalation and lateral movement through compromised credentials. Currently Credential Guard is only available in Windows 10 Enterprise, Windows 10 Education, Windows Server 2016 and newer.
When connecting through Remote Desktop your credentials are stored in memory for the duration of the session and once the session is terminated by performing a sign out, the credentials are removed from local memory. The longer the session the higher the chances that a malicious user can retrieve the credentials from memory.
Out of simplicity or convenience many users close the Remote Desktop window by using the “X” button instead of actually singing out when they finish their work. As a result the session is still active and the credentials can be retrieved from memory during this time.
In order to make sure that sessions are indeed terminated a company should configure automatic sign out based on idle time via GPO settings for RDP service.
On older versions of Windows there was an issue where signing out was not always clearing the cached credentials, this was resolved with KB2871997 for Windows 7, Windows 8, Windows Server 2008R2, and Windows Server 2012. If you’re still using older Windows versions please check the following article:
Privileged users should have different accounts for different purposes, this can be achieved by implementing a tiering model that organizes users and systems by levels of risk and controls access to critical components of the domain.
By using a tiering model an employee can have multiple accounts for different types of activities (email and chat, helpdesk, systems administration). By using these principles, compromising an account through one infrastructure area will not lead to the compromise of the entire domain infrastructure.
Moreover, giving users local admin rights should be avoided. Application installs and system changes should be performed with the IT department’s approval or supervision, otherwise attackers will have an easier time escalating their privileges through the domain.
A strong password policy with account lockout will reduce the chances of successful brute-forcing, hash cracking and password spraying, while regular password changes will limit the window of opportunity for attackers. It is recommended to enforce all these settings for domain users by using Group Policy.
Some critical functionalities such as banning specific easy to guess words can be very useful in enforcing strong passwords and eliminating situations that result in attackers cracking passwords with ease, but these features are not available by default in Active Directory Group Policy. If you are using Azure Active Directory or a Hybrid AD environment these types of settings are available:
But if you are using an on-premise solution you would have to rely on a third party Password Filtering solution such as:
However, when it comes to managing local user accounts for all computers it is common to see the same account and same password being used across the network. This is an ideal scenario for an attacker and should be avoided by all means possible. So how to manage local accounts in an elegant way? Microsoft Local Administrator Password Solution (LAPS) allows storing local account credentials in Active Directory and easily managing who can access them. This way companies can avoid using the same account/password combination and mitigate the risk of lateral movement.
All service accounts should have complex passwords of at least 25 characters, especially if you have service accounts where you don’t change the password. This will help protect against attackers trying to crack the NTLM hashes of domain service accounts that can be easily obtained through Kerberoasting.
Free Antivirus software usually offers only antivirus protection and no Network Intrusion Prevention capabilities. Enterprise software usually have features that protect a computer against network attacks including port scanning, Pass-The-Hash, Pass-The-Ticket, etc. Not only that common attacks will most likely be blocked, but notifications will be triggered so that further investigations can be made.
For situations where the attacker may have already bypassed your IPS or WAF and has gained access to the internal network, consider using a Network-Based IDS or SIEM solution that will passively monitor all network traffic and report suspicious activities. Honeypots in my personal opinion are underestimated, it can be a very good solution to detect ongoing attacks.
An old, yet still very popular and efficient starting point for an attacker with network access is to perform Man-In-The-Middle attacks that lead to stealing or relaying credentials/hashes and this can be done by abusing protocols such as LLMNR, NetBIOS, WPAD, IPv6.
Link-Local Multicast Name Resolution (LLMNR) and Netbios Name Service (NBT-NS) are two components of Windows systems. If a machine tries to resolve a specific host, but the DNS resolution fails, the machine will then try to ask all other machines on the local network for the correct address using the LLMNR or NBT-NS protocols. Thus, an attacker can respond and direct the traffic to their machine.
Web Proxy Autodiscovery (WPAD), if enabled, can be used by the system browser to automatically configure an HTTP proxy based on a configuration file. Through the WPAD configuration file, the attacker can direct a user’s browser to a proxy to intercept and modify web traffic.
An attacker with network access can reply to DHCPv6 messages through a link-local IPv6 address and trick a system into using the attacker’s host as a DNS server.
If you don’t have any services or applications on the network that rely on these protocols then disabling them for the entire domain using a Group Policy Object should be a priority. This will help protect against different credential/hash stealing or relaying techniques executed with the infamous Responder or other tools like mitm6.
Another subset of Man-In-The-Middle attacks are those that can be performed by abusing layer 2 devices such as switches. The main attacks that should be taken into consideration are Rogue DHCP, ARP Spoofing/Poisoning and ARP Flooding.
These types of attacks can lead to intercepting credentials that are transmitted in clear text over an unencrypted channel, but even encrypted channels can be affected by conducting SSL stripping or downgrading attacks that also result in compromised credentials.
If the company owns switches with management then it is recommended to implement DHCP Snooping prevention and use Port Security features designed to prevent ARP attacks such as limiting the number of MAC addresses that can be learned on each port in order to prevent ARP Flooding attacks. The following Cisco article details how to implement these features on Cisco switches:
Even though encrypted channels can be bypassed through different methods when the attacker is on the same network, using an encrypted communication throughout the entire domain is definitely recommended in order to reduce the chances of successfully intercepting credentials.
I know system patching can be a daunting task, but one of the main ways an attacker can gain initial access or escalate their privileges through the network is by exploiting known vulnerabilities in corporate applications and systems.
A company should periodically apply patches and constantly monitor that they are up to date according to a Software Update Policy. Automatic patching should be leveraged where it is possible. Unpatched systems can be a gateway towards gaining access to user credentials.
Even though this is not an exhaustive list and multiple other protections could be implemented (2-Factor Authentication, Just-In-Time and Just-Enough-Access, etc.), a company enforcing all these security controls will significantly reduce the attack vectors and can reply with promptitude when a breach does happen. In case some settings or features cannot be disabled because they are used by legacy applications, careful analysis should be done to decide if risks can be accepted. Continuous internal/external auditing is key in order to ensure that controls are properly implemented and misconfigurations are detected and dealt with, otherwise the next breach can be just around the corner.