Crypto-Ransomware mitigations

Nel post Anatomia degli attachi Crypto-Ransomware ho analizzato il modus operandi dei ransomware come CryptoLocker e TeslaCrypt il cui obbiettivo è cifrare i file dell’utente per poi chiederne un riscatto per fornire la chiave di decifratura.

Sinteticamente possiamo schematizzare il funzionamento degli attuali crypto-ransomware come segue:

image

Come ogni minaccia informatica anche i crypto-ransoware possono essere mitigati in modo che non causino danni se non bloccati o che il loro margine di manovra sia quanto più possibile ristretto.

A prescindere dal fatto che il sistema antimalware lato Firewall/UTM (Unified threat management)/proxy, lato sever di posta o sull’end point riesca ad individuare la minaccia ed ad eliminarla evitando di farla arrivare all’utente è necessario impostare delle politiche di sicurezza che agiscano a più livelli in modo da avere una gestione della sicurezza più affidabile.

Va infatti precisato che oggi un sistema di protezione antimalware basato su firme non è più sufficiente dal momento che il numero di minacce e di varianti delle stesse ha raggiunto valori troppo elevati, secondo le statistiche pubblicate su AV-TEST – The Independent IT-Security Institute negli ultimi dodici mesi si arriverebbe ad avere una media giornaliera di circa 390.000 nuovi malware.

The AV-TEST Institute registers over 390,000 new malicious programs every day. These are examined using the analysis tools Sunshine and VTEST, classified according to their characteristics and saved. Visualisation programs then transform the results into diagrams that can be updated and produce current malware statistics.

image

E’ quindi necessario adottare un sistema di UTM (Unified threat management) che al tradizionale sistema di rilevamento basato su firma affianchi anche metodi di rilevamento dinamici, a riguardo i vendor di prodotti di sicurezza hanno messo in campo diverse soluzioni.

Sophos propone ad esempio una gestione centralizzata delle varie tecnologie antimalware lato end point e lato UTM per far sì che possano interagire quando viene individuata una minaccia o viene rilevato un comportamento anomalo (l’end point protection può ad esempio interagire con l’UTM chiedendo il blocco del traffico per quel determinato client verso specifiche destinazioni o l’UTM può richiedere all’end point protection il blocco di un determinato processo su un client in quanto sorgente di traffico anomalo). Inoltre Sophos, come altri vendor ad esempio WatchGuard, tenta di rilevare APT (Advanced Persistent Threat) e Zero-day sfruttando un’analisi comportamentale per determinare se un file è malevolo inoltrando i file sospetti per cui non esiste ancora un firma ad un sandbox in cloud dove il codice viene analizzato in un ambiente virtuale, emulato ed eseguito per determinarne l’effettiva pericolosità.

Se però questi approcci basati su prodotti di sicurezza specifici fallisco nell’individuazione di file o link malevoli (fase 1 del modus operandi) o nel blocco del download del payload del malware  (fase 2 del modus operandi) occorre predisporre, come detto precedentemente, predisporre ulteriori livelli di sicurezza.

Di seguito alcune configurazioni che è possibile implementare in una infrastruttura informatica aziendale basata su Active Directory, ma alcune di queste possono anche essere utilizzate sul computer stand alone.

Blocco degli allegati di posta elettronica

Dal momento la posta elettronica non è un mezzo di scambio file, ma è prima di tutto un mezzo di comunicazione che saltuariamente necessita di allegare file è opportuno bloccare lo scambio di tutti i file che gli utenti non hanno necessità di scambiarsi e che non devono scambiarsi per ragioni di sicurezza perché possono essere un veicolo d’infezione come ad esempio:

  • File applicativi: *.exe, *.lnk, *.pif, *.dll, *.ocx, *.sys, *.scr, *.msi, *.msp, *.gadget, *.application, *.com, *.hta, *.html, *.htm, *.jar, *.cpl, *.msc, *.hlp
  • File VBScript e JavaScript: *.vb, *.vbs, *.vbe, *.js, *.jse
  • File script Monhad (rinominato poi in ProwerShell): *.msh, *.msh1, *.msh2, *.mshxml, *.msh1xml, *.msh2xml
  • File script PowerShell: *.ps1, *.ps1xml, *.ps2, *.ps2xml, *.psc1, *.psc2
  • File script DOS: *.bat, *.cmd
  • File Windows Script: *.ws, *.wsf, *.wsc, *.wsh
  • File di collegamento e configurazione: *.lnk, *.pif, *.sfc, *.inf, *.reg

Dal momento che il file di dropper spesso viene inserito all’interno di un file compresso se possibile è consigliabile anche bloccare i file compressi come *.zip, *.rar, *.7z.

Questo tipo di blocco è ovviamente consigliabile configurarlo sull’UTM e/o sull’antimalware utilizzato dal server di posta in modo che non sia possibile ricevere tali allegati scaricarli tramite il proxy, inoltre se possibile è ovviamente consigliabile configurare il blocco di tali file non basandosi sull’estensione, sull’header del file (per quanto riguada Exchenge Online Protection si veda la

KB2959596 How to reduce malware threats through file attachment blocking in Exchange Online Protection).

Per quanto riguarda Exchange 2013 è possibile bloccare gli allegati tramite la funzionalità di filtro sul server Edge Transport o tramite Transport Rules a riguardo si vedano:

Volendo è possibile anche configurare tale blocco a livello del client di posta, ad esempio per quanto riguarda Outlook a esempio è già configurato per bloccare una lista di tipi di file che è possibile modificare a riguardo si vedano:

Blocco hyperlink nelle mail

Il blocco degli allegati non argina completamente il rischio d’infezione nel caso in cui il veicolo di attacco sia un link contenuto nel corpo della mail che sfrutta un Zero-day o un exploit.

In Outlook il blocco degli hyperlink è gestito in modo nativo sulle mail classificate come junk, a riguardo si veda Turn on or off links in email messages. Quindi se si volesse bloccare tutti gli hyperlink in Outlook occorrerebbe far si che tutta la mail che non arrivi da mittenti attendibili sia classificata come junk.

Un’alternativa, che però giudico al quanto invasiva, potrebbe essere quella di agire sulle associazioni delle estensioni .html, .htm etc (HKEY_CLASSES_ROOT \.ext) oppure sull’associazione estensione-applicazione (per esempio HKEY_LOCAL_MACHINE\SOFTWARE\Classes\htmlfile\shell\open\command). Ovviamente oerò queste impostazioni avrebbero ripercussioni anche sul comportamento del sistema nella gestione degli hyperlink anche al di fuori del client di posta (a riguardo si veda KB310049 Hyperlinks are not working in Outlook)

Un’ultima alternativa è quella di evitare di utilizzare il formato html per mail, a riguardo si veda la KB831607 How to view all e-mail messages in plain text format.

Blocco esecuzione applicazioni da directory del profilo utente

Premesso che impedire l’esecuzione di eseguibili da directory del profilo utente in molti contesti aziendali non è applicabile a causa dell’overhead di gestione che comporta dal momento che molte applicazioni vengono eseguite proprio dal profilo utente, si pensi alle applicazioni portable o a quelle aziendali che fanno cache in locale dei binari per gestire in modo più snello gli aggiornamenti.

In ogni caso ovviamente, laddove sia possibile applicarlo, un sistema di blocco di avvio di applicazioni da directory del profilo utente costituisce un ottimo modo per impedire al payload del crypto-ransomware che si occupa di cifrare i file di poter portare a termine il suo lavoro.

In Windows 10 Enterprise è possibile implementare questo tipo i blocco tramite il Package inspector tool che una delle funzionalità contente in Device Guard, a riguardo si veda il mio precedente post Windows 10: Device Guard.

Nelle versioni precedenti del sistema operativo è possibile utilizzare le Application Control Policies messe a disposizione da AppLocker introdotta in Windows 7 e Windows 2008 R2 e che permette appunto di gestire rules per consentire o bloccare l’esecuzione di applicazioni. Con Windows 10 AppLocker è stato ulteriormente evoluto (a riguardo si veda la sezione dedicata su Technet e AppLocker technical reference) mentre per i requisiti si veda Requirements to use AppLocker.

Visualizzazione estensioni file

Per agevolare l’utente conviene modificare l’impostazione di default di Windows che nasconde le estensioni dei file in modo che sia possibile individuare semplicemente tipi di file che l’utente non è abituato a gestire o a riconoscere allegati che mediante una seconda estensione cercano di spacciarsi per file conosciuti (per esempio fattura.pdf.exe).

La visualizzazione delle estensioni dei file è possibile impostando a 0 la chiave di registro HideFileExt in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced.

Anche se non esiste una Group Policy specifica per gestire la visualizzazione delle estensioni dei file è possibile utilizzare le Group Policy Preferences per impostare la chiave di registro, a riguardo si veda Configure a Registry Item:

image

In alternativa è possibile utilizzare la Group policy preference per la gestione delle Folder Options extension

image

Implementazione di EMET

Enhanced Mitigation Experience Toolkit (EMET) è un tool rilasciato da Microsoft progettato per difendersi da vulnerabilità Zero-day e per fornire protezione contro le corruzioni della memoria per le applicazioni più comuni. Per maggiori informazioni si veda il mio post Enhanced Mitigation Experience Toolkit.

Restrizione dei permessi di scrittura sulle cartelle dei file server

Per contenere i danni in casi di infezione occorre ridurre la superficie di azione del malware assicurandosi che ciascun utente abbia il diritti di poter modificare esclusivamente i file di propria competenza che risiedono sulle cartelle dei file server.

E’ possibile verificare i privilegi assegnati a gruppi od ad utenti sulle cartelle tramite i seguienti tool sviluppati da Mark Russinovich:

  • AccessChk: tool a riga di comando per il check delle permissions di utenti/gruppi
  • AccessEnum: tool grafico per eseguire il dump delle permissions NTFS
  • ShareEnum: tool grafico per eseguire il dump delle permissions sulle shares

Inoltre Netwrix mette a disposizione il suo tool free Netwrix Effective Permissions Reporting Tool.

Auditing delle operazioni sui file

Oltre a predisporre misure atte a contrastare l’operato del malware occorre anche configurare i file server in modo che eseguano l’auditing dei file modificati in modo che sia possibile risalire rapidamente a quale utente abbia eseguito operazioni di rename sui file e quindi sia stato infettato dal ransomare.

Per impostare l’auditing sulle cartelle di un file server è possibile utilizzare le GPO locali o di dominio Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies che hanno sostituito le GPO legacy di Windows Server 2003 Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy.

Per i passi necessari alla configurazione dell’auditing  si veda il post Auditing File Access on File Servers, mentre per uno script Powershell che implementa un report HTML giornaliero dei file modificati ed eliminati si veda https://How to audit changed / deleted files – ver 1.25.

Esistono ovviamente molti tool che offrono la possibilità di gestire l’auditing delle operazioni eseguite sui file, ad esempio Netwrix offre il tool free Netwrix Change Notifier for File Servers che permette un auding di base senza limitazioni di utilizzo e maggiori funzionalità di analisi tramite la suite Netwrix Auditor.

Conclusioni

Ovviamente questo è solo un elenco delle principali contromisure che è possibile mettere in campo per arginare un’infezione da ransomware e non ha la pretesa di essere esaustivo. Inoltre come vuole la filosofia della sicurezza informatica le misure di difesa vanno riviste periodicamente in base alla dinamicità delle minacce e delle possibilità offerti dai prodotti software coinvolti nel processo d’infezione.

Si tenga anche presente che occorre mettere in campo quante più misure di difesa possibile, inoltre ogni contromisura va ponderata prima di essere implementata per evitare che se bypassata possa costituire un aggravio dell’infezione. Ad esempio il blocco delle estensioni non gestite nell’organizzazione potrebbe sembrare e con le prime versioni del ransomware era un buona idea per bloccare l’esecuzione del codice malware, le ultime versioni però prima cifrano il file e poi tentano di rinominarlo col risultato che se il rename non va a buon fine in caso d’infezione non sarà possibile distinguere tra file cifrati e quelli non  corrotti dal malware.