A cyber-attack on a Microsoft Exchange server has alarmed Malwarebytes Labs around mid-July of 2021, wherein the attacker has taken advantage of this entry point to access the Domain Controller and trigger a ransomware deployment to the server. This particular ransomware – called AvosLocker – is a variant that the Malwarebytes Labs have newly discovered, thus describing it as a solid yet not too distinct of a ransomware strain that claims to have already infected several victims.
Regardless of being a common ransomware attack, it is evident that many industries have been severely affected by these kinds of cybersecurity threats. Many threat actors have been filling in the position from the disappearance of the notorious ransomware called REvil.
AvosLocker is looking for partners
Detected by late June and early July 2021, AvosLocker is a relatively new ransomware in the industry. Its authors began looking for members and partners across many online underground forums. The details of their acquisition of members include those that are “pentesters with Active Directory network experience” and “access brokers”, or in other words, they recruit those that have active remote access to hacked servers or infrastructures.
Their advertisements include a product description where they claim to be multi-threaded ransomware written in C++
Aside from the malware itself, their advertisement also states that managing the communication with the target and hosting of the data stolen throughout the procedure are two of their vital descriptions. Some victims had started surfacing eventually.
AvosLocker does not do its job slyly. Hence the attacker who manually runs the ransomware remotely accesses its target machine. The progress report and details of the process will be shown on a screen in default mode, which technically works as a console application.
Below is a shortened example from the run:
Searching files on: C:*
Searching files on: D:*
drive D: took 0.002000 seconds
Start encryption on C:
Encrypting C:\autoexec.bat – ext bat – capped YES
Searching files on: C:_pin*
Start encryption on C:
Encrypting C:_pin\pinadx-vsextension-3.17.98314-g0c048d619.bat – ext bat – capped YES
Searching files on: C:\Documents and Settings*
Searching files on: C:\$Recycle.Bin*
drive C: took 52.590000 seconds
The process from the log above consists of how the ransomware lists down all the files through “mapping” and then moving forward into encryption that selects files depending on each of its extensions.
Those identified with the .avos extension attached to initial file names are the files encrypted with AvosLocker ransomware. Even though it becomes an unreadable file, we will be able to locate an added block that is Base64-encoded data wherein it assumably comprises an RSA-protected AES key used in encrypting files
To detect which directory has been attacked, there will be a ransom note in it, namely GET_YOUR_FILES_BACK.txt
The ID will be hardcoded in the sample and is not generated during the deployment process, and could mean that there is a generated sample per victim by the ransomware distributors. In addition, the ransom note will also append a link that redirects to an Onion website where an ID included in the note will be requested.
An individual panel will then be presented to the victim upon submitting the ID to the website.
Aside from the threats that declare to increase the price once the victim goes beyond the deadline, another threat states that the ransomware blackmails utilizing doxing. To show the victim that these are not just empty threats, AvosLocker also provides a website called “Press releases”.
As observed from the contents of the encrypted files, it is evident how random it is, and that contents coming from the original file have no patterns to prove that it was preserved.
However, it may demonstrate a substantial encryption algorithm property that is possibly used in a CBC mode or Cipher Block Chaining. To add, for each file, a new key – or maybe at least a new initialization vector – was created since similar plaintext files have been translated into altered ciphertext output.
The deployment of the AvosLocker ransomware is initially aimed to be deployed manually by the threat actor towards the hacked machines, and it is shown on how it is designed. The threat actor could see in real-time what the program is performing during its execution by recognizing through the console all the logs of the completed activities. This ransomware does not come with any protective or crypter layer, unlike most malware in the industry. Nonetheless, it is proved to not be vulnerable as all of its strings, and few of its APIs are disguised to dodge static exposure and detection.
The execution of AvosLocker ransomware initially begins in its primary function. The first step includes checking if the optional command-line arguments are correctly supplied; afterwards, it allows the threat actor to enable or disable targeted features
The presence of the mutex name “ievah8eVki3Ho4oo” will then be decoded and checked, which is done to avoid running the ransomware more than once at a time. In other words, the execution will be terminated once it’s proved that the mutex already exists.
In addition, the malware has a hardcoded RSA Public Key of the attacker, wherein it is used to encrypt individual AES keys and files. This Public Key is somewhat optional, and the application can produce a new key pair in an instance that it wasn’t catered to.
The malware will then move on to encrypt files once the preparation is done, and it can also encrypt network resources depending on given arguments. The next step would be the encryption of drives wherein operations run through new threads.
Printing of the information for the attacker will follow once the encryption was completed, and then all running threads should be finalized. It also includes a summarized printed report about the time it took for the malware to encrypt all the available resources.
This malware operates as a console application by default. However, the console can be hidden by provisioning specific command line arguments such as ‘h’ for hide and ‘n’ for network, allowing encryption of network resources to be opted out.
AvosLocker applies string obfuscation wherein all strings are obfuscated by XOR with the provided key and then be de-obfuscated before use. The way it implements the obfuscation is tiresome to counteract, even if it is deemed to have a simple algorithm. The central de-obfuscating function is done inline through each of its operations, rather than having one.
Nearly some of the APIs operated by the malware are obfuscated, adding in the strings as well. To prevent hardcoding names of the functions, which may intensify victim suspicions, a common trick is being used by malware functions retrieved by their checksums. The process determining the solution for the API is also used as an inline – is lesser common.
To make it more unreadable and tough to follow, obfuscating API calls adds volume to the code and hides the used functions. Nonetheless, with the use of tagging and tracing, it is a proven easy way to expose the hidden used function names.
All the attached drives are encrypted by the AvosLocker ransomware.
AvosLocker continues to encrypt network shares, lest the argument (‘n’) was provided from the command line. To add, there is an enumeration of all available resources that are found in a loop
Network shares that are accessible become encrypted
The files are initially be included in the list from each medium, and then an encryption routine will process the created list.
How the encryption works
Two strong encryption algorithms are being used by AvosLocker, which are symmetric: AES used to simply encrypt files, and the asymmetric: RSA used to encrypt the generated AES keys. Although often also implemented by some other ransomware, this combo is proven to deliver robust data protection.
The RSA Key
The RSA Public key can be hardcoded in the AvosLocker sample, and through an analyzed case, this Public Key was hardcoded
A new key pair can be generated in an instance that is not provided. The Private Key is logged on the screen, which is used as the information for the attacker, while the Public Key is kept and saved for further use.
For example, given no hardcoded Public Key, a new pair is generated, while the Private Key will be displayed. This same Private Key will then be dumped in each provided ransom note instead of the ID
This mode is not projected to be used on victims, and that this mode was solely created for testing purposes. The Public Key hard coded is the only mode that is usable in real attack situations.
The malware first recovers a list of related processes that may block access before it encrypts any file.
RmGetList helped retrieve the list below
If any processes have been found, they are being terminated. Then the malware proceeds with encryption.
An AES key that has been generated by a previously deployed routine is then retrieved and used to initialize the AES context for each of the files.
Then, the file content will be AES encrypted.
An amount or chunks of plaintext is then read, encrypted, and written back to the original file. With 64-byte long chunks, the file is encrypted in place, ensuring no additional copy is created.
The block with the RSA encrypted and base64-encoded AES key is found and written at the end part, as detected throughout the behavioural analysis of the process.
AES key generation
Preceding the encryption, the creation of random keys is deployed in the function tallying the files of a specific directory. A new key and Initialization Vector are also generated and kept for further use for each listed file.
A cryptographically strong random generator is used as default. If the strong generator malfunctions for some valid reason, it will automatically fall back to the naive generator (based on the standard rand() function).
Nevertheless, the chances that the strong random generator will fail and malfunction are too small considering the worth of attention in real-life situations.
Per each file, the malware makes a buffer of 512 random bytes, and then out of it, it will generate a 64-character long string for the key and the Initialization Vector a 32-characters long string.
Afterwards, the key and the initialization vector will be submitted to a function initializing the AES context. We must note that only the first 32 characters will be used even though the initial key is 64 bytes long. Only the first 16 bytes matter with the case of the Initialization Vector and both of these strings will be regarded as ASCII.
Below is a preview of the key/IV set presented in an encrypted file
With the use of the key and initialization vector dumped from memory, an example is a ChyberChief recipe decrypting the said file
Valid implementation, unimpressive design
Disregarding its unusually noisy description, AvosLocker is pretty common ransomware in comparison to other existing ransomware. Generally, its features are typical and average, and its encryption scheme appears to be executed appropriately. Therefore recovering the data is impossible without attaining the original Private Key for a sample in particular. RSA and AES are both well-established pairs of algorithms used by this ransomware, and regardless of few discrepancies in the execution, it typically does not impact the malware’s primary purpose.
The attackers likely do the data exfiltration manually because the model of the approach of this ransomware requires manual access.
Overall, the main goals of the ransomware AvosLocker are met as it focuses on being a tool to contribute and assist manual attacks and making sure that it has inflicted the damage that’s been anticipated.
Protection and recommendations
- Make sure to keep your software up-to-date and automatic updates are turned on
- Impose a strong password policy and multi-factor authentication or MFA
- Execute backups and test restoring
- Remove unused or unnecessary services to reduce attack threats
- Prevent brute-force attacks
- Prevent attackers from uninstalling your security software by enabling tamper protection