N-able conferma che gli aggressori di N-central hanno raggiunto endpoint gestiti

Il 31 luglio 2026 il servizio gestito di rilevamento e risposta Adlumin di N-able ha segnalato un'attività insolita all'interno dell'ambiente di un cliente e ha individuato un attore ostile che sfruttava una vulnerabilità in N-central che il fornitore non aveva ancora divulgato. N-central è la piattaforma di monitoraggio e gestione remota che i managed service provider usano per amministrare i sistemi dei propri clienti, quindi ciò che gli intrusi avevano tra le mani non era una singola macchina ma la console davanti a molte. La falla, successivamente registrata come CVE-2026-18577, consentiva l'accesso amministrativo remoto senza autenticazione; l'attaccante ha poi usato la funzione Take Control di N-central per aprire sessioni sugli endpoint gestiti e ha registrato servizi tunnel Cloudflare su quei dispositivi, così che l'accesso sarebbe sopravvissuto alla perdita dell'account N-central. N-able afferma che "un numero limitato di clienti è stato identificato come impattato" e non ha detto quanti siano, né fino a che punto siano arrivati gli attaccanti. Questo articolo si basa su un unico record in l'Orca AI Incident Archive, che lo archivia insieme agli altri incidenti documentati della supply chain RMM e MSP che tiene traccia.

Poco di questo resoconto è contestato tra le fonti che lo descrivono. L'aggiornamento di sicurezza di N-able stesso, i record NVD per entrambi gli identificatori CVE, un'indagine di Huntress pubblicata entro pochi giorni dal rilevamento e i resoconti di The Register del 7 agosto e di The Hacker News dell'8 agosto descrivono la stessa sequenza: accesso non autenticato a N-central, Take Control usato come pivot, tunnel Cloudflare registrati sugli endpoint per la persistenza. L'archivio data l'incidente al 31 luglio 2026 con precisione al giorno, vale a dire quel singolo giorno — il giorno in cui è stato sollevato il rilevamento di Adlumin — e non una finestra temporale. Un dettaglio sulle fonti vale la pena di essere precisato: il post consolidato di N-able è datato 10 agosto 2026, e l'URL citato dall'archivio, che termina con "august-2-2026", ora rimanda a quell'aggiornamento successivo, per cui il testo del 2 agosto così come era stato pubblicato in origine non è più recuperabile da quel link.

Il difetto era il secondo bypass, non il primo

N-central era già stato aggirato una volta quell’estate. CVE-2026-18556, classificata come bypass dell’autenticazione tramite un percorso o canale alternativo, interessava N-central fino alla versione 2026.1 ed è stata corretta nella 2026.2. La scheda NVD di CVE-2026-18577 la descrive in una frase come “una patch incompleta per CVE-2026-18556” che “consente il bypass dell’autenticazione e l’acquisizione del controllo dell’account in N-central fino alla versione 2026.3.1”. In altre parole, le organizzazioni che avevano già applicato la correzione 2026.2 erano ancora esposte, ed è per questo che una seconda vulnerabilità e un secondo hotfix sono seguiti entro una settimana dal primo.

Entrambi i record riportano la stessa classe di debolezza, CWE-288. I punteggi non coincidono tra i diversi sistemi di scoring, e questa è una proprietà del sistema di scoring, non una contraddizione: NVD registra un punteggio base CVSS 4.0 di 8.2 per CVE-2026-18577, mentre la valutazione CVSS 3.1 di NIST lo colloca a 8.1. Per CVE-2026-18556 i due valori sono 8.2 e 7.4. Il vettore 4.0 per 2026-18577 è AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N con i sotto-punteggi SC:L/SI:L/SA:L — riservatezza alta, integrità e disponibilità nulle. Questa è una descrizione del bypass stesso, non di ciò che un attaccante fa dopo averlo superato, e non è un buon riferimento per valutare i danni che una console di gestione compromessa può causare.

La versione di correzione per CVE-2026-18577 è indicata come tutte le build precedenti alla 2026.3.1.7, una formulazione usata nell'advisory di Beazley Security sulla vulnerabilità; il post di N-able cita solo le build hotfix e non pubblica alcuna matrice delle versioni interessate.

Cosa hanno fatto gli intrusi con una console di gestione

Take Control è lo strumento di supporto remoto proprietario di N-central, distribuito per consentire a un tecnico MSP di aprire una sessione sul desktop di un utente finale senza chiedere a quell'utente di installare nulla. Gli attaccanti lo hanno usato come farebbe un tecnico. Come riportato da The Register, Huntress ha definito l'accesso "lo stesso livello di accesso a N-central normalmente riservato al personale fidato delle operazioni di rete e dell'ingegneria" — sufficiente per aprire sessioni remote e inviare script nei sistemi dei clienti e, per come il riepilogo del 3 agosto di CISO Intelligence ha descritto la capacità, per aprire sessioni verso i domain controller. Nessuna fonte indica quali di queste capacità gli attaccanti abbiano effettivamente usato.

La fase di persistenza è la parte che è sopravvissuta all'incidente. Un attaccante che registra un tunnel Cloudflare come servizio Windows su un endpoint ottiene un canale solo in uscita che non richiede alcuna regola firewall in ingresso, riparte dopo un riavvio e continua a funzionare dopo che l'account N-central usato per impiantarlo viene revocato. L'aggiornamento di N-able elenca il nome del servizio da cercare, Cloudflared, insieme a una copia di svchost.exe collocata nella cartella Documenti di un utente e a sessioni Take Control anomale nei log del prodotto stesso. L'avviso di Beazley Security aggiunge l'account integrato mspsupport@n-able.com come segno da cercare. N-able ha anche avvertito che gli attaccanti stavano creando nuovi account e reimpostando quelli esistenti per mantenersi, e ha affermato chiaramente la conseguenza: l'applicazione della patch "non rimuove un attore di minaccia che potrebbe essere già presente nel tuo ambiente".

Fin dove è arrivata: nove organizzazioni e un fornitore che non sarà conteggiato

L'unico dato che chiunque abbia pubblicato sulla portata dell'intrusione proviene da Huntress, non da N-able. In un singolo ambiente partner compromesso, Huntress ha rilevato che gli attaccanti raggiungevano nove organizzazioni a valle, toccando un endpoint in ciascuna e limitandosi in gran parte all'enumerazione dei processi prima di disconnettersi. Si tratta di un minimo osservato in un caso, non di un totale: N-able si è rifiutata di dire quanti clienti siano stati colpiti, quanti sistemi a valle siano stati raggiunti o cosa abbiano fatto gli attaccanti una volta ottenuta la persistenza. The Register ha riportato esplicitamente tale rifiuto. Il riepilogo del 3 agosto di CISO Intelligence collocava a oltre il 55 percento la quota di server N-central cloud raggiungibili dei partner di Huntress ancora privi di patch a quella data.

Che cos'è in realtà la connessione AI

L'archivio attesta come confermato il coinvolgimento dell'IA in questo incidente, e il punto in cui cercarlo è il rilevamento, non l'attacco. N-able commercializza Adlumin come «SecOps potenziato dall'IA e guidato dall'uomo», con un'«IA adattiva» che «apprende continuamente dal tuo ambiente» e segnala anomalie comportamentali; a RSAC 2026, a marzo, l'azienda ha annunciato tre rilevamenti basati sull'IA all'interno di Adlumin MDR: rilevamento anomalo di PowerShell, un avviso di interruzione DNS basato su ML e un modello di esecuzione dei processi a evento singolo che valuta un processo in base al nome, al percorso e alla catena dei processi padre. È stato il servizio MDR di Adlumin a rilevare l'intrusione il 31 luglio.

Quello che è accertato finisce lì. Nessuna fonte consultata per questo articolo afferma che sia stato un modello di IA o un analista umano ad aver lanciato l'allarme specifico che ha dato avvio alla risposta, e N-able non attribuisce il rilevamento a un motore identificato. Altrettanto chiaro è che dall'altra parte non compare alcun sistema di IA: né il resoconto di N-able, né i risultati di Huntress così come riportati, né la copertura del Register o di The Hacker News descrivono un modello, un agente o uno strumento di IA in qualsiasi punto della catena dell'intrusione. Letto senza giri di parole, questo caso appartiene a un archivio degli incidenti di IA perché è stata una piattaforma di sicurezza assistita da IA lo strumento del rilevamento, non perché l'IA abbia causato o portato a termine la compromissione. Tale distinzione è la cosa più utile che il tag d'archivio può dire a un lettore in questo contesto.

Cosa è cambiato e cosa N-able continua a non dire

N-able ha rilasciato l'Hotfix 1, build 2026.3.1.7, il 2 agosto e ha mitigato centralmente i propri ambienti ospitati; i clienti on-premises hanno dovuto installarlo da soli. Il 6 agosto, il monitoraggio continuo ha fatto emergere un percorso di attacco correlato e l'azienda ha rilasciato l'Hotfix 2, build 2026.3.1.10, che secondo quanto dichiarato sostituisce il primo "con ulteriori misure di hardening" ed è richiesto anche ai clienti che avevano già applicato l'Hotfix 1. Il 3 agosto CISA ha aggiunto CVE-2026-18577 al proprio catalogo delle vulnerabilità note e sfruttate, con scadenza federale di remediation fissata al 6 agosto, e il 4 agosto CVE-2026-18556 con scadenza al 7 agosto — in entrambi i casi una finestra di tre giorni, che The Register ha definito una scadenza insolitamente breve, riservata a rischi urgenti. Le indicazioni che accompagnavano le correzioni erano di natura operativa più che tecnica: imporre l'MFA, disabilitare l'account di supporto integrato nel prodotto a meno che non serva per un ticket, verificare account e privilegi per creazioni e reset, ed eseguire il template del servizio di scansione degli indicatori fornito dal vendor — considerando però una scansione pulita come nessuna prova. "Un esito pulito non dovrebbe essere interpretato come garanzia che il proprio ambiente non sia stato compromesso", ha scritto N-able.

Ciò che N-able non ha pubblicato è la causa radice. Afferma di trattenere deliberatamente i dettagli tecnici mentre gli attori restano attivi — "Un'analisi completa della causa radice è in arrivo e la condivideremo non appena sarà sicuro farlo" — e che "non considera chiusa questa vicenda" finché non ne sarà certo. Questo lascia il secondo bypass descritto soltanto dai suoi effetti, come un percorso alternativo attorno allo stesso controllo di autenticazione che la correzione 2026.2 avrebbe dovuto chiudere.

Cosa è ancora aperto

L'attribuzione è sconosciuta e gli indicatori stessi del fornitore non potranno fornirla. CISO Intelligence ha riferito che diversi indirizzi IP pubblicati da N-able erano nodi di uscita di Mullvad e NordVPN, e che due ulteriori indirizzi sono stati aggiunti all'elenco in seguito — piste investigative più che attribuzione, come osserva la stessa sintesi. Il livello di confidenza di N-able in questo caso non è quello dell'archivio: il record riporta confidenza A perché le fonti primarie concordano tra loro, il che è un'affermazione sulla documentazione, non sul fatto che qualcuno abbia verificato l'intrusione in modo indipendente dall'inizio alla fine.

Quello che i fatti documentati supportano è più circoscritto e più duraturo di un titolo su una violazione. Un secondo bypass dell'autenticazione in una piattaforma che i MSP usano per amministrare interi parchi clienti è stato sfruttato attivamente in ambienti reali ed è rimasto aperto per almeno i sei giorni tra il primo rilevamento, il 31 luglio, e il secondo hotfix, il 6 agosto. Gli attaccanti hanno creato una via per rientrare negli endpoint che l'applicazione delle patch a N-central non chiude — ed è per questo che il consiglio dello stesso fornitore a chiunque avesse applicato le patch in ritardo era di considerare l'ambiente compromesso e iniziare a verificare gli account invece di fidarsi di una scansione pulita.