Transfert de Zone DNS Active Directory Mise à Jour Dynamique Non Sécurisée : Détection et Remédiation

Transfert de zone DNS Active Directory mise à jour dynamique non sécurisée : ce n'est pas un réglage unique — ce sont trois failles distinctes, proches des paramètres par défaut, dans la configuration des zones DNS intégrées à Active Directory, qui permettent ensemble à un attaquant de cartographier ou de réécrire le DNS de votre domaine sans jamais toucher à Kerberos ni à LDAP. Un transfert de zone DNS Active Directory laissé ouvert, un paramètre de mise à jour dynamique non sécurisé et une ACL par défaut qui laisse le groupe Authenticated Users créer des enregistrements DNS sont trois faiblesses distinctes, faciles à exploiter — et la sécurité DNS, dans la plupart des environnements AD, les traite encore comme un bruit de fond plutôt que comme une surface d'attaque.

Aucune des trois ne nécessite de CVE ni d'exploit récent. Ce sont des paramètres proches des valeurs par défaut, livrés « fonctionnels » dès l'installation et rarement revus une fois le domaine en production. Chaînées entre elles, elles permettent à un attaquant non authentifié ou à faibles privilèges de cartographier gratuitement le réseau interne, d'y injecter des enregistrements, ou les deux.

Transfert de Zone DNS Active Directory Mise à Jour Dynamique Non Sécurisée : la surface d'attaque du DNS intégré à AD

Lorsqu'une zone DNS est intégrée à Active Directory, ses enregistrements vivent sous forme d'objets dnsNode dans la partition d'annuaire (DomainDnsZones ou ForestDnsZones), et non dans un fichier de zone plat. Microsoft documente ce modèle dans Active Directory-Integrated DNS Zones : chaque contrôleur de domaine accessible en écriture exécutant le rôle DNS Server peut accepter des mises à jour de la zone, et ces mises à jour se répliquent via la réplication AD normale plutôt que par un mécanisme de transfert de zone distinct entre serveur primaire et secondaires.

Cette conception a deux conséquences importantes pour la sécurité, pas seulement pour la disponibilité :

• La zone elle-même possède une ACL, exactement comme une UO ou un groupe. Quiconque détient des droits d'écriture sur cette ACL peut créer, modifier ou supprimer des enregistrements DNS — et les droits par défaut sont plus larges que ce que la plupart des administrateurs imaginent.
• Deux protections historiques indépendantes gardent encore le périmètre de la zone : le transfert de zone classique (AXFR, utilisé pour répliquer vers des secondaires non-AD ou pour la reconnaissance) et la mise à jour dynamique (le mécanisme que les clients utilisent pour s'auto-enregistrer). Les deux sont antérieures à l'intégration AD et toutes deux ont par défaut un comportement permissif.

Kerberos, LDAP et l'abus d'ACL captent l'essentiel de l'attention dans la littérature sur la sécurité AD. Le DNS est différent : il relève de la catégorie Réseau, pas de la catégorie Identité, et il est fréquemment absent des checklists de durcissement — aux côtés de voisins comme la signature LDAP laissée désactivée ou un TLS LDAPS faible et un Spouleur d'Impression que personne n'a désactivé, traités dans cette checklist d'hygiène réseau du contrôleur de domaine — ce qui explique précisément pourquoi un domaine peut réussir une revue Kerberos et ACL tout en laissant fuiter toute sa topologie via le DNS.

Comment ça fonctionne : trois mauvaises configurations chaînables

1. Transfert de zone non restreint (AXFR)

AXFR est le protocole originel de réplication de zone DNS, et il n'a jamais été conçu avec l'authentification à l'esprit. Comme l'indique l'avis de la CISA sur le sujet, si un serveur DNS n'est pas explicitement configuré pour restreindre les transferts, n'importe quel client capable de l'atteindre sur TCP/53 peut demander — et recevoir — une copie complète de la zone. Pour une zone intégrée à AD, cela signifie que chaque nom d'hôte, adresse IP, enregistrement de service (y compris _ldap._tcp, _kerberos._tcp et d'autres enregistrements SRV qui identifient les contrôleurs de domaine), et tout sous-domaine oublié, sont livrés en une seule requête.

Set-DnsServerPrimaryZone expose directement la correction : le paramètre -SecureSecondaries contrôle si les transferts sont autorisés vers n'importe quel serveur, uniquement vers les serveurs listés dans l'onglet Name Servers, ou uniquement vers une liste d'IP explicite — NoTransfer est l'option durcie lorsqu'aucun secondaire externe n'a besoin de la zone.

2. Mise à jour dynamique non sécurisée

La mise à jour dynamique permet à un client d'enregistrer ou de mettre à jour son propre enregistrement DNS sans intervention manuelle d'un administrateur — un comportement normal et nécessaire pour les postes joints au domaine. La frontière de sécurité tient au mode de mise à jour utilisé par la zone. La documentation de Microsoft sur Dynamic DNS Update in Windows and Windows Server et le guide historique Allow Only Secure Dynamic Updates sont explicites : la mise à jour dynamique sécurisée — disponible uniquement sur les zones intégrées à AD — restreint les mises à jour aux ordinateurs authentifiés et joints au domaine, appliquée via les ACL de la zone. Une zone laissée en Nonsecure and secure, à l'inverse, accepte les mises à jour de quiconque peut atteindre le service DNS, authentifié ou non — ce qui signifie qu'un hôte non authentifié sur le segment réseau peut créer ou écraser des enregistrements à volonté.

3. Authenticated Users peut carrément créer des enregistrements enfants

C'est celle que la plupart des équipes n'ont jamais examinée directement. Par défaut, le groupe Authenticated Users détient le droit Create All Child Objects sur l'ACL de la zone intégrée à AD — confirmé par la documentation communautaire de Microsoft elle-même sur les permissions de création d'enregistrements DNS et documenté dans la recherche offensive comme le fondement de l'abus ADIDNS (Active Directory-Integrated DNS). Les recherches de NetSPI sur l'exploitation du DNS intégré à Active Directory et ADIDNS Revisited exposent l'effet pratique : tout compte de domaine, y compris les utilisateurs à faibles privilèges et les comptes d'ordinateur, peut enregistrer de nouveaux enregistrements DNS dans la zone sans le moindre droit élevé. La page ADIDNS poisoning de The Hacker Recipes et la référence AD DNS Records de HackTricks documentent toutes deux cette technique comme établie et bien connue — pas comme un exploit inédit. Elle s'inscrit dans un schéma plus large qui mérite un audit à part entière : Authenticated Users et Everyone silencieusement sur-membrés dans des périmètres privilégiés à travers un domaine, dont l'ACL par défaut de la zone DNS n'est qu'une instance particulière, facile à manquer.

Deux types d'enregistrements rendent cela immédiatement dangereux :

• Un enregistrement pour un nom qui n'existe pas encore — par exemple enregistrer le nom d'hôte d'un serveur mis hors service ou un nom qu'une application legacy interroge toujours, puis le pointer vers une IP contrôlée par l'attaquant.
• Un enregistrement générique (*) — puisqu'un enregistrement générique répond à toute requête qui n'a pas déjà d'enregistrement explicite dans la zone, un attaquant qui en crée un devient le résolveur de dernier recours pour la zone entière. La règle de détection prête à l'emploi d'Elastic pour l'empoisonnement ADIDNS par wildcard décrit exactement cela : un attaquant se positionne en adversaire-au-milieu en résolvant des noms arbitraires non appariés, ce qui permet l'interception d'identifiants ou le relais NTLM — un résultat conceptuellement proche du spoofing LLMNR/NBNS, mais persistant et couvrant toute la zone au lieu d'une simple diffusion ponctuelle.

La Global Query Block List (GQBL) est la mitigation de Microsoft pour la cible la plus tristement célèbre de cette technique — WPAD — mais les recherches complémentaires de NetSPI notent que les enregistrements NS la contournent encore sur des systèmes entièrement patchés, ce qui fait de la GQBL un contrôle partiel, pas un substitut à la correction de l'ACL sous-jacente.

Les deux failles complémentaires : DNSSEC absent et enregistrements génériques déjà présents

DNSSEC_NOT_ENABLED et DNS_WILDCARD_RECORDS aggravent les trois mauvaises configurations ci-dessus plutôt que de constituer des chemins d'attaque indépendants :

• Sans DNSSEC, rien dans l'origine d'un enregistrement n'est vérifiable cryptographiquement — une réponse empoisonnée ou usurpée ne peut pas être distinguée d'une réponse légitime. Microsoft traite de la signature de zone dans Sign DNS Zones with DNSSEC on Windows Server et des mécanismes sous-jacents dans le DNSSEC overview — pour une zone intégrée à AD, les clés de signature de zone se répliquent automatiquement vers les serveurs DNS primaires via la réplication AD normale, ce qui rend DNSSEC comparativement peu contraignant à déployer sur cette plateforme spécifiquement.
• Un enregistrement générique déjà présent, constaté lors d'un audit — par opposition à un enregistrement qu'un attaquant vient de créer — indique généralement que l'ACL de la zone a déjà été abusée, ou qu'une équipe applicative legacy l'a demandé sans revue de sécurité. Dans les deux cas, il vaut mieux le traiter comme une question de réponse à incident, pas comme un simple item de nettoyage de configuration, jusqu'à preuve du contraire.

La chaîne d'attaque

Étape 1 — Reconnaissance via le transfert de zone

Un attaquant présent sur le réseau (ou, si la zone est joignable depuis l'extérieur, depuis internet) demande un transfert de zone auprès du serveur DNS :

dig axfr corp.local @10.10.10.10

Si la zone n'est pas restreinte, la réponse contient l'intégralité des enregistrements : contrôleurs de domaine, enregistrements SRV pour Kerberos/LDAP, tous les noms d'hôte des postes et serveurs, et tout sous-domaine qui n'était jamais censé être public.

Étape 2 — Choisir un nom cible et enregistrer un enregistrement

Avec rien de plus qu'un compte de domaine standard, l'attaquant enregistre un enregistrement DNS pour un nom d'intérêt — un hôte mis hors service, un nom qu'une application legacy résout encore, ou un générique :

# Depuis n'importe quelle machine jointe au domaine, en tant qu'utilisateur de domaine authentifié
Add-DnsServerResourceRecordA -ZoneName "corp.local" -Name "legacy-app" -IPv4Address 10.10.10.50 -ComputerName dc01.corp.local

Si la zone autorise encore la mise à jour dynamique non sécurisée, cette étape ne nécessite même pas d'identifiant de domaine valide — un hôte non authentifié sur le segment peut pousser la même mise à jour directement via le protocole de mise à jour dynamique.

Étape 3 — Relayer ou intercepter

Une fois l'enregistrement actif, tout trafic destiné à ce nom atterrit à la place sur l'hôte de l'attaquant. Pour la résolution de noms SMB/HTTP, c'est un équivalent direct du spoofing LLMNR/NBNS — sauf qu'il persiste dans le DNS au lieu d'exiger que l'attaquant gagne une course sur chaque requête broadcast — et il alimente directement l'outillage de relais NTLM (Responder, ntlmrelayx) de la même manière qu'une réponse broadcast empoisonnée le ferait. La technique est encore plus fiable quand la signature SMB est désactivée ou non exigée, puisque rien n'empêche la session relayée d'être acceptée comme légitime.

Détection

Windows Server livre deux canaux de journalisation DNS dédiés, tous deux couverts dans la documentation Microsoft Enable DNS Logging and Diagnostics : les événements DNS Audit (activés par défaut, faible surcharge) couvrant les actions administratives — création/suppression de zone, modifications d'enregistrements et opérations de signature DNSSEC — et les événements DNS Analytical (désactivés par défaut, volume plus élevé) couvrant le trafic requête/réponse/mise à jour dynamique lui-même. Les deux se trouvent sous Applications and Services Logs > Microsoft > Windows > DNS-Server dans l'Observateur d'événements.

Remédiation

1. Restreindre les transferts de zone. Limitez les transferts aux secondaires de confiance uniquement, ou désactivez-les entièrement si aucun n'existe :

   Set-DnsServerPrimaryZone -Name "corp.local" -SecureSecondaries TransferToSecureServers
   # ou, si aucun secondaire externe n'a besoin de cette zone :
   Set-DnsServerPrimaryZone -Name "corp.local" -SecureSecondaries NoTransfer
   

2. Forcer la mise à jour dynamique sécurisée uniquement sur chaque zone intégrée à AD. Nonsecure and secure ne devrait apparaître sur aucune zone de production :

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

3. Durcir l'ACL par défaut de la zone. Retirer entièrement le droit create-child d'Authenticated Users cassera l'auto-enregistrement légitime des machines jointes au domaine — cela doit donc être scopé, pas simplement révoqué. La documentation de Microsoft sur cette permission (voir le fil de discussion communautaire sur le sujet) confirme que le défaut est plus large que ce que la plupart des équipes réalisent. Passez en revue l'onglet sécurité de la zone (ou dsacls sur CN=<zone>,CN=MicrosoftDNS,DC=DomainDnsZones,DC=...) et scopez les droits create-child aux comptes et groupes qui ont réellement besoin de s'auto-enregistrer — typiquement les ordinateurs du domaine via la mise à jour dynamique sécurisée, et non le groupe Authenticated Users complet sans condition.

4. Supprimez les enregistrements génériques inattendus trouvés lors du balayage d'audit, et traitez tout enregistrement que vous n'avez pas provisionné comme un indicateur potentiel de compromission antérieure, pas comme un simple nettoyage.

5. Activez la Global Query Block List pour les pièges de noms classiques à forte valeur (WPAD, ISATAP) en tant que couche de défense en profondeur — dnscmd /config /enableglobalqueryblocklist 1 — en gardant à l'esprit la constatation de NetSPI que les enregistrements NS la contournent encore, ce qui en fait un complément à la correction de l'ACL, pas un remplacement.

6. Activez DNSSEC sur les zones intégrées à AD selon le guide de signature de zone de Microsoft — les clés de signature se répliquent automatiquement via AD, donc une fois le Key Master configuré, le déploiement est largement automatique sur le reste des contrôleurs de domaine hébergeant la zone.

Le DNS n'est qu'un point sur une liste bien plus longue — pour un tour d'horizon complet de ce qu'il faut vérifier en premier concernant l'exposition Tier 0, l'abus d'ACL, Kerberos et la journalisation, voir Audit de sécurité Active Directory : quoi vérifier d'abord.

Comment EtcSec détecte cela

L'audit de catégorie Réseau d'EtcSec vérifie directement les zones DNS intégrées à AD contre ces cinq failles : DNS_ZONE_TRANSFER_UNRESTRICTED et DNS_DYNAMIC_UPDATE_INSECURE signalent les zones dont les paramètres de transfert ou de mise à jour sont plus permissifs que le défaut sécurisé, DNS_ZONE_AU_CREATE_CHILD signale les zones où Authenticated Users détient encore les droits create-child sur l'ACL de la zone, DNSSEC_NOT_ENABLED signale les zones intégrées à AD non signées, et DNS_WILDCARD_RECORDS signale les enregistrements génériques existants pour revue manuelle.