Nessus Vulnerability Scanning Lab — Azure

Intero ciclo di vita della gestione delle vulnerabilità — scansiona, trova, correggi, verifica — eseguito nel mio ambiente lab Azure Active Directory utilizzando uno scanner Nessus dedicato, distribuito con Terraform.

Cosa Dimostra Questo Lab

Ho distribuito una VM scanner Ubuntu 24.04 dedicata nel mio ambiente lab Azure AD esistente, ho eseguito una scansione di base non autenticata e una scansione con credenziali contro un domain controller, un file server e un client aggiunto al dominio, ho analizzato i risultati, ho risolto un finding di gravità Alta (CVE-2013-3900) tramite hardening del registro di PowerShell, e ho verificato la correzione con una nuova scansione. Questo è il flusso di lavoro completo che i programmi enterprise di gestione delle vulnerabilità eseguono in modo continuo.

Questo balzo nei findings è l'intero argomento a favore della scansione con credenziali — il finding di gravità Alta CVE-2013-3900 che ho risolto in questo lab è un controllo locale che la scansione non autenticata non poteva assolutamente vedere.

Architettura

Appliance scanner dedicato NESSUS01 su Subnet-Servers con percorsi di scansione con credenziali verso tutti e tre i target Windows. Il piano di gestione è raggiungibile solo tramite tunnel SSH dalla workstation amministrativa — la porta 8834 non è mai esposta pubblicamente.

Lo scanner si unisce alla VNet lab esistente della mia serie Enterprise Azure Infrastructure Automation, distribuito come configurazione Terraform indipendente con il proprio remote state.

Decisioni progettuali che ho preso:

• VM scanner dedicata invece di installare Nessus su un target. Gli scanner enterprise vengono posizionati come appliance di rete indipendenti con linea di vista libera verso i loro target — scansionare da un host che è anche lui un target contamina i risultati.
• Data source Terraform contro l'infrastruttura esistente. La configurazione dello scanner fa riferimento alla VNet e alla subnet esistenti tramite blocchi data invece di duplicarli, con lo state isolato nella propria chiave nessus-scanner.tfstate così lo scanner può essere creato e distrutto senza toccare lo state del lab principale.
• La UI web di Nessus (porta 8834) non è mai esposta pubblicamente. L'NSG consente solo SSH (22) dal mio IP amministrativo; raggiungo la UI tramite un tunnel SSH (ssh -L 8834:localhost:8834). L'esposizione del piano di gestione è il primo motivo per cui le appliance scanner vengono compromesse.
• Solo autenticazione con chiave SSH — coppia di chiavi ed25519, nessuna autenticazione con password sullo scanner.

Fase 0 — Revisione di Sicurezza Pre-Flight (Pratica Ciò Che Scansiona)

Prima di distribuire qualsiasi cosa, ho verificato le regole NSG esistenti — e ho trovato esattamente il tipo di misconfigurazione che questo lab esiste per intercettare: la regola RDP consentiva source * (qualsiasi IP su internet).

Verifica pre-flight: la query az network nsg list rivela Allow-RDP-3389 aperta a qualsiasi origine (*).

L'ho ristretta al mio IP pubblico attuale prima di procedere:

az network nsg rule update -g RG-FileServerLab --nsg-name NSG-RDP \
  -n Allow-RDP-3389 --source-address-prefixes $(curl -s ifconfig.me)

La stessa regola dopo la correzione — origine limitata a un singolo IP amministrativo.

Trovare e correggere un'esposizione nel proprio ambiente prima di puntare uno scanner è il cambio di mentalità dal "usare uno strumento" al "fare sicurezza."

Fase 1 — Distribuire lo Scanner con Terraform

Cinque risorse — IP pubblico, NSG, NIC, associazione NSG e la VM Ubuntu — distribuite in meno di due minuti:

terraform apply: 5 aggiunte, 0 modificate, 0 distrutte. Gli output includono il comando SSH pronto all'uso.

Poi mi sono connesso via SSH e ho eseguito l'installazione headless di Nessus Essentials 10.12.1:

Prima connessione SSH a NESSUS01 con autenticazione basata su chiave — Ubuntu 24.04 attivo su 10.0.1.8, pronto per l'installazione headless di Nessus.

Fase 2 — Scansione di Base Non Autenticata

Prima scansione: nessuna credenziale — questo è ciò che un attaccante sul segmento di rete vede.

Scansione di rete di base che targettizza tutti e tre gli host: 10.0.1.5, 10.0.1.6, 10.0.1.7.

Risultati della baseline: 35 findings su 3 host, colonna Auth su Fail — Nessus non ha potuto effettuare il login, quindi ogni risultato deriva solo da osservazione esterna.

Fase 3 — Scansione con Credenziali

La scansione con credenziali è lo standard enterprise per la gestione interna delle vulnerabilità. Ho preparato i target Windows abilitando il servizio Remote Registry e aprendo i gruppi di regole firewall richiesti sul profilo Domain:

Set-Service -Name RemoteRegistry -StartupType Automatic
Start-Service RemoteRegistry
Set-NetFirewallRule -DisplayGroup "File and Printer Sharing" -Enabled True -Profile Domain
Set-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)" -Enabled True -Profile Domain

Preparazione del target su FS01 — RemoteRegistry in esecuzione con avvio Automatic, regole WMI e File & Printer Sharing abilitate per il profilo Domain.

Ho configurato le credenziali Windows nella scansione con le opzioni di sicurezza che le aziende richiedono: mai inviare credenziali in chiaro e solo NTLMv2.

Configurazione delle credenziali Windows — dominio LAB, NTLMv1 disabilitato, trasmissione credenziali in chiaro disabilitata, Remote Registry con auto-avvio abilitato per la scansione.

Risultati con credenziali: 64 findings — un aumento dell'83% rispetto alla baseline non autenticata contro gli stessi identici tre host.

Findings ordinati per gravità, con il controllo locale WinVerifyTrust di gravità Alta ora visibile — un finding che la scansione non autenticata non aveva alcun modo di rilevare.

Fase 4 — Analizzare il Finding Critico: CVE-2013-3900

Il plugin #166555 ha segnalato WinVerifyTrust Signature Validation (CVE-2013-3900) sia su DC01 che su FS01 — punteggio base CVSS v3 8.8, Tenable VPR 9.0. Il valore di registro EnableCertPaddingCheck era mancante, lasciando gli host in uno stato in cui un attaccante poteva aggiungere contenuto dannoso a un eseguibile firmato senza invalidarne la firma Authenticode.

Analisi completa del finding: l'output del plugin conferma che il valore di registro è assente su 10.0.1.5 e 10.0.1.6, con il percorso di correzione esatto documentato nella sezione Solution.

Perché questo finding è importante: è una vulnerabilità mitigata per configurazione — non esiste alcuna patch perché Microsoft ha reso la correzione opt-in. Era assente nelle immagini Windows Server 2025 fresche nel 2026, tredici anni dopo la pubblicazione della CVE. Questa è esattamente la classe di problemi che solo la scansione con credenziali e la gestione della configurazione intercettano.

Fase 5 — Correggere e Verificare

Ho applicato la correzione sugli host interessati secondo la sezione Solution del plugin — impostando EnableCertPaddingCheck = 1 sia nei percorsi di registro a 64 bit che in Wow6432Node — poi ho verificato entrambe le chiavi prima di rieseguire la scansione:

New-Item -Path "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" `
  -Name "EnableCertPaddingCheck" -Value "1" -Type String

New-Item -Path "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" `
  -Name "EnableCertPaddingCheck" -Value "1" -Type String

Correzione applicata e verificata con Get-ItemProperty — entrambi i percorsi di registro ora restituiscono EnableCertPaddingCheck : 1.

Poi il passaggio che la maggior parte delle persone salta — la nuova scansione di verifica. Non si chiude il ticket finché lo scanner non conferma che il finding è sparito:

Scansione di verifica (History: 2): il finding di gravità Alta CVE-2013-3900 è risolto. La gravità residua più alta è Media.

Trova → analizza → correggi → verifica. Ciclo chiuso.

Competenze Dimostrate

Perché Questo È Rilevante per il Lavoro

La gestione delle vulnerabilità è una funzione centrale in praticamente ogni ruolo di security operations, cloud security e GRC. Questo lab copre l'intero lavoro — non solo eseguire uno scanner, ma architettarne il posizionamento in modo sicuro, preparare correttamente i target, distinguere il segnale dal rumore nei risultati, eseguire una correzione e dimostrare che ha funzionato. Il confronto non autenticata-vs-credentialed e la nuova scansione di verifica sono le due cose che separano i professionisti dagli operatori di strumenti.

Report di Valutazione

Il deliverable professionale completo — sommario esecutivo, metodologia, analisi dettagliata del finding CVE-2013-3900, gestione del rischio residuo e raccomandazioni prioritarie — è disponibile come PDF:

Vulnerability-Assessment-Report.pdf

Nessus Essentials non include l'export dei report, quindi questo deliverable è stato redatto in modo indipendente dai dati di scansione — che è di per sé la competenza di reporting che la versione gratuita non include.

Lab Correlati

Questo scanner si distribuisce nell'ambiente costruito dalla mia serie Enterprise Azure Infrastructure Automation:

• Lab 1 — Terraform Infrastructure
• Lab 2 — Active Directory
• Lab 3 — NTFS File Server & RBAC
• Labs 4–6 — Azure RBAC

In questo repository non sono memorizzati segreti — lo scanner usa solo autenticazione con chiave SSH e le credenziali di scansione sono state inserite direttamente nella console Nessus, mai commitate nel codice.