TG Soft Security Software Specialist - Vir.IT eXplorer: AntiVirus-AntiSpyware-AntiMalware-AntiRansomware
Identifica virus/malwareIdentifica virus polimorfici grazie a DEEP SCANMacro Virus AnalyzerTecnologia INTRUSION DETECTIONTools rimozione virus/malwareInstallazione su Active DirectoryProtezione Real-Time 16/32/64 bitVir.IT Scan MailVir.IT Console Client/ServerVir.IT WebFilter ProtectionAggiornamenti automatici Live-UpdateVir.IT Personal FirewallAssistenza tecnica in lingua italianaCentro Ricerche Anti Malware


Attiva la tua Licenza Invia file sospetto Newsletter

fb rss linkedin twitter

ICSA Lab ICSA Lab

Vir.IT eXplorer PRO supera il test internazionale VB100 2019-06

AMTSO

OpsWat



EICAR Membro SERIT - Security Research in ITaly

24/06/2019 17:14:48 - Analisi tecnica del ransomware REvil - Sodinokibi e Threat Intelligence Report

Italiano  Inglese

      
 
 

Il ransomware Sodinokibi, conosciuto anche con il nome di REvil, ha fatto la sua prima apparizione nel mese di aprile 2019, dove sfruttava una particolare vulnerabilità di Oracle WebLogic Server per diffondersi.

Il C.R.A.M. (Centro di Ricerca Anti-Malware) di TG Soft ha analizzato negli ultimi mesi l’evoluzione di questo ransomware.

Scarica il report in PDF: Analisi tecnica e Threat Intelligence REPORT

Last update: 2019-08-08

INDICE

Introduzione

In Italia la sua prima apparizione risale al 24 maggio 2019 con un attacco RDP, come abbiamo segnalato nel tweet del 28 maggio 2019:

Gli autori del ransomware Sodinokibi, anche se sono alle prime versioni della loro creazione, sembrano avere una lunga esperienza nella creazione di questa tipologia di progetto criminale.

Alcuni ricercatori hanno individuato delle similitudine con il ransomware GandCrab, quest’ultimo ha pubblicato ufficialmente a inizio giugno la chiusura del progetto. Sembrerebbe che il candidato a occupare il vuoto lasciato dal GandCrab sia proprio il ransomware Sodinokibi.

 Tweet

Vettore d’infezione

Il ransomware Sodinokibi usa diverse metodologie per diffondersi:
  • Vulnerabilità di Oracle WebLogic Server
  • Attacco RDP
  • Campagne di Malspam
  • Watering hole
  • Uso Exploit kit e malvertising
In Italia abbiamo osservato diverse tipologie di diffusione implementate dal ransomware. A parte la vulnerabilità di Oracle WebLogic Server, le altre metodologie elencate sopra sono state riscontrate infezioni in Italia.

Il primo attacco che abbiamo registrato risale al 24 maggio 2019, in questo caso il ransomware Sodinokibi si diffondeva attraverso un attacco RDP. L’attacco via RDP, eseguendo un brute force sulle credenziali, è già stato utilizzato da altri ransomware come il Dharma.

Interessante notare che l’IP utilizzato dall’attaccante per accedere via RDP era 151.106.56[.]254, questo stesso IP è stato individuato in altri attacchi RDP nel mese di giugno 2019.

Altri attacchi che abbiamo individuato sono avvenuti attraverso campagne di malspam nel mese di giugno. Queste campagne avevano come tema:
  • Booking.com
  • DHL
Il tema di “Booking.com” nel mese estivo è molto azzeccato visto l’avvicinarsi delle vacanze, questo può indurre molte persone ad aprire l’allegato infetto.

Nelle figure sottostanti possiamo vedere le due campagne di malspam del Sodinokibi.

Booking DHL

In Italia abbiamo avuto il primo caso di watering hole sul sito “winrar.it” del distributore italiano di WinRar. Dal pomeriggio fino a tarda sera del 19 giugno 2019 veniva scaricato un file infetto dal ransomware Sodinokibi al posto del setup di WinRar.

Nel 2016 il sito di “winrar.it” era già stato colpito dall’APT StrongPity, anche in questo caso stiamo parlando di attacco watering hole, dove il setup di WinRar era stato modificato in modo da contenere oltre al programma di installazione il malware spia StrongPity.

Se nel 2016 l’attacco a “winrar.it” era avvenuto da un gruppo professionista di Cyber-spionaggio, nell’attacco del 2019 si sono limitati a sostituire il setup di WinRar con Sodinokibi.
Chi ha prelevato nel pomeriggio del 19 giugno WinRar, poteva accorgersi immediatamente che nel file scaricato qualcosa non andava bene, infatti le icone del file scaricato non sono quelle di WinRar ma di un cerchio rosso sbarrato o di un pupazzo di neve, come possiamo vedere in figura:
Icona Icona 2
Inoltre l’esecuzione del file non comportava l’installazione di WinRar, come invece era successo con StrongPity.

Chi ha eseguito l’attacco di watering hole a winrar.it ha sfruttato in malo modo l’occasione.

Altri casi di diffusione in Italia del Sodinokibi sono stati osservati attraverso attacchi di malvertising in data 7 giugno 2019.

Gli autori del Sodinokibi sembrano essere molto attivi nella diffusione della loro creazione.
Torna ad inizio pagina

Analisi ransomware Sodinokibi

Vediamo quindi l’analisi tecnica riferita alla versione 1.1 di Sodinokibi.

Quando viene eseguito un file infetto da Sodinokibi, il ransomware per prima cosa crea un mutex differente per ogni build, come ad esempio:
  • Global\D382D713-AA87-457D-DDD3-C3DDD8DFBC96
A questo punto viene decifrato con RC4 una sezione del file, che contiene la configurazione del malware strutturata in questo modo:

{
    "pk": "",
    "pid": "",
    "sub": "",
    "dbg": ,
    "fast": ,
    "wipe": ,
    "wht": {
        "fld": [],
        "fls": [],
        "ext": []
    },
    "wfld": [],
    "prc": [],
    "dmn": "",
    "net": ,
    "nbody": "",
    "nname": "",
    "exp": ,
    "img": ""
}

Nella seguente tabella vediamo la descrizione dei campi:

Campo Descrizione
pk

Chiave pubblica in base64

pid

Identificatore distributore

sub

Identificatore della sottoscrizione

dbg

Debug: true/false

fast

True/False

wipe

True/False

wht -> fld

Esclusione cartelle

wht -> fls

Esclusione files

wht -> ext

Esclusione in base alle estensioni

wfld

Wipe folder

prc

Processi da terminare

dmn

Domini C2

net

Cifratura dei file nella rete: true/false

nbody

Istruzioni del riscatto

nname

{EXT}-readme.txt (dove EXT è l’estensione del file cifrato)

exp Exploit True/False
img

Immagine del desktop con alert della cifratura


Se il campo “exp” è “true” allora viene eseguita una shellcode a 32 o 64 bit con l’exploit CVE-2018-8453 per l’elevazione dei privilegi.

Il passo successivo è la creazione della chiave di registro REcfg se non già presente:
  • HKEY_LOCAL_MACHINE\SOFTWARE\recfg
Se non dispone delle autorizzazioni sufficienti, la chiave viene creata in HKEY_CURRENT_USER.
All’interno di REcfg vengono creati i seguenti valori:
  • pk_key
  • sk_key
  • 0_key
  • rnd_ext
  • stat
asm_shellcode
Torna ad inizio pagina

Calcolo delle chiavi private e pubbliche

A questo punto vengono calcolate le chiavi private e pubbliche, come possiamo vedere in figura:

asm_preparazione_chiavi_privata_pubblica


Le chiavi private e pubbliche vengono calcolate in questo modo:


asm_calcola_key_privata_pubblica

La chiave privata viene generata partendo da un numero random di 256 bit, come possiamo vedere in figura dalla sua subroutine di generazione del PRNG (PseudoRandom Number Generators):

asm_prng_random_number

La funzione per la generazione del PRNG utilizza l’hardware Intel Ivy Bridge, basato sulle linee guide del NIST’s SP 800-90, attraverso la chiamata dell’istruzione assembly rdrand.

Il numero random generato, prima che diventi la chiave privata, viene elaborato come nella figura a destra.

asm_last_step_chiave_privata
A questo punto viene generata la chiave pubblica a partire dalla chiave privata. La coppia di chiavi (privata e pubblica) è generata attraverso il metodo delle curve crittografiche ellittiche ECC (Elliptic Curve Cryptography).

Sia la chiave privata sia la chiave pubblica sono 2 numeri a 256 bit che individuano 2 punti nella curva ellittica.

Lo scambio delle chiavi avviene con il metodo chiamato “Elliptic Curve Diffie-Hellman” (ECDH), dove:
dAPB = dBPA
Sia G un punto fisso della curva, dove:
  • dA = key privata di A (numero segreto casuale)
  • PA = G*dA = key pubblica di A (il punto G è moltiplicato da dA)
  • dB = key privata di B (numero segreto casuale)
  • PB = G*dB = key pubblica di B

Sodinokibi usa la curva ellittica “Curve25519” con G={9}, sviluppata da Dan Bernestein, come supposto nel tweet di Eric Klonowski (@noblebarstool).

Ora che Sodinokibi ha generato in memoria la coppia ECC di chiavi privata e pubblica che chiameremo rispettivamente dk_key e pk_key, la chiave pubblica viene memorizzata nel chiave di registro recfg all’interno di pk_key:

HKEY_LOCAL_MACHINE\SOFTWARE\recfg

[pk_key] = Chiave pubblica

Torna ad inizio pagina

Struttura dati sk_key

A questo punto viene generata la struttura dati sk_key, attraverso la chiamata alla subroutine Sub_13597B:

pBuff_sk_key = Sub_13597B (key_pubblica_json, key_privata, size IN, size out)

Lo scopo di Sub_13597B è quello di cifrare la chiave privata generata all’interno della struttura dati sk_key.


La Sub_13597B prende in input 4 parametri:
  • key_pubblica_json: chiave pubblica “pk” all’interno della sezione di configurazione in json
  • key_privata: chiave privata generata “dk
  • size IN: dimensione della chiave privata “dk
  • size out: dimensione della struttura sk_key
La subroutine Sub_13597B esegue i seguenti passi:
  1. Alloca un buffer da 0x58 byte e copia dall’offset 0x4 la chiave privata (dk_key) “key_privata”
  2. Calcola una nuova coppia di chiavi ECC privata (dk_new) e pubblica (pk_new)
  3. Calcola dk_new*pk -> shared_key_new (dove pk è la chiave pubblica della sezione di configurazione in json) e il risultato viene “hashato” con SHA-3.
  4. Calcola un numero casuale di 16 byte -> random_16 che verrà utilizzato come IV (vettore di inizializzazione per AES)
  5. Cifra il buffer allocato da 0 a 0x24 con AES-256 CTR attraverso il vettore di inizializzazione IV e SHA-3 (shared_key_new)
  6. Copia nel buffer allocato all’offset 0x24 la chiave pubblica pk_new
  7. Copia nel buffer allocato all’offset 0x44 il numero casuale random_16
  8. Calcola il CRC32 del buffer allocato da 0 a 0x24 e salva il risultato all’offset 0x54

La subroutine Sub_13597B restituisce il puntatore al buffer allocato di 0x58 byte della struttura dati sk_key.
La struttura dati sk_key, che vediamo nella figura a destra, verrà memorizzata nel registro sotto l’omonima voce.
sk_key

Nella figura sottostante possiamo vedere la chiamata ad AES-256 in modalità CTR:

asm_aes_ctr

AES CTR segue il seguente schema:

schema_aes_ctr
Torna ad inizio pagina

Struttura dati 0_key

Ora viene generata la struttura dati 0_key, sempre attraverso la chiamata alla subroutine Sub_13597B:

pBuff_0_key = Sub_13597B (master_key_pubblica, key_privata, size IN, size out)


La procedura per la generazione della struttura dati di 0_key è analoga a quella di sk_key, in questo caso viene utilizzata una “master key pubblica” memorizzata all’interno del file eseguibile al posto della chiave pubblica pk (quella del json).

La master key pubblica “embedded” è:

79 CD 20 FC E7 3E E1 B8 1A 43 38 12 C1 56 28 1A

04 C9 22 55 E0 D7 08 BB 9F 0B 1F 1C B9 13 06 35


All’interno di 0_key abbiamo la chiave privata dk cifrata attraverso la “master public key”.

Anche la struttura dati 0_key, che vediamo nella figura sottostante, verrà memorizzata nel registro sotto l’omonima voce.
0_key

Chiave di registro “rnd_ext”

All’interno della chiave di registro REcfg viene memorizzato il valore “rnd_ext”, che contiene l’estensione dei file cifrati calcolata in modo casuale.

Chiave di registro “stat”

All’interno della chiave di registro REcfg viene memorizzato il valore “stat”, che contiene la seguente stringa formattata:

{"ver":%d,"pid":"%s","sub":"%s","pk":"%s","uid":"%s","sk":"%s",
"unm":"%s","net":"%s","grp":"%s","lng":"%s","bro":%s,"os":"%s",
"bit":%d,"dsk":"%s","ext":"%s"}

Questa viene memorizzata all’interno di “stat” in forma cifrata e codificata in base64.

Nome

Descrizione
ver Versione di Sodinokibi
pid PID del json
sub SUB del json
pk PK del json
uid CRC32 di “processor brand string” e Volume Serial Number (8 bytes)
sk sk_key in BASE64
unm Nome utente
net Nome del computer
Grp Nome del gruppo di lavoro o dominio
lng Codice lingua
bro True / False in base al codice della lingua
Os Sistema Operativo
Bit Valore 86 o 64
Dsk Informazioni dei dischi in base 64 (drive e spazio libero)
Ext Estensione dei file cifrati

Paesi considerati “amici” sulla base del valore di “bro”:
  • Romania
  • Russia
  • Ucraina
  • Bielorussia
  • Estonia
  • Lettonia
  • Lituania
  • Tajikistan
  • Iran
  • Armenia
  • Azerbaijan
  • Georgia
  • Kazakistan
  • Kyrgyzstan
  • Turkmenistan
  • Uzbekistan
Il ransomware Sodinokibi termina il processo corrente se la lingua della tastiera risulta essere appartenente alla lista dei paesi considerati “amici”.

La stringa formattata “stat” viene cifrata con una chiave master pubblica memorizzata all’interno del file eseguibile.

La master key pubblica “embedded” è:

36 7D 49 30 85 35 C2 C3 68 60 4B 4B 7A BE 83 53

AB E6 8E 42 F9 C6 62 A5 D0 6A AD C6 F1 7D F6 1D

Torna ad inizio pagina

Istruzioni del riscatto

Successivamente vengono preparate le istruzioni del riscatto partendo dal body che viene estratto dal campo “nbody” della configurazione json.
Il body viene formattato con i seguenti valori:
  • uid
  • rnd_ext
  • stat in base 64
L’”uid” è l’user ID calcolato dal CRC di “processor brand string” e Volume Serial Number che viene utilizzato per comporre l’URL dove sarà possibile effettuare il pagamento del riscatto:
  • http://aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd.onion/<uid>
  • http://decryptor.top/<uid>


Termina Processi e Cancella Shadow Copy

In questa fase vengono terminati i processi elencati nel JSON di configurazione alla voce “prc” e cancellate le Copie Shadow di Windows con il seguente comando:

cmd.exe /c vssadmin.exe Delete Shadows /All /Quiet & bcdedit /set {default} recoveryenabled No & bcdedit /set {default} bootstatuspolicy ignoreallfailures

Wipe

In seguito il malware verifica il valore di “wipe” nel JSON di configurazione e se posto a true cancella tutti i file contenuti nelle cartelle che corrispondono al valore “wfld” del JSON di configurazione.

Cifratura dei file

Viene creato un nuovo Thread che rimane in attesa sulla funzione “GetQueuedCompletionStatus”.

Vengono enumerati tutti i file nei dischi locali e nelle cartelle di rete (solo se il parametro “net” del JSON di configurazione è a valore “true”), per procedere quindi alla cifratura dei file.

In ogni cartella viene creato un file .lock e le istruzioni del riscatto con nome {estensione random}-readme.txt.

Vengono esclusi dalla cifratura i file e le cartelle che corrispondono al campo JSON “wht” che contiene i sottocampi “fld”,”fls” e ”ext”, che stanno rispettivamente per “folder”, “files” e “estensione”.

Ne riportiamo un esempio:

"wht": {
        "fld": ["google", "mozilla", "$windows.~bt", "programdata", "$recycle.bin", "program files (x86)", "appdata", "msocache", "program files", "windows.old", "$windows.~ws", "application data", "perflogs", "windows", "boot", "intel", "system volume information", "tor browser"],
        "fls": ["bootsect.bak", "autorun.inf", "ntldr", "ntuser.dat.log", "ntuser.ini", "boot.ini", "ntuser.dat", "bootfont.bin", "desktop.ini", "thumbs.db", "iconcache.db"],
        "ext": ["exe"]
    }

Per ogni file candidato alla cifratura viene generata una chiave di Salsa20 nel seguente modo:

asm_salsa20key

L’algoritmo di cifratura utilizzato da Sodinokibi è Salsa20.

La chiave di cifratura per Salsa20 è ottenuta in questo modo:

  1. Calcola una nuova coppia di chiavi Private/Pubbliche ECC (dk_new_file, pk_new_file)
  2. Calcola SHA-3 (dk_new_file*pk_key) -> shared_key_salsa (dove pk_key è la chiave pubblica memorizzata nel registro alla voce pk_key). In shared_key_salsa avremo la chiave che viene inserita nella tabella master di Salsa20.
  3. Calcola un numero casuale di 8 byte per il Vettore di inizializzazione della tabella master di Salsa20.
  4. Compone la tabella master di Salsa20.
Viene creata in memoria una struttura dati che contiene:
  • Handle del file da cifrare
  • sk_key
  • 0_key
  • pk_new_file
  • Il vettore di inizializzazione di Salsa20
  • Il CRC32 di pk_new_file
  • Tabella master di Salsa20
Questa struttura dati viene passata al Thread creato in precedenza attraverso le funzioni API:
  • CreateIoCompletationPort
  • PostQueuedCompletionStatus
Il thread è in attesa sulla funzione API GetQueuedCompletionStatus, quando riceve una nuova chiamata inizia la fase di cifratura del file attraverso l’algoritmo Salsa20 e successivamente appende una parte della struttura dati che contiene i seguenti campi:
  • sk_key
  • 0_key
  • pk_new_file
  • Il vettore di inizializzazione di Salsa20
  • Il CRC32 di pk_new_file
La dimensione della parte appesa varia in base alla versione del malware Sodinokibi. Nelle versioni 1.0 e 1.1 la lunghezza è di 0xE0 byte mentre nella versione 1.2 è di 0xE4 byte.

In figura possiamo vedere lo schema di cifratura di Sodinokibi versione 1.1:

sodinokibi_encryption_scheme
Torna ad inizio pagina

Immagine del desktop

Terminata la cifratura dei file, il passo successivo è la modifica dell’immagine del desktop, che possiamo vedere nella figura a destra.
L’immagine viene generata utilizzando le funzioni API per la grafica BitMap e attraverso la funzione “DrawText” viene inserito il testo che viene caricato dal JSON di configurazione al campo “img”.
sodinokibi_desktop

Server C2

All’interno del JSON di configurazione vi troviamo una lista di 1079 domini.
Sodinokibi contatta ogni dominio di questa lista generando un URL attraverso un algoritmo DGA utilizzando i seguenti termini:

Termine Estensione
  • wp-content
  • pictures
  • news
  • pics
  • admin
  • data
  • temp
  • graphic
  • game
  • static
  • assets
  • tmp
  • uploads
  • images
  • include
  • image
  • content
  • jpg
  • gif
  • png

https://<host>/<termine 1>/<termine 2>/
<random chars>.<estensione>

Alcuni esempi:

https://stagefxinc[.]com/wp-content/pictures/pmkapi.jpg
https://birthplacemag[.]com/admin/pictures/hpxxqbak.gif
https://clemenfoto[.]dk/news/pics/ohxkyt.gif
https://wineandgo[.]hu/admin/pics/ahlpbrzo.jpg
https://lexced[.]com/data/temp/hpttgdyg.png

Sodinokibi attraverso un “POST” invia ad ogni dominio della lista la struttura dati “stat” in forma cifrata.

Dalla nostra analisi solo i seguenti domini hanno risposto con “HTTP/1.1 200 OK”:

www[.]zuerich-umzug[.]ch
belofloripa[.]be
www[.]soundseeing[.]net
utilisacteur[.]fr
www[.]airserviceunlimited[.]com
www[.]mediahub[.]co[.]nz
www[.]irizar[.]com
www[.]cleanroomequipment[.]ie
www[.]pinkxgayvideoawards[.]com
www[.]rhino-turf[.]com
mike[.]matthies[.]de
drbenveniste[.]com
scotlandsroute66[.]co[.]uk
m2graph[.]fr
geitoniatonaggelon[.]gr
insane[.]agency
acb-gruppe[.]ch
www[.]cardsandloyalty[.]com
www[.]sbit[.]ag
yourhappyevents[.]fr
tieronechic[.]com
mariajosediazdemera[.]com
www[.]skyscanner[.]ro
11[.]in[.]ua
funworx[.]de
www[.]omnicademy[.]com
www[.]bratek-immobilien[.]de
metroton[.]ru

Ma questo non significa che uno di questi domini sia quello del server C2 di Sodinokibi.
Torna ad inizio pagina

Pagamento riscatto

In base alle istruzioni del riscatto la vittima deve collegarsi ai seguenti domini per le modalità di pagamento:
  • http://aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd[.]onion/<uid>
  • http://decryptor[.]top/<uid>
Come primo step (img.1) viene richiesto di inserire l’estensione random e il valore “Key” contenuto nelle istruzioni del riscatto (si tratta della versione di “stat” cifrata in base64).

Una volta inseriti i dati viene generato l’importo del pagamento (img.2) e vengono fornite le istruzioni su come reperire i BitCoin (img.3) ed in aggiunta una Chat di supporto (img.4) come è possibile vedere nelle successive immagini.

Riscatto1
img.1
Riscatto2
img.2
Riscatto3
img.3
Riscatto4
img.4

Il wallet per il pagamento è generato in automatico per ogni vittima, il prezzo del riscatto è di 2500$ che raddoppia a 5000$ se non viene effettuato il pagamento entro 7 giorni.


Come avviene la decifratura

Per recuperare i file cifrati da Sodinokibi è necessario conoscere la private key “dk_key”. Questa chiave viene cifrata all’interno di “sk_key” e di “0_key”.

Gli autori di Sodinokibi recuperano la chiave “dk_key” nei seguenti modi:
  1. Decifrando sk_key
  2. Decifrando 0_key
Per decifrare “sk_key” gli autori di Sodinokibi utilizzano la chiave privata “dk” che solo loro conoscono. La chiave privata “dk” è la controparte della chiave pubblica “pk” memorizzata nel json di configurazione.
All’interno della struttura “sk_key” vi è in chiaro la chiave pubblica “pk_new”.
Viene calcolato il valore: dk * pk_new = shared_key_new
La “shared_key_new” è uguale anche a: dk_new*pk.

La private key (dk_key) è cifrata con AES-256 CTR attraverso la “SHA-3 (shared_key_new)” e il random number (IV) che si trova all’offset 0x44.
Decifrando con AES-256 il buffer da 0x4 a 0x24 con “SHA-3 (shared_key_new)” e il random number si ottiene “dk_key”.

La stessa operazione può essere ripetuta partendo da “0_key”, in questo caso per ottenere la “dk_key” viene utilizzata la master private key che solo gli autori di Sodinokibi conoscono.
sk_key


Nota ora la dk_key per determinare la chiave di cifratura utilizzata in Salsa20 si esegue la seguente operazione:
SHA-3 (dk_key *pk_new_file) = shared_key_salsa
Dove pk_new_file è la chiave pubblica appesa in chiaro alla fine del file cifrato.

shared_key_salsa è anche uguale a SHA-3 (dk_new_file*pk_key)

In shared_key_salsa avremo la chiave che viene inserita nella tabella master di Salsa20.
A questo punto è possibile decifrare i file attraverso la shared_key_salsa.
file_encrypted

sodinokibi_decryption_scheme
Torna ad inizio pagina

Versioni

Gli autori di Sodinokibi hanno sviluppato le seguenti versioni:

Versione Data Dimensione Dati appesi
1.0a 2019-04-23 0xe0
1.0b 2019-04-27 0xe0
1.0c 2019-04-29 0xe0
1.1 2019-05-05 0xe0
1.2 2019-06-10 0xe4
1.3a 2019-07-08 0xe4
1.3b 2019-08-02 0xe4

Versione 1.2

Nella versione 1.2 è stata aggiunta la chiave di registro “sub_key” che contiene la chiave pubblica del json di configurazione (pk) e la dimensione dei datti appesi nei file cifrati è di 0xe4 bytes, dove viene aggiunta un ulteriore dword di controllo con valore 0.

Versione 1.3

Nella versione 1.3 è stato aggiunto il campo “svc” nel json di configurazione, in questo campo è contenuto una lista di servizi da cancellare, come possiamo vedere in figura.

Inoltre per verificare se la vittima appartiene ad uno stato “amico”, oltre al controllo della tastiera sono stati aggiunti i controlli sulla lingua default e di sistema, come possiamo vedere in figura.

Usa WQL per la determinazione della creazione dei processi:

SELECT * FROM __InstanceCreationEvent WITHIN 1 WHERE TargetInstance ISA 'Win32_Process'

Inoltre utilizza una nuova chiave di registro al posto della “REcfg”:
  • HKEY_LOCAL_MACHINE\SOFTWARE\QtProject\OrganizationDefaults
All’interno di QtProject\OrganizationDefaults vengono creati i seguenti valori:
  • pvg
  • sxsP
  • BDDC8
  • f7gVD7
  • Xu7Nnkd
  • sMMnxpgk
Tabella di confronto tra la versione 1.2 e 1.3:

Vers. 1.2: REcfg Vers. 1.3a: QtProject\OrganizationDefaults
 sub_key  pvg
 pk_key  sxsP
 sk_key  BDDC8
 0_key  f7gVD7
 rnd_ext  Xu7Nnkd
 stat  sMMnxpgk



Telemetria

E’ stato monitorato l’andamento delle campagne malware di Sodinokibi nell’arco dei mesi di Aprile 2019/Luglio 2019.

Nella tabella sottostante possiamo vedere le campagne monitorate:

statistiche

Nella tabella possiamo vedere i seguenti campi:
  1. Data Campagna
  2. Tipologia Campagna
  3. PK (chiave pubblica presente nel JSON di configurazione)
  4. PID presente nel JSON di configurazione
  5. SUB presente nel JSON di configurazione
  6. Versione di Sodinokibi
  7. Data di compilazione del file master di Sodinokibi
Il campo PID va ad identificare il gruppo che ha acquistato il servizio Ransomware Sodinokibi (RAAS). Il campo SUB sembra invece identificare la “SUBSCRIPTION” ovvero il periodo di validità del servizio.

Le coppie PID & SUB uguali hanno sempre la stessa chiave pubblica PK come si può vedere nei casi PID: 7 e SUB: 3.

Si può notare che il gruppo con PID 7 è stato il primo ad usare Sodinokibi attraverso la campagna che sfruttava la vulnerabilità di Oracle Weblogic il 25 Aprile 2019 (SUB: 3), lo stesso gruppo sembra essere associato alla campagna dell’attacco di Watering Hole al distributore italiano di Winrar il 19 Giugno 2019 con una nuova SUB: 474.

Come si può vedere il gruppo con PID: 7 ha acquistato più periodi di sottoscrizione. Utilizzando il trio PID-SUB-PK si possono individuare le campagne associate allo stesso attore.

Fino ad inizio Luglio 2019 il PID con valore più alto è stato 40 facendo quindi ipotizzare che vi siano almeno 40 gruppi differenti. Il valore massimo di SUB è stato 607 che potrebbe indicare siano stati acquistati almeno 607 periodi di sottoscrizione.

Nel grafico visibile qui sotto mettiamo in relazione la data di compilazione del malware con il valore SUB contenuto nel JSON di configurazione. E’ subito possibile notare come la crescita sia in forte aumento facendo supporre che il CryptoMalware Sodinokibi sia appunto distribuito con il metodo “as-a-service”.

grafico_statistiche
Torna ad inizio pagina

Conclusioni

Il Ransomware Sodinokibi è stato realizzato da soggetti con un certo livello di conoscenza tecnica ed è attivamente sviluppato, molto probabilmente non sono alla loro prima creazione di Ransomware.

Il progetto è chiaramente strutturato per essere distribuito come servizio (raas).

Il Ransomware Sodinokibi utilizza lo scambio di chiavi ECDH e la cifratura dei dati avviene attraverso l’algoritmo Salsa20.

La distribuzione nell’ultimo mese ha avuto una forte impennata, attraverso varie tipologie di diffusione come Malspam, RigEK, attacchi RDP, ecc. Molto probabilmente la recente decisone dei creatori di GandCrab di chiudere ufficialmente il progetto ha aperto la strada a nuovi attori e Sodinokibi sembra aver sfruttato subito l’occasione.

IOC

MD5:
DB42F17991A7BA10218649B978D78674
E713658B666FF04C9863EBECB458F174
16863F6727BC5DD44891678EBCA492D2
FD3F3AF76D31D8F134E2E02463D89D29
6E543C13594F987A6051BC3D9456499F
CCFDE149220E87E97198C23FB8115D5A
FB68A02333431394A9A0CDBFF3717B24
692870E1445E372DDD82AEDD2D43F9B8
DB6D3A460DEDE97CA7E8C5FBFAEF3A72
48A673157DA3940244CE0DFB3ECB58E9
79F2341510D9FB5291AEFC3E69D18253
3DF42FA9732864A9755F5C8FB7ED456A


URL:
aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd[.]onion
decryptor[.]top

Autori: Gianfranco Tonello, Michele Zuin e Federico Girotto
TG Soft - Centro Ricerche Anti-Malware (C.R.A.M.)

Torna ad inizio pagina
 


Come cercare di riconoscere una falsa mail

L'esperienza ed il buon senso sono le prime armi per non rimanere vittima di questo tipo di truffe.
E' fondamentale un'attenta lettura della mail, in tutti i suoi elementi. Diffidare da subito di allegati in formato ZIP e, se possibile, NON abilitare l'esecuzione automatica delle macro. E' fortemente sconsigliato impostare l'esecuzione automatica delle macro poichè la semplice apertura di file Word ed Excel vedrà l'immediata esecuzione delle macro senza alcun alert preventivo.
Nel caso in cui si fosse stati infettati da un Banker,  il consiglio da parte del C.R.A.M. di TG Soft è quello di prendere opportuni accorgimenti di sicurezza anche dopo la bonifica del/dei sistemi coinvolti come il cambio delle password più comunemente utilizzate nel web.
Nel caso in cui  la postazione coinvolta fosse stata utilizzata per operazioni di home-banking è consigliato anche un accertamento con il proprio istituto di credito.  


Come inviare e-mail sospette per l'analisi come possibili virus/malware/ransomware e/o tentativi di Phishing

L'invio di materiali da analizzare al Centro Ricerche Anti-Malware di TG Soft per l'analisi che è sempre e comunque gratuito può avvenire in tutta sicurezza in due modalità:
  1. qualsiasi e-mail che sia da considerarsi sospetta può essere inviata direttamente dalla posta elettronica del ricevente scegliendo come modalità di invio "INOLTRA come ALLEGATO" e inserendo nell'oggetto "Possibile Phishing da verificare" piuttosto che "Possibile Malware da verificare" alla mail lite@virit.com
  2. salvare come file esterno al programma di posta elettronica utilizzato la mail da inviare al C.R.A.M. di TG Soft per l'analisi . Il file che ne risulterà dovrà essere inviato facendone l'Upload dalla pagina di INVIO File Sospetti (http://www.tgsoft.it/italy/file_sospetti.asp). Naturalmente per avere un feed-back rispetto al responso dell'analisi dei file infetti inviati sarà necessario indicare un indirizzo e-mail e sarà gradita una breve descrizione del motivo dell'invio del file (ad esempio: possibile/probabile phishing; possibile/probabile malware o altro).
Tutto questo per aiutare ad aiutarvi cercando di evitare che possiate incappare in furti di credenziali, virus/malware o ancor peggio Ransomware / Crypto-Malware di nuova generazione.
Torna ad inizio pagina
 


Integra la protezione del tuo PC/SERVER con Vir.IT eXplorer Lite

Se non doveste ancora utilizzare Vir.IT eXplorer PRO è consigliabile installare, ad integrazione dell'antivirus in uso per aumentare la sicurezza dei vostri computer, PC e SERVER indifferentemente, Vir.IT eXplorer Lite -FREE Edition-.

Vir.IT eXplorer Lite ha le seguenti caratteristiche peculiari:
  • liberamente utilizzabile sia in ambito privato sia in ambito aziendale con aggiornamenti Motore+Firme senza limitazioni temporali;
  • interoperabile con eventuali altri AntiVirus, AntiSpyware, AntiMalware o Internet Security già presenti su PC e SERVER, consigliato l'utilizzo ad integrazione dell'AntiVirus già in uso poichè non conflitta nè rallenta il sistema ma permette di aumentare sensibilmente la sicurezza in termini di identificazione e bonifica dei file infetti;
  • identifica e, in moltissimi casi, anche rimuove la maggior parte dei virus/malware realmente circolanti o, in alternativa, ne permette l'invio al C.R.A.M. Centro Ricerche Anti-Malware di TG Soft per l'analisi e l'aggiornamento di Vir.IT eXplorer per l'univoca identificazione e la corretta rimozione;
  • grazie alla tecnologia Intrusione Detection, resa disponibile anche nella versione Lite di Vir.IT eXplorer, il software è in grado di segnalare eventuali virus/malware di nuova generazione che si siano posti in esecuzione automatica e procedere all'invio dei file segnalati al C.R.A.M. di TG Soft.
  • Procedi al  download di Vir.IT eXplorer Lite dalla pagina ufficiale di distribuzione del sito di TG Soft.

Per i licenziatari in assistenza della versione PRO di Vir.IT eXplorer...

Per i possessori di Vir.IT eXplorer PRO è anche possibile contattare gratuitamente il supporto tecnico telefonico di TG Soft le cui modalità sono consultabili alla pagina del supporto CLIENTI.
 


C.R.A.M.

Centro Ricerche Anti-Malware di TG Soft

Torna ad inizio pagina





Utilizzabilità delle informative e delle immagine in esse contenute

Ogni informazione pubblicata sul nostro sito può essere utilizzata e pubblicata su altri siti internet, blog, forum, facebook a patto che venga sempre e comunque citata la fonte "Fonte: C.R.A.M. by TG Soft www.tgsoft.it" con link cliccabile all'informativa e/o pagina web originale da cui sono stati estrapolati contenuti testuali, spunti e/o immagini. Inoltre per ogni immagine utilizzata dovrà essere sempre indicata la fonte ed il link cliccabile alla pagina originale dell'informativa di prima pubblicazione. Per quanto riguarda le pubblicazioni cartacee sarà necessario citare la fonte esplicitamente "Fonte: C.R.A.M. by TG Soft www.tgsoft.it" ed in analogia alle pubblicata elettroniche i link sotto ad ogni immagine alla pagina web originale da cui sono state estratte.

Sarà gradito nel caso di utilizzo dell'informativa del C.R.A.M. by TG Soft www.tgsoft.it nella relazione di articoli di sintesi il riconoscimento/ringraziamento di seguito "Si ringrazia il Centro Ricerche Anti-Malware C.R.A.M. by TG Soft di cui segnaliamo il link diretto all'informativa originale:[link diretto cliccabile]"

fb rss linkedin twitter
 




Legal & Eula | Privacy | Disinstallazione

TG Soft S.r.l. - via Pitagora 11/b, 35030 Rubàno (PD), ITALIA - C.F. e P.IVA 03296130283