This blog post was authored by Hasherezade

In mid-July we responded to an incident that involved an attack on a Microsoft Exchange server. The threat actor used this entry point to get into a Domain Controller and then leveraged it as a springboard to deploy ransomware.

While examining the ransomware payload, we noticed it was a new variant which we had not heard of before. In this blog we will take a look at AvosLocker a solid, yet not too fancy new ransomware family that has already claimed several victims.

This type of ransomware attack is unfortunately all too common these days and has wreaked havoc across many industries. With the disappearance of the infamous REvil, it is possible new threat actors are actively looking to fill the void.

New ransomware, looking for partners

Avos is a relatively new ransomware, that was observed in late June and early July. Its authors started searching for affiliates through various underground forums. They announced a recruitment for “pentesters with Active Directory network experience” and “access brokers” which suggests that they want to cooperate with people who have remote access to hacked infrastructure.

In the other advert they describe the product they offer: a multi-threaded ransomware written in C++:

They offer not only the malware, but also help in managing the communication with the victim, and hosting of the data stolen during the operation. Soon, some victims of this ransomware started to emerge.

Behavioral Analysis

AvosLocker is ran manually by the attacker who remotely accessed the machine. For this reason, it is not trying to be stealthy during its run. In default mode, it works as a console application reporting details about its progress on screen.

A sample log from the run (shortened):

 drive: C:  drive: D:  Threads init  Map: C:  Searching files on: C:*  file: C:autoexec.bat  Map: D:  Searching files on: D:*  FindFirstFileA: INVALID_HANDLE_VALUE  drive D: took 0.002000 seconds  Start encryption on C:  Encrypting C:autoexec.bat - ext bat - capped YES  Searching files on: C:_pin*  file: C:_pinpinadx-vsextension-3.17.98314-g0c048d619.bat  Start encryption on C:  Encrypting C:_pinpinadx-vsextension-3.17.98314-g0c048d619.bat - ext bat - capped YES [...] Searching files on: C:Documents and Settings*  FindFirstFileA: INVALID_HANDLE_VALUE  Searching files on: C:$Recycle.Bin*  […]  drive C: took 52.590000 seconds  Done!!  64.620000 seconds

Looking at the log, we can see that the ransomware first “maps” the accessible drives by listing all their files. After that it goes to the encryption. The files are selected for encryption depending on their extensions.

The files that have been encrypted by AvosLocker can be identified with .avos extension appended to the original filename. While the content is unreadable, at the end we find a Base64-encoded block added:

We can assume that this Base64-encoded data contains RSA-protected AES key that was used for encrypting this file. Each attacked directory has a ransom note dropped in it, named GET_YOUR_FILES_BACK.txt:

Interestingly, the ID is not generated during the deployment, but hardcoded in the sample (which we can see easily by viewing the sample strings). This may mean that the distributors generate a sample per victim.

The link given in the ransom note guides to the Onion website, requesting the ID, that was also in the note:

Upon the ID submission, the victim is presented with the individual panel:

In addition to the casual threats about increasing the price after the deadline has passed, this ransomware adds blackmail by doxing. The additional website titled “Press releases” is provided to prove that those aren’t just empty threats:

Visual analysis

Visualizing the content of the encrypted files shows their high entropy. No patterns from the original file content were preserved. Example:

Those properties suggest that a strong encryption algorithm was used, probably in a CBC mode (Cipher Block Chaining).

Also, the same plaintext files have been encrypted into different ciphertext output. This suggests that for each file a new key (or at least a new initialization vector) was generated.

Inside

This ransomware is dedicated to be deployed by the attacker manually on the hacked machines. This purpose is reflected in the design. In contrast to most malware, AvosLocker comes without any protective (crypter) layer. Yet, it’s not completely defenseless: all the strings, and some of the APIs, are obfuscated in order to evade static detection. Yet, during its execution, it yells out on the console the logs of the performed actions, so that the attacker could observe in the real time what the program is doing.

Execution flow

The execution starts in the main function:

First, the malware checks if it was provided with the optional commandline arguments. By supplying them, the attacker can enable/disable some of the features.

Then, the mutex name is decoded (“ievah8eVki3Ho4oo”), and its presence is checked. It is done in order to prevent the ransomware from being run more than once at the time. If the mutex already exists, the execution terminates.

This malware may come with a hardcoded RSA Public Key of the attacker. This key will be further used for encrypting individual AES keys, used for encrypting files. Yet, the presence of the Public Key is optional. In case if it wasn’t provided, the application will generate a new key pair.

After this preparation, the malware proceeds to encrypt files. Depending on the argument given, it may encrypt network resources. Then, unconditionally, it encrypts drives. The encryption operations are run in new threads.

After the encryption was done, it prints information for the attacker. Then, all the running threads are finalized. At the end the malware prints the summary about how long it took to encrypt available resources.

Arguments

By default it runs as a console application, yet the console can be hidden by supplying a specific commandline argument: ‘h’ (hide). There is also a commandline argument allowing to opt out encryption of network resources: ‘n’ (network).

String obfuscation

As mentioned before, Avos uses string obfuscation. All the strings are obfuscated by XOR with the given key, and deobfuscated just before use. Although the algorithm is simple, the way it implements it is especially tedious to counteract. Rather than having one, central deobfuscating function, each of such operations is done inline. Examples:

API obfuscation

As well as the strings, some of the APIs used by the malware are obfuscated. Functions are retrieved by their checksums, which is a common trick used by malware, in order to avoid hardcoding names of the functions which may rise suspicions. Which is lesser common though, is that the function resolving the API is also used as an inline.

This way of obfuscating API calls not only hides the used functions, but also adds volume to the code, making it more unreadable and difficult to follow.

Yet, it is easy to reveal the used function names with the help of tracing and tagging. Example – the above obfuscated function resolved to GetLogicalDrives:

Attacked targets

The ransomware encrypts all attached drives.

Additionally, unless the argument (‘n’) was given from the commandline, the ransomware proceeds to encrypt network shares. Available resources are being enumerated in a loop:

The accessible network shares are getting encrypted:

From each medium, the files are first added to the list. Then, the created list is processed by the encryption routine.

Files with the following extensions are being attacked:

ndoc docx xls xlsx ppt pptx pst ost msg eml vsd vsdx txt csv rtf wks wk1 pdf dwg onetoc2 snt jpeg jpg docb docm dot dotm dotx xlsm xlsb xlw xlt xlm xlc xltx xltm pptm pot pps ppsm ppsx ppam potx potm edb hwp 602 sxi sti sldx sldm sldm vdi vmdk vmx gpg aes ARC PAQ bz2 tbk bak tar tgz gz 7z rar zip backup iso vcd bmp png gif raw cgm tif tiff nef psd ai svg djvu m4u m3u mid wma flv 3g2 mkv 3gp mp4 mov avi asf mpeg vob mpg wmv fla swf wav mp3 sh class jar java rb asp php jsp brd sch dch dip pl vb vbs ps1 bat cmd js asm h pas cpp c cs suo sln ldf mdf ibd myi myd frm odb dbf db mdb accdb sql sqlitedb sqlite3 asc lay6 lay mml sxm otg odg uop std sxd otp odp wb2 slk dif stc sxc ots ods 3dm max 3ds uot stw sxw ott odt pem p12 csr crt key pfx der dat

How the encryption works

Avos uses two strong encryption algorithms. Symmetric: AES – to encrypt files, and asymmetric: RSA – to encrypt the generated AES keys. This is a very common combo which provides strong data protection. It is also often used by variety of ransomware.

The RSA Key

As mentioned before, the RSA Public key may be hardcoded in the Avos sample. In the analyzed case, the following Public Key was hardcoded:

In case of lack of thereof, a new keypair is generated. The Public Key is stored for the further use, and the private key is logged on the screen, as the information for the attacker.

The same Private Key is also dumped in each ransom note, instead of the ID:

This suggests that this mode was created only for testing purposes, and it not intended to be used on victims. Only the mode with the Public Key hardcoded is usable in real attack scenarios.

File encryption

Before the malware proceeds to encrypt particular file, it first retrieves a list of associated processes, that may be blocking the access:

The list is retrieved with the help of RmGetList:

If any processes has been found, they are being terminated. Then the malware proceeds with encryption.

For each file, an AES key generated by a previously deployed routine is retrieved and used to initialize AES context.

After that, the AES encryption is applied on the file content.

The file is encrypted in-place (without creating additional copy), in 64-byte long chunks. A chunk of a plaintext is read, encrypted, and written back to the original file.

As we observed during the behavioral analysis, the block with the RSA encrypted, base64-encoded AES key is written at the end.

AES key generation

The generation of random keys is deployed in the function enumerating the files of a particular directory, prior to the encryption. For each listed file a new key and Initialization Vector are generated, and stored for further use.

As default, the cryptographically strong random generator is used. However, if for some reason this strong generator fails, it falls back to the naive generator (based on the standard rand() function).

This may render a flaw in the full encryption scheme. However, the chance of the strong random generator failing is too small to consider worth the attention in real life scenarios.

The malware fetches a buffer of 512 random bytes per each file, and then generates out of this a 64-character long string for the key, and a 32-characters long string for the Initialization Vector.

This key and the initialization vector are further passed to a function initializing AES context. Although the created key is 64 bytes long, we must note that only 32 first characters are going to be used. Similarly, in the case of the Initialization Vector, only first 16 bytes matter. Both strings are treated as ASCII.

Preview of the file encrypted with the presented key/IV set:

Example – a ChyberChief recipe decrypting the aforementioned file, using the key and initialization vector dumped from the memory:

Valid implementation, unimpressive design

AvosLocker does not distinguish itself much from other ransomware (apart from being unusually noisy). All its features are average. Its encryption scheme seems implemented correctly, so recovering the data is not possible without obtaining the original Private Key for a particular sample. It also uses a well-established pair of algorithms: RSA and AES. Although it contains some inconsistencies in the implementation, they do not impact the main goals of this malware.

We didn’t find in the sample any routines responsible for uploading the stolen files. Yet, since the model of the delivery of this ransomware assumes manual access, it is possible that the data exfiltration is done manually by the attackers.

AvosLocker meets its objective by being a simple tool assisting in the manual attacks, and creating the expected damage.

Protection and recommendations

• Keep software up-to-date and turn on automatic updates whenever possible
• Enforce strong password policies and multi-factor authentication (MFA)
• Perform backups and periodically test restoring them
• Reduce attack surface by removing unused or unnecessary services
• Mitigate brute-force attacks (this is a feature in our Nebula product) 
• Enable tamper protection to prevent attackers from uninstalling your security software (this is a feature in our Nebula product)

AvosLocker is detected without specific signatures by Malwarebytes’ anti-ransomware technology:

Indicators of Compromise

43b7a60c0ef8b4af001f45a0c57410b7374b1d75a6811e0dfc86e4d60f503856