Windows Server 2022 su Azure: file hosts che si svuota — come scoprire il processo responsabile e audit sicuro in produzione

Su una VM Windows Server 2022 in Azure il file C:\Windows\System32\drivers\etc\hosts si azzera a intervalli irregolari? In questa guida trovi un piano di troubleshooting passo‑passo per identificare il processo che lo modifica, correlare gli eventi e valutare l’impatto dell’audit in produzione.

Indice

Scenario e obiettivo

In ambienti cloud ibridi e serverizzati è raro che Windows azzeri spontaneamente hosts: quasi sempre c’è un processo (legittimo o no) che lo apre in scrittura e lo sovrascrive con un file vuoto, oppure lo rimpiazza (rename atomic) con un nuovo file di dimensione zero. L’obiettivo è:

capire chi o cosa modifica/cancella il file,
mettere in atto audit mirato a basso impatto,
decidere se lasciare l’audit in produzione in modo sicuro.

Checklist rapida (azioni immediate per preservare le prove)

Crea una copia protetta del file attuale (anche se vuoto) in un percorso non standard, ad esempio C:\Forensics\hosts.bak con ACL restrittive.
Non sostituire subito il file con versioni “pulite” a meno di urgenze operative: rischi di perdere il momento esatto e il processo responsabile.
Attiva l’audit (successo+fallimento) solo su etc/hosts prima del prossimo “svuotamento”.
Annota l’ora dell’ultimo azzeramento (timestamp/Dimensione) e verifica anche SysWOW64\drivers\etc\hosts per capire se agisce un processo a 32 bit.

Perché il file `hosts` è sensibile

Il file hosts è consultato dal servizio DNS Client prima delle query DNS. È spesso bersaglio di:

tool di sicurezza che “ripuliscono” modifiche ritenute rischiose,
script di configurazione continua (GPO, DSC, strumenti di gestione) che lo rigenerano,
editor o agent che, in caso di crash, scrivono un file temporaneo/zero‑length e poi lo rinominano sopra l’originale,
backup/restore o snapshot incoerenti che ripristinano una versione vuota.

Tabella di marcia del troubleshooting

La seguente tabella riassume i passi principali (dettagli più avanti).

Passo	Cosa fare	Note operative
Verificare i permessi	Controllare ACL su `etc` e `hosts`: solo SYSTEM, Administrators e account di servizio necessari dovrebbero avere Write.	Ridurre gruppi ereditati o ruoli temporanei.
Abilitare l’audit oggetti	Abilitare “Audit File System” (success+failure) e impostare SACL su dir/file.	Event Viewer → Security: ID 4656/4663/4658/4660/4670 (filtra Object Name=hosts).
Cercare processi sospetti	Correlare timestamp dell’evento 4663 con Process Name / PID e, se serve, usare Process Monitor.	Spesso agent di backup/EDR/Config management sovrascrivono il file.
Controllare criteri di dominio/GPO	Cerca script di accesso oppure preferenze/file distribuiti che toccano `hosts`.	Esegui `gpresult /r` o `RSOP.msc`.
Esaminare software Azure	Verifica Azure VM Agent, estensioni (DSC, RunCommand), Defender for Cloud, Automation.	Controlla log del Guest Agent e Activity Log; se collegato, interroga Log Analytics.
Validare integrità disco	`chkdsk /scan` e verifica salute dello storage; abilita log NTFS Operativo per rename/replace.	Uno “zero‑byte” può venire da crash in scrittura o file replace mal riuscito.

Passi dettagliati e comandi pronti all’uso

Verificare e mettere in sicurezza i permessi NTFS

Mostra ACL effettive su directory e file:

icacls "C:\Windows\System32\drivers\etc"
icacls "C:\Windows\System32\drivers\etc\hosts"

Valori consigliati (base):

SYSTEM: Full Control
Administrators: Modify (o Full Control per esigenze operative)
Users: Read
Account di servizio che davvero devono scrivere: espliciti, non gruppi generici

Per hardening (opzionale e con cautela), porta la proprietà a TrustedInstaller così da prevenire scritture non autorizzate anche da admin locali:

takeown /f "C:\Windows\System32\drivers\etc\hosts"
icacls "C:\Windows\System32\drivers\etc\hosts" /setowner "NT SERVICE\TrustedInstaller"

Nota: modifica avanzata—valutare impatto su tool che aggiornano legittimamente hosts. Evitare ACE “Deny” generici: meglio rimuovere il Write dove non serve.

Abilitare l’audit degli accessi al file system

Attiva l’audit a livello di criterio locale o GPO:

Apri Local Security Policy → Advanced Audit Policy Configuration → Object Access.
Abilita Audit File System: Success e Failure.

Da riga di comando:

auditpol /get /subcategory:"File System"
auditpol /set /subcategory:"File System" /success:enable /failure:enable

Impostare la SACL (auditing) su directory e file

La SACL definisce quali accessi generano eventi. Per tracciare scritture, usa PowerShell per aggiungere una FileSystemAuditRule mirata:

# Aggiunge audit su Write e WriteAttributes per tutti (modifica se vuoi un SID specifico)
$path = "C:\Windows\System32\drivers\etc\hosts"
$acl  = Get-Acl $path
$sid  = New-Object System.Security.Principal.NTAccount("Everyone")
$rule = New-Object System.Security.AccessControl.FileSystemAuditRule(
    $sid, "Write, WriteAttributes, AppendData, CreateFiles, Delete, WriteData",
    "None", "None", "Success, Failure"
)
$acl.AddAuditRule($rule)
Set-Acl -Path $path -AclObject $acl

Ripeti anche per la cartella 'etc' (utile per rename/replace)

$dir = "C:\Windows\System32\drivers\etc"
$dirAcl = Get-Acl $dir
$dirRule = New-Object System.Security.AccessControl.FileSystemAuditRule(
$sid, "Write, WriteData, CreateFiles, Delete, DeleteSubdirectoriesAndFiles",
"ContainerInherit,ObjectInherit", "None", "Success, Failure"
)
$dirAcl.AddAuditRule($dirRule)
Set-Acl -Path $dir -AclObject $dirAcl

D’ora in poi vedrai in Event Viewer → Windows Logs → Security eventi chiave:

4656 – richiesta handle
4663 – accesso all’oggetto (cerca Accesses: WriteData/WriteAttributes/Delete)
4658 – handle chiuso
4660 – oggetto eliminato
4670 – permessi cambiati

Filtro pronto per Event Viewer

Crea un filtro XML (scheda XML nel filtro) per velocizzare l’analisi:

&lt;QueryList&gt;
  &lt;Query Id="0" Path="Security"&gt;
    &lt;Select Path="Security"&gt;
      *[System[(EventID=4656 or EventID=4663 or EventID=4658 or EventID=4660 or EventID=4670)]]
      and
      *[EventData[Data[@Name='ObjectName']
        and (contains(Value,'\Windows\System32\drivers\etc\hosts')
          or contains(Value,'\Windows\SysWOW64\drivers\etc\hosts'))]]
    &lt;/Select&gt;
  &lt;/Query&gt;
&lt;/QueryList&gt;

Correlare l’evento con il processo

Gli eventi 4663 includono Process Name e Process ID del chiamante. Per arricchire il contesto con la riga di comando completa abilita “Include command line in process creation events” e l’audit dei processi:

# Abilita audit process creation
auditpol /set /subcategory:"Process Creation" /success:enable

Attiva la policy "Include command line in process creation events"

(via GPO: Computer Configuration → Administrative Templates → System → Audit Process Creation)

Da quel momento l’evento 4688 mostrerà il comando. Correlazione consigliata:

Prendi da 4663 il Process ID e l’orario.
Cerca un 4688 con lo stesso PID (o “New Process ID”) poco prima del 4663.
Annota CommandLine, firma digitale dell’eseguibile, percorso padre (Creator Process Name).

PowerShell: estrazione rapida degli accessi in scrittura a `hosts`

$filter = @{
  LogName = 'Security'
  Id      = 4663
}
Get-WinEvent -FilterHashtable $filter | Where-Object {
  $_.Properties.Value -join ' ' -match '\\drivers\\etc\\hosts'
} | ForEach-Object {
  $xml = [xml]$_.ToXml()
  $data = @{
    TimeCreated = $_.TimeCreated
    ProcessName = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'ProcessName'}).'#text'
    ObjectName  = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'ObjectName'}).'#text'
    Accesses    = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'AccessMask'}).'#text'
    Subject     = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'SubjectUserName'}).'#text'
  }
  [pscustomobject]$data
} | Sort-Object TimeCreated | Format-Table -AutoSize

Quando serve Process Monitor (Sysinternals)

Se gli eventi non bastano o sospetti un replace atomico (creazione di un file temporaneo e rename), usa Process Monitor con questi filtri (inclusivi):

Path ends with \drivers\etc\hosts
Operation is CreateFile OR WriteFile OR SetEndOfFileInformation OR Rename OR SetRenameInformationFile
Result non filtrato (inizialmente)

Avvia la cattura qualche minuto prima del momento in cui tipicamente compare lo “svuotamento”. Quando il problema si manifesta, ferma la traccia e cerca la sequenza: CreateFile (Desired Access: Generic Write) → WriteFile → SetEndOfFileInformation → CloseFile or Rename. L’entry Process identificherà l’eseguibile.

Controlli lato dominio: GPO, script, engine di configurazione

gpresult /h C:\Temp\gp.html per avere la lista di GPO applicate e script (logon, startup) attivi.
Verifica Group Policy Preferences → Files e Scheduled Tasks che puntino a hosts.
Se usi DSC, Chef/Puppet/Ansible o ConfigMgr, controlla baseline e risorse File che possano ripristinare il contenuto.

Controlli specifici in Azure

Azure VM Agent/Estensioni: esamina C:\WindowsAzure\Logs\WaAppAgent.log e le cartelle in C:\Packages\Plugins\ (es. Microsoft.CPlat.Core.RunCommandWindows, Microsoft.Powershell.DSC). Un’estensione può distribuire script che scrivono su hosts.
Defender for Cloud / MDE: alcune policy/azioni di remediation possono riportare hosts a uno stato “pulito”. Cerca eventi di “modifica file protetti”.
Automation/Runbook: verifica nell’Activity Log eventuali runbook pianificati sulla VM (Run Command, Script Extension).
Backup: se usi Azure Backup, controlla log dell’agent MARS o del servizio di backup in uso. Un restore parziale o un snapshot inconsistente può rimpiazzare il file.

Validazione dell’integrità del volume

Escludi cause legate a I/O e journaling NTFS:

chkdsk C: /scan
wevtutil sl Microsoft-Windows-Ntfs/Operational /e:true

Nel log “Microsoft‑Windows‑Ntfs/Operational” cerca eventi di File Replace/Rename sul percorso del file: aiutano a riconoscere chi crea un file temporaneo e lo rinomina su hosts.

Interpretare correttamente gli eventi Security

Event ID	Significato	Cosa osservare
4656	Richiesta handle all’oggetto	Requested Access (mask). Se include WRITE_DATA o DELETE, è un candidato.
4663	Accesso all’oggetto	Accesses: WriteData/AppendData/WriteAttributes/Delete. Process Name è decisivo.
4658	Chiusura handle	Conferma la fine dell’operazione; utile per sequenze temporali.
4660	Oggetto eliminato	Compare nei replace/rename con delete dell’originale.
4670	Permessi cambiati	Allerta se qualcuno modifica le ACL/SACL per eludere l’audit.

Cause frequenti in produzione

EDR/AV con protezione file di sistema: blocco o rollback di modifiche a hosts (specialmente se conteneva voci “ad‑blocking”).
Script di compliance (GPO/DSC/ConfigMgr/Intune): file rigenerato da template, talvolta vuoto in caso di errore variabili.
Agent di backup o snapshot: ripristino parziale/temporaneo che rimpiazza il file.
Editor/testi con BOM/encoding: salvataggi in UTF‑16 o crash durante il save creano file zero‑byte prima del rename finale.
Processi a 32 bit: scrivono SysWOW64\drivers\etc\hosts lasciando “invariato” il principale (o viceversa). Audit entrambi i percorsi.

Audit in produzione: impatto, log e retention

Overhead: per un solo file o una cartella specifica l’impatto su CPU e I/O è trascurabile. L’audit produce eventi solo quando avvengono accessi che matchano la SACL. In ambienti di produzione è considerato sicuro mantenere l’audit attivo finché il problema non è risolto, e spesso anche oltre come controllo di integrità.

Retention: imposta una dimensione adeguata per il registro Security (es. 256–512 MB) e, se possibile, inoltra gli eventi a Log Analytics/SIEM. In Log Analytics, una query tipo:

// Se invii SecurityEvent al workspace
SecurityEvent
| where EventID in (4656,4663,4658,4660,4670)
| where ObjectName endswith @"\Windows\System32\drivers\etc\hosts" 
    or ObjectName endswith @"\Windows\SysWOW64\drivers\etc\hosts"
| project TimeGenerated, EventID, Computer, Account, Process, ObjectName, Activity
| order by TimeGenerated desc

Mitigazioni e protezioni complementari

Monitoraggio di integrità (FIM)

Abilita Microsoft Defender for Endpoint o soluzioni FIM di terze parti per alert in tempo reale quando il file cambia o scende a 0 byte.
Combina con l’audit Security: l’alert FIM ti dice “quando”, l’evento 4663 “chi”.

DSC o strumento di configurazione per enforcement

Imponi il contenuto del file e ricevi avvisi se diverge (drift):

Configuration HostsEnforcement {
  Node localhost {
    File HostsFile {
      DestinationPath = 'C:\Windows\System32\drivers\etc\hosts'
      Contents        = @'
Esempio contenuto controllato
127.0.0.1   localhost
'@
      Type            = 'File'
      Ensure          = 'Present'
    }
  }
}
HostsEnforcement
Start-DscConfiguration -Path .\HostsEnforcement -Force -Verbose

Nota: l’enforcement “cieco” può mascherare il colpevole, perché ripristina subito il file. Usalo dopo aver identificato la causa o in parallelo con l’audit per catturare prima l’evento di modifica e poi il ripristino.

Script di ripristino automatico (con log)

Se non puoi aspettare l’analisi completa, uno script leggero ripristina il file quando scende a 0 byte e registra l’evento:

$target = "C:\Windows\System32\drivers\etc\hosts"
$backup = "C:\Forensics\hosts.bak"
$log    = "C:\Forensics\hosts-restore.log"

if (!(Test-Path $backup)) {
Copy-Item $target $backup -Force
}

$size = (Get-Item $target).Length
if ($size -eq 0) {
Add-Content -Path $log -Value ("{0:u} - Size=0, restoring from backup" -f (Get-Date))
Copy-Item $backup $target -Force

forza flush su disco

[System.IO.File]::WriteAllText($target, [System.IO.File]::ReadAllText($target))
}

AppLocker/WDAC e restrizioni

AppLocker e WDAC regolano l’esecuzione, non le scritture. Possono però impedire a processi non autorizzati di girare e quindi di toccare hosts. Per limitare le scritture, affidati a NTFS (ACL) e all’audit.

Attributo Read‑only e MIC

Impostare “attrib +R hosts” non è una vera protezione: processi con privilegi possono comunque scrivere o rimuovere l’attributo. L’innalzamento del livello di integrità (MIC) è possibile ma non sempre raccomandabile sugli artefatti di sistema: preferisci ACL e auditing.

Diagnostica avanzata

Auditing anche su SysWOW64

Su OS 64‑bit, i processi a 32‑bit possono essere reindirizzati verso C:\Windows\SysWOW64\drivers\etc\hosts. Per evitare cieche‑spot, applica SACL e controlli anche su quel percorso.

Riconoscere il “file replace” atomico

Molti programmi scrivono su un file temporaneo e poi eseguono rename over sull’originale. Segnali tipici:

Security 4663 su etc (directory) con Delete/WriteAttributes.
Log NTFS/Process Monitor con SetRenameInformationFile o Rename immediatamente prima del cambio di dimensione del file.

Eventi che “mancano”? (troubleshooting dell’audit)

Hai abilitato Advanced Audit Policy ma non hai impostato la SACL: niente 4663.
La SACL è solo sul file, ma l’attività è un replace a livello directory: aggiungi la SACL anche su etc con ereditarietà.
Il Maximum log size del Security log è troppo basso e gli eventi vengono sovrascritti prima di essere analizzati.

Playbook operativo completo

ACL: verifica e riduci i Write inutili; valuta proprietario TrustedInstaller se serve hardening.
Audit: attiva “File System (S/F)” + SACL su hosts e su etc (e su SysWOW64, se presente).
Process Creation: abilita 4688 con command line per contesto completo.
Osservazione: attendi il prossimo evento di azzeramento e raccogli 4656/4663 (+4688 correlati). Se dubbio, avvia Process Monitor con i filtri indicati.
Domino/Azure: controlla GPO/script, estensioni Azure (DSC/RunCommand), EDR/Defender, Automation/Runbook, backup agent.
Storage: esegui chkdsk /scan, abilita NTFS Operational, verifica errori I/O.
Decisione: lascia l’audit attivo in produzione finché non identifichi la causa. Effetto su risorse: minimo e prevedibile.
Stabilizzazione: abilitare FIM/alert, eventuale DSC o script di autoripristino (dopo aver trovato il colpevole), retention dei log verso SIEM.

Esempi pratici di filtri e correlazioni

Event Viewer: filtro veloce per le scritture

EventID is 4663
AND Object Name contains "\drivers\etc\hosts"
AND (Accesses contains "WriteData" OR Accesses contains "Delete" OR Accesses contains "WriteAttributes")

Kusto (Log Analytics) – top process che modificano `hosts`

SecurityEvent
| where EventID == 4663
| where ObjectName has @"\drivers\etc\hosts"
| summarize count() by Process, Account
| top 10 by count_

PowerShell – monitor “quasi real‑time”

$q = @"
&lt;QueryList&gt;
  &lt;Query Id='0' Path='Security'&gt;
    &lt;Select Path='Security'&gt;
      *[System[(EventID=4663)]]
      and
      *[EventData[Data[@Name='ObjectName'] and contains(Value,'\drivers\etc\hosts')]]
    &lt;/Select&gt;
  &lt;/Query&gt;
&lt;/QueryList&gt;
"@
$sub = Register-WmiEvent -Query "Select * From InstanceCreationEvent Within 5 Where TargetInstance ISA 'Win32_NTLogEvent' and TargetInstance.EventCode = '4663'" -Action {
  Write-Host "4663 captured at: $($event.TimeGenerated)"
}
oppure:
Register-ObjectEvent -InputObject (Get-WinEvent -LogName Security -FilterXPath $q) -EventName RecordWritten -Action {
  Write-Host "Host file access recorded"
}

Domande frequenti

Posso limitarmi a mettere Read‑only? È un palliativo: processi con privilegi rimuovono l’attributo e scrivono comunque. Meglio ACL + audit.

Perché vedo 4663 ma non il Process Name? Controlla di non aver filtrato i campi. I 4663 includono Process Name; se mancante, usa anche 4688 (Process Creation) per ricostruire il contesto.

Il problema accade “a orari variabili”: può essere il backup? Sì. Gli agent possono eseguire pre/post‑script o “quiesce” che tocca file. I log dell’agent e l’Activity Log in Azure chiariscono.

È sicuro tenere l’audit attivo? Sì, su un perimetro ristretto (file/dir) l’impatto è minimo. Mantieni una retention adeguata o invia a SIEM.

Riepilogo decisionale

Obiettivo: identificare il processo che svuota o sostituisce hosts.
Strumenti: Audit File System (4656/4663…), Process Creation (4688), Process Monitor, log Azure/EDR, NTFS Operational.
Esito atteso: un evento 4663 con Accesses di scrittura e il Process Name responsabile; da lì disabilitazione/configurazione del componente o allowlist controllata.
In produzione: audit consigliato; overhead trascurabile; integra con FIM/alert e retention centralizzata.

Appendice: comandi utili

:: Verifica rapido dimensione e data
dir C:\Windows\System32\drivers\etc\hosts

:: Copia forense (senza lock, best effort)
copy /b C:\Windows\System32\drivers\etc\hosts C:\Forensics\hosts%DATE:/=-%%TIME::=-%.bak

:: Flush DNS (non risolve la causa, ma aiuta dopo ripristino)
ipconfig /flushdns

:: Rimuovi eventuali eredità “rumorose” (valuta bene!)
icacls "C:\Windows\System32\drivers\etc\hosts" /inheritance:r

Conclusioni

Un hosts che si svuota su Windows Server 2022 in Azure è quasi sempre il risultato di una scrittura o sostituzione effettuata da un processo legittimo (EDR, backup, script di compliance) o indesiderato. Con un audit mirato a livello di file system e directory, più la correlazione con la creazione dei processi, puoi individuare con precisione il responsabile in tempi brevi e mettere in campo i correttivi: permessi più stretti, esclusioni/allowlist nel tool coinvolto, enforcement del contenuto con DSC o monitor FIM. Sì: lasciare l’audit attivo in produzione è una pratica consigliabile e a basso impatto finché la causa non è chiusa (e spesso anche dopo, come controllo di regressione).

Risorse utili (senza link)

Microsoft Learn – Guida “Apply a basic audit policy on a file or folder”.
Varonis – Approfondimento “Windows File System Auditing (Event 4656/4663)”.
Sysinternals – Process Monitor: tracciamento file e filtri.
Documentazione Azure – VM Agent ed Estensioni (DSC, RunCommand, Defender for Cloud).

Suggerimenti extra

Backup del file: conserva una copia firmata (hash) del contenuto atteso e verifica periodicamente con Get-FileHash.
Controllo versioni: usa DSC/Chef/Puppet per tenere il file allineato, con alert sul drift.
Protezione antimanomissione: hardening ACL e, dove possibile, impedisci l’esecuzione di binari non firmati che potrebbero toccare hosts.

Soluzioni e passi di troubleshooting (riepilogo compatto)

Passo	Cosa fare	Note operative
Verificare i permessi	Controllare ACL su `etc` e `hosts`; ridurre Write ai soli account necessari.	Evita ACE “Deny” generici; valuta proprietario TrustedInstaller.
Abilitare l’audit oggetti	“Audit File System” (S/F) + SACL su file/dir; filtra Security 4656/4663.	Event Viewer → Security; aggiungi anche audit su SysWOW64.
Cercare processi sospetti	Correlazione 4663 ↔ 4688; Process Monitor per rename/replace.	Attiva “Include command line in process creation events”.
Controllare criteri di dominio / GPO	Esamina script di logon/startup, GPP Files, baseline di compliance.	`gpresult /h`, `RSOP.msc`.
Esaminare software Azure	VM Agent/estensioni, Defender for Cloud, Automation, backup agent.	Controlla log in `C:\WindowsAzure\Logs` e `C:\Packages\Plugins`.
Validare integrità disco	`chkdsk /scan`, abilita NTFS Operational, verifica I/O.	Individua zero‑byte da crash in scrittura/snapshot incoerenti.