Dad! There’s A Rat In Here!

As promised in my last post, I’ll be doing a walkthrough of the DADSTACHE sample fetched by the maldoc (MD5: 571efe3a29ed1f6c1f98576cb57db8a5) found off VirusTotal in late Feb 2020. After completing my analysis, I realized that a thorough “walkthrough” is not necessary as the beaconing code logic is simple enough. I think the toughest part was to make IDA Pro take in the final payload encrypted within the sample so that I can do static analysis. Hence, I decided to dedicate most of this post to my approach to unveiling the final payload ;) The second half would be a documentation of my findings.

DADSTACHE sample analysed:
009a9f7024c4dd5db8e3d793be3e99c0 dbgeng.dll

Let’s Tuck In!

There are 2 exported functions, we can quickly see that DebugCreate is the interesting one, with tell-tale API calls.

Looks like an AES encryption, using 0x40 bytes as a “seed” to derive the key. The easiest way to arrive at the decrypted content is to run the sample and read the decrypted content from memory.

The content hardcoded in offset 100127B4 looks like this:

After decryption, the following content is seen:

Continuing dynamic analysis showed that the decrypted payload is mapped into memory and then its OEP is called.

Now, I would like to analyze the actual payload with IDA Pro, but the content dumped from memory doesn’t look like a proper PE file and hence the IAT can’t be recognized (though I can actually see the import table in there).

Dump & Fix

Dump the decrypted file after it has been mapped to memory in sub_10001920. A good place to do this would be after this function ends.

Repairing the decrypted file’s PE header

The first 0x11C bytes of this extracted memory looked “wrong” — I would expect it to be following the structure of a PE header, but the “DOS Header” and part of the “NT Header” are missing. I can kind of recognize some of the fields in the “NT Header” from this chunk, which means that the content before these fields are intentionally “corrupted”.

I confirmed that these 0x11C bytes are not some kind of meaningful shell code:

From the dynamic analysis done up to this point, the OEP of the decrypted file in binary is 0x57E4 (called from the function sub_10001FF0). This helps to confirm that the PE header is only corrupted up till the “Machine” field in the “NT Header”.

So, let’s fix it! I’m going to copy the PE header of the parent binary, which is only 0x10C in size before the “Machine” field, to overwrite the corrupted 0x11C of header. Since we don’t care about what is actually in this header, other than the offset e_lfanew that needs to be corrected, I’m just going to pad 0x10 worth of values so as not to mess up all the other offsets (like the import table address) in the file. Of course, you may also wish to just fill up 0x11C bytes of your choice, just need to be sure the “MZ” “PE” and e_lfanew are correct.

Now, using a tool like CFF Explorer would help to confirm if the edits have been successful. The last step is to fix the section raw addresses so that IDA Pro will be able to do its magic for us. A trick that I usually apply to binaries that I dumped from memory, is to copy the values from the “Virtual Address” column to the “Raw Address” column.

With this, the import/export table would be nicely pointed to.

Since the RICH header portion of the PE header is lost, we are not able to perform analysis on that. Fortunately, there’s still one value that is intact, and that is the compilation date: 23 Dec 2019 17:15:32. This file is compiled about 1 hour before its parent file (which has compilation timestamp 23 Dec 2019 18:17:44). This might suggest that the file is manually compiled into the parent file, and not through a generator.

Finally, DADSTACHE

The first thing that the malware does is to update its configuration placeholder with the actual configuration (decrypted above).

Then it proceeds to do the beaconing, which comprises of AES-encrypted contents within HTTP POST requests.

AES Encrypted Network Communication

One point to note is that the configuration within the malware decides whether the HTTP requests will be wrapped with SSL or not. It is an additional layer of “security” for the C2 communications. Regardless, we’ll look at what is sent to and expected from the C2.

The following structure is AES-encrypted then sent to the C2. The AES key is found within the configuration data.

A quick python script can help with confirming that the content sent to the C2 is indeed AES-encrypted with the key from the configuration data.

Once there is a status 200 response from the C2 server for the above beacon, the malware will then proceed to do further information collection, and await commands from the C2.

The following information are being collected from the victim’s machine and then written into %temp%\\~liscen3.tmp:

• Recent files
• Installed programs
• Drives
• Count of cursor staying in one position

One of the information collected is to count the number of times that the cursor stayed in one position on screen — I suspect this is for the attacker to know if the binary is being executed in a sandbox instead of a real victim.

The content to send to the C2 would be read from %temp%\\~liscen3.tmp into a buffer and then the file is deleted.

Before sending the above in another AES-encrypted POST request, an additional 0x208 bytes of data (path of ~liscen3.tmp and “Client\<ip>_<computername>\Disinfo.txt”), followed by 8 bytes to indicate the start and end offsets of collected data within ~liscen3.tmp, are pre-pended to the buffer.

The Command ID received from the C2 server is not expected to be encrypted, but the parameters used within the command are AES-encrypted with the same key as configured within the malware.

If there are no commands received from the C2 server for a period of time (up to 3 seconds), the malware sends a GET request for /list_direction to the C2, possibly as an attempt to get a new command.

After-analysis thoughts

There we go, a straight-forward and light-weight RAT. The next thing I would like to do is to compare this latest DADSTACHE sample with the older ones, and other malware families known to be used by APT40. Who knows what interesting findings await?

~~

Asuna

Drop me a DM if you would like to share findings or samples ;)