Trasferimento di Zona DNS Active Directory Aggiornamento Dinamico Non Sicuro: Rilevamento e Remediation

Trasferimento di zona DNS Active Directory aggiornamento dinamico non sicuro: non è un'unica impostazione — sono tre falle distinte, vicine ai valori predefiniti, nel modo in cui vengono configurate le zone DNS integrate in AD, e insieme permettono a un attaccante di mappare o riscrivere il DNS del dominio senza mai toccare Kerberos o LDAP. Un trasferimento di zona DNS Active Directory lasciato aperto, un'impostazione di aggiornamento dinamico non sicura e un'ACL predefinita che consente al gruppo Authenticated Users di creare record DNS sono tre debolezze distinte e a basso sforzo — e la sicurezza DNS, nella maggior parte degli ambienti AD, le tratta ancora come rumore di fondo piuttosto che come superficie di attacco.

Nessuna delle tre richiede una CVE o un exploit recente. Sono impostazioni vicine al predefinito, consegnate «funzionanti» di fabbrica e raramente riviste una volta che il dominio è in produzione. Concatenate tra loro, permettono a un attaccante non autenticato o a basso privilegio di mappare gratuitamente la rete interna, di iniettarvi record, o entrambe le cose.

Trasferimento di Zona DNS Active Directory Aggiornamento Dinamico Non Sicuro: la superficie di attacco del DNS integrato in AD

Quando una zona DNS è integrata in Active Directory, i suoi record vivono come oggetti dnsNode all'interno della partizione di directory (DomainDnsZones o ForestDnsZones), non in un file di zona piatto. Microsoft documenta questo modello in Active Directory-Integrated DNS Zones: ogni domain controller scrivibile che esegue il ruolo DNS Server può accettare aggiornamenti alla zona, e questi aggiornamenti si replicano tramite la normale replica AD anziché un meccanismo di trasferimento di zona separato tra primario e secondari.

Questo design ha due conseguenze che contano per la sicurezza, non solo per la disponibilità:

• La zona stessa ha un'ACL, esattamente come un'OU o un gruppo. Chi detiene diritti di scrittura su quell'ACL può creare, modificare o eliminare record DNS — e i diritti predefiniti sono più ampi di quanto la maggior parte degli amministratori si aspetti.
• Due protezioni storiche indipendenti presidiano ancora il perimetro della zona: il trasferimento di zona classico (AXFR, per replicare verso secondari non-AD o per ricognizione) e l'aggiornamento dinamico (il meccanismo che i client usano per auto-registrarsi). Entrambe precedono l'integrazione AD ed entrambe tendono per default a essere permissive.

Kerberos, LDAP e l'abuso di ACL catturano la maggior parte dell'attenzione nella letteratura sulla sicurezza AD. Il DNS è diverso: appartiene alla categoria Rete, non alla categoria Identità, ed è comunemente assente dalle checklist di hardening — accanto a vicini come la firma LDAP lasciata disabilitata o un TLS LDAPS debole e uno Spooler di Stampa che nessuno ha disabilitato, trattati in questa checklist di igiene di rete del domain controller — il che spiega esattamente perché un dominio può superare una revisione Kerberos e ACL e comunque far trapelare l'intera topologia tramite il DNS.

Come funziona: tre configurazioni errate concatenabili

1. Trasferimento di zona senza restrizioni (AXFR)

AXFR è il protocollo originale di replica di zona DNS e non è mai stato progettato pensando all'autenticazione. Come afferma l'avviso CISA sul tema, se un server DNS non è esplicitamente configurato per limitare i trasferimenti, qualsiasi client che possa raggiungerlo su TCP/53 può richiedere — e ricevere — una copia completa della zona. Per una zona integrata in AD questo significa che ogni hostname, indirizzo IP, record di servizio (inclusi _ldap._tcp, _kerberos._tcp e altri record SRV che identificano i domain controller), e qualsiasi sottodominio dimenticato, vengono consegnati in un'unica query.

Set-DnsServerPrimaryZone espone direttamente la correzione: il parametro -SecureSecondaries controlla se i trasferimenti sono consentiti verso qualsiasi server, solo verso i server elencati nella scheda Name Servers, o solo verso un elenco IP esplicito — NoTransfer è l'opzione irrigidita quando nessun secondario esterno ha bisogno della zona.

2. Aggiornamento dinamico non sicuro

L'aggiornamento dinamico permette a un client di registrare o aggiornare il proprio record DNS senza che un amministratore lo faccia manualmente — normale e necessario per le workstation unite al dominio. Il confine di sicurezza è quale modalità di aggiornamento usa la zona. La documentazione stessa di Microsoft su Dynamic DNS Update in Windows and Windows Server e la guida storica Allow Only Secure Dynamic Updates sono esplicite: l'aggiornamento dinamico sicuro — disponibile solo sulle zone integrate in AD — limita gli aggiornamenti ai computer autenticati e uniti al dominio, applicato tramite le ACL della zona. Una zona lasciata su Nonsecure and secure, al contrario, accetta aggiornamenti da chiunque possa raggiungere il servizio DNS, autenticato o meno — il che significa che un host non autenticato sul segmento di rete può creare o sovrascrivere record a piacimento.

3. Authenticated Users può creare direttamente record figli

Questa è quella che la maggior parte dei team non ha mai esaminato direttamente. Per default, il gruppo Authenticated Users detiene il diritto Create All Child Objects sull'ACL della zona integrata in AD — confermato nella guida della community di Microsoft su permessi di creazione dei record DNS e documentato nella ricerca offensive come fondamento dell'abuso ADIDNS (Active Directory-Integrated DNS). La ricerca di NetSPI su lo sfruttamento del DNS integrato in Active Directory e ADIDNS Revisited espongono l'effetto pratico: ogni account di dominio, inclusi utenti a basso privilegio e account computer, può registrare nuovi record DNS nella zona senza alcun diritto elevato. La pagina ADIDNS poisoning di The Hacker Recipes e il riferimento AD DNS Records di HackTricks documentano entrambi questa come una tecnica consolidata e ben nota — non un exploit inedito. Si inserisce in uno schema più ampio che merita un audit a sé stante: Authenticated Users ed Everyone silenziosamente sovra-inclusi in ambiti privilegiati in tutto un dominio, di cui l'ACL predefinita della zona DNS è un'istanza specifica e facile da trascurare.

Due tipi di record rendono questo immediatamente pericoloso:

• Un record per un nome che non esiste ancora — ad esempio registrare l'hostname di un server dismesso o un nome che un'applicazione legacy interroga ancora, per poi puntarlo verso un IP controllato dall'attaccante.
• Un record wildcard (*) — poiché un wildcard risponde a ogni query che non ha già un record esplicito nella zona, un attaccante che ne crea uno diventa il resolver di ultima istanza per l'intera zona. La regola di rilevamento predefinita di Elastic per l'avvelenamento wildcard ADIDNS descrive esattamente questo: un attaccante si posiziona come adversary-in-the-middle risolvendo nomi arbitrari non corrispondenti, il che consente l'intercettazione di credenziali o il relay NTLM, concettualmente simile nell'esito allo spoofing LLMNR/NBNS ma persistente e a livello di intera zona invece che un singolo broadcast.

La Global Query Block List (GQBL) è la mitigazione Microsoft per il bersaglio più famigerato di questa tecnica — WPAD — ma la ricerca di follow-up di NetSPI nota che i record NS la aggirano ancora su sistemi completamente patchati, quindi la GQBL è un controllo parziale, non un sostituto della correzione dell'ACL sottostante.

Le due falle complementari: DNSSEC assente e record wildcard già presenti

DNSSEC_NOT_ENABLED e DNS_WILDCARD_RECORDS aggravano le tre configurazioni errate sopra descritte invece di costituire percorsi di attacco indipendenti:

• Senza DNSSEC, nulla nell'origine di un record è verificabile crittograficamente — una risposta avvelenata o falsificata non può essere distinta da una legittima. Microsoft tratta la firma di zona in Sign DNS Zones with DNSSEC on Windows Server e la meccanica sottostante nella panoramica DNSSEC — per una zona integrata in AD, le chiavi di firma della zona si replicano automaticamente ai server DNS primari tramite la normale replica AD, il che rende DNSSEC relativamente poco oneroso da distribuire specificamente su questa piattaforma.
• Un record wildcard già esistente, rilevato durante un audit — a differenza di uno che un attaccante ha appena creato — indica di solito che l'ACL della zona è già stata abusata, o che un team applicativo legacy l'ha richiesto senza revisione di sicurezza. In entrambi i casi, vale la pena trattarlo come una questione di incident response, non come una semplice pulizia di configurazione, fino a prova contraria.

La catena di attacco

Passaggio 1 — Ricognizione tramite trasferimento di zona

Un attaccante sulla rete (o, se la zona è raggiungibile dall'esterno, da internet) richiede un trasferimento di zona al server DNS:

dig axfr corp.local @10.10.10.10

Se la zona non è limitata, la risposta è l'intero set di record: domain controller, record SRV per Kerberos/LDAP, ogni hostname di workstation e server, e qualsiasi sottodominio che non doveva mai essere pubblico.

Passaggio 2 — Scegliere un nome bersaglio e registrare un record

Usando nient'altro che un account di dominio standard, l'attaccante registra un record DNS per un nome di interesse — un host dismesso, un nome che un'app legacy risolve ancora, o un wildcard:

# Da qualsiasi macchina unita al dominio, come qualsiasi utente di dominio autenticato
Add-DnsServerResourceRecordA -ZoneName "corp.local" -Name "legacy-app" -IPv4Address 10.10.10.50 -ComputerName dc01.corp.local

Se la zona consente ancora l'aggiornamento dinamico non sicuro, questo passaggio non richiede nemmeno una credenziale di dominio valida — un host non autenticato sul segmento può inviare lo stesso aggiornamento direttamente tramite il protocollo di aggiornamento dinamico.

Passaggio 3 — Relay o intercettazione

Con il record attivo, tutto il traffico destinato a quel nome finisce invece sull'host dell'attaccante. Per la risoluzione dei nomi SMB/HTTP questo è un diretto analogo dello spoofing LLMNR/NBNS — tranne che persiste nel DNS anziché richiedere che l'attaccante vinca una gara su ogni query broadcast — e alimenta direttamente il tooling di relay NTLM (Responder, ntlmrelayx) allo stesso modo di una risposta broadcast avvelenata. La tecnica è ancora più affidabile quando la firma SMB è disabilitata o non richiesta, poiché nulla impedisce che la sessione relayata venga accettata come legittima.

Rilevamento

Windows Server fornisce due canali di log DNS dedicati, entrambi trattati nella documentazione Microsoft Enable DNS Logging and Diagnostics: gli eventi DNS Audit (abilitati per default, basso overhead) che coprono le azioni amministrative — creazione/eliminazione di zona, modifiche ai record e operazioni di firma DNSSEC — e gli eventi DNS Analytical (disabilitati per default, volume maggiore) che coprono il traffico stesso di query/risposta/aggiornamento dinamico. Entrambi si trovano sotto Applications and Services Logs > Microsoft > Windows > DNS-Server nel Visualizzatore eventi.

Remediation

1. Limitate i trasferimenti di zona. Impostate i trasferimenti solo verso secondari fidati, o disabilitateli del tutto se non ne esistono:

   Set-DnsServerPrimaryZone -Name "corp.local" -SecureSecondaries TransferToSecureServers
   # oppure, se nessun secondario esterno ha bisogno di questa zona:
   Set-DnsServerPrimaryZone -Name "corp.local" -SecureSecondaries NoTransfer
   

2. Forzate l'aggiornamento dinamico solo sicuro su ogni zona integrata in AD. Nonsecure and secure non dovrebbe comparire su una zona di produzione:

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

3. Irrigidite l'ACL predefinita della zona. Rimuovere del tutto i diritti create-child di Authenticated Users romperà l'auto-registrazione legittima delle macchine unite al dominio, quindi va delimitato, non semplicemente revocato — la guida stessa di Microsoft su questo permesso (vedi il thread della community sul tema) conferma che il default è più ampio di quanto la maggior parte dei team pensi. Rivedete la scheda sicurezza della zona (o dsacls contro CN=<zone>,CN=MicrosoftDNS,DC=DomainDnsZones,DC=...) e delimitate i diritti create-child agli account e ai gruppi che hanno effettivamente bisogno di auto-registrarsi — tipicamente i computer di dominio tramite aggiornamento dinamico sicuro, non l'intero gruppo Authenticated Users senza condizioni.

4. Eliminate i record wildcard inattesi trovati durante la scansione di audit, e trattate qualsiasi record non provisionato da voi come potenziale indicatore di compromissione pregressa, non solo come pulizia.

5. Abilitate la Global Query Block List per le trappole di nomi classiche ad alto valore (WPAD, ISATAP) come livello di difesa in profondità — dnscmd /config /enableglobalqueryblocklist 1 — ricordando il riscontro di NetSPI secondo cui i record NS la aggirano ancora, quindi è un supplemento alla correzione dell'ACL, non un sostituto.

6. Abilitate DNSSEC sulle zone integrate in AD secondo la guida di firma di zona di Microsoft — le chiavi di firma si replicano automaticamente tramite AD, quindi una volta configurato il Key Master il rollout è in gran parte automatico sul resto dei domain controller che ospitano la zona.

Il DNS è solo una voce in un elenco molto più lungo — per una panoramica completa di cosa rivedere per primo tra esposizione Tier 0, abuso di ACL, Kerberos e logging, vedi Auditare la sicurezza di Active Directory: cosa verificare per prima.

Come EtcSec rileva questo

L'audit di categoria Rete di EtcSec verifica direttamente le zone DNS integrate in AD rispetto a queste cinque falle: DNS_ZONE_TRANSFER_UNRESTRICTED e DNS_DYNAMIC_UPDATE_INSECURE segnalano zone i cui impostazioni di trasferimento o aggiornamento sono più ampie del default sicuro, DNS_ZONE_AU_CREATE_CHILD segnala zone in cui Authenticated Users detiene ancora i diritti create-child sull'ACL della zona, DNSSEC_NOT_ENABLED segnala zone integrate in AD non firmate, e DNS_WILDCARD_RECORDS segnala voci wildcard esistenti per revisione manuale.