Anatomia degli attacchi Crypto-Ransomware
Negli ultimi anni una delle principali minacce informatiche è costituita dai ransomware, che altro non sono che malware la cui finalità è limita l’accesso del dispositivo infettato o cifrare i file dati e richiedere poi un pagamento per sbloccare il sistema o dare modo di riportare in chiaro i file.
Sebbene i ransonware siano divenuti famosi negli ultimi tempi hanno in realtà una storia di circa 18 anni infatti il primo ransomware noto è stato il trojan “AIDS”, noto anche come “PC Cyborg”, scritto nel 1989 da Joseph Popp, che eseguiva un payload il cui scopo era mostrare all’utente l’avviso di scadenza delle licenza di un software installato nel sistema, criptava i file dell’hard disk e obbligava l’utente a pagare 189 dollari alla “PC Cyborg Corporation” per sbloccare il sistema. Sebbene Popp sia stato catturato fu poi dichiarato incapace di intendere e di volere e non venne processato, ma promise di devolvere i proventi del malware alla ricerca per la cura dell’AIDS.
L’idea di usare la crittografia a chiave pubblica per tali attacchi è stata però introdotta 1996 da Adam L. Young e Moti Yung, i quali credevano che il trojan AIDS fosse poco efficace perché usava la crittografia simmetrica, e per esercizio di stile presentarono un criptovirus per il Macintosh SE/30 che usava algoritmi RSA e TEA.
La celebrità dei crypto-ransonware arriva nel maggio 2005 e nella metà del 2006 worm come Gpcode, TROJ.RANSOM.A, Archiveus, Krotten, Cryzip, e MayArchive iniziano ad usare schemi di criptazione RSA molto più sofisticati, con chiavi di dimensione sempre maggiore (Gpcode.AG identificato nel giugno 2006 utilizzava una chiave pubblica RSA a 660 bit) e nel giugno 2008 fu identificato la variante Gpcode.AK che utilizzava una chiave RSA a 1024 bit ed era quindi ritenuta impossibile da decrittare senza uno sforzo computazionale distribuito combinato.
I ransomware a criptazione ritornarono famosi verso la fine del 2013 grazie alla diffusione di CryptoLocker, che usava la piattaforma di valuta virtuale Bitcoin per incassare il denaro del riscatto. Nel dicembre 2013, ZDnet stimò, basandosi su informazioni relative alle transazioni su Bitcoin, che tra il 15 ottobre e il 18 dicembre gli operatori di CryptoLocker avevano incassato circa 27 milioni di dollari dagli utenti infetti.
A sua volta CryptoLocker ha ispirato una serie di imitatori che attaccarono nei mesi seguenti, tra cui CryptoLocker 2.0, CryptoDefense (il quale però inizialmente memorizzava la chiave privata nel sistema infetto in un file modificabile dall’utente, dal momento che usava le API per la criptazione incluse in Windows consentendo quindi di recuperare semplicemente i file cifrati).
In generale i crypto-ransonware agiscono in base al seguente schema:
L’ultima versione di crypto-ransonware è di pochi giorni fa ovvero fine gennaio/inizio febbraio ed è il TeslaCrypt 3.0 che viene inviato alla vittima mediante una e-mail che non ha testo se non la data d’invio (spesso identica a quella inserita nell’oggetto) e un allegato .ZIP che contiene un file con estensione .JS. Lo script non è altro che un dropper il cui scopo è scaricare il payload che infetterà il sistema.
Come riportato in questo post The current state of ransomware: TeslaCrypt pubblicato nel blog di Sophos il TeslaCrypt 3.0 può venire distribuito sfruttando un exploit, come ad esempio quello basato sulla vulnerabilità di Adobe Flash (CVE-2015-0311):
TeslaCrypt is distributed widely via the Angler exploit kit and a few other known exploit kits. Using Angler, it exploits Adobe Flash (CVE-2015-0311) and, once successfully exploited, it downloads TeslaCrypt as a payload.
Angler is exploited via an injected iframe from the compromised website. It redirects to a landing page that is highly obfuscated, contains anti-vm techniques, and performs checks for the presence of antivirus software or malware analysis tools like fiddler, etc.
Dal momento che il payload sfrutta tecniche di offuscamento per evitare di farsi individuare dai programmi antivirus come riportato nel post The current state of ransomware: TeslaCrypt:
Angler is exploited via an injected iframe from the compromised website. It redirects to a landing page that is highly obfuscated, contains anti-vm techniques, and performs checks for the presence of antivirus software or malware analysis tools like fiddler, etc.
For each obfuscation code, it contains de-obfuscation script in the same web page.
Once all the conditions are met, the decrypted URLs download the Flash exploit which, in turn, downloads the ransomware payload in the temp folder.
It also uses Xtea algorithm to decode the encoded payload. Apart from the Flash exploit, we have also seen exploits related to Silverlight and Internet Explorer.
Angler doesn’t use the file-less payload technique – rather it writes the payload ransomware into the disk.
Il payload cifra i file con una una chiave RSA a 4096 bit e ne modifica l’estensione in .XXX, .TTT o .MICRO una volta cifrati i documenti nelle cartelle dove risiedono i file vengono creati i file help_recover_instructions.BMP, help_recover_instructions+xjp.txt e help_recover_instructions+xso.html contenenti le istruzioni per il pagamento del riscatto.
Scendendo nel dettaglio il payload avviato dallo script .js scarica il contenuto fi un file eseguibile e crea un eseguibile dal nome casuale in una directory del profilo utente,per esempio:
C:\Users\NomeUtente\AppData\Roaming\NomeRandom.exe
Inoltre crea una serie di chiavi di registro per assicurarsi che il malware venga avviato automaticamente quando l’utente esegue il login:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run\meryHmas C:\Users\NomeUtente\AppData\Roaming\NomeRandom.exe
HKCU\Software\{random}
HKCU\Software\xxxsys
Se il paylod viene eseguito in una sessione utente con privilegi amministrativi la compromissione del sistema è ovviamente maggiore.
Una volta in esecuzione il malware tenta di cifrare i file con la seguente estensione:
sql, .mp4, .7z, .rar, .m4a, .wma, .avi, .wmv, .csv, .d3dbsp, .zip, .sie, .sum, .ibank, .t13, .t12, .qdf, .gdb, .tax, .pkpass, .bc6, .bc7, .bkp, .qic, .bkf, .sidn, .sidd, .mddata, .itl, .itdb, .icxs, .hvpl, .hplg, .hkdb, .mdbackup, .syncdb, .gho, .cas, .svg, .map, .wmo, .itm, .sb, .fos, .mov, .vdf, .ztmp, .sis, .sid, .ncf, .menu, .layout, .dmp, .blob, .esm, .vcf, .vtf, .dazip, .fpk, .mlx, .kf, .iwd, .vpk, .tor, .psk, .rim, .w3x, .fsh, .ntl, .arch00, .lvl, .snx, .cfr, .ff, .vpp_pc, .lrf, .m2, .mcmeta, .vfs0, .mpqge, .kdb, .db0, .dba, .rofl, .hkx, .bar, .upk, .das, .iwi, .litemod, .asset, .forge, .ltx, .bsa, .apk, .re4, .sav, .lbf, .slm, .bik, .epk, .rgss3a, .pak, .big, wallet, .wotreplay, .xxx, .desc, .py, .m3u, .flv, .js, .css, .rb, .png, .jpeg, .txt, .p7c, .p7b, .p12, .pfx, .pem, .crt, .cer, .der, .x3f, .srw, .pef, .ptx, .r3d, .rw2, .rwl, .raw, .raf, .orf, .nrw, .mrwref, .mef, .erf, .kdc, .dcr, .cr2, .crw, .bay, .sr2, .srf, .arw, .3fr, .dng, .jpe, .jpg, .cdr, .indd, .ai, .eps, .pdf, .pdd, .psd, .dbf, .mdf, .wb2, .rtf, .wpd, .dxg, .xf, .dwg, .pst, .accdb, .mdb, .pptm, .pptx, .ppt, .xlk, .xlsb, .xlsm, .xlsx, .xls, .wps, .docm, .docx, .doc, .odb, .odc, .odm, .odp, .ods, .odt
Se siete interessati ad analizzare i campioni di TeslaCrypt 3.0 si faccia riferimento al seguente post
Nuova ondata di ransomware Teslacrypt 3.0:
Per chi volesse analizzare i campioni del ransomware TeslaCrypt 3.0 inviati durante questa campagna d’infezione o bloccare il sito da cui viene scaricato il payload, forniamo alcuni link:
DROPPER: invoice_DjzkX0.js
https://malwr.com/analysis/ZGM4YWYyODgwMDYyNGU4NThhMGU3YmYyMTYwNGYwZTg
https://www.hybrid-analysis.com/sample/ea83f58ba3184f42673bfdff2518520b9691d7cb10451914edaef5e51abc6d50?environmentId=4
PAYLOAD: 93.zip
Viene scaricato dal dropper dai domini skuawill.com e skuawillbil.com, registrati tramite Key-Systems GmbH e WebNic, con record DNS A verso gli IP 191.101.251.155, 162.221.176.52, 173.82.74.197 e 37.123.101.74
https://malwr.com/analysis/MGI5ZWJiY2YwZDY2NDY5OWJkYzZmNWE5ZTU4MTM2YjM/
https://www.hybrid-analysis.com/sample/0d036a5f5d6b64b64ddee327c8a5c02ce5a8a9ebef46419a65e58884e093aea3?environmentId=1
Per aiutare le vittime di ransonware sono stati resi disponibili vari tool di decriptazione:
- Netherlands’ National Prosecutors Office and Kaspersky Lab RANSOMWARE DECRYPTOR
- TeslaDecrypt (a riguardo si veda il post sul blog di Cisco Threat Spotlight: TeslaCrypt – Decrypt It Yourself)
- TeslaCrack
Inoltre al seguente TeslaDecoder released to decrypt .EXX, .EZZ, .ECC files encrypted by TeslaCrypt è stata resa disponibile la versione 0.0.80 del tool TeslaDecoder che stando al Changelog è in grado di recuperare i file cifrati da TeslaCrypt 3.0.
==========
= 0.0.80 =
==========
– Added support for TeslaCrypt 3.0.0 encrypted files (.xxx, .ttt, .micro).
– Following keys are accepted for decryption of files encrypted by TeslaCrypt 3:
– PrivateKeyTesla (4th Tesla’s private key)
– PrivateKeyRandom1
– PrivateKeyMaster
– PrivateKeySHA256Master
– PrivateKeyRandom2
– PrivateKeyFile
Utile il post di MMPC https://www.microsoft.com/security/portal/mmpc/shared/ransomware.aspx, che contiene info e possibili soluzioni per il recupero dati.
Ottimo lavoro, Ermanno!
Ciao Ermanno,
nel 2013 si era diffuso l’uso di alcune regole AppLocker/Criteri di restrizione software; tali GPO limitavano l’esecuzione di applicativi dalle cartelle dei profili utente.
Possono ancora essere considerate valide?
Ovvio il lavoro più grosso è rendere consapevoli gli utenti…
Ciao Vincenzo e grazie della segnalazione!
You’re welcome, Ermanno! :-)
Ciao R2PO,
impedire l’esecuzione di eseguibili dal profilo utente o utilizzare l’approccio introdotto in Windows 10 con Device Guard per consentire solo l’esecuzione di eseguibili firmati può bloccare il malware, ma in molti casi, soprattutto in contesti aziendali non è applicabile a causa dell’overhead di gestione che comporta e conti alla mano conviene avere un buon sistema di backup che la gestione continua dei blocchi dal momento che orami molte applicazioni vengono eseguite proprio dal profilo utente (si pensi alle portable o a quelle aziendali che fanno cache in locale dei binari per gestire in modo più snello gli aggiornamenti)
Nei prossimi giorni pubblicherò un post sulle mitigations che è possibile mettere in atto nelle infrastrutture aziendali…
Io gestisco una rete di circa 500 postazioni su 15 sedi ed utilizzo le “restrizioni software” fin da quando comparvero nelle policy del glorioso Windows server 2003. Nella mia rete viene consentito solo il codice contenuto nelle cartelle a sola lettura per gli utenti non amministratori (c:\Windows, c:\programmi, netlogon, ecc.) . Ed ovviamente gli utenti non sono MAI amministratori del proprio PC. In questo modo viene eseguito solo il codice installato dagli amministratori.
Questo approccio fino ad ora mi ha salvato dalla totalità dei virus, nonostante gli utenti, pure avvisati, aprano qualunque cosa.
L’overhead riguarda la necessità di intervenire per ogni installazione se ho capito bene?
Potendo bloccare l’esecuzione di exe nel profilo utente ovviamente è la cosa migliore, ma ci sono situazioni di applicazioni magari sviluppate specificatamente per l’azienda che sfruttanto tecniche di autoupdate, ovvero di avviano da share di rete ma poi si copiano in cartelle locali per evitare il dover eseguire setup dal momento che vengono aggiornate con frequenza… in questi scenari occorre per forza lasciare accesso almeno ad alcune cartelle del profilo utente, volendo si può configurare che solo gli exe firmati possano avviarsi, ma questo vuol dire che ad ogni release occorre ricordarsi di firmare l’exe
Un buon compromesso è sboccare solo gli exe o dll con un particolare nome e/o in un particolare percorso della cartella utente. In questo caso è facile creare la policy senza doverla aggiornare ogni volta. Certo teoricamente il virus potrebbe sostituirsi a quell’eseguibile ed avviarsi, ma dovrebbe essere scritto in modo specifico per la rete target da qualcuno che conosca quella policy. Quelli generici verrebbero bloccati.
Io ho usato questo sistema per sboccare un driver di stampa che si ostinava a salvare delle dll nel profilo utente
Certo questo è un approccio che comporta un overhead contenuto… ma oltre col passare del tempo potrebbe capitare che il payload prima di scaricare il malware controlli se esiste nel profilo utente un exe e nel caso lo sovrascrive… putroppo questo tipo di malware è molto “industrializzato” e monitorato da chi fa business tramite esso… puntualmente quando si mettono in campo astuzie per contenerlo il business scende e l’attacante ha eviedenza di questo e compensa modificado il comportamento dei payload…
Un esempio è che in passato di solito il malware tentava di rinominare il file e poi lo cifrava e di conseguenza molti antivirus avevano messo in campo il blocco del rename con una lista di estensioni. Ora il malware apre il file lo cifra e poi lo rinomina di conseguenza bloccare l’estensioni significa non sapere più quali file sono stati cifrati
Comunque il tuo approccio per il momento va bene, ma il consiglio è non dormire comunque sonni tranquilli e attua anche altre linee di difesa
Ciao Ermanno,
innanzitutto grazie e complimenti per questo post.
Ho letto con interesse la tua risposta a R2PO relativamente a possibili attività di mitigazione e sono totalmente d’accordo con te. Credo che in realtà di tipo enterprise, dove le tematiche di security dovrebbero essere di grossa importanza, dove possiamo trovare un ente IT dedicato e dove forse è più facile avere una standardizzazione degli utenti si può lavorare molto su attività preventive di mitigazione, mentre in ambito SMB credo sia nella maggior parte dei casi improponibile non avendo risorse IT dedicate. In questo caso credo si rischierebbe più che altro di arrivare a “blindare” e, di conseguenza, frustrare gli utenti finali.
Lunga vita, pertanto, a un buon sistema di backup che includa anche gli endpoint !
Veeam Endpoint Backup! Numero uno
[…] post Anatomia degli attachi Crypto-Ransomware ho analizzato il modus operandi dei ransomware come CryptoLocker e TeslaCrypt il cui obbiettivo è […]