Recently, I found myself in a common situation—helping a comrade in our Incident Response division on an ongoing forensic investigation. The information provided was simple, as two pieces of malware were discovered on a point of sale device, and at least one of them was grabbing track data(cardholder data) on the infected system. What started as a somewhat typical reverse engineering engagement quickly transpired into an interesting and unusual scenario where I found myself relying on assistance from antivirus software in an unexpected way. And so our story begins…
So let's paint the picture for everyone. As mentioned earlier, I was given two pieces of suspect malware that were identified by Incident Response. One sample was very straightforward, as it appeared to be a variant of the popular Sality Trojan family. I didn't even have to dig into the file to find out, as there are a number of A/V detections already in place. So what's Sality you ask? Well, it's a quite old piece of malware for one. Some reports date it back to as far as 2003. It has a number of capabilities, but certainly it's most known is the ability to infect other PE files on the system. Specifically, Sality has the ability to infect other EXEs and SCRs(Screensaver files). This file, as expected, dumps a library file (DLL) to the system32 directory, and proceeds to load it with a specific function name.
We can see below a snippet of what I mean, as pretty much every A/V in existence has detections in place for this family:
* Please note the list above is not all-inclusive, and I'm sure there are many other vendors with detections in place.
So as it happens, I did end up digging into it because I thought the sample was cool, but the point remains that this malware wasn't something that should be considered part of a targeted attack on a point of sale system. This is more of the type of malware you'd expect to see on your Aunt Sally's computer after she went to some link she saw in an email.
So it looks like I have a pretty good handle on that particular sample. Certainly malicious, but nothing inside led me to believe that this sample was targeting track data on the victim. That leads me to sample #2.
This sample, unlike #1, wasn't as straightforward as previously hoped. It had roughly the same number of detections by A/V, all of which indicated that this malware was Sality, just like the first piece of malware. What was unusual about this sample was the fact that it looked nothing like #1. Typically, if it's a variant of a malware family, you're going to see some evidence of similarity. In this case, very little "likeness" was seen in this sample when comparing it to the first one. That being said, there was one thing that this malware shared with the first one, both samples dropped the same library file (DLL) in the system32 directory, and proceeded to load it with a specific export name during runtime. Other than that, however, these samples were very distinct.
One thing that made sample #2 so unique is that it included evidence that it was malware that targeted track data, which was great news. The problem? Sality was never known to target track data. This, initially, left me scratching my head. My brain began racing to a number of crazy situations—Did I just discover a brand new variant that targets banking data? Perhaps the author was able to get his/her hands on the Sality source code and was making modifications for a targeted attack against this client?
Alas, the answer, as is often found in life, was much more simple. Further inspection of these samples revealed that the second piece of malware (the one targeted track data), had an added section (named 'sr data'),with some obfuscated data:
Remember how I said earlier that the Sality family of malware infected other samples? Well, guess what—That's exactly what happened. In some strange coincidence, both the banking malware and Sality wound up infecting this system. The banking malware was most likely the result of a more targeted attack, whereas Sality probably wound up getting placed on there via a more automated method. Perhaps someone was using this box to browse the web, or perhaps another system on the network infected it. It's hard to say for sure. The funny thing is, once Sality got its hands on the system, it proceeded to infect this banking malware along with everything else. So what we are left with is malware that is infected with other malware.
Armed with this information, I was able to use one of the many antivirus products at my disposal (went with Kaspersky, but really most of them would have been sufficient) and proceeded to 'disinfect' my malware, leaving me with wonderful, non-modified …malware. At this point, I was able to take this new sample and perform my analysis with much more ease. No more broken assembly, and no more random PE sections in the file. This 'clean' malware was no longer caught by any antivirus product I had access to, which left me feeling a bit underwhelmed. I was glad to accept assistance in the disinfection process, but saddened that this new piece of malware was not caught. But that's life—you win some and you lose some. Overall, this was a pretty strange situation to find malware battling it out on the infected system. And with that, I leave you with an XKCD comic.
(Source: http://imgs.xkcd.com/comics/network.png)
