DTrack activity targeting Europe and Latin America

DTrack itself hasn’t changed much over the course of time. Nevertheless, there are some interesting modifications that Analysts want to highlight in this blogpost. Dtrack hides itself inside an executable that looks like a legitimate program, and there are several stages of decryption before the malware payload starts.

First stage – implanted code
DTrack unpacks the malware in several stages. The second stage is stored inside the malware PE file. To get it, there are two approaches:

1. offset based.
2. resource based.
The idea is that DTrack retrieves the payload by reading it from an offset within the file or by reading it from a resource within the PE binary. An example of a decompiled pseudo function that retrieves the data using the offset-based approach can be found below.

After retrieving the location of the next stage and its key, the malware then decrypts the buffer (with a modified RC4 algorithm) and passes control to it. To figure out the offset of the payload, its size and decryption keys, DTrack has a special binary (we have dubbed it ‘Decrypt config’) structure hidden in an inconspicuous part of the PE file.

The encryption method used by the second layer differs for each sample. So far, Analysts have spotted modified versions of RC4, RC5 and RC6 algorithms. The values of the third stage payload and its decryption key are obtained by reading Decrypt config again.

One new aspect of the recent DTrack variants is that the third stage payload is not necessarily the final payload; there may be another piece of binary data consisting of a binary configuration and at least one shellcode, which in turn decrypts and executes the final payload.

Third stage – shellcode and final binary
The shellcode has some quite interesting obfuscation tricks to make analysis more difficult.
When started, the beginning of the key (used to decrypt the final payload) is searched for. For example, when the beginning of the key is 0xDEADBEEF, the shellcode searches for the first occurrence of 0xDEADBEEF.

Once the key is found, the shellcode uses it to decrypt the next eight bytes after the key, which form yet another configuration block with final payload size and its entry point offset. The configuration block is followed by an encrypted PE payload that starts at the entry point offset after decryption with the custom algorithm.

Final payload
Once the final payload (a DLL) is decrypted, it is loaded using process hollowing into explorer.exe. In previous DTrack samples the libraries to be loaded were obfuscated strings. In more recent versions they use API hashing to load the proper libraries and functions. Another small change is that three C2 servers are used instead of six. The rest of the payload’s functionality remains the same.