Skip to main content

Active Directory Security

AD Hardening

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.

  • Disable Broadcast Traffic
  • Enforce Strong Password Policy
  • Enforce SMB Signing
  • Remove Outdated Windows Operating Systems 
  • Patch Critical Vulnerabilities
  • Disable Kerberos Pre-authentication
  • Prevent User Enumeration via Null SMB Sessions
  • Detect & Prevent Kerberoasting
  • Disable WDigest
  • Remove Domain Users from Local Administrators Group
  • Remove Group Policy Preferences (GPP) Passwords

Internal Network Security

How To Disable Broadcast Traffic

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.

Disable LLMNR & NBT-NS

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”

Disable or Configure WPAD

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:

This screen grab from White Oak Security shows how 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).

Disabled Broadcast Traffic

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 -A

Or you can omit the analyze flag to actually poison responses:

sudo responder -I eth0 -w

If 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.  

Detect Broadcast Poisoning Attacks

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. 

Enforce Strong Password Policy

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. 

Strong Password Policy Example

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.

Enforce SMB Signing

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). 

Enable & Enforce SMB Signing

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)

Remove Outdated Windows Operating Systems 

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,ACL

Then 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 Systems
White Oak's screenshot show's that 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 then Find Computers with Unsupported Operating Systems

How To Fix Outdated Windows Operating Systems

Ideally, legacy devices should be removed from your network entirely in place of currently supported operating systems.

Patch Critical Vulnerabilities

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).

Vulnerability Patching

Use a centralized patching service such as Windows System Update Services (9) to automatically test and apply patches across your environment. 

Disable Kerberos Pre-Authentication

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)

Fix Kerberos Pre-Authentication

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”
This White Oak Security screenshot shows to DESELECT 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”

Enumerate SMB Sessions

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_smbenumusers

If this dumps a list of Active Directory users, then you are vulnerable.

This capture shows an example Nmap output indicating configuration is vulnerable by White Oak Security.
Example Nmap output indicating configuration is vulnerable.

Prevent User Enumeration Via Null SMB Sessions

To remedy this issue, the following changes must be made within Active Directory:

  1. Remove the “ANONYMOUS LOGON” and “Everyone” groups from the “Pre-Windows 2000 Compatible Access” group in Active Directory Users and Groups
Builtin -> Pre-Windows 2000 Compatible Access -> Remove “ANONYMOUS LOGON” and “Everyone” groups
This screenshot by White Oak Security shows to remove or deselect the “ANONYMOUS LOGON” and “Everyone” groups from the “Pre-Windows 2000 Compatible Access” group in Active Directory Users and Groups
  1. Make the following Group Policy changes:

Enable:

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 accounts

Disable:

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”

Make It Difficult To Pivot & Escalate!

Identify Kerberoastable Accounts

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 Accounts

Prevent Kerberoasting

For 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 Features

WDigest

WDigest 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. 

Disable WDigest 

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 Item
Screenshot by White Oak Security shows the steps for how to change the registry change can be done via Group Policy:

Computer Configuration -> Preferences -> Windows Settings -> Registry -> New -> Registry Item

3. 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.

This shows to put the Input Value Type of “REG_DWORD” and a value of “00000000” to disable WDigest by White Oak Security's pentesters

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.

Remove Domain Users Group From Local Administrators

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 Admin

How To Remove Domain Users From Local Administrators Group

Once 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

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).

Remove Group Policy Preferences (GPP) Passwords

  1. Use LAPS to create unique local administrative passwords for each computer (16).
  2. Install Windows Patch KB2962486 on all domain controllers used to update GPOs to prevent new GPP Passwords from being created. 
  3. Examine and remove existing Group Policy objects with GPP Passwords set (17).

Active Directory Security

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:

  1. https://docs.microsoft.com/en-us/previous-versions/tn-archive/cc995062(v=technet.10) – Microsoft WPAD configuration guidance
  2. https://github.com/SpiderLabs/Responder – Responder Github repo
  3. https://github.com/BloodHoundAD/BloodHound/blob/master/Collectors/SharpHound.exe – SharpHound executable from BloodHound Github repo
  4. https://bloodhound.readthedocs.io/en/latest/installation/linux.html – BloodHound documentation
  5. https://github.com/BloodHoundAD/BloodHound/releases – BloodHound binary downloads from Github
  6. https://docs.microsoft.com/en-us/security-updates/securitybulletins/2017/ms17-010 – Microsoft security bulletin regarding MS17-010
  7. https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/ – SigRED vulnerability information
  8. https://www.crowdstrike.com/blog/cve-2020-1472-zerologon-security-advisory/ – Zerologon security advisory
  9. https://docs.microsoft.com/en-us/windows-server/administration/windows-server-update-services/get-started/windows-server-update-services-wsus – WSUS getting started guide
  10. http://www.harmj0y.net/blog/activedirectory/roasting-as-reps/ – Blog post describing AS-REP roasting attack
  11. https://github.com/ropnop/kerbrute – Kerbrute Github repo
  12. https://www.whiteoaksecurity.com/blog/attacks-defenses-dumping-lsass-no-mimikatz/ – Blog post on dumping LSASS 
  13. https://blogs.technet.microsoft.com/askpfeplat/2016/04/18/the-importance-of-kb2871997-and-kb2928120-for-credential-protection/ – Microsoft article on disabling WDigest
  14. https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-manage – Windows Credential Guard information
  15. https://adsecurity.org/?p=2288 – Article on Group Policy Preferences Passwords
  16. https://www.microsoft.com/en-us/download/details.aspx?id=46899 – Local Administrator Password Solution (LAPS) info
  17. https://adsecurity.org/?p=2288 – Article on finding GPP Passwords in domain controller SYSVOL shares.
  18. https://attack.mitre.org/ – MITRE ATT&CK knowledge base