Skip to main content

Enumerating Hosts and Identifying the Domain Controllers

Enumerating Live Hosts

Internal

ARP-Scan

Since this is an internal assessment, Kali is on the same LAN segment as the target(s) and ICMP is not needed to enumerate.

ARP is not going to be firewalled like ICMP pings.

# Assumes internal LAN is 10.10.10.0/24
sudo arp-scan -d 10.10.10.0/24

CrackMapExec

You can spray some unauthenticated SMB requests around a network to discover hosts. This will reveal the hosts' NetBIOS names, from which you may able to identify domain controllers and servers.

This will only work on hosts where SMB is enabled.

For example, a domain controller may be named something DC01 .

crackmapexec smb 10.10.10.0/24

External (Post-Compromise Enumeration)

PowerShell Ping Sweep on Target

Not the most reliable, as ICMP is disabled by default on Windows hosts.

# Assumes 10.10.10.0/24 network
1..254 | % { try { (ping -n 1 -w 1 10.10.10.$_ | select-string 'reply from').ToString().Split(' ')[2] -replace ':' } catch {} }

CrackMapExec

Again, only effective as long as SMB is enabled on the target.

# Via proxy host
proxychains -q crackmapexec smb 10.10.10.0/24

Nmap

Nmap on Target

# No port scan
# Will use ARP discovery on same subnet
nmap -n -sn 10.10.10.0/24

 

Through Proxy

# Via proxy host
# Full connect scans are slower, thus using top 1,000 ports initially
proxychains -q nmap -Pn -sT -T4 --top-ports 1000 10.10.10.0/24


Compile Targets in a List

For example, save the targets in a file called targets.txt

nano targets.txt
10.10.10.2
10.10.10.5
10.10.10.6
10.10.10.11

Identify SMB Signing Requirements

Good information to know when considering NetNTLM relay attacks

Internal

sudo nmap --script=smb2-security-mode -p445 -iL targets.txt -oN smb_signing_scan.txt

External

You could consider transferring statically compiled nmap binaries to the target and running the scans from the target, which would speed up the scans a good bit.

sudo proxychains -q nmap --script=smb2-security-mode -p445 -sT -iL targets.txt -oN smb_signing_scan.txt

Identifying the Domain Controllers

It's very obvious when you're looking at a domain controller due to its running services; something akin to this:

PORT     STATE SERVICE
53/tcp   open  domain
88/tcp   open  kerberos-sec
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
389/tcp  open  ldap
445/tcp  open  microsoft-ds
464/tcp  open  kpasswd5
593/tcp  open  http-rpc-epmap
636/tcp  open  ldapssl
3268/tcp open  globalcatLDAP
3269/tcp open  globalcatLDAPssl

Internal

sudo nmap -Pn -p- -T4 -A -oN nmap-scan.txt -iL targets.txt

External

You could consider transferring statically compiled nmap binaries to the target and running the scans from the target, which would speed up the scans a good bit.

 

#  -sT             : Use TCP full connect flag due to scanning through a proxy
# --top-ports 1000 : Top 1,000 ports due to slow speeds with TCP full connect scanning 
sudo proxychains -q nmap -Pn -sT --top-ports 1000 -T4 -A -oN nmap-scan.txt -iL targets.txt

 

Identify the Root Domain

LDAP DSE

The root DSE is the entry at the top of the LDAP server directory information tree. All the namingcontexts (suffixes) in the LDAP server are directly below the root DSE. The root DSE contains information about the LDAP server, including the namingcontexts that are configured and the capabilities of the server.

-- https://www.ibm.com/docs/en/zos/2.1.0?topic=considerations-root-dse

Internal

# Assumes 10.10.10.2 is the DC based on port enumeration
sudo nmap -Pn -T4 -p 389,636 --script ldap-rootdse 10.10.10.2 | grep dnsHostName | sort -u

External

# Via Proxy Host
# Assumes 10.10.10.2 is the DC based on port enumeration
sudo proxychains -q nmap -Pn -T4 -sT -p 389,636 --script ldap-rootdse 10.10.10.2 | grep dnsHostName | sort -u

Add DC to Hosts File

echo '10.10.10.2        dc01.ad.lab' | sudo tee -a /etc/hosts
Back to top