For penetration testers who do many internal network penetration tests, the process tends to follow a familiar rhythm: Default Active Directory and Windows OS settings often lead to easy footholds and escalation paths to Domain Admin, meaning the same few tricks often yield wild success. Domain Admin is often achieved on the first day of testing by running Responder to obtain user hashes, cracking a weak password to obtain domain credentials, then Kerberoasting and cracking a weak service password.
The goal of this post is to make our lives as penetration testers more difficult by providing defenders with an easy-to-follow guide for eliminating the most common security misconfigurations on internal networks. This is not intended to be a comprehensive guide to hardening all aspects of Active Directory environments. However, following the remediation steps in this post will help secure your network and add value to your next penetration test by allowing your tester to dive more deeply into other potential issues.
This post will cover 11 common internal network security misconfigurations and fixes to get you started AD hardening.
Windows environments have multiple ways to identify hosts on the networks. When a hostname can’t be resolved via DNS, the default setting is to send out broadcast requests to the network to ask who has the requested hostname. This process requires no verification, so an attacking machine can simply use a tool, such as Responder, to say “I am that device” – and the initiating computer will attempt to authenticate using a Net-NTLMv2 hash. An attacker can then attempt to crack this hash offline, or if SMB signing is disabled, they can relay the hash to another machine and authenticate using just the hash.
If possible, disable LLMNR and NBT-NS protocols. There may be some situations where these protocols are needed, but in many instances, it is best to disable them entirely. This can be done via Group Policy:
Computer Configuration -> Policies -> Administrative Templates -> Network -> DNS Client -> Enable “Turn Off Multicast Name Resolution”Depending on the needs of your network, you may want to create a WPAD configuration that points to the corporate proxy server. In many instances, it is best to disable WPAD entirely by creating an empty WPAD entry. This can be done by creating a DNS CNAME record with the name “wpad” and an empty FQDN:
Microsoft published an article that further guides you regarding the configuration of WPAD (1).
Alright, so you made the above changes and there should no longer be any broadcast traffic, right? Double-check by running Responder (2) yourself and see what shows up. Depending on your network configuration and segmentation, this should be done on each subnet to ensure your network is not vulnerable.
Responder can be run in Analyze Mode (-A) to simply view broadcast traffic:
sudo responder -I eth0 -w -AOr you can omit the analyze flag to actually poison responses:
sudo responder -I eth0 -wIf no traffic shows up initially, allow it to run in Analyze mode for a few hours (or a few days) to determine if there are any hosts that the GPO settings may not have reached, or if some other misconfiguration is causing broadcast traffic to still be present.
Some EDR solutions include detections for poisoned broadcast responses. They do this by making fake broadcast traffic requests then generating alerts if responses are given, as responses to nonexistent resources indicate poisoning is occurring. Additionally, there are several open-source projects that can be used to generate fake traffic and detect broadcast traffic poisoning.
Password spraying is often wildly successful, especially in large organizations. Implementing and enforcing a strong password policy is definitely encouraged, as it makes it more difficult for an attacker to guess simple passwords. Configuring a policy does not retroactively apply to existing weak passwords, so it is often beneficial to additionally audit current passwords to eliminate password reuse and weak passwords that were set before implementing the policy.
Password policy can be set for Active Directory users via Group Policy:
Computer Configuration-> Policies-> Windows Settings-> Security Settings -> Account Policies -> Password Policy -> Enable “Password must meet complexity requirements”Computer Configuration-> Policies-> Windows Settings-> Security Settings -> Account Policies -> Password Policy -> Set “Minimum password length”Additionally, privileged accounts such as those in the Domain Administrator group should be separated from everyday user accounts and should have a separately defined password policy with stronger complexity requirements.
Another issue that we often see on internal networks is a lack of SMB signing. SMB signing is a complex topic with several risks associated with it not being required. One is that it’s possible to relay Net-NTLMv2 hashes to other devices, effectively negating the need to crack the obtained hashes. This means that hashes obtained from a tool like Responder can be used to directly authenticate to devices where SMB signing is not required. Successful exploitation leads to authenticated SMB access, and if the user has local administrative access it leads to code execution on the affected device.
There are also several recent vulnerabilities that benefit from SMB signing not being enforced such as “PetitPotam”. Additionally, there are numerous other methods for eliciting Net-NTLMv2 hashes that can then be used against hosts without SMB signing. The bottom line is SMB signing should be set to enforced in nearly all situations (setting it to “enabled” isn’t sufficient, as the client can simply request SMB signing to be disabled).
SMB signing for client and server can be set to enforced via Group Policy (make sure to set to “always”):
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options -> Enable “Microsoft network server: Digitally sign communications (always)”Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options -> Enable “Microsoft network client: Digitally sign communications (always)”An attacker’s goal is to find something network administrators and defenders missed. Implementing and maintaining a solid asset inventory is not glamorous, and can be especially difficult in large organizations. Thankfully, Bloodhound (3) exists and makes Active Directory inventory easy. As a defender, Bloodhound can be used to see and mitigate attack paths (other blogs about Bloodhound here). It provides easy, out-of-the-box queries for many issues, including end-of-life operating systems. Ideally, you should be decommissioning and removing any end-of-life operating systems.
To run Bloodhound on your network, grab the latest release of SharpHound from their Github page. The binary will likely be flagged by AV, so you will have to create an exception to run it. SharpHound is used to collect information from the domain and provide files to be ingested by BloodHound. BloodHound then provides a nice graphical interface for viewing your active directory environment and potential attack paths.
Run SharpHound as a domain user to include the useful ACL collection method:
SharpHound.exe --CollectionMethod Default,ACLThen follow the instructions to get BloodHound installed (4).
Once installed, you can ingest the zip file and begin to view data on your domain. Identifying unsupported operating systems in Bloodhound (5) can be achieved by selecting:
Analysis -> Find Computers with Unsupported Operating SystemsIdeally, legacy devices should be removed from your network entirely in place of currently supported operating systems.
Patching should be a high priority for baseline security. Ideally, all devices on your network should be on the latest supported operating systems and fully patched. Even in 2022, we still see the MS17-010 (EternalBlue) vulnerability in environments and use it to gain an initial foothold. There have been several critical vulnerabilities in recent years that should be a top priority to address and patch. As a defender/system administrator, you should be performing regular vulnerability scans and applying the necessary patches across your entire environment. Some of the highest impact Microsoft vulnerabilities in recent years are MS17-010 (Eternalblue) (6), SigRED (7), and Zerologon (8).
Use a centralized patching service such as Windows System Update Services (9) to automatically test and apply patches across your environment.
While Kerberos pre-authentication is disabled by default, it can lead to an easy foothold if enabled on any accounts. Disabling pre-authentication bypasses initial verification within a Kerberos authentication request and allows an attacker to obtain a user’s encrypted password. This attack is known as “AS-REP Roasting” (10).
Armed with a list of usernames, an attacker can use a tool like Kerbrute (11) to check for AS-REP roasting and extract password hashes for offline cracking if Kerberos pre-authentication is enabled for any accounts.
Bloodhound can be used to query for any users with Kerberos pre-authentication enabled. This can be found in Bloodhound by selecting:
Analysis -> Find AS-REP Roastable Users (DontReqPreAuth)If any instances of this security misconfiguration are identified, they can be remedied by editing the user in Active Directory Users and Computers:
Account -> Deselect “Do not require Kerberos preauthentication”In some Active Directory environments, especially those that have been upgraded from older Operating Systems, a misconfiguration allows an unauthenticated user to dump a list of all domain usernames from domain controllers using null SMB sessions. This is a high-impact issue, as it often leads to an initial foothold through AS-REP roasting or password spraying/guessing. Detecting this issue can be done in several ways, including using Nmap against all domain controllers within your environment:
nmap -iL domaincontrollers.txt -p445 -Pn --script=smb-enum-users -oA nmap_smbenumusersIf this dumps a list of Active Directory users, then you are vulnerable.
To remedy this issue, the following changes must be made within Active Directory:
Builtin -> Pre-Windows 2000 Compatible Access -> Remove “ANONYMOUS LOGON” and “Everyone” groupsEnable:
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options -> Enable “Network access: Restrict Anonymous access to Named Pipes and Shares”Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options -> Enable “Network access: Do not allow anonymous enumeration of SAM accountsDisable:
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options -> Disable “Network access: Let Everyone permissions apply to anonymous users”Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options -> Disable “Network access: Allow anonymous SID/Name translation”Kerberoasting is probably one of the most common domain escalation paths, often leading to compromise of the entire Active Directory domain shortly after initial domain user compromise. Active Directory authentication is configured so that any domain user can request a hashed password for service accounts. This means that all Active Directory service accounts are susceptible to offline password cracking attempts. This is a feature of Active Directory authentication and cannot be changed. To prevent this feature from being abused, it is recommended to use extremely long passwords for all Kerberoastable service accounts to make it effectively impossible to crack the passwords.
Bloodhound can once again be used to identify all Kerberoastable service accounts:
Analysis -> List all Kerberoastable AccountsFor each of these accounts, a unique, extremely long password should be randomly generated and stored securely. The maximum supported password length for Active Directory passwords is 256 characters, but the Windows GUI only supports up to 127 characters. To render password cracking effectively useless, a randomly generated password of 64 characters or longer should be sufficient. These passwords should be rotated on a regular schedule (e.g., every 6 months).
Note: Some of these accounts (i.e., the “krbtgt” account) may not be visible by default in the “Active Directory Users and Computers” console. To modify these users in the console, select:
View -> Advanced FeaturesWDigest allows plaintext passwords to be stored in memory each time a user logs on to an affected machine. These can then be dumped by an attacker with local administrative access (12). The default setting for modern Windows Operating Systems is to disable WDigest, but WDigest is enabled by default on Windows operating systems prior to Windows 8 and Windows Server 2012 R2. This issue often allows for easy lateral movement and privilege escalation, as an attacker can log on to a device where they have local administrative access and dump plaintext credentials of any other user who has logged on to the device since the last reboot.
Upgrade all devices to currently supported Operating Systems.
If this is not possible, disabling WDigest authentication from storing passwords in cleartext in memory can be done using the following steps (13):
1. Windows patch KB 2871997 must be installed
2. The following registry key must be set to “0”:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential This registry change can be done via Group Policy:
Computer Configuration -> Preferences -> Windows Settings -> Registry -> New -> Registry Item3. Select “Update” for Action, as this will create the key if it is not present. Enter the keypath:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential 4. Input a Value Type of “REG_DWORD” and a value of “00000000” to disable WDigest.
Please note that disabling WDigest will break SSO WDigest authentication if it is in use on the affected resources.
Additionally, even on newer versions of Windows, an attacker can enable WDigest via registry change without requiring a reboot. This means the registry should be monitored for unauthorized changes. Even if WDigest is disabled, attackers can dump LSASS memory to view stored NTLM hashes. Ideally, Windows Credential Guard (14) should be used as an additional layer of security.
In many environments, we find computers that are configured with the “Domain Users” group as local administrators. This means that once an attacker has compromised any domain credentials, even if the user does not have explicit local administrative access to any devices, they will by default inherit local administrative access to these computers. Local administrative access to devices is instrumental in pivoting throughout the domain and eventually escalating privileges to the domain administrator, so eliminating this misconfiguration is essential to securing the domain.
Bloodhound can once again be used to quickly identify any computers with this misconfiguration:
Analysis -> Find Computers where Domain Users are Local AdminOnce identified, this can be remedied by removing the “Domain Users” group from the computer’s “Local Administrators”:
Control Panel -> Edit Local Users and Groups -> Groups -> Administrators -> Remove “YOURDOMAIN\Domain Users”Group Policy Preferences Passwords allowed organizations to set a local administrative account across numerous computers within the domain via Group Policy. This configuration stores the encrypted password for the account in a Group Policy object. However, the key used to encrypt these passwords were published publicly by Microsoft prior to 2012. This means environments still using GPP Passwords are effectively storing these passwords in plaintext for any authenticated domain user to obtain (15).
While this post is not meant to provide a comprehensive list of security controls for Active Directory networks, it should help prevent the most common attack paths from being exploited. This will allow your next penetration tester to dive deeper into more complex attack paths that might be otherwise overlooked. Defenders should stay up-to-date on commonly used attack methodologies and have detection and protection mechanisms in place to prevent them. The MITRE ATT&CK (18) knowledge base is incredibly useful for achieving this goal.
Read more How-To blogs from White Oak Security’s expert pentesters…
Sources: