Ondata di Attacchi Contro Aziende Italiane (Ursnif)
Con la presente Yoroi desidera informarLa riguardo al rilevamento di una pericolosa campagna di attacco in corso ai danni di utenti ed Aziende italiane. I messaggi di posta inviati dai cyber criminali contengono riferimenti a ipotetici documenti e fatture fittizie, ed invitano la vittima ad aprire un foglio Excel in grado di infettare la macchina con un impianto malware della famiglia Ursnif (TH-124), minaccia in grado di intercettare digitazioni da tastiera, trafugare le password salvate ed alterare la navigazione web utente.
Di seguito si riportano gli indicatori di compromissione estratti durante le analisi condotte:
Fattura n. <NUM>/000 del 03/09/2019
Alleghiamo documento <NUM> del 04/09/19
nuova pro forma
Invio documento n..1<NUM> del 04/09/19
SRL - INVIO COPIA Fattura 1<NUM> del 03-09-2019
Yoroi consiglia infine di mantenere alto il livello di consapevolezza degli utenti, avvisandoli periodicamente delle minacce in corso e di utilizzare un team di esperti per salvaguardare la sicurezza del perimetro "cyber". Per avere un indice di minaccia in tempo reale si consiglia di visitare il seguente link: Yoroi Cyber Security Index
JSWorm: The 4th Version of the Infamous Ransomware
The ransomware attacks have no end. These cyber weapons are supported by a dedicated staff that constantly update and improve the malware in order to make harder detection and decryption. As the popular GandCrab, which was carried on up to version 5 until its shutdown, also other ransomware are continuously supported with the purpose of creating revenues for cyber criminals. One of them is JSWorm, which has been updated to version 4.
JSWorm encrypts all the user files appending a new extension to their name. Unlike other ransomware, the extension is composed by many fields, reporting the information the user needs to move on the ransom payment phase. These fields are the same shown in the ransom note, that are: "Filename.originalExtension.[Infection_ID][Attacker_email].JSWRM"
Moreover, in the ransom note there is also a backup email, “[email protected]”, to ensure availability in case of blacklisting. During the encryption phase, the ransomware creates an HTML Application “JSWRM-DECRYPT.hta” in each folder it encounters. The HTA file corresponds to the ransom window shown in Figure 1.
To ensure the correct machine functionalities, the ransomware excludes from the encryption phase several system directories (Windows, Perflogs) and junction points like Document and Settings, $RECYCLE.BIN, System Volume Information, MSOCache. Also, for each encountered file, the malware compares it with the excluded paths and if they match, a conditional jump is taken.
Unlike most ransomware, JSWorm does not embed a list of file extensions to encrypt, but uses a set of extensions to exclude during the cipher step. The malware encrypts all the files whose extension is not present in the list.
During the encryption phase, JSWorm writes a suspicious file named “key.Infection_ID.JSWRM” in “C:\ProgramData”.It contains the AES key used to encrypt the files. Unfortunately, the key is processed with an additional RSA encryption step before its storing. The following figure shows an example of the encrypted key.
Moreover, to maximize the impact of the encryption phase, the ransomware:
deletes the shadow copies and other system restore points automatically created by Windows;
kills some processes related to common programs, like SQL server, to proceed with the encryption of the files on which these programs were operating;
adds a registry key to the autorun path to show the ransom note window also after a system reboot.
The commands invoked by JSWorm to perform the above mentioned actions are:
An example of how the malware invokes the commands using the “ShellExecuteA” API is shown in the following figure.
The Encryption Scheme
The AES key the malware encrypt is generated starting from an embedded Base64 seed “MI2i6BWRFhcswznItBEl33UaIoDOwqI=”, which is converted into a byte array through CryptStringToBinaryA API before proceeding with low-level manipulation.
The fixed string is combined with a random one to make the derived AES key different for each infection. Not even the malware writer knows the final AES key to decrypt the files, so when the user asks to recover his files, he must send the key file stored in “C:\ProgramData”. On the other side, the attacker will receive the file, then he will decrypt the content using his private RSA key and will proceed to extract the AES key useful to decrypt the user files.
To encrypt the AES key, JSWorm uses an RSA public key embedded into it in Base64 form, as shown in the following figure.
The control flow used to encrypt the AES key is based on Windows Cryptography API, as visible in the following figure.
After decoding of RSA public key and the initialization of a new PROV_RSA_FULL cryptographic service provider (CSP) through the “CryptAcquireContextA” function, the ransomware import the decoded RSA key using the “CryptImportKey” API.
The last step is the encryption routine, which is done using the “CryptEncrypt” function, as shown in the following figure.
A funny piece of the malware code is the Russian string used to instantiate a new mutex, “kto prochtet tot sdohnet =)” which means “who reads will die =)”.
The analyzed case has features in common with most ransomware like encryption scheme, the deletion of shadow copy and persistence. About the encryption scheme, the ransomware uses an AES key generated starting from an embedded Base64 seed which is converted into a byte array through CryptStringToBinaryA API. It is very common to find Ransomware relying on this library (CryptoAPI) for cryptographic task mainly for reliability and for reducing time for development.
Another interesting element is the presence of a mutex containing the string “kto prochtet tot sdohnet =)” in Russian language. This leads us to think that the authors could have Russian hands. Obviously, this could also be a false flag, but the Russian underground have a long tradition in such kind of cyber-crime activities: in fact, according to an Anton Ivanov research, senior malware analyst at Kaspersky Lab, even back in 2016 the Russian underground gave birth to about the 75% of the new crypto-ransomware tracked in that year, evidence of a consolidated malware writing capability.