One of the things we try to keep an eye out for is a new malware binary that is poorly detected by other methods, since it helps us show that there is real value in the non-traditional detection techniques used in WebPulse.
A couple of weeks ago, we rolled out an important update to one of the main WebPulse components. It included updates to several of dynamic malware detection modules. This week, as I was resuming work on the blog, I went looking for a good example to feature.
In Tuesday’s logs, I found a great example that had been caught by one of the updates to our "Shady-EXE detector" (which is still in need of cool nickname)…
Very early in the Shady-EXE logs was a batch of five URLs from a new malware host, and I could tell that all five had been caught by the new update.
The next step was to grab a copy of the EXE payload (it was actually disguised as a .SCR file), and see how well detected it was…
VirusTotal had seen a copy an hour or so before I tested, and reported that only one AV engine had flagged it. I did a re-scan, and saw that the total had doubled: there were now two detections. As I was heading home Tuesday night, I submitted it again, and the re-scan showed that the grand total was up to four detections (out of 42 engines). Unfortunately, this illustrates the typical time lag for AV engines to get up to speed on a new threat (or a new way to encrypt an old threat).
All four detections were what I would classify as "early stage" detections: the malware names returned by the four engines included such terms as "Generic", "DangerousObject", "Suspicious", and "LooksLike". Which all correspond very well with the "Suspicious" rating WebPulse had returned for the payload since the beginning of the attack, even before we had done any research to confirm that it was malicious.
Speaking of research, here’s a screenshot of what the main "site" returned when I visited it:
Let’s see… if we have an EXE file with several suspicious characteristics, and it’s coming from a shady place on the Web (including a site that is pretending to be under construction), we don’t really need any additional confirmation from an AV engine, do we? 🙂
Other Attack Notes:
– There was an unfortunate lack of Referrer data in the logs for this attack, meaning a little bit of deductive reasoning is in order to work out the attack vector.
– In addition to the .SCR file extension on the payload, the file name was reminiscent of the default names bestowed by a typical digital camera on its JPG image files.
– Those two characteristics are typical of what we call a "fake foto" attack.
–C.L.
Leave a reply
