Tra giugno e dicembre 2025, il popolarissimo editor di testo e codice Notepad++ è stato al centro di un sofisticato attacco alla sua supply chain che ha compromesso il sistema di aggiornamento automatico utilizzato dall’applicazione. L’attacco non ha sfruttato vulnerabilità nel codice sorgente dell’applicazione stessa, bensì ha preso di mira l’infrastruttura di distribuzione degli aggiornamenti, in particolare il server di hosting condiviso che gestiva lo script responsabile del processo di update.
Secondo le analisi pubblicate dal team di Notepad++ e confermate da osservatori indipendenti, gli aggressori sono stati in grado di reindirizzare selettivamente alcune richieste di aggiornamento verso server controllati da loro. La manipolazione ha permesso la consegna di installer contenenti un trojan a un sottoinsieme specifico di utenti, mentre la maggior parte degli utenti continuava a ricevere aggiornamenti legittimi dal server corretto.
La catena di attacco secondo Kaspersky
I ricercatori di Kaspersky hanno descritto nel dettaglio le catene di infezione osservate durante l’attacco alla supply chain di Notepad++.
Una delle caratteristiche più rilevanti dell’incidente è stata la varietà di catene di infezione e payload osservati. Tra luglio e ottobre 2025, gli aggressori hanno costantemente cambiato:
- Gli indirizzi dei server di comando e controllo (C2) dai quali distribuivano i payload malevoli;
- I downloader utilizzati per consegnare il malware;
- I payload finali stessi.
Tali difformità indicano che gli aggressori non si sono limitati a un singolo metodo di compromissione, ma hanno adattato costantemente le tecniche per rendere più difficile il rilevamento.
Uno script per controllare un’eventuale compromissione
Uno sviluppatore indipendente ha utilizzato le informazioni tecniche condivise da Kaspersky nella sua analisi per sviluppare uno script PowerShell pubblicato su GitHub che svolge automaticamente una serie di controlli sui sistemi Windows alla ricerca di indicatori di compromissione (IOC) associati all’attacco.
Si tratta di uno script di scansione che non risolve eventuali compromissioni, ma offre un primo strumento di “triage tecnico” per verificare la presenza di artefatti comunemente collegati all’incidente pubblico.
Le indicazioni per eseguire lo script sono riportate su GitHub e l’autore stesso invita a verificare il codice PowerShell prima di eseguirlo. Non si dovrebbe infatti mai eseguire script PowerShell sviluppati da soggetti terzi senza prima averne ben compreso il comportamento.
Strumento per avviare una verifica preliminare
Lo script si configura come uno strumento di verifica preliminare orientato all’individuazione di possibili indicatori di compromissione, combinando controlli sul file system, sui processi in esecuzione, sulle comunicazioni di rete e sulla risoluzione DNS, con un’ulteriore fase di validazione basata sul confronto di hash noti.
L’approccio è dichiaratamente non invasivo e adatto a un contesto di triage, ma – a nostro avviso – presenta limiti tipici di questo tipo di strumenti, in particolare la possibilità di falsi positivi dovuti a controlli basati su nomi generici di processi o directory, e falsi negativi legati alla natura temporanea di alcuni elementi, come le connessioni di rete attive o la cache DNS.
Dal punto di vista metodologico, emergono anche aspetti migliorabili in termini di copertura, ad esempio nel controllo dei percorsi di installazione di Notepad++ e dei meccanismi di persistenza, oltre a considerazioni di affidabilità e prestazioni legate alla scansione ricorsiva e alla gestione dell’output
Nel complesso, però, il codice rappresenta una base solida per un’analisi iniziale, che può essere resa più efficace integrando verifiche contestuali aggiuntive, una normalizzazione dei criteri di matching e un arricchimento delle informazioni raccolte per supportare valutazioni più accurate.