Con la tipologia "file canarino" (canary) si intendono file dal contenuto irrilevante che vengono usati come "sentinelle" per monitorare eventi all'interno di una cartella: la loro cifratura da parte di un ransomware, l'esfiltrazione durante un attacco hacker, la rimozione dolosa o accidentale, innescheranno un allarme che avviserà l'utente (o l'amministratore di rete) che qualcosa di sospetto sta accadendo in quella cartella. Si possono anche impostare misure difensive che attivano una reazione automatica in base al tipo di allarme, senza richiedere l'intervento dell'operatore.
Solitamente si tratta di soluzioni di cybersecurity a livello aziendale (v. qui e qui), abbastanza costose e pensate per un'infrastruttura di rete articolata; se quindi un utente domestico volesse fruirne, pare non ci siano buone soluzioni gratuite offline (da non confondere con i servizi gratuiti online che possono inserire tracking pixel in un file; qui l'obiettivo, come vedremo, è differente). Anche stavolta ci è venuto in aiuto PowerShell per cercare di "preparare in casa" qualcosa che possa emulare il comportamento dei "file canarino", senza ambizioni di "data loss prevention" professionale, ma quantomeno come speranza per un tempestivo allarme in casi estremi.
Supponiamo che siano stati aggirati o male impostati i permessi di accesso ad una cartella con documenti importanti; un utente malevolo accede, da remoto o in presenza, alla cartella e può operare al suo interno. Per il monitoraggio di cui parleremo, non intessa che sia segnalata l'aggiunta di file, altrimenti anche ogni nostra nuova modifica alla cartella farebbe scattare l'allarme, ma intendiamo solo evitare che i file al suo interno siano cifrati, cancellati o siano trafugati tramite copia su dispositivo esterno o altra cartella, magari condivisa con altri utenti o in rete. Per questa sorveglianza ci affideremo ad un "file canarino", "canary" in breve, che dovrà essere creato ad hoc prima di eseguire lo script PowerShell "CanaryShell" (potete scaricarlo da questo indirizzo GitHub) che avrà il compito di aiutarci a monitorare la presenza e i cambiamenti del canary e della sua cartella.
Il processo che dovremmo seguire è di tre fasi:
- creazione del file canary
- usare lo script CanaryShell per creare un altro script PowerShell con i parametri che preferiamo (è sufficiente lanciare CanaryShell e digitare le nostre scelte)
- impostare il nuovo script creato in modo che parta all'avvio di Windows o al login dell'utente, oppure tenerlo in una cartella da cui possiamo attivarlo al bisogno.
Creazione del canary
Il file canary richiesto da CanaryShell può essere un qualunque file; tuttavia, per evitare futuri errori, conviene creare un nuovo file, anche un semplice ".txt" va bene. Come nome del canary è opportuno scegliere qualcosa di allettante, come "password.txt"; l'importante, per evitare "falsi positivi" è che il nome non sia uguale o contenuto come stringa nel nome di altri file che siamo soliti usare. Il contenuto del "file esca" è irrilevante, ma per renderlo credibilmente allettante è bene non sia un file di 1 kB o un file con un'estensione non associata ad alcun programma.
Usare lo script "CanaryShell"
Una volta avviato lo script CanaryShell, seguendo le consuete modalità per qualunque script PowerShell (impostare adeguata execution policy, etc.), dobbiamo semplicemente fornire i parametri che ci vengono richiesti; questi sono tutti i semplici passaggi (ovviamente chiamare il canary "canarys.txt", ha senso solo a scopo esemplificativo):
Se per errore viene indicato un canary file non esistente, non c'è rischio di innescare un loop infinito di allarmi o di riavvi automatici del PC, perché prima di produrre lo script di monitoraggio, CanaryShell controlla che il file canary indicato esista realmente; se così non è, lo script di monitoraggio non viene generato e viene chiesto all'utente di provvedere a creare prima il file.
Le possibili azioni d'allarme che possono essere innescate dal canary sono:
- disconnessione USB drive (ma non periferiche USB come mouse e tastiera) e utente
- disconnessione USB drive, reti e utente (richiede admin)
- spegnimento pc
- tentativo di riavvio al BIOS (da cui poter impostare boot con sistema live)
- comando personalizzato: si può digitare un comando PowerShell a piacimento, ad esempio "logoff" se si vuole solo disconnettere l'utente corrente; oppure si può inserire un programma da avviare, ad esempio "Notepad.exe" per aprire un notepad in bianco come segnale d'allarme (sapendo che non ci saranno allarmi successivi, salvo modificare lo script); o magari anche azioni più complesse come spostare una determinata cartella in cloud o su una share di rete, poi disconnettersi dalla rete, salvare sul desktop il log dell'evento che ha innescato l'allarme e infine avviare una scansione con Defender; oppure è anche possibile indicare un altro script da lanciare.
Inoltre, sebbene per praticità d'uso nello script generato l'azione d'allarme è la medesima a prescindere dall'evento di "innesco", per chi è un po' pratico di PowerShell è comunque possibile modificare direttamente il codice contenuto in CanaryShell (ci sono dei commenti che possono aiutare ad orientarsi), in modo da avere azioni d'allarme differenziate in base all'evento che le "trigghera". Trattandosi di uno script destinato ad un uso consapevole, in CanaryShell non è stata prevista la bonifica dell'input dell'utente, né la gestione degli errori: se come intervallo fra i monitoraggi viene inserita una lettera, oppure se come comando viene inserito un comando non valido, lo script andrà semplicemente in errore e non funzionerà. Per chi vuole sperimentare con modifiche personalizzate, è comunque disponibile una versione che consente il log degli errori.
Alla fine, se non vengono fatti errori, verrà dunque prodotto uno script PowerShell con il nome e le impostazioni che abbiamo scelto; se ci siamo dimenticati di mettergli estensione "ps1", possiamo chiaramente assegnargliela in un secondo momento. Questo è lo script che avrà il compito di monitorare il canary e la sua cartella; se vogliamo che parta automaticamente all'avvio di Windows, possiamo passare alla fase successiva, tenendo presente che, per chiari motivi di sicurezza, trattandosi di uno script che parte all'avvio è bene salvarlo in una cartella a cui possano accedere solo utenti fidati e a basso rischio di compromissione account..
Impostare il monitoraggio all'avvio di Windows
Per creare un'attività (task) pianificata, digitiamo sulla barra di ricerca Utilità di pianificazione; poi clicchiamo su Esegui come amministratore, menu Azione, Crea attività:
Nella tab Generale, diamo un nome all'attività (magari meno rivelatore di "Canary"), spuntiamo Esegui con i privilegi più elevati, così che lo script possa eseguire anche comandi da admin; possiamo anche configurare la modalità nascosta (non attivata in questo caso):
Clicchiamo sulla tab Attivazione, poi Nuovo e nel campo Avvia l'attività scegliamo All'accesso ed eventualmente altre specifiche; l'importante è che ci sia la spunta in basso su "Attivato":
Clicchiamo OK e passiamo alla tab Azioni, su Nuova, poi Sfoglia:
Su Programma e script (3) dobbiamo sfogliare fino a trovare PowerShell ("C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"), poi su Aggiungi argomento (facoltativo) (4) è necessario inserire "-ExecutionPolicy Bypass -WindowStyle Hidden -File [percorso e nome file]" mettendo come percorso e nome file lo script creato in precedenza da CanaryShell (non quello di CanaryShell, che ormai ha già fatto il suo dovere e non dobbiamo più usare). Clicchiamo quindi su OK.
Nella tab Impostazioni ricordiamoci, se non spegniamo spesso il dispositivo, di disabilitare il limite massimo di 3 giorni di esecuzione dell'attività. Terminate le impostazioni, clicchiamo OK, chiudiamo l'"Utilità di pianificazione" e riavviamo il PC, così da avviare l'attività di controllo del canary. Ad ogni avvio in cui parte il monitoraggio, vedremo comparire brevemente la classica finestra blu di PowerShell.
Monitoraggio
L'azione impostata dall'allarme verrà avviata se:
- il canary, da solo o assieme ad altri file, viene selezionato e copiato o tagliato con combinazioni di tasti
- il canary, da solo o assieme ad altri file, viene selezionato poi viene aperto il menu contestuale (tasto destro), per poi essere copiato, rinominato, etc.
- il canary, da solo o assieme ad altri file, viene spostato o cancellato dal suo percorso originario
- il canary viene citato con nome ed estensione in un comando PowerShell
- la cartella del canary, da sola o assieme ad altre, viene selezionata, viene aperto il menu contestuale (tasto destro) e poi copiata, rinominata, tagliata, spostata o cancellata, oppure se vengono usate combinazioni di tasti come "CTRL+C" o comandi PowerShell la contengono il suo percorso intero come stringa
A scanso di eccessivi timori, ricordiamo che creare nuovi file nella cartella monitorata non fa scattare l'allarme; è quindi possibile farlo sia usando il "Salva con nome" comune nelle applicazioni, sia creando il file localmente con "tasto destro / Nuovo /". Risulta ovviamente possibile aprire e modificare i file già esistenti, senza che l'allarme disturbi la nostra attività.
Come mai fare attenzione anche a quanto accade nel terminale PowerShell? Una funzione dello script intercetta ogni comando PowerShell (ma non CMD) in cui viene nominato il percorso della cartella o il nome del canary; questo per impedire che un malware o un attaccante faccia leva su PowerShell per copiare o cifrare la cartella (o il canary che, di per sé, funge solo da allarme). Ne consegue che anche l'utente stesso, se coinvolge la cartella (o il canary) in comandi PowerShell senza aver prima disattivato lo script, farà scattare l'allarme, proprio come accade con le porte allarmate se vengono aperte dal padrone di casa. Ricordate dunque che se eseguite, anche solo una volta, un comando PowerShell che nomina il canary o la sua cartella, quel comando resterà memorizzato nella history di PowerShell e quindi quando lo script la interrogherà di nuovo, trovando la "citazione" del canary o della sua cartella, attiverà l'azione d'allarme. Per pulire la storico dei comandi PowerShell, non basta chiudere la sessione o pulire lo schermo (CTRL+L) o usare "Clear-History" (che vale solo per la sessione in corso), ma è necessario usare i due comandi: Remove-Item (Get-PSReadlineOption).HistorySavePath -Force per cancellare il file della history e poi, per ricreare il file vuoto, New-Item -Path (Get-PSReadlineOption).HistorySavePath -ItemType File -Force.
Come monitorare anche se il file canary viene aperto? Lo script monitora anche la differenza fra le date di accesso al canary, ma purtroppo Windows non aggiorna sempre in tempo reale la data di ultimo accesso ai file, per limitare le scritture; in alcuni casi possono volerci anche minuti (un'eternità se c'è un attacco in corso) prima che l'ultimo accesso risulti registrato. Si potrebbe eliminare questo ritardo, ma le prestazioni del sistema operativo e del disco ne risentirebbero (ogni accesso a qualunque file comporterebbe una scrittura). Ne consegue che, solo nella maggior parte dei casi (a seconda del refresh dell'ultimo accesso), l'allarme viene innescato anche se il canary viene aperto o viene attivato il suo menu contestuale (tasto destro o SHIFT+F10); oppure anche se il canary, individualmente o all'interno di una selezione multipla, viene compresso utilizzando programmi di terze parti o da remoto (caso ransomware). Lo script non è quindi da considerare, per quanto appena detto, in grado di monitorare sempre attendibilmente il solo accesso (da parte di utenti e programmi) al canary: se qualcuno accede in presenza o da remoto al canary e, senza modificarlo, lo comprime e copia altrove la cartella compressa, non è affatto garantito che l'allarme scatti istantaneamente (e sappiamo quanti dati possano essere spostati in soli pochi secondi nei dispositivi e nelle connessioni moderne).
Se si vuole avere la certezza che l'allarme scatti tempestivamente almeno se il canary viene aperto da chi eccede in maliziosa curiosità, è possibile utilizzare come canary un file Word in cui sia impostata una macro (settando il percorso del canary come "percorso attendibile" per le macro, così da continuare a bloccarle in altri percorsi) che, ad ogni apertura del file, lo auto-modifica (con una modifica "sfuggente", come l'aggiunta di una riga all'inizio del documento) e salva automaticamente tale modifica. Nel momento in cui il file viene aperto, la proprietà del file "ultima modifica", assieme ad "ultimo accesso", verranno aggiornate istantaneamente e prontamente rilevate dallo script che innescherà l'allarme. La macro da inserire e salvare nel documento (in formato ".docm", estensione nota quindi possibilmente nascosta), come nuovo modulo nel VBS editor è:
Sub Document_Open()With Selection.HomeKey wdStory.TypeParagraphActiveDocument.SaveEnd WithEnd Sub
Efficacia
La principali criticità da cui ci si vuole tutelare con questo impiego del canary sono l'esfiltrazione in copia (tramite PowerShell o altro metodo), la cifratura e cancellazione tramite ransomware e la cancellazione/spostamento dolosi. Lo script si è dimostrato nei test sempre affidabile all'istante nei casi di cancellazione e di copia; sporadicamente c'è stato qualche ritardo nella segnalazione del solo accesso ai file, dovuto alla "latenza" del refresh della data di ultima modifica da parte di Windows. Nondimeno, in caso di tentato "prelievo" con accesso fisico alla macchina, è probabile che un malintenzionato usi "CTRL+C" o il mouse (interfaccia di Explorer o tasto destro) per copiare o cancellare i file o la cartella: in tal caso, per aggirare inconsapevolmente l'allarme (di cui si suppone non sia a conoscenza), gli basta cancellare singolarmente i file nella cartella monitorata, senza toccare il canary o la cartella nel suo complesso. Parimenti, se è stato impostato come allarme il logout, ma il malintenzionato è in possesso della password utente e può agire indisturbato sul dispositivo, gli sarà sufficiente reimmetterla (anche se l'inatteso logout magari lo disorienterà per un attimo). Da notare inoltre che la copia tramite trascinamento e tasto destro non innesca l'allarme.
Il consumo di risorse dello script in background, trattandosi di operazioni intervallate di semplice lettura di pochissime informazioni, non è minimamente considerabile un peso anche per sistemi meno performanti.
Nota di gestione errori: se nel task manager, dopo aver disinnescato lo script o cambiato alcune impostazioni dell'attività pianificata, trovate come "risultato ultima esecuzione" l'errore 0xFFFD0000 e lo script di monitoraggio non viene ricaricato al successivo riavvio (ossia non avete quel processo PowerShell in "Gestione attività"), conviene cancellare quel task e ricrearne uno nuovo.
IMPORTANTE: ATTENZIONE AI LOOP
Da considerare che alcune combinazioni possono essere molto rischiose anche per l'utente stesso: ad esempio, se viene scelto come allarme il logout, viene impostato un tempo ridotto (o mantenuto quello di default di 10 secondi) e viene impostato l'avvio dello script all'accesso dell'utente, ciò significa che, se viene rilevato un cambio di data nell'ultima accesso al canary (perché viene cliccato o viene rinominata la cartella, ad esempio), o viene usato PowerShell citando il canary o la sua cartella, l'utente verrà disconnesso. Quando poi proverà a rientrare, essendo ormai registrate la divergenze fra i valori previsti (salvati nel canary) e quelli calcolati all'ultimo accesso (quello cha ha fatto già scattare l'allarme), l'utente avrà 10 secondi prima che parta nuovamente la disconnessione; e così sarà fino a quando non viene bloccato tale allarme. Rimane possibile cavarsela comunque "dall'esterno", accedendo da linea di comando in modalità manutenzione, o da sistema operativi live, etc. e rinominando lo script che lancia gli allarmi.
Una misura preventiva è quella di impostare l'avvio del monitoraggio solo al logon di un determinato utente: se anche viene attivato un potenziale "moto perpetuo" di allarmi, basterà fare il logon con un altro account, magari come admin, per controllare cosa sta succedendo nell'account "allarmato" ed eventualmente disinnescare l'allarme rinominando/cancellando/spostando) lo script di monitoraggio o annullando il corrispettivo task da "Utilità di pianificazione".L'importante è quindi calibrare gli allarmi in base all'uso effettivo del dispositivo, soprattutto considerando cosa accade quando alcune condizioni di alert (ultimo accesso, comandi di PowerShell, etc.) vengono registrate dal sistema e lo script è stato impostato per un monitoraggio continuo.
