DMA Locker 4.0 – Known Ransomware Preparing For A Massive Distribution

From the beginning of this year, we are observing rapid development of DMA Locker. First, the threat was too primitive to even treat it seriously. Then it evolved to more complex but still decryptable ransomware.

The 3.0 edition was very similar to the previous one that we described, so we skipped posting about its details (the only change was to fix the bug making it decryptable). Now we are facing an outbreak of version 4.0, coming with various changes.

In the past, DMA Locker was known from being installed on hacked Remote Desktops. New release has been found distributed via exploit kit (Neutrino). This change is another step towards maturity of the malware, showing that now this threat will be spreading on a bigger scale.

DMA Locker development timeline

---

discovered: January 2016
version: 1.0
crypto:

• files encrypted by AES-256 in ECB mode.
• AES key is the same for each attacked file, stored in the binary and erased after use.

decryptable: yes, if we have the original sample
works offline: yes
prefix: ABCXYZ11
read more: here

---

discovered: 8 February 2016
version: 2.0
crypto:

• files encrypted by AES-256 in ECB mode
• AES key is randomly generated for each attacked file. After use, it is encrypted by RSA and stored in the file
• RSA public key comes hardcoded in the binary.

decryptable: Yes. Due to the weak random generator AES key can be guessed.
works offline: yes
prefix: !DMALOCK
read more: here

---

discovered: 22 February 2016
version: 3.0
crypto:

• files encrypted by AES-256 in ECB mode
• AES key is randomly generated for each attacked file. After use, it is encrypted by RSA and stored in the file
• RSA public key comes hardcoded in the binary.

decryptable: No, the previous bug has been fixed. However, RSA key is the same for full campaign and once we buy the private key, it can be reused for several victims.
works offline: yes
prefix: !DMALOCK3.0

---

discovered: 19 May 2016
version: 4.0
crypto:

• files encrypted by AES-256 in ECB mode, key is randomly generated for each file.
• each random AES key is encrypted by RSA and stored in the file
• RSA key pair is generated on the server (per client). The public key is downloaded.
  

decryptable: No. Neither RSA key can be reused.
works offline: no
prefix: !DMALOCK4.0
read more: in the current article

---

Analyzed sample

• 73f9bd05825cbe3cc9fc22b59806e1ac – original sample of DMA Locker 4.0 (in this form it is distributed)
  • d74e6aa609d4b962b55ec47e29559c70 – unpacked

Behavioral analysis

In contrast to the previous versions, DMA Locker 4.0 cannot encrypt files offline. It needs to download the public RSA key from its C&C. That’s why, if the file has been opened on the computer without the internet connection, it will just install itself and wait. If the machine is connected – it runs silently until it finish encrypting the files.

This time DMA Locker comes with a deception layer added – packed sample have an icon pretending a PDF document:

After being run, it moves itself to the same location like it’s previous editions –C:\ProgramData under the name svchosd.exe:

In addition to the main sample, we can see two additional files: select.bat and cryptinfo.txt.

cryptinfo.txt is a ransom note, analogical to those that we know from the previous editions – only the content changed. Now it is much shorter and contains a link to the individual website for the victim:

Script select.bat is used to display this note just in case if the original executable has been removed:

It also adds registry keys for the persistence. This time the main sample – svchosd.exe – is saved under the name Windows Firewall and the script select.bat – under Windows Update :

After it finishes the encryption process, a red window, similar to the one known form the previous editions pops up:

In addition to the incremented version number, visible in the corner, we can see some slight usability improvements. Following current trends, the option to decrypt a test file has been added. Also, there is a link to a tutorial.

As it was in the previous editions, extensions of the encrypted files are unchanged. We can recognize that they have been attacked by this ransomware only by the prefix of the content. This time it in “!DMALOCK4.0”:

Experiment

In the last editions, DMA Locker was using two algorithms for the encryption AES – to encrypt the file content and RSA – to encrypt the randomly generated AES key. Let’s see if the patterns of the encrypted content are similar to those found before:

Left – raw bytes of original BMP, right – the same BMP encrypted by DMA Locker 4.0:

Indeed, again we can see patterns of original content reflected in the encrypted content, that suggest that some block cipher has been used. We can suspect, that also in this case it is AES in ECB mode.

Also this time, every file is encrypted with a different key.

Network communication

The feature that is new in this edition of DMA Locker is the communication with the C&C. The generated traffic is not encrypted and we can easily see what for the C&C is used.

The victim ID is generated server side (not like in some other cases of malware, where the generated locally ID is sent and registered to the C&C). During the beaconing, bot receives it and stores in the registry as dma_id.

The role of the C&C is crucial, because the public key is not hardcoded this time, but generated per victim* and downloaded:

*logic of the application suggests, that keys are unique for each victim, but we don’t know what really happens on the server side and if the keys are not being reused for some pool of victims

Before the windows pops up, it asks the C&C about the individual data of the victim, that has to be displayed:

Website for the victim

Most of the ransomware provide a website for the victim, but what is surprising in case ofDMA Locker 4.0 is the fact that the website is not on the Tor-based, but on a normal hosting. The same IP is used as the C&C server.

Content of the website is clean, but very simple – that may suggest early stage of development:

The same site is supposed to offer the service of decrypting the test file (opened by the button in GUI):

However, during our tests this service was not working properly and we didn’t got any file back, although it has been successfully submitted:

Inside

In the past, DMA Locker was distributed without any packing. The reason behind it was probably the chosen distribution method – samples were deployed manually by attackers, who accessed machines via hacked Remote Desktops. Attacker didn’t bothered much about adding any deception layer.

In this edition it has changed. DMA Locker comes packed in some underground crypter, that is used to protect the payload and deceive tools used for the detection.

When we open the original executable under the debugger, we will see the code of the crypter’s stub, that doesn’t make much sense. The real payload is revealed after unpacking. It has similar structure to the previous editions of DMA Locker, but several new features are added.

How does the encryption work?

Encryption follows similar steps like in the previous versions.

The main difference comes in the method of delivering the public RSA key. In the previous editions, the key was one per campaign and it was stored hardcoded in the binary. Now it changed. The key is downloaded from the server – along with the unique bot it. Both are stored in the registry and fetched when needed.

Individual AES key is generated for each and every file just before encryption. Since version 3.0 of DMA Locker, a weak random generator has been fixed. Now it uses a function CryptGenRandom from Windows Crypto API to fetch 32 random bytes that are used as a key:

Just like it was before, a file is read and divided into chunks. Then, the random key along with the buffer containing a single chunk is passed as a parameter to a new encrypting thread. For the content encryption, the same AES implementation like in the previous versions has been used.

After the full content is processed, the RSA key is imported and used to encrypt the random AES key. The encrypted key is saved at the beginning of the file, just after the !DMALOCK4.0tag.

Then, the AES encrypted content is appended to the file. At the end, the random key is destroyed.

Like in the previous edition, the same application can be used for decryption when the victim managed to get the appropriate RSA private key. Previously, the only way to communicate with the attacker and to purchase the key was via e-mail. Now the payment is managed automatically and the private key is released on the server after completing the payment. Bot can automatically download it and perform the decryption.

What is attacked?

This part remained unchanged. Like the previously described version (2.0) it attacks local drives as well as unmapped network shares. Instead of list of attacked extensions, DMA Locker comes with list of blacklisted extensions and paths, that are excluded from the encryption process.

Communication protocol

DMA Locker communicates with it’s CnC server by a simple, HTTP based protocol. Bot sends GET requests and server responds in JSON. There are 6 actions, for which URLs are hardcoded in the bot:

JSON responses are then parsed with another dedicated function. Every status change is reflected in the red window. Example, showing setting appropriate string accordingly to the update received from the server:

In case if accessing the C&C was not possible, the bot sets in window the hardcoded bitcon address:

…also, a hardcoded sum of 4 BTC:

Old style communication via e-mail is still offered as a failsafe.

Actions

Particular actions are recognized by their numerical identifiers. Below – action numbers and their meaning:

0: get a unique id for the bot
sample request:

GET /crypto/gate?action=0

sample response:

{"status":0,"id":"7D6FB84840584C6484EEAD3DB377409B"}

1: get the public RSA key
sample request:

GET /crypto/gate?action=1&botId=7D6FB84840584C6484EEAD3DB377409B

sample response (giving RSA public key):

{"status":0,"rsa_public_key":"-----BEGIN PUBLIC KEY-----MIIBCgKCAQEAxPaoqNvUn8T52DtCr80OEJOa4bIXRDIRnVdCYxPQZ4rrNniBNnM+uEb2AUmSHTgZvlH1s3g0TDkrclv+mF8gGAZrU7TPZjg5KVfn2VB7pDLRqUJ\/XkMMDhviFuzgMDIBxDrf1oJoQUr\/XkXIjFJBDEJYDkJ+xVlbrMFvZblAzCySarvA0OGVrBJKmV1SVYnEPUyMMnGV4QtPBXcZhjxbElQu1XE2681tpPLMdaK9wL1iY+OE+poEzF7GBZ\/0mCKYF+P9Et9\/ZZHikxhABPSPF6COybgJhAVJWyFOWw4gh3\/pqL+4Q1MkNkIPf7WWbSRqX6URGiTriif98Z3uM7yWKwIDAQAB-----END PUBLIC KEY-----"}

2: report saving the public key
sample request:

action=2&botId=7D6FB84840584C6484EEAD3DB377409B

sample response:

{"status":0}

3: get information about the payment specific to the client:

GET /crypto/gate?action=3&botId=7D6FB84840584C6484EEAD3DB377409B

sample response:

{"status":0,"minimum_btc_confirmations":3,"bitcoin_address":"1C8yA7wJuKD4D2giTEpUNcdd7UNExEJ45r","ransom_amount":"1","private_key_destroy_timestamp":"2016-05-31 15.02.39","ransom_amount_increase_timestamp":"2016-05-27 15.03.58","ransom_amount_increase_amount":"1.5"}

4: check the transaction status

GET /crypto/gate?action=4&botId=7D6FB84840584C6484EEAD3DB377409B&transactionId=66614538ca4e50f44c06cf87f0ecfa5f82b0ac3cca33909f0c57a63ef3111101

sample response:

{"status":7}

5: get the private key (if released)

sample request:

GET /crypto/gate?action=5&botId=070F39D8E01A4B71B8414352CDB186E9

sample response:

{"status":0,"rsa_private_key":"[the key content goes here]"}

6: check bot status
sample request:

GET /crypto/gate?action=6&botId=070F39D8E01A4B71B8414352CDB186E9

sample response:

{"status":0,"bot_status":1}

possible bot statuses and their meanings:

0: fresh
1: public key saved
3: "Transaction and payment are confirmed. Getting decryption key..."

If this action receives bot status 3 it directly execute the action 5, fetching the private key.

Statuses

Each action return some status. Most common is status 0 that is a standard “OK” response. Some of the statuses are translated to the displayed strings:

2 - "Transaction ID confirmed! Confirming your payment, please be patient, it can take 15-20 minutes..."
4 - "Your private key is currently deleted. You are late with payment."
7 - "Your transaction need to be confirmed by server. It can take few hours. Check again for 1 hour."
8 - "Invalid transaction ID."
9 - "You have to wait 15 minutes to check again."

Conclusion

DMA Locker started being seen at the beginning of this year and drew our attention by the fast quality improvements. However, after a few months of seeing unchanged version 3.0, we got the impression that development of this ransomware got frozen.

The current edition shows that it is not true. This threat is still evolving and catching up with the features, known from other ransomware. So far it didn’t shown any novelty in the used techniques and we can rather expect a conventional attack from this side.

The recently observed changes suggest that the product is preparing to be distributed on a massive scale. Few important things got automated. Distribution is now exploit kit based – that makes it reach much more targets. Purchasing a key and managing payment is supported via dedicated panel – no longer human interaction is required.

Source:https://blog.malwarebytes.org