0. Overview
Many organizational networks rely on Active Directory (AD) to streamline administrative tasks and enhance efficiency. However, in its default configuration, AD introduces “features” that attackers could exploit. The SMB (Server Message Block) protocols stand out as particularly vulnerable to relay attacks. For companies that haven’t undergone a penetration test, grasping these vulnerabilities is essential. In this article, we delve into SMB relay attacks, uncovering their mechanics, potential outcomes, and mitigation methods.
1. What is SMB?
Server Message Block (SMB) serves as a network file sharing protocol. It empowers computer applications to read, write to files, and request server programs’ services in a network. Widely adopted in Windows environments, SMB provides shared access to resources like files and printers. However, when paired with NTLM (NT LAN Manager) authentication and left unsecured, it becomes a prime target for relay attacks. In essence, attackers manipulate the protocol’s inherent trust in network users.
2. How is SMB Vulnerable to Relay Attacks?
The core vulnerability of SMB to relay attacks stems from its authentication mechanism, especially when using NTLM. When a user seeks access to a shared resource, SMB initiates a connection and authenticates the Active Directory user. Attackers can seize this authentication attempt, relaying it to a different server to impersonate the user. The lack of SMB’s validation (via SMB signing) of the authentication request’s origin or destination allows attackers to exploit it for unauthorized access.
Requirements for an attack:
- The target must not enforce or enable SMB signing.
- For valuable outcomes, the relayed user’s credentials must have local admin status on the machine.
- You cannot relay credentials to the same machine they were captured from.
- Note: By default, all Windows workstations (non-servers) have SMB signing either disabled or not enforced.
- Another note: Since these credentials undergo relaying, password strength becomes irrelevant.
3. SMB Relay Attack Setup
In our hypothetical attack scenario:
- Frank Castle (fcastle) from the MARVEL.local domain has local administrator privileges on two machines.
- As workstations, these machines don’t enforce SMB signing by default, paving the way for a relay attack.
Attack sequence:
- An attacker identifies the IPs of vulnerable workstations.
- The attacker initiates the necessary tools for the relay attack.
- Next, an event occurs (such as LLMNR Poisoning) that leads to a user hash being intercepted behind the scenes.
- Finally, the attacker relays the intercepted credentials, gaining unauthorized access to the workstation via Active Directory.
4. Exploiting SMB (AKA SMB Relay Attacks)
During an SMB relay attack, attackers capture a valid authentication session and then relay it, gaining access. Instead of cracking hashes, attackers can relay these hashes for unauthorized access to the workstation via Active Directory.
Step 1: The Attacker Identifies Workstations without SMB Signing Enforced
nmap –script=smb2-security-mode.nse -p445 10.0.0.0/24 |
The above image shows a workstation without SMB signing enforced. As a reminder, this is a default setting for all Windows workstations.
We will gather all workstations without SMB signing enforced and place them into a file called targets.txt.
Step 2: The Attacker Sets Up Their Attack
We will utilize Responder and ntlmrelayx for our attack. First, we must properly configure Responder to disable SMB and HTTP responses as these will be forwarded to ntlmrelayx (and eventually relayed).
sudo mousepad /etc/responder/Responder.conf |
Next, we will launch Responder.
sudo responder –I eth0 -dwP |
Finally, we will launch ntlmrelayx and wait for an event to occur.
sudo ntlmrelayx.py –tf targets.txt –smb2support |
Step 3: An Event Occurs and Credentials Get Relayed
Behind the scenes, an event (such as LLMNR poisoning) has occurred. Responder will capture this event, pass it to ntlmrelayx, which will relay the credentials to the targets in our targets file.
Below is what a successful relay looks like.
As you can see here, the local SAM hashes are dumped. These hashes can now be taken offline and cracked. Even better, we can utilize pass-the-hash attacks to gain access to machines without ever cracking the password.
Note: we have not compromised a domain account, nor did we need to. Again, the beauty of relay attacks is that you do not need to ever know the password to pull off the attack. So much for a good password policy!
Other SMB Relay Exploits
Beyond dumping out the local SAM hashes, we can have other fun with SMB relay attacks. For example, we can gain shell access on a machine:
sudo ntlmrelayx.py –tf targets.txt –smb2support –i |
nc 127.0.0.1 11000 |
We can also run commands remotely. In this example, we’ll simply run “whoami” during the relay attack.
sudo ntlmrelayx –tf targets.txt –smb2support –c “whoami” |
4. How Can SMB Relay Attacks Be Mitigated?
Main Defense – Enable SMB Signing on All Devices
Pro: This completely stops the attack.
Con: Requiring SMB signing can cause performance issues with file copies and legacy devices using SMBv1.
To configure Active Directory to enforce SMB signing, enable the following policies in Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options:
On the client side:
- Microsoft network client: Digitally sign communications (always)
- Microsoft network client: Digitally sign communications (if server agrees)
On the server side:
- Microsoft network server: Digitally sign communications (always)
- Microsoft network server: Digitally sign communications (if client agrees)
Confirming Our Mitigation
We can confirm that we have mitigated SMB relay attacks by running the following command in cmd.exe and receiving ‘0x1’ for both items return:
reg query HKLM\System\CurrentControlSet\Services\LanManServer\Parameters | findstr /I securitysignature |
Alternate Defenses
If a company cannot enforce SMB signing on all devices, the best course of action is to:
- Utilize account tiering. For example, if Bob is a Domain Admin, Bob will have two accounts: “bob” and “bob-da”. This will limit domain admins to specific tasks (e.g. only log onto servers with the need for a domain admin).
- Local admin restriction. Limiting local admins will make relay attacks much more difficult.
These actions are considered best practices and should be implemented, regardless of the decision to enforce, or not enforce, SMB signing.
Penetration Testing
By simulating potential attack vectors like SMB relay attacks, penetration testing helps organizations spot and understand vulnerabilities. The insights from these tests pave the way for remediating weaknesses, ensuring a robust defense against cyber threats.
Conclusion
As networking and cybersecurity evolve, grasping protocols like SMB becomes critical. While SMB facilitates network communication and file sharing, its vulnerabilities might open doors for attackers. The risk of relay and man-in-the-middle attacks looms especially when using SMB with NTLM authentication. Prioritizing security over mere user convenience is crucial. By disabling risk-prone configurations in Active Directory, updating patches, and fostering a cybersecurity-centric culture, organizations can maintain network safety in today’s digital era.
If you are looking to learn more about SMB relay attacks and other ways that Active Directory is vulnerable to attackers, join our one day live training sessions! You will learn more about common exploits and how to defend against them to protect your network. Our next class is Friday, September 27th- save your spot today!
Heath Adams TCM