CVE-2026-69676 Kerberos: esecuzione di codice remoto e patch

Che cos'è CVE-2026-69676, l'esecuzione di codice remoto in Kerberos?

CVE-2026-69676 Kerberos: esecuzione di codice remoto, interessa Windows Kerberos e richiede una rapida verifica delle patch. Microsoft la classifica come critica: un attaccante autenticato con accesso di basso livello a un server interessato può inviare una richiesta appositamente creata che esegue codice su quel server, senza interazione dell'utente. L'avviso non indica l'accesso amministrativo come prerequisito.

Il CVRF MSRC di settembre 2026, letto in formato JSON il 3 ottobre 2026, riporta questi valori esatti per questa CVE:

La revisione dell'avviso individuale è la 1.0, datata 8 settembre 2026. Si tratta di un aggiornamento di sicurezza di settembre esaminato in ottobre. La CVE era assente dal catalogo CISA Known Exploited Vulnerabilities il 3 ottobre 2026, nella versione recuperata del catalogo 2026.10.02. Questa osservazione e la valutazione dello sfruttamento di Microsoft sono evidenze separate; nessuna delle due dimostra che lo sfruttamento non possa essersi verificato altrove.

Come funziona: cattura e riproduzione con privilegi bassi

Microsoft identifica un bypass dell'autenticazione che implica cattura e riproduzione. La descrizione colloca l'esecuzione di codice risultante attraverso la rete, mentre le FAQ specificano un attaccante autenticato con accesso di basso livello al server interessato. La conseguenza operativa è che l'applicazione della patch non può essere rimandata soltanto perché gli account ordinari non hanno diritti amministrativi.

Il CVRF pubblico non spiega quale messaggio venga catturato, come venga riprodotto o quale sia l'esatto percorso di elaborazione vulnerabile. Non specifica nemmeno l'identità con cui viene eseguito il codice risultante. Una sequenza dettagliata di pacchetti, un comando di exploit o un'affermazione di compromissione automatica del dominio andrebbero oltre queste evidenze.

La catena di attacco confermata dall'avviso

1. L'attaccante dispone di accesso autenticato di basso livello a un server interessato.
2. L'attaccante invia una richiesta appositamente creata attraverso la rete.
3. Il codice viene eseguito su quel server senza che un utente debba interagire.

Questi sono i limiti documentati dello scenario, non una prova di concetto. Il requisito di privilegi bassi rende le identità ordinarie compromesse rilevanti per la definizione delle priorità, ma l'avviso non afferma che ogni account di dominio possa sfruttare ogni server.

Rilevamento: raccogliere il contesto Kerberos, poi indagare

La documentazione degli eventi Microsoft offre una visibilità Kerberos utile sui controller di dominio. Questi eventi possono supportare un'indagine, ma nessuno è documentato qui come una firma affidabile dello sfruttamento di CVE-2026-69676.

Abilitate e raccogliete centralmente le sottocategorie di controllo Kerberos Authentication Service e Kerberos Service Ticket Operations. Verificate la copertura sia dei successi sia degli errori, ove applicabile. La guida pubblicata al monitoraggio di Active Directory spiega perché criteri di controllo, inoltro, conservazione dei campi e baseline devono funzionare insieme prima che una query SIEM offra una copertura utile.

Punto di partenza KQL per il triage

Questa query scritta da un analista usa la tabella SecurityEvent documentata e le sue colonne tipizzate. In questa tabella, EventData è una stringa, quindi la query non vi accede come a un oggetto dinamico. Raggruppa l'attività per l'analisi; la finestra retrospettiva di 24 ore e gli intervalli di 15 minuti sono scelte d'indagine, non soglie di sfruttamento.

SecurityEvent
| where TimeGenerated > ago(24h)
| where Channel == "Security"
| where EventSourceName == "Microsoft-Windows-Security-Auditing"
| where EventID in (4768, 4769, 4771)
| extend Account = TargetUserName,
         ClientIP = IpAddress,
         Service = ServiceName
| summarize Events = count(), Services = make_set(Service, 20)
    by bin(TimeGenerated, 15m), Computer, EventID, Account, ClientIP, Status
| order by Events desc

Confermate che il vostro connettore raccolga questi identificativi di evento in SecurityEvent e valorizzi TargetUserName, IpAddress, ServiceName e Status per ogni tipo di evento. Confrontate righe di esempio con l'XML dell'evento originale; i campi mancanti richiedono una revisione del parser prima che i risultati raggruppati siano utili. Non interpretate valori mancanti o un risultato vuoto come prova che non si sia verificato uno sfruttamento. Questa query non è stata eseguita sulla telemetria dei clienti.

Confrontate le combinazioni insolite di account, client e servizio e i picchi con l'attività normale, le finestre di modifica e le evidenze dell'endpoint sul server interessato. Gli eventi dei ticket sul controller di dominio non costituiscono un registro completo di ciò che viene eseguito su un server membro. Conservate la telemetria dell'host quando un'attività sospetta coincide con una risorsa senza patch.

La guida separata al fallback Kerberos a RC4 spiega come distinguere le evidenze di cifratura dei ticket dalla configurazione degli account e correggere le dipendenze AES in modo sicuro. L'attività RC4 è un'evidenza di contesto; il passaggio ad AES non è stato dimostrato come correzione per questa CVE.

Correzione: verificare l'aggiornamento giusto per ogni prodotto

1. Associare ogni risorsa al suo prodotto CVRF

Leggete le voci relative al prodotto interessato e alla correzione per la versione Windows e il tipo di installazione della risorsa. La voce include client Windows oltre ai prodotti server, quindi una revisione AD non deve presumere che contino soltanto i controller di dominio.

Per Windows Server 2025, il CVRF associa ProductID 12436, e Server Core ProductID 12437, a KB5122871, con FixedBuild 10.0.26100.33438 e RestartRequired Yes. La pagina di aggiornamento Microsoft Support conferma il rilascio dell'8 settembre e la build del sistema operativo 26100.33438. Usatelo come esempio specifico per una versione, non come KB da applicare a ogni versione Windows. La stessa pagina Support documenta una regressione di Remote Desktop Services dopo l'aggiornamento di settembre e indica che è risolta negli aggiornamenti rilasciati a partire dal 14 settembre 2026. Esaminate i problemi noti attuali e gli aggiornamenti applicabili che lo sostituiscono prima della distribuzione.

2. Raccogliere evidenze dell'installazione

Su una risorsa Windows Server 2025, adattate la ricerca per identificativo documentata di Get-HotFix alla KB confermata sopra:

Get-HotFix -Id KB5122871

Per ulteriori evidenze sulla versione, questo comando è citato direttamente dalla documentazione di Get-ComputerInfo:

Get-ComputerInfo -Property "*version"

Questi comandi sono esempi basati sulla documentazione, non misurazioni dei vostri server. Get-HotFix interroga Win32_QuickFixEngineering; conservate anche i registri di manutenzione e le evidenze complete della build del sistema operativo. Se la KB originale è assente, verificate se un aggiornamento cumulativo installato la sostituisce e include la correzione. Non dichiarate una risorsa vulnerabile o corretta basandovi soltanto sull'assenza di risultati nella ricerca della KB.

3. Installare, riavviare e ricontrollare

Distribuite l'aggiornamento di sicurezza applicabile, o un aggiornamento sostitutivo di cui sia stata verificata la copertura, attraverso il vostro processo di manutenzione supportato. Completate il riavvio richiesto, registrate la build in esecuzione e verificate le applicazioni dipendenti da Kerberos. Tracciate le eccezioni con un responsabile e una data di correzione. Finché permane un'eccezione, limitate l'accesso non necessario al server interessato e monitorate le attività sospette; queste misure non sostituiscono la patch.

Come EtcSec rileva questo problema

Per questo articolo non è stato verificato alcun controllo EtcSec diretto per CVE-2026-69676. Non usate un risultato di postura di etc-collector da solo come prova dello stato della patch o dello sfruttamento.

Usate le evidenze della patch e il flusso di indagine Kerberos descritti sopra per valutare questo problema. Tenete separati i risultati di postura, le evidenze degli aggiornamenti installati e le osservazioni sugli incidenti quando registrate l'esito. Un audit di configurazione senza anomalie non può stabilire da solo che questo difetto del codice Windows sia stato corretto.