DMA Locker Strikes Back

DMA Locker Strikes Back

A few days ago we published a post about a new ransomware – DMA Locker (read more here). At that time, it was using a pretty simple way of storing keys. Having the original sample was enough to recover files. Unfortunately, the latest version (discovered February 8) comes with several improvements and RSA key. Let’s take a look at the changes.

DMA Locker in recent campaigns have been found installed by the attackers via Remote Desktop (similar distribution method was used by LeChiffre ransomware).

[UPDATE] READ ABOUT THE LATEST VERSION OF DMA LOCKER: 4.0


UPDATE: version 3.0 (discovered 22-th Feb) fixed the bug in the cryptography implementation. Due to this fact, encrypted files cannot be recovered by external tools (although it was possible in case of the earlier version, described in this article). Sorry, but our decryptor can no longer help!

PREVENTION TIP: Create these files to protect yourself from this version of DMA Locker. Content doesn’t matter. In presence of these files, the program will go by other path of execution and display the red message only – but not deploy the encryption.

  • C:Documents and SettingsAll Usersdecrypting.txt
  • C:Documents and SettingsAll Usersstart.txt
  • C:ProgramDatadecrypting.txt
  • C:ProgramDatastart.txt

This trick works only as a PREVENTION – once your files are encrypted, it is not going to help. For more info about why it happens, please read this post.


Analyzed sample

28b44669d6e7bc7ede7f5586a938b1cb

Behavioral analysis

Again we are alerted by a red window – almost identical like before, only the locker image is added:

new_dma_lock

This time the key necessary to decrypt files must be supplied not as a text, but as RSA key file. Author added also key validation.

expected_key

Similarly, it drops files in C:ProgramData (or C:Documents and SettingsAll Users). Now, the dropped copy is named svchosd.exe.

dropped_files

And created registry keys to autorun the file and to autodisplay ransom note via notepad at system startup.

Encrypted files again have unchanged extensions – they can be only recognized by 8 byte long prefix at the beginning of the content. In the previous edition it was “ABCXYZ11“, in current it is “!DMALOCK“:

enc_hexdump

Experiment

Let’s compare how the encrypted files look

From the left we can see visualizations of raw bytes of following files: original, encrypted by previous DMA Locker, encrypted by current DMA Locker

enc_square1_bmp

enc_square1
enc_square1

Previous DMA Locker(middle picture) was encrypting files by AES-256 ECB mode, applied on 16 byte long chunks of input. Now (last picture), also repetitive patterns exist – so probably AES-256 ECB mode was used again.

However, pay attention to the strips in the BMP – in a new file they are shifted a bit more. It would suggest that the header is longer than previously. Let’s visualize the same files with a different width, to make sure that this impression is right. The header of the file is visualized as a line at the top left corner – it ends where the vertical line starts.

enc_square1

enc_square1_encrypted

Now it is visible clearly – the header is really longer. Why? To answer this question, code analysis is required – but it can signify, that some additional data have been stored there (it can be for example the AES key, encrypted by RSA).

Inside

When does the encryption start?

At the beginning of execution, (as in the previous version) the malware terminates applications used for backups. Also, adds registry keys for its persistence. Then, execution of the main function may follow 3 alternative paths.

  • if system is already infected -> do not deploy encryption, only display the red window with ransom note
  • system is not yet infected, malware is not yet installed (current file name is different than the expected one – svchosd.exe) -> install the malware in ProgramData and then deploy again the dropped file
  • system is not yet infected, but malware is installed -> deploy encryption, after finishing display the red window with ransom note

The recognition, in which state is the system, is performed basing on the presence of some predefined files. Presence of file decrypting.txt informs that system is already infected. File start.txt informs that encrypting started (and no need to start it again):

recognition

Knowing this fact, we can easily drop those files by our own and fake that our system is infected. It will prevent this version of DMA Locker from attacking our system (it will display the ransom note but not touch our files).

How does the encryption work?

This time the author decided to practice what he preached and really used RSA key (previous version supplied to the encrypting function just a text key, read from the end of the original sample).

rsa_key

In contrast to the previous edition, where one AES key was used for all the files, here a new random key is generated per every file.

As you can see – in example below the randomly generated key was MRNW9KSC5JRCeT4uJVmI2AOS7JUjPQc6

random_AES_key

Then, the key is used in the same way like the previous one – to encrypt 16 byte long chunk with AES ECB mode.

Below – buffer before encryption (fragment of the input is selected on the hex dump – it is a header of a PNG file):

AES_key_encrypt

The same chunk encrypted (result in bytes -> “55 0F 94 4C B0 98 81 DB F4 57 8A 98 92 2C 09 14”)

AES_encrypt_result

After use, the random AES key is RSA encrypted:

RSA_encrypt

and then, appended to the beginning of the AES encrypted file (just after the “!DMALOCK” signature):

AES_key_written

We can see that now the AES encrypted content starts with offset 0x88 (compare the selected part with the above example showing AES encryption result):

AES_offset88

What is attacked?

As previous, attacked are logical disks as well as network shares.

This sample introduced also check against Floppy and CD using QueryDosDeviceA (floppy and CD are skipped):

not_floppy_or_cd

Like in the previous version, skipped are some predefined folders:

skip_folders

…and file extensions:

skip_extensions

Conclusion

The author of this malware, despite appearing inexperienced in programming, seems to be very determined to gradually improve the quality of the product. The disparity between the quality of the first edition, second (described in the previous article) and the third (current) is significant. We will keep eye on the evolution of this malware family and provide you with updates and possible tips on dealing with this threat.

ABOUT THE AUTHOR

hasherezade

Malware Intelligence Analyst

Unpacks malware with as much joy as a kid unpacking candies.