Blogs & Stories

SpiderLabs Blog

Attracting more than a half-million annual readers, this is the security community's go-to destination for technical breakdowns of the latest threats, critical vulnerability disclosures and cutting-edge research.

How Antivirus Saved the Day…Sort of.

Recently, I found myself in a common situation—helping acomrade in our Incident Response division on an ongoing forensic investigation.The information provided was simple, as two pieces of malware were discoveredon 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 typicalreverse engineering engagement quickly transpired into an interesting andunusual scenario where I found myself relying on assistance from antivirussoftware in an unexpected way. And so our story begins…

So let's paint the picture for everyone. As mentionedearlier, I was given two pieces of suspect malware that were identified byIncident Response. One sample was very straightforward, as it appeared to be avariant of the popular Sality Trojan family. I didn't even have to dig into thefile to find out, as there are a number of A/V detections already in place. Sowhat's Sality you ask? Well, it's a quite old piece of malware for one. Somereports date it back to as far as 2003. It has a number of capabilities, butcertainly it's most known is the ability to infect other PE files on thesystem. Specifically, Sality has the ability to infect other EXEs and SCRs(Screensaver files). This file, asexpected, dumps a library file (DLL) to the system32 directory, and proceeds toload it with a specific function name.

We can see below a snippet of what I mean, as pretty muchevery A/V in existence has detections in place for this family:


* Please note the list above is not all-inclusive, and I'msure there are many other vendors with detections in place.

So as it happens, I did end up digging into it because Ithought the sample was cool, but the point remains that this malware wasn'tsomething that should be considered part of a targeted attack on a point ofsale system. This is more of the type of malware you'd expect to see on yourAunt 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 thatparticular sample. Certainly malicious, but nothing inside led me to believethat this sample was targeting track data on the victim. That leads me tosample #2.

This sample, unlike #1, wasn't as straightforward aspreviously hoped. It had roughly the same number of detections by A/V, all ofwhich indicated that this malware was Sality, just like the first piece ofmalware. What was unusual about this sample was the fact that it looked nothinglike #1. Typically, if it's a variant of a malware family, you're going to seesome evidence of similarity. In this case, very little "likeness" was seen inthis sample when comparing it to the first one. That being said, there was onething that this malware shared with the first one, both samples dropped thesame library file (DLL) in the system32 directory, and proceeded to load itwith a specific export name during runtime. Other than that, however, thesesamples were very distinct.

One thing that made sample #2 so unique is that it includedevidence that it was malware that targeted track data, which was great news. Theproblem? Sality was never known to target track data. This, initially, left mescratching my head. My brain began racing to a number of crazy situations—Did Ijust discover a brand new variant that targets banking data? Perhaps the authorwas able to get his/her hands on the Sality source code and was making modificationsfor a targeted attack against this client?

Alas, the answer, as is often found in life, was much moresimple. Further inspection of these samples revealed that the second piece ofmalware (the one targeted track data), had an added section (named 'srdata'),with some obfuscated data:

Screen shot 2012-08-27 at 11.14.34 AM

Remember how I said earlier that the Sality family ofmalware infected other samples? Well, guess what—That's exactly what happened.In some strange coincidence, both the banking malware and Sality wound up infectingthis system. The banking malware was most likely the result of a more targetedattack, whereas Sality probably wound up getting placed on there via a moreautomated method. Perhaps someone was using this box to browse the web, orperhaps 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 toinfect this banking malware along with everything else. So what we are leftwith is malware that is infected with other malware.


Armed with this information, I was able to use one of themany antivirus products at my disposal (went with Kaspersky, but really most ofthem would have been sufficient) and proceeded to 'disinfect' my malware,leaving me with wonderful, non-modified …malware. At this point, I was able totake this new sample and perform my analysis with much more ease. No morebroken 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, whichleft me feeling a bit underwhelmed. I was glad to accept assistance in thedisinfection process, but saddened that this new piece of malware was notcaught. But that's life—you win some and you lose some. Overall, this was apretty 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)