Active Directory DNS-Zonentransfer und unsichere dynamische Updates: Erkennung und Behebung

Active Directory DNS-Zonentransfer und unsichere dynamische Updates sind keine einzelne Einstellung — es handelt sich um drei getrennte, nah am Standard liegende Lücken in der Konfiguration AD-integrierter DNS-Zonen, die zusammen einem Angreifer erlauben, die DNS Ihrer Domain zu kartieren oder umzuschreiben, ohne jemals Kerberos oder LDAP anzufassen. Ein offen gelassener Active Directory DNS-Zonentransfer, eine unsichere Einstellung für dynamische Updates und eine Standard-ACL, die es Authenticated Users erlaubt, DNS-Einträge zu erstellen, sind drei getrennte Schwachstellen mit geringem Aufwand — und DNS-Sicherheit wird in den meisten AD-Umgebungen immer noch als Hintergrundrauschen behandelt statt als Angriffsfläche.

Keine der drei erfordert eine CVE oder einen neuen Exploit. Es sind nah am Standard liegende Einstellungen, die ab Werk „funktionsfähig" ausgeliefert werden und kaum noch einmal überprüft werden, sobald die Domain läuft. Miteinander verkettet erlauben sie einem nicht authentifizierten oder gering privilegierten Angreifer, das interne Netzwerk kostenlos zu kartieren, Einträge hineinzuinjizieren, oder beides.

Active Directory DNS-Zonentransfer und unsichere dynamische Updates: Die Angriffsfläche von AD-integriertem DNS

Wenn eine DNS-Zone Active-Directory-integriert ist, liegen ihre Einträge als dnsNode-Objekte innerhalb der Verzeichnispartition (DomainDnsZones oder ForestDnsZones) und nicht in einer flachen Zonendatei. Microsoft dokumentiert dieses Modell unter Active Directory-Integrated DNS Zones: Jeder beschreibbare Domain Controller mit der Rolle DNS-Server kann Updates für die Zone entgegennehmen, und diese Updates replizieren über die normale AD-Replikation statt über einen separaten Zonentransfer-Mechanismus zwischen Primary und Secondaries.

Dieses Design hat zwei Konsequenzen, die für die Sicherheit relevant sind, nicht nur für die Verfügbarkeit:

• Die Zone selbst besitzt eine ACL, genau wie eine OU oder eine Gruppe. Wer Schreibrechte auf dieser ACL besitzt, kann DNS-Einträge erstellen, ändern oder löschen — und die Standardrechte sind großzügiger, als die meisten Administratoren erwarten.
• Zwei unabhängige Legacy-Schutzmechanismen sichern nach wie vor den Rand der Zone: der klassische Zonentransfer (AXFR, zur Replikation an Nicht-AD-Secondaries oder für Reconnaissance) und dynamische Updates (der Mechanismus, mit dem Clients ihre Einträge selbst registrieren). Beide stammen aus der Zeit vor der AD-Integration, und beide sind standardmäßig eher permissiv.

Kerberos, LDAP und ACL-Missbrauch bekommen in der AD-Sicherheitsliteratur die meiste Aufmerksamkeit. DNS ist anders: Es gehört zur Kategorie Netzwerk, nicht zur Kategorie Identität, und wird auf Hardening-Checklisten häufig komplett ausgelassen — neben Nachbarn wie deaktivierter LDAP-Signierung oder schwachem LDAPS-TLS und einem Print Spooler, den niemand deaktiviert hat, behandelt in dieser Checkliste zur Netzwerk-Hygiene von Domain Controllern — genau deshalb kann eine Domain eine Kerberos- und ACL-Prüfung bestehen und trotzdem ihre gesamte Topologie über DNS preisgeben.

So funktioniert es: Drei verkettbare Fehlkonfigurationen

1. Uneingeschränkter Zonentransfer (AXFR)

AXFR ist das ursprüngliche DNS-Zonenreplikationsprotokoll und wurde nie mit Authentifizierung im Sinn entworfen. Wie CISAs Advisory zum Thema feststellt: Ist ein DNS-Server nicht explizit so konfiguriert, dass er Transfers einschränkt, kann jeder Client, der ihn über TCP/53 erreicht, eine vollständige Kopie der Zone anfordern — und erhalten. Für eine AD-integrierte Zone bedeutet das: jeder Hostname, jede IP-Adresse, jeder Dienst-Eintrag (einschließlich _ldap._tcp, _kerberos._tcp und weiterer SRV-Einträge, die Domain Controller fingerprinten) sowie jede vergessene Subdomain werden in einer einzigen Abfrage preisgegeben.

Set-DnsServerPrimaryZone bietet die Lösung direkt an: Der Parameter -SecureSecondaries steuert, ob Transfers an jeden Server, nur an die im Reiter Name Servers gelisteten Server oder nur an eine explizite IP-Liste erlaubt sind — NoTransfer ist die gehärtete Option, wenn überhaupt kein externer Secondary die Zone benötigt.

2. Unsichere dynamische Updates

Dynamische Updates erlauben es einem Client, seinen eigenen DNS-Eintrag zu registrieren oder zu aktualisieren, ohne dass ein Administrator das von Hand erledigt — normal und notwendig für domänenverbundene Arbeitsstationen. Die Sicherheitsgrenze liegt darin, welchen Update-Modus die Zone verwendet. Microsofts eigene Dokumentation zu Dynamic DNS Update in Windows and Windows Server und die Legacy-Anleitung Allow Only Secure Dynamic Updates sind eindeutig: Sichere dynamische Updates — nur auf AD-integrierten Zonen verfügbar — beschränken Updates auf Computer, die authentifiziert und domänenverbunden sind, durchgesetzt über die ACLs der Zone. Eine Zone, die auf Nonsecure and secure belassen wird, akzeptiert dagegen Updates von jedem, der den DNS-Dienst erreichen kann, authentifiziert oder nicht — das heißt, ein nicht authentifizierter Host im Netzwerksegment kann Einträge nach Belieben erstellen oder überschreiben.

3. Authenticated Users können direkt untergeordnete Einträge erstellen

Das ist der Punkt, den die meisten Teams sich noch nie direkt angesehen haben. Standardmäßig besitzt die Gruppe Authenticated Users Create All Child Objects auf der ACL der AD-integrierten Zone — bestätigt in Microsofts eigener Community-Anleitung zu DNS record creation permissions und in Offensive-Security-Research als Grundlage des ADIDNS-Missbrauchs (Active Directory-Integrated DNS) dokumentiert. NetSPIs Research zu Exploiting Active Directory-integrated DNS und ADIDNS Revisited legen den praktischen Effekt dar: Jedes Domain-Konto, einschließlich gering privilegierter Benutzer- und Computer-Konten, kann ohne erhöhte Rechte neue DNS-Einträge in der Zone registrieren. The Hacker Recipes' Seite zu ADIDNS-Poisoning und HackTricks' AD-DNS-Records-Referenz dokumentieren dies beide als etablierte, bekannte Technik — nicht als neuartigen Exploit. Das reiht sich in ein größeres Muster ein, das eine eigene Prüfung wert ist: Authenticated Users und Everyone, die still und heimlich in privilegierte Bereiche übermitgliedert werden über eine gesamte Domain hinweg, wovon die Standard-ACL der DNS-Zone eine spezifische, leicht zu übersehende Ausprägung ist.

Zwei Eintragstypen machen das unmittelbar gefährlich:

• Ein Eintrag für einen Namen, der noch nicht existiert — zum Beispiel die Registrierung des Hostnamens eines stillgelegten Servers oder eines Namens, den eine Legacy-Anwendung noch abfragt, und das anschließende Zeigen auf eine vom Angreifer kontrollierte IP.
• Ein Wildcard-Eintrag (*) — da eine Wildcard jede Abfrage beantwortet, für die es noch keinen expliziten Eintrag in der Zone gibt, wird ein Angreifer, der eine solche erstellt, zum Resolver letzter Instanz für die gesamte Zone. Elastics eigene vorgefertigte Erkennungsregel für Wildcard-ADIDNS-Poisoning beschreibt genau das: Ein Angreifer positioniert sich als Adversary-in-the-Middle, indem er beliebige nicht zugeordnete Namen auflöst, was Credential-Interception oder NTLM-Relay ermöglicht — im Ergebnis konzeptionell ähnlich zu LLMNR/NBNS-Spoofing, aber persistent und zonenweit statt auf einen einzelnen Broadcast beschränkt.

Die Global Query Block List (GQBL) ist Microsofts Gegenmaßnahme für das berüchtigtste Ziel dieser Technik — WPAD —, aber NetSPIs Folge-Research zeigt, dass NS-Einträge sie auf vollständig gepatchten Systemen weiterhin umgehen. Die GQBL ist damit eine Teilkontrolle, kein Ersatz für die Behebung der zugrunde liegenden ACL.

Die zwei begleitenden Lücken: DNSSEC und bereits vorhandene Wildcard-Einträge

DNSSEC_NOT_ENABLED und DNS_WILDCARD_RECORDS verstärken die drei oben genannten Fehlkonfigurationen, statt als eigenständige Angriffspfade für sich zu stehen:

• Ohne DNSSEC lässt sich die Herkunft eines Eintrags in keiner Weise kryptografisch verifizieren — eine vergiftete oder gefälschte Antwort ist von einer legitimen nicht zu unterscheiden. Microsoft behandelt Zone-Signing in Sign DNS Zones with DNSSEC on Windows Server und die zugrunde liegende Mechanik im DNSSEC-Überblick — bei einer AD-integrierten Zone replizieren die Zone-Signing-Keys automatisch über die normale AD-Replikation an die primären DNS-Server, was DNSSEC auf dieser Plattform vergleichsweise reibungsarm einsetzbar macht.
• Ein während eines Audits vorgefundener, bereits bestehender Wildcard-Eintrag — im Gegensatz zu einem, den ein Angreifer gerade erst erstellt hat — deutet meist darauf hin, dass die ACL der Zone bereits missbraucht wurde, oder dass ein Legacy-Anwendungsteam ihn ohne Security-Review angefordert hat. So oder so lohnt es sich, das als Incident-Response-Frage zu behandeln und nicht als reine Config-Bereinigung — bis das Gegenteil bewiesen ist.

Die Angriffskette

Schritt 1 — Recon per Zonentransfer

Ein Angreifer im Netzwerk (oder, falls die Zone von außen erreichbar ist, aus dem Internet) fordert vom DNS-Server einen Zonentransfer an:

dig axfr corp.local @10.10.10.10

Ist die Zone uneingeschränkt, enthält die Antwort den vollständigen Eintragsbestand: Domain Controller, SRV-Einträge für Kerberos/LDAP, jeden Workstation- und Server-Hostnamen sowie jede Subdomain, die nie öffentlich sein sollte.

Schritt 2 — Zielnamen auswählen und Eintrag registrieren

Mit nichts weiter als einem Standard-Domain-Konto registriert der Angreifer einen DNS-Eintrag für einen interessanten Namen — einen stillgelegten Host, einen Namen, den eine Legacy-Anwendung noch auflöst, oder eine Wildcard:

# Von jeder domänenverbundenen Maschine aus, als beliebiger authentifizierter Domain-Benutzer
Add-DnsServerResourceRecordA -ZoneName "corp.local" -Name "legacy-app" -IPv4Address 10.10.10.50 -ComputerName dc01.corp.local

Erlaubt die Zone weiterhin nonsecure dynamische Updates, benötigt dieser Schritt nicht einmal ein gültiges Domain-Credential — ein nicht authentifizierter Host im Segment kann das gleiche Update direkt über das Dynamic-Update-Protokoll durchdrücken.

Schritt 3 — Relay oder Interception

Sobald der Eintrag live ist, landet jeglicher für diesen Namen bestimmte Traffic stattdessen beim Host des Angreifers. Für SMB/HTTP-Namensauflösung ist das eine direkte Entsprechung zu LLMNR/NBNS-Spoofing — nur dass es persistent in DNS verankert ist, statt dass der Angreifer bei jeder Broadcast-Abfrage ein Rennen gewinnen muss — und es fließt direkt in NTLM-Relay-Tooling (Responder, ntlmrelayx) ein, genau wie eine vergiftete Broadcast-Antwort das täte. Die Technik ist noch zuverlässiger, wenn SMB-Signierung deaktiviert oder nicht erforderlich ist, da nichts verhindert, dass die weitergeleitete Sitzung als legitim akzeptiert wird.

Erkennung

Windows Server liefert zwei dedizierte DNS-Log-Kanäle, beide in Microsofts Dokumentation Enable DNS Logging and Diagnostics behandelt: DNS Audit-Events (standardmäßig aktiviert, geringer Overhead) decken administrative Aktionen ab — Zonenerstellung/-löschung, Eintragsänderungen und DNSSEC-Signing-Operationen — und DNS Analytical-Events (standardmäßig deaktiviert, höheres Volumen) decken den eigentlichen Query-/Response-/Dynamic-Update-Traffic ab. Beide liegen unter Applications and Services Logs > Microsoft > Windows > DNS-Server in der Ereignisanzeige.

Behebung

1. Zonentransfers einschränken. Beschränken Sie Transfers auf vertrauenswürdige Secondaries, oder deaktivieren Sie sie ganz, falls keine existieren:

   Set-DnsServerPrimaryZone -Name "corp.local" -SecureSecondaries TransferToSecureServers
   # oder, falls überhaupt kein externer Secondary diese Zone benötigt:
   Set-DnsServerPrimaryZone -Name "corp.local" -SecureSecondaries NoTransfer
   

2. Erzwingen Sie ausschließlich sichere dynamische Updates auf jeder AD-integrierten Zone. Nonsecure and secure sollte auf einer Produktionszone nicht vorkommen:

   Set-DnsServerPrimaryZone -Name "corp.local" -DynamicUpdate Secure
   

3. Verschärfen Sie die Standard-ACL der Zone. Das vollständige Entfernen der Create-Child-Rechte von Authenticated Users bricht die legitime Selbstregistrierung domänenverbundener Maschinen — das muss also eingegrenzt, nicht einfach entzogen werden. Microsofts eigene Anleitung zu dieser Berechtigung (siehe den Community-Thread zum Thema) bestätigt, dass der Standard großzügiger ist, als die meisten Teams annehmen. Prüfen Sie den Sicherheits-Reiter der Zone (oder dsacls gegen CN=<zone>,CN=MicrosoftDNS,DC=DomainDnsZones,DC=...) und grenzen Sie Create-Child-Rechte auf die Konten und Gruppen ein, die sich tatsächlich selbst registrieren müssen — typischerweise Domain-Computer über sichere dynamische Updates, nicht die gesamte Gruppe Authenticated Users bedingungslos.

4. Löschen Sie unerwartete Wildcard-Einträge, die beim Audit-Sweep gefunden werden, und behandeln Sie jeden, den Sie nicht selbst angelegt haben, als potenziellen Hinweis auf eine vorherige Kompromittierung — nicht nur als Aufräumarbeit.

5. Aktivieren Sie die Global Query Block List für klassische hochwertige Namensfallen (WPAD, ISATAP) als zusätzliche Defense-in-Depth-Schicht — dnscmd /config /enableglobalqueryblocklist 1 — denken Sie dabei an NetSPIs Erkenntnis, dass NS-Einträge sie weiterhin umgehen; das ist also eine Ergänzung zur ACL-Behebung, kein Ersatz dafür.

6. Aktivieren Sie DNSSEC auf AD-integrierten Zonen gemäß Microsofts Zone-Signing-Anleitung — die Signing-Keys replizieren automatisch über AD, sodass der Rollout auf den übrigen Domain-Controllern, die die Zone hosten, weitgehend hands-off verläuft, sobald der Key Master konfiguriert ist.

DNS ist nur ein Punkt auf einer viel längeren Liste — eine vollständige Übersicht, was bei Tier-0-Exposure, ACL-Missbrauch, Kerberos und Logging zuerst zu prüfen ist, finden Sie unter Active Directory Sicherheit auditieren: Die Checkliste.

Wie EtcSec das erkennt

Das Network-Kategorie-Audit von EtcSec prüft AD-integrierte DNS-Zonen direkt gegen diese fünf Lücken: DNS_ZONE_TRANSFER_UNRESTRICTED und DNS_DYNAMIC_UPDATE_INSECURE markieren Zonen, deren Transfer- oder Update-Einstellungen großzügiger als der sichere Standard sind, DNS_ZONE_AU_CREATE_CHILD markiert Zonen, in denen Authenticated Users weiterhin Create-Child-Rechte auf der Zonen-ACL besitzt, DNSSEC_NOT_ENABLED markiert unsignierte AD-integrierte Zonen, und DNS_WILDCARD_RECORDS markiert bestehende Wildcard-Einträge zur manuellen Prüfung.