Recently, from Lab52 we have detected a recent malware sample, using the Dll-Sideload technique with a legitimate binary, to load a threat.
This particular sample has a very small DLL, that loads an encrypted file, which after being decrypted consists of a sample of the PlugX Trojan. This technique, and final threat together, consists of one of the most common TTPs among some APT groups generally of Chinese origin such as APT1, APT27 and Mustang Panda.
The sample in question is downloaded from the following link “http://miandfish.]store/player/install_flash_player.exe” and although in previous months, it had another hash, currently the sample hosted under that name has the following hash “c56ac01b3af452fedc0447d9e0fe184d093d3fd3c6631aa8182c752463de570c”.
The binary consists of an installer, which drops in the folder “C:\ProgramData\AAM Updatesnnk” the legitimate binary vulnerable to dll sideload, the small dll that acts as a loader for the final threat, and the binary file, which consists of the encrypted PlugX sample.
After deploying the three files, the installer runs the legitimate binary, causing the final PlugX threat to be loaded by it.
In this case, the legitimate vulnerable binary is part of Adobe’s Swite which will load any library named “hex.dll” that is next to the executable.
That hex.dll, in this case is a very simple and relatively small loader:
It has 4 exports that return 0 without doing anything, the Main function of the library, on the other hand, calls a function that checks the existence of the .dat file which is hardcoded (adobeupdate.dat in this case), loads it, extracts the first string of the binary and uses it as XOR key to decode the rest of the file, which consists on the final threat.
The following code in python imitates the logic of decoding:
When it finishes deciphering it, it loads the malware into memory, makes a “Memprotect” to make it executable and launches its logic from the byte 0 of the binary.
It is a functional PE, so this should not work, since it starts with the “MZ” header of a normal binary:
But in this case it uses a technique already seen before in tools like the Cobalt Strike Beacon that by modifying some bytes of the MZ header, it becomes meaningful executable code.
If we open the binary as a shellcode (de-compiling from byte 0) we see how they have modified the first bytes into a routine that jumps to a code zone, consisting of a PE loader:
After loading the IAT and leaving everything ready as a normal executable, this threat decrypts its own config, which is encrypted in XOR in the .data section of the binary. This time the decryption key is hardcoded in the binary, and is the string “123456789”.
After decrypting its configuration, it contains the folder where the binary must be installed, a XOR key that will use to encrypt it’s traffic and a list of up to 4 domains or IP addresses of command and control servers together with the port to be used. Generally the 4 C2 elements consists of the same domain repeated 4 times or 2 domains repeated twice each.
After the analysis, both the loader in DLL format and the final encrypted threat (after decryption) have been compared with different campaign samples of groups known to use this dll sideload technique, and it has been possible to verify how both the loader and the final threat coincide in a high percentage with the samples of the “Mustang Panda” group analyzed in the following reports   . In fact, the loader of this campaign is able to load and run the samples of the campaigns analyzed in those reports, and the final threat uses exactly the same XOR key to decipher its configuration as the samples in those reports, so there is a high probability that it is a new campaign from this same group.
This particular sample has the domains “www.destroy2013.]com” and “www.fitehook.]com” as c2 servers, and we have seen that they have a very characteristic behavior, since most of the day they resolve to 127.0.0.1, but from 1-3 AM (UTC) to 8-9 AM (UTC) it resolves to the IP “107.150.112.]250, except for weekends that it resolves constantly to 127.0.0.1, which could indicate that it is a campaign that is focused on a time zone in which those hours are working hours.
You shared python code… in a screenshot??! Not cool
Although it is very short, you are right that putting iocs or code in a screenshot is far from being cool.
Here you have de script 🙂