Haxoris Wiki

Internal DNS Zone Transfer And Enumeration

How Internal DNS Zone Transfer And Enumeration works

Internal DNS zone transfer is a name server handing an unauthorised client the full contents of a zone in one query. AXFR is a legitimate replication mechanism between a primary and its secondaries, but when the transfer ACL is empty every workstation on a user VLAN can pull every A, CNAME, SRV, TXT and PTR record the internal domain holds. The same estate usually leaks in parallel through SNMP agents on community string public, SMB null sessions on file servers and appliances, and anonymous LDAP binds on domain controllers.

A full forward zone plus its reverse is a pre-built target map, and internal naming does the attacker’s classification for free: sqlprod01, dc02, bkup-veeam, vcenter and hr-fileserver announce role, owner and value before a single port is touched. It is easy to miss because it is silent and read-only. Nothing breaks, no account locks out, and the transfer looks like ordinary replication in the logs if anyone reads them. The classifier that catches SRV records for Kerberos and LDAP still points back at the domain controllers, but the enumeration channel itself is the leak, not the AD service behind it.

Internal DNS Zone Transfer And Enumeration in practice

Establish which servers are authoritative and enumerate the zones

Find the authoritative servers first, and enumerate reverse zones as well as forward, because PTR records leak the addressing plan even when a forward transfer is refused.

# Authoritative name servers for the internal zone
dig +short NS lab.internal @10.10.0.10

# Attempt a forward transfer from a user-VLAN host you are testing from
dig AXFR lab.internal @10.10.0.10

# Reverse zone: PTR records map the whole /16 back to hostnames
dig AXFR 10.10.10.in-addr.arpa @10.10.0.10

A returned record set instead of ”; Transfer failed.” is the finding. Save it: it is both the evidence and the target list for the rest of the engagement.

Read roles straight out of the zone dump

The value is in the parse, not the pull. Bucket the records so the report shows what the transfer actually exposed.

Record pattern in the dump        What it hands the attacker
--------------------------------  ------------------------------------------
_ldap._tcp / _kerberos._tcp SRV   Domain controllers and the AD domain name
sqlprod01, ora-fin01 A            Database tier, named by application
vcenter, esx0[1-8] A              Virtualisation management plane
bkup-veeam, veeam-repo A          Backup infrastructure, a ransomware target
citrix-gw, vpn A                  Remote access edge
TXT records                       SPF, verification tokens, sometimes notes
PTR sweep of 10.10.20.0/24        The server VLAN, host by host

No scanning was required to produce this. The hostnames did the segmentation of the estate for you.

Test the parallel enumeration channels

DNS is rarely the only open channel. Check SNMP, SMB null sessions and anonymous LDAP from the same position, because one of them usually answers.

# SNMP v1/v2c with default community: full interface and process tables
snmpwalk -v2c -c public 10.10.20.5 1.3.6.1.2.1.1
onesixtyone -c /opt/audit/communities.txt 10.10.20.0/24

# SMB null session: shares and users with no credential
smbclient -L //fs01.lab.internal -N
rpcclient -U "" -N fs01.lab.internal -c "enumdomusers;querydominfo"

# Anonymous LDAP bind against a domain controller
ldapsearch -x -H ldap://dc01.lab.internal -b "DC=lab,DC=internal" \
  -s sub "(objectClass=user)" sAMAccountName description | grep -i -E 'password|temp|svc'

A populated description field is its own leak: administrators park passwords and account purpose there.

Confirm the fix narrows the transfer to named secondaries

After remediation, prove the ACL both refuses an unauthorised host and still serves the real secondaries, so replication is not broken.

# BIND-style check plus the Windows DNS view of who may transfer
Get-DnsServerZone -Name lab.internal |
  Select-Object ZoneName, ZoneType, SecureSecondaries, SecondaryServers

# Expected after fix:
#   SecureSecondaries : TransferToSecureServers
#   SecondaryServers  : {10.10.0.11}   (the listed secondary only)

Re-run dig AXFR from the user VLAN: “Transfer failed.” from the test host and a successful transfer from the listed secondary together confirm the control.

How to fix and prevent Internal DNS Zone Transfer And Enumeration

  1. Restrict transfers to listed secondaries
    • Set allow-transfer to the secondary addresses on BIND, or SecureSecondaries to TransferToSecureServers with an explicit SecondaryServers list on Windows DNS, on forward and reverse zones alike.
    • Default-deny: a zone with no configured secondaries should refuse AXFR from everyone.
  2. Disable the parallel enumeration channels
    • Move SNMP to v3 authPriv and remove public and private, disable SMB null sessions with RestrictAnonymous and RestrictNullSessAccess, and turn off anonymous LDAP binds on the domain controllers.
  3. Stop parking data in records and descriptions
    • Keep credentials and free-text notes out of TXT records and account description fields; those travel in every dump and bind.
  4. Log and alert on transfer requests
    • Enable DNS query or analytic logging and alert on any AXFR or IXFR from a source that is not a listed secondary; the request itself is the incident.
  5. Split internal and external resolution
    • Serve internal zones only from internal resolvers, so an external query can never reach or transfer the internal name space in the first place.

Last updated

References