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: 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
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.
Again we are alerted by a red window – almost identical like before, only the locker image is added:
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.
Similarly, it drops files in C:ProgramData (or C:Documents and SettingsAll Users). Now, the dropped copy is named svchosd.exe.
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“:
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
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.
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).
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):
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).
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
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):
The same chunk encrypted (result in bytes -> “55 0F 94 4C B0 98 81 DB F4 57 8A 98 92 2C 09 14”)
After use, the random AES key is RSA encrypted:
and then, appended to the beginning of the AES encrypted file (just after the “!DMALOCK” signature):
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):
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):
Like in the previous version, skipped are some predefined folders:
…and file extensions:
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.