GhostLock blocca file Windows abusando CreateFileW e condivisioni SMB

GhostLock blocca file Windows abusando dell’API CreateFileW e del parametro dwShareMode impostato a zero per ottenere accesso esclusivo a documenti locali o su condivisioni SMB. Il proof-of-concept pubblicato dal ricercatore Kim Dvash di Israel Aerospace Industries dimostra come una funzionalità legittima del sistema operativo possa trasformarsi in uno strumento di disruption operativo senza crittografia, cancellazione dati o privilegi amministrativi. L’attacco genera errori STATUS_SHARING_VIOLATION e può produrre downtime simile al ransomware, ma con una logica più stealth perché non modifica i file e non attiva i classici segnali di cifratura massiva. In uno scenario dove ransomware e tecniche di sabotaggio digitale evolvono verso modelli sempre più distruttivi, GhostLock mostra che anche un semplice abuso di API può interrompere attività aziendali, bloccare file server e distrarre i team IT durante intrusioni più ampie.

GhostLock abusa del parametro dwShareMode nell’API CreateFileW

GhostLock sfrutta un comportamento previsto della funzione CreateFileW, una delle API fondamentali di Windows per aprire file, directory, dispositivi e risorse di sistema. Quando il parametro dwShareMode viene impostato a zero, il processo richiede accesso esclusivo al file e impedisce ad altri utenti o applicazioni di aprire la stessa risorsa fino alla chiusura dell’handle. Questa modalità è legittima e viene usata da software che devono garantire integrità durante operazioni sensibili, ma GhostLock la applica in modo massivo e ricorsivo. Il codice dimostrativo pubblicato da Kim Dvash mostra l’apertura di un file Excel su una condivisione SMB con accesso esclusivo e il conseguente errore STATUS_SHARING_VIOLATION per ogni tentativo successivo di accesso. Il punto critico è che l’operazione non richiede scrittura, modifica o cifratura: il file resta intatto, ma diventa temporaneamente inutilizzabile per gli altri processi.

GhostLock usa chiamate legittime per evitare i segnali classici del ransomware

La forza tecnica di GhostLock deriva dalla normalità apparente delle sue azioni. Il tool non cifra documenti, non rinomina file, non altera estensioni e non cancella dati. Si limita ad aprire file con accesso esclusivo e a mantenere vivi gli handle il più a lungo possibile. Molti sistemi EDR, SIEM e strumenti anti-ransomware sono progettati per intercettare pattern come scritture massive, modifiche simultanee ai metadati, creazione di ransom note o uso intensivo di algoritmi crittografici. GhostLock aggira questo modello perché non produce nessuno di questi segnali. La tecnica funziona sia su file system locali sia su condivisioni SMB e può essere eseguita da un normale utente di dominio senza privilegi elevati. In un ambiente aziendale, un endpoint compromesso può quindi bloccare documenti condivisi, cartelle operative e file di lavoro senza sfruttare vulnerabilità kernel o ottenere permessi amministrativi. Questa dinamica rende GhostLock vicino a un attacco di denial-of-service applicato al file access, più che a un ransomware tradizionale.

Il tool pubblicato su GitHub automatizza il blocco ricorsivo dei file

GhostLock è stato rilasciato su GitHub come proof-of-concept open source per dimostrare la fattibilità dell’attacco e stimolare attività di rilevamento difensivo. Il tool scandisce directory locali o remote, apre ricorsivamente i file individuati e mantiene attivi gli handle per prolungare il blocco. Se un processo viene terminato, lo strumento può rilanciare rapidamente nuove istanze e tentare di riacquisire accesso esclusivo alle stesse risorse. L’effetto si amplifica quando più dispositivi compromessi eseguono GhostLock contro le stesse condivisioni SMB, generando una pressione distribuita sui file server aziendali. Gli handle restano validi fino alla chiusura della sessione SMB, all’uccisione dei processi o al riavvio del sistema. Questa reversibilità distingue GhostLock dai ransomware distruttivi, ma non ne riduce l’impatto operativo. Per l’utente finale il risultato è identico: documenti, fogli di calcolo, file di progetto e risorse condivise risultano inaccessibili nel momento in cui servono.

GhostLock produce downtime operativo senza crittografia o perdita dati

L’impatto di GhostLock è puramente operativo ma può diventare esteso in ambienti con forte dipendenza da file server e share di rete. Gli utenti vedono errori di condivisione quando tentano di aprire documenti, mentre le applicazioni aziendali possono smettere di funzionare se non riescono ad accedere a file di configurazione, database locali, modelli, template o directory condivise. In una rete enterprise con migliaia di file aperti contemporaneamente, la disruption diventa immediata e può simulare gli effetti di un attacco ransomware pur senza cifratura. Questo aspetto rende GhostLock particolarmente insidioso per help desk e team IT, che inizialmente potrebbero interpretare l’evento come un problema di permessi, lock applicativi, storage o sessioni SMB malfunzionanti. La differenza sostanziale rispetto a un ransomware è che l’accesso torna disponibile dopo la chiusura degli handle o il riavvio dei sistemi. Tuttavia il downtime resta reale e può interrompere processi amministrativi, produzione documentale, attività contabili e workflow critici.

GhostLock può diventare un diversivo durante intrusioni più complesse

Il valore offensivo di GhostLock aumenta se viene utilizzato come decoy durante un’intrusione multi-fase. Un attaccante può lanciare il tool su larga scala per generare centinaia di ticket e blocchi utente mentre continua a muoversi lateralmente, esfiltrare dati o consolidare persistenza. Il team IT viene assorbito dal ripristino della produttività e potrebbe perdere visibilità su segnali più critici presenti nella rete. Questa logica è coerente con molte campagne moderne, dove il rumore operativo viene usato per mascherare attività silenziose di raccolta credenziali o accesso a sistemi sensibili. GhostLock richiede risorse minime, non installa componenti persistenti e può essere interrotto senza lasciare danni permanenti ai file. Proprio questa reversibilità lo rende utile anche per scenari red team e test di resilienza. Allo stesso tempo, se utilizzato da attori reali, può diventare una tecnica a basso rischio per creare caos controllato e aprire una finestra temporale utile ad altre azioni malevole, come avviene spesso negli attacchi che combinano disruption, movimento laterale e furto dati.

Il rilevamento richiede metriche specifiche sui file server SMB

Il rilevamento di GhostLock è complesso perché l’attività malevola non emerge chiaramente nei log tradizionali di Windows, nei flussi di rete o nella telemetria EDR standard. Secondo Kim Dvash, l’indicatore più affidabile è il conteggio anomalo di file aperti con ShareAccess uguale a zero a livello di file server. Questa metrica però vive spesso nelle interfacce di gestione dello storage o nei dettagli delle sessioni SMB, non nei log che vengono normalmente raccolti dai SIEM. Senza query dedicate, un picco di handle esclusivi può passare inosservato per ore o giorni. Il whitepaper associato al progetto fornisce template per query SIEM e regole NDR, ma gli amministratori devono adattarle alla propria infrastruttura. In questo contesto logging centralizzato, anomaly detection, SIEM ed EDR devono lavorare insieme per garantire visibilità sugli eventi critici, soprattutto quando il comportamento malevolo imita funzioni legittime del sistema operativo.

Gli EDR devono superare il modello basato solo sulla cifratura massiva

GhostLock evidenzia un limite importante nei modelli di detection orientati al ransomware classico. Molti controlli cercano pattern di cifratura concorrente, creazione di file anomali, rinomina massiva o scrittura intensiva su directory condivise. Questa impostazione funziona contro numerose famiglie ransomware ma non intercetta un blocco esclusivo degli handle. L’attacco non altera contenuti, non richiama algoritmi crittografici e non genera I/O di scrittura significativo. La telemetria difensiva deve quindi includere anche comportamenti di accesso, volume di handle aperti, durata delle sessioni SMB, numero di file bloccati per utente e concentrazione temporale delle richieste CreateFileW. In passato i controlli EDR hanno dimostrato efficacia contro ransomware che modificano massivamente file e metadati, ma GhostLock sposta il problema su un piano diverso: non la trasformazione dei dati, bensì la negazione temporanea dell’accesso. Per questo le organizzazioni devono estendere la detection anche a pattern di file locking anomalo.

La mitigazione passa da limiti sugli handle e risposta rapida

La mitigazione di GhostLock non richiede una patch tradizionale, perché il tool sfrutta un comportamento legittimo del sistema operativo. La difesa si basa su controlli preventivi e capacità di risposta rapida. Gli amministratori dovrebbero monitorare il numero massimo di handle aperti per sessione utente, limitare l’accesso ricorsivo alle condivisioni più sensibili e introdurre soglie di alert quando un singolo endpoint apre centinaia o migliaia di file in modalità esclusiva. In caso di attacco, la chiusura forzata delle sessioni SMB, l’uccisione dei processi GhostLock o il riavvio dei sistemi coinvolti ripristinano l’accesso. Le organizzazioni possono inoltre segmentare meglio le share, applicare il principio del least privilege e ridurre la quantità di file accessibili da utenti standard. Questo approccio è coerente con la difesa moderna contro ransomware e disruption, dove il principio di least privilege e la segmentazione limitano l’impatto degli attacchi su share e sistemi critici. GhostLock rende evidente che anche permessi apparentemente ordinari possono generare effetti sistemici se applicati su larga scala.

GhostLock mostra il rischio nascosto delle API legittime di Windows

GhostLock non introduce una vulnerabilità classica ma dimostra un abuso potente di una funzione di base di Windows. Questo aspetto lo rende importante per blue team, red team e amministratori di file server, perché mostra come una superficie d’attacco possa esistere anche senza exploit, privilege escalation o malware persistente. Le API legittime sono necessarie al funzionamento delle applicazioni, ma possono produrre impatti inattesi quando vengono orchestrate in modo massivo e malevolo. L’attacco conferma che la sicurezza enterprise deve monitorare non solo ciò che modifica i dati, ma anche ciò che ne impedisce l’accesso. Nel 2026 la resilienza operativa passa quindi dalla capacità di distinguere un lock applicativo normale da un blocco sistematico e distribuito. GhostLock diventa un caso di studio utile perché obbliga le organizzazioni a rivedere metriche, playbook e strumenti di detection su file server SMB. La lezione è diretta: un attacco può fermare un’azienda anche senza cifrare un solo file.