Accedi
Il fragile patto di fiducia della cybersecurity
Immagine in evidenza rielaborata con ausilio dell’intelligenza artificiale
Il 3 aprile 2026, un utente registrato sotto il nome di Nightmare Eclipse pubblica sulla piattaforma GitHub – di proprietà di Microsoft – uno strumento chiamato BlueHammer: un archivio contenente il codice necessario a sfruttare una vulnerabilità di Defender, l’antivirus integrato in Microsoft Windows.
Il messaggio di accompagnamento alla pubblicazione di BlueHammer suona come un’accusa alla stessa azienda, che secondo l’autore “avrebbe saputo cosa sarebbe successo”. Nei giorni seguenti, sullo stesso account vengono pubblicate informazioni su due vulnerabilità zero-day che prendono ancora di mira lo stesso antivirus, battezzate RedSun e UnDefend.
Tra il 10 e il 16 aprile 2026, i ricercatori di Huntress hanno osservato l’impiego delle tre vulnerabilità pubblicate da Nightmare Eclipse nel corso di un’intrusione ai danni di un’azienda. RedSun e UnDefend erano inoltre ancora zero-day, perché Microsoft non aveva ancora distribuito la relativa patch. Nessuno dei tre exploit sembra aver avuto successo durante l’attacco: la vicenda ha però riacceso i riflettori sul sistema che regola la pubblicazione delle vulnerabilità nel mondo della cybersecurity.
Scoprire una falla di sicurezza ancora sconosciuta rappresenta il Santo Graal dei cyber criminali. Uno zero-day può infatti consentire di colpire anche sistemi ben protetti, sfruttando una vulnerabilità per la quale non esiste ancora una correzione.
Scovare uno zero-day non è però qualcosa alla portata di tutti. E i casi in cui i gruppi criminali sono riusciti a individuare indipendentemente vulnerabilità di questo tipo sono rarissimi. Nelle cronache, l’uso di strumenti di attacco che fanno leva su falle di sicurezza di questo tipo è stato storicamente associato a organizzazioni dotate di risorse notevoli – tra cui i cosiddetti gruppi APT (Advanced Persistent Threat) – e che spesso agiscono direttamente sotto il controllo statale.
Normalmente, le nuove vulnerabilità software vengono invece individuate da società di cybersecurity e ricercatori indipendenti, che passano al setaccio il codice dei software più diffusi secondo la logica di “trovare la falla prima che lo facciano i cattivi”. Le scoperte sono gestite in modo che la loro pubblicazione avvenga solo dopo che il problema è già stato segnalato allo sviluppatore, in modo che abbia il tempo di predisporre e distribuire l’aggiornamento che lo corregge e – possibilmente – che la maggior parte degli utenti abbia il tempo di installare l’update.
Il difficile concetto di “responsible disclosure”
Definire le modalità con cui vengono pubblicati i dettagli delle vulnerabilità individuate dai ricercatori non è semplice come potrebbe sembrare a prima vista. La prassi di segnalare prima la vulnerabilità allo sviluppatore del software e di attendere il rilascio di un aggiornamento prima di renderne pubblici i dettagli – la cosiddetta “responsible disclosure” – si basa infatti su convenzioni, più che su regole vincolanti: norme di buon senso pensate per evitare che una falla di sicurezza venga esposta prima che sia disponibile una correzione, com’è accaduto nel caso delle vulnerabilità pubblicate da Nightmare Eclipse.
Se ci si fermasse a questo, però, si correrebbe il rischio che le segnalazioni vengano semplicemente ignorate. Nel corso degli anni, nel settore della cybersecurity si è spesso citata la frase – ormai quasi un clichè e attribuito prevalentemente a Microsoft – “it’s not a bug, it’s a feature” (non è una falla, è una funzionalità), che molti ricercatori avrebbero incassato come risposta per sminuire l’impatto delle vulnerabilità individuate.
A complicare ulteriormente le cose c’è l’aspetto economico legato al sistema di segnalazione delle falle di sicurezza. I programmi di bug bounty implementati da tutte le maggiori aziende software prevedono, infatti, ricompense economiche per i ricercatori che segnalano un problema di sicurezza. Insomma: nella gestione del processo pesa anche il rischio che qualcuno possa ignorare la segnalazione per non sborsare il compenso dovuto.
Segnalazioni con la scadenza
Per evitare che l’inerzia (o la malafede) dello sviluppatore possa lasciare esposti i sistemi dei suoi utenti a una vulnerabilità, è stata introdotta una consuetudine basata sul concetto di scadenza. Ogni team che lavora sulla ricerca di vulnerabilità impone un termine (solitamente 30, 60 o 90 giorni) entro il quale la società deve rilasciare l’aggiornamento che corregge la vulnerabilità. Trascorso il termine, è considerato lecito pubblicare i dettagli del bug per consentire agli utilizzatori di implementare le misure di mitigazione più opportune.
Tutto bene, quindi? Non proprio. Alcune vulnerabilità, infatti, non sono semplicissime da correggere e i casi in cui il mancato rispetto dei termini si è scontrato con una rigida intransigenza da parte di chi li ha segnalati non sono mancati. I più celebri attriti hanno interessato il team Google Project Zero, Microsoft e Apple. In almeno un paio di occasioni (i dettagli qui e qui), infatti, gli esperti di Google hanno rilasciato i dettagli su bug che non erano stati tempestivamente corretti.
Quando le regole saltano
Il caso di Nightmare Eclipse, che da qualche mese sta appassionando il ristretto settore dei commentatori della cybersecurity, si colloca al di fuori di quanto finora illustrato. Dopo le prime tre vulnerabilità, il fantomatico ricercatore di sicurezza ha infatti sparato a raffica una serie di ulteriori bug. Alla fine, l’elenco completo comprende: YellowKey, GreenPlasma, MiniPlasma, GreenPlanet, GreatXML, LegacyHive e ShieldBreak. In tutto, Nightmare Eclipse ha pubblicato i dettagli di ben dieci vulnerabilità che interessano diversi prodotti Microsoft.
Non solo: la scelta dei tempi di pubblicazione sembra essere stata accuratamente pianificata per rendere particolarmente difficile a Microsoft distribuire con puntualità gli aggiornamenti di sicurezza ai propri clienti. Per Windows, infatti, l’azienda di Satya Nadella concentra normalmente il rilascio degli aggiornamenti di sicurezza nel secondo martedì di ogni mese, il cosiddetto Patch Tuesday. Una modalità che consente di raggruppare le correzioni e che, soprattutto per le aziende, offre il vantaggio di poter pianificare gli aggiornamenti con un certo grado di prevedibilità.
Tra aprile e agosto, Nightmare Eclipse ha pubblicato le vulnerabilità con una tempistica apparentemente studiata per mettere Microsoft in difficoltà: almeno quattro sono state rese pubbliche il giorno stesso o immediatamente dopo il Patch Tuesday. In questo modo, se Microsoft avesse mantenuto la normale cadenza mensile degli aggiornamenti, i sistemi Windows sarebbero potuti rimanere esposti per quasi un mese. Un modus operandi diabolico, orientato a provocare il massimo disagio possibile e che, in alcuni casi, ha spinto Microsoft a distribuire correzioni al di fuori del normale ciclo mensile.
A contribuire a massimizzare il danno reputazionale subito dall’azienda, per la verità, ha contribuito anche la sorte. La pubblicazione di BlueHammer, la prima vulnerabilità di Windows Defender, è quasi coincisa con l’improvvida pubblicazione di un articolo sul sito ufficiale di Microsoft (poi apparentemente rimosso) che promuoveva il suo antivirus dicendo esplicitamente che per la maggior parte degli utenti “non serve un antivirus di terze parti”, pubblicizzandone quindi l’affidabilità proprio mentre finiva nel mirino di Nightmare Eclipse.
L’ingestibile vendetta dell’ex
Il vero problema nell’intera vicenda di Nigthmare Eclipse è che Microsoft si è scoperta estremamente vulnerabile nei confronti di quella che potrebbe essere stata soltanto la vendetta di un ex collaboratore che non ha gradito il trattamento che ha ricevuto da parte dell’azienda.
Una ricostruzione puntuale e verificabile di quanto sia accaduto precedentemente alle comunicazioni pubbliche è pressoché impossibile. Anche perché il protagonista della vicenda ha dimostrato più volte di essere piuttosto “ondivago”, inviando messaggi contraddittori sui suoi canali social. Le rivendicazioni più esplicite riguardano il fatto che Microsoft avrebbe cancellato il suo account sul Microsoft Security Response Center (MSRC), il portale che permette ai ricercatori di sottoporre le segnalazioni di nuove vulnerabilità e attiva i processi di bug bounty.
Nel corso di una conversazione su Discord riportata da uno dei partecipanti, Nightmare Eclipse avrebbe affermato di essere addirittura un ex dipendente della filiale tedesca di Microsoft. Un’ipotesi che era già circolata nel settore, ma che l’azienda non ha mai confermato.
Una certa familiarità con i processi di sicurezza adottati da Microsoft e l’evidente buona conoscenza dell’antivirus di Windows (la metà delle vulnerabilità pubblicate interessavano proprio Defender) sono indizi che confermerebbero questa pista. Tanto più che, in alcuni casi, Nightmare Eclipse ha dimostrato una discreta abilità nell’aggirare gli aggiornamenti messi a punto da Microsoft per mitigare le falle di sicurezza. Insomma, il ricercatore aderisce piuttosto bene al profilo di un “insider” che sta sfruttando tutte le sue conoscenze per massimizzare il danno.
Botta e risposta
Le reazioni di Microsoft non contribuiscono particolarmente a fare chiarezza sulla vicenda. Il 23 maggio ha sospeso l’account di Nightmare Eclipse su GitHub rimuovendo in seguito i contenuti. In un comunicato ufficiale del 27 maggio, l’azienda ha poi usato toni piuttosto duri, criticando senza mezzi termini il rilascio “non coordinato” delle vulnerabilità, pur senza minacciare direttamente azioni legali contro il ricercatore.
Le contromisure adottate da Microsoft non hanno portato a grandi risultati. Nightmare Eclipse ha infatti prima aperto un repository autogestito per continuare la sua opera di pubblicazione e poi – a metà giugno, quando ormai la vicenda stava facendo parecchio rumore nell’ambiente – ha abbandonato il suo blog ufficiale su Blogspot, sostenendo che Google, proprietaria della piattaforma, avrebbe censurato ingiustamente i suoi contenuti e creandone uno nuovo sulla sua piattaforma personale.
Al di là delle speculazioni su come si sia arrivati a questa sorta di “duello rusticano” e a quali siano i reali retroscena di tutta la vicenda Nightmare Eclipse, quello che emerge è il quadro terribilmente fragile di un sistema pieno di contraddizioni. Il comportamento dell’ormai famigerato ricercatore di sicurezza, infatti, non viola direttamente nessuna legge.
Il concetto di responsible disclosure è basato su consuetudini e le normative presenti negli Stati Uniti e in Europa, pur avendo progressivamente introdotto regole e procedure per la divulgazione coordinata delle vulnerabilità, non disciplinano in maniera puntuale tutti gli aspetti del rapporto tra ricercatori e aziende. Una parte importante del sistema continua quindi a fare riferimento alle “buone pratiche” sviluppatesi negli anni sulla base dei principi dell’hacking etico e a una visione un po’ romantica di una community che collabora per un bene comune superiore.
Insomma: tutto il sistema si basa sostanzialmente su un rapporto basato su fiducia, etica e correttezza di tutte le parti coinvolte. In un settore in cui si intrecciano giganteschi interessi economici, crescenti tensioni geopolitiche e la variabile impazzita rappresentata dall’impatto dell’intelligenza artificiale, gli scricchiolii sono sempre più evidenti.
P.S: Nel corso della stesura di questo articolo, sul repository di Nightmare Eclipse sono state rilasciate nuove vulnerabilità zero-day. L’elenco delle “vittime” comprende anche Nvidia, Kaspersky, Crowdstrike e Avast.
| # | Data | Exploit | Bersaglio | Impatto |
|---|---|---|---|---|
| 1 | 3 aprile | BlueHammer | Microsoft Defender | Ottenimento di privilegi di amministratore sul sistema |
| 2 | 12 aprile | RedSun | Microsoft Defender | Ottenimento di privilegi di amministratore sul sistema |
| 3 | 15 aprile | UnDefend | Microsoft Defender | Disabilitazione/blocco degli aggiornamenti Defender |
| 4 | 12 maggio | YellowKey | BitLocker / WinRE | Accesso a dati cifrati con Bitlocker |
| 5 | 12 mag. | GreenPlasma | CTFMON / CTF | Ottenimento di privilegi di amministratore sul sistema |
| 6 | 15 mag. | MiniPlasma | Cloud Files Mini Filter Driver | Ottenimento di privilegi di amministratore sul sistema |
| 7 | 9 giugno | RoguePlanet | Microsoft Defender | Ottenimento di privilegi di amministratore sul sistema |
| 8 | 10 giugno | GreatXML | BitLocker / WinRE | Accesso a dati cifrati con Bitlocker |
| 9 | 14 luglio | LegacyHive | Windows User Profile Service | LPE / manipolazione degli hive di altri utenti |
| 10 | 11 agosto | ShieldBreak | Microsoft Defender | Bypass della patch di RoguePlanet. Ottenimento di privilegi di amministratore sul sistema |
| 11 | 26 agosto | HardBreacher | Kaspersky Endpoint Security | Ottenimento di privilegi di amministratore sul sistema |
| 12 | 30 agosto | GreenSection | NVIDIA Vulkan driver | Crash |
| 13 | 30 agosto | PrettyPrague | AVAST Antivirus | Ottenimento di privilegi di amministratore sul sistema |
| 14 | 3 settembre | FalconFlank | Crowdstrike Falcon EDR | Ottenimento di privilegi di amministratore sul sistema |
| 15 | 9 settembre | ShieldCrash | Microsoft Defender | Bypass della patch di ShieldBreak. Ottenimento di privilegi di amministratore sul sistema |
L'articolo Il fragile patto di fiducia della cybersecurity proviene da Guerre di Rete.
