The recent vulnerability of MS15-093 revealed that attackers were using it distribute the Korplug/Plugx RAT. After obtaining a sample from this attack and conducting further analysis, we found that the attackers have been using the same payload and just altering its configurations in attacks since March of this year.
The sample obtained is from the PlugX malware family, and has a MD5 value of: 076ae76dcd0946ff913a9ce033e0ca55.
There has been a lot of good analysis on the PlugX malware family so we are not going to rehash it. Rather, we will show how a deeper dive into samples and data can deliver interesting results. If you are unfamiliar with the PlugX malware take a look at some of these links for background:
Running the obtained sample showed some very basic PlugX dynamic analysis behavior:
- The dropper binary drops a DLL (nvdisps.dll) and a .DAT file (nvdisps_user.dat) to the users %Temp% directory.
- It then utilizes rundll32.exe to execute the dropped DLL. Utilizing the ShadowPlay export
The malware is configured to utilize the export ShadowPlay from the dropped DLL and pass in the value ‘84’ as a command line argument.
The ShadowPlay export from DLL when run does the following:
- Locates the dropped nvdisps_sers.dat file in the users %TEMP% directory
- Loads the .dat file into process space utilizing CreateFileMapping function
- Once the file is mapped into memory it will then XOR every byte with the passed-in argument of 84 plus a counter for each byte, and place the unobfuscated data into ESI
- When fully unobfuscated, the malware will call ESI which is the location of the unobfuscated .dat file in memory. The .dat file (or PlugX config) is not fully decoded. The XOR plus counter key is only an initial level of obfuscation.
PlugX has changed over the years, but the basics of its loading mechanism remain almost the same as seen in the behavior of our obtained sample.
After doing this initial triage and analysis I decided to create a YARA rule that would flag for other binaries and DLLs with these characteristics. The YARA rules can be found at our teams GitHub repo.
Using these YARA rules we searched other data sets looking for other binaries, and were a little surprised by what we found. The dropper YARA rule returned hits on four additional files.
The hashes for the additional binaries are:
This is where the story gets a little more interesting.
The compile dates and times of the samples suggest that the configuration of the malware has been used in campaigns since early 2015:
|Sample||Compile Date/Time (UTC)|
|076ae76dcd0946ff913a9ce033e0ca55 (Original sample)||March 26, 2015 at 8:25:35|
|84bb1c8c5957125029e4fbfa9ec63045||March 26, 2015 at 8:25:35|
|6c260baa4367578778b1ecdaaab37ef9||March 26, 2015 at 8:25:35|
|3475d208c6a67e7ddb3c266b79789||March 5, 2015 at 8:09:42
|66a2f4470913020780853bb06ef44b2f||February 27, 2015 at 2:24:01|
Compile dates can be altered so it doesn’t necessarily mean that the actors have been utilizing this configuration plugin since March of this year. This led us to dive further into the samples. While looking at the results for each file I started looking at the first submission date and that is where things got even more interesting.
- first submission date of March 5, 2015
- first submission date of March 31, 2015
- first submission date of July 9, 2015
- first submission date of July 23, 2015
- first submission date of August 8, 2015
Instead of trusting compile dates and results, we decided to take a closer look at the binary level. We ran every dropper through our sandbox and all four new samples showed the same dynamic behavior:
- They all dropped a DLL (nvdisps.dll) and a .DAT file (nvdisps_user.dat) to the users %Temp% directory.
- Started the DLL with rundll32.exe calling the ShadowPlay export and passing in the number 84 on command line
This led us to more code analysis. So we loaded up all the DLLs and did some binary diffing and they all showed the exact same code flow. The nvdisps.dll is really not the “malicious” piece of theses PlugX samples, it is simply a mechanism used to get the encrypted/obfuscated payload into memory (nvdisps_user.dat). The image below is a code flow difference screenshot of the ShadowPlay export from IDA using the Diaphora plugin.
Every one of the DLL’s ShadowPlay exports had the same code flow and when compared showed no differences, but the hashes of each DLL are different. We did not fully dive into why the hashes of each DLL that is just used to load the .dat file code into memory and transfer control to it are different. The main code execution lives in the ShadowPlay export.
We also used our newly released tool, mpesm, (Mnemonic PE Signature Matching) to see if the files were likely created with the same compiler/packer. Each file showed some similarities within the current signature set: Microsoft Visual Studio 2002/2003, Install Shield 2000, VISE Installer, and Visual C : Generic. This was an interesting sign and we wanted to dig further. Since it’s easy to create a custom signature, we created the following:
major_linker = 6
minor_linker = 0
numberofsections = 4
mnemonics = push,mov,push,push,push,mov,push,mov,sub,push,push,push,mov,xor,mov,push,call,pop,or,or,call,mov,mov,call,mov,mov,mov,mov,mov,call
When this run against the sample set the results were encouraging:
However, another way to help determine if malware is related or at least used in the same campaign is to investigate command-and-control infrastructure. There are several aspects that can be investigated for relationships. Domains registered by the same set of attributes, hosts within a domain, IP addresses that have hosted or currently host domains, and the IPs contacted as well as hostnames resolved by the individual malware samples.
After spending some time gathering data it was loaded up into Neo4j to look for any overlapping relationships:
To give more evidence that the samples are all related, we would have liked to see some evidence of overlap between network-level indicators and attributes. The green circles above represent the samples, and as you can see no samples are connected. This can mean several things: we lacked the visibility to tie the samples together, they are related and the attackers are practicing good opsec, or the samples are not related.
So what does all this mean? Just because the malware was installed via a new exploit, does not mean the malware itself is new. We have demonstrated that the characteristics of this malware have actually been seen since March of this year in other attacks. Is it from the same attackers? We don’t really know and when it comes to the defense of your network, it might not matter. However, taking the time to dig into a sample and review data sets is extremely import and useful for understanding how some attackers really work. If these samples represent the same attackers, this shows there is little impetus to change tactics if the current ones are getting the job done.
Some indicators you could look for if you’re concerned are:
Carbon Black query:
- filemod:temp\nvdisps.dll AND filemod:temp\nvdisps_user.dat
- cmdline:rundll32.exe AND cmdline:ShadowPlay
- Sample files
- Dat files
- DLL files