I've mentioned here before that many times it's very difficult for experienced incident responders to really get their heads wrapped around a malware issue, such as an infection in a corporate infrastructure. As difficult as it is for folks who do this kind of work, imagine how difficult it can be for the IT staffers managing that environment and attempting to recover from such an infection. I recently spent some time working with someone who'd been hit with a variant of a 9 year old dropper. Yes, that's right...9 years old. The secondary download was about 2 years old, and their AV product was able to detect these baddies...well, as long as the AV product installed was up-to-date and enabled. No extra.dat files were required.
Again, as I've mentioned before, one of the issues faced by responders (IT staff, as well as guys like me) is a lack of information from AV companies...most do not provide necessary information to perform detection, eradication and recovery effectively, simply because they're not in the business to do so. A commercial AV company's goal is to get you to use their product, so their response is to attempt to get a copy of the variant, develop a definition or signature for it, and see if that signature works for you...all while you just want it gone!
As a side note, one of the things that software vendors, in general, don't realize is this...by now, most folks are aware of the fact that things won't always be perfect. All products will have flaws, and most consumers know that. So the key at this point is, when someone does have a problem, how do you respond? Customers are happiest with the first person that feels their pain and really helps them.
Okay, enough of that. I thought that after our last example, it might be a good idea to take a look at some of the malware that comes out, and take a look at it from the perspective of an incident responder (and subsequently, a forensic analyst). An example I ran across today was W32/FakeXPA. Let's take a look at this from perspective of the framework we've already put together...
First off, W32/FakeXPA is a "rogue" security product, which infects a system and makes the user believe that they have some sort of issue (or no issues at all) on their system. Other similar malware includes Trojan:W32/AntivirusXP. Fortunately, Trojan:W32/FakeXPA was added to MRT in December, 2008...so there's some protection there.
Initial Infection Vector
No specific infection vector is identified. MS says that "various methods" are used to infect systems, so I'm sure that responders should look to either email attachments or a secondary download based on an initial dropper via email or the web browser. However, this also does not rule out other infected media (thumb drives, CDs) as the transport mechanism.
Artifacts
MS's write-up on W32/FakeXPA states that among other things, this malware may add an "XP Antivirus" value to the HKCU\Software key. The most recent information available from the MMPC also states that a recent variant modifies the hosts file.
Other artifacts may include an entry in the user's Start Menu folder (ie, "%UserProfile%\Start Menu\XP Antivirus XXXX")
Some of the different variants have different artifacts. For example, from MS's write-up, the 2010 variant installs as an BHO, as well as adding a subdirectory and files to the "C:\Documents and Settings\All Users\Application Data" directory.
While the "under the hood" artifacts of an infection vary, the commonality is that the user will see the fake antivirus GUI giving alerts to various threats detected on the system. Most peoples reaction will be, "yes, get rid of all of it!!", but responders need to look to whether or not the alerts are coming from the legit installed AV product or not. See the MS write-ups for screenshots of some of the variants.
Propagation Mechanism
This particular bit of malware doesn't appear to propogate once it's on a system. This is classified as a Trojan, not a worm.
Persistence Mechanism
According to the MS write-up, W32/FakeXPA writes a file to the %ProgramFiles% or "%ProgramFiles%\XP Antivirus" directory and creates an entry in the user's (HKCU hive) Run key. This appears to be the common persistence mechanism across the variants (the 2010 variant also includes a BHO), and provides responders with a great way to check individual machines, systems within a domain, as well as acquired images for indications of an infection.
Interestingly, the latest MMPC write-up ends with a listing of SHA-1 hashes for the latest variant. Come on, guys...not only do many products rely on MD5 hashes (EnCase, Gargoyle, etc.) but using static hashes in the face of malware that varies just does not make sense! Why not use fuzzy hashes?
Resources
VirusTotal page for one variant of FakeXPA (see how other AV vendors are detecting it)
ThreatExpert (2009 variant, A360 variant)
Another rogue "security product"
Final Note
Look at some of the differences between the various write-ups...for example, compare the write-up on the ThreatExpert 2009 variant to the MMPC Security Portal write-up for the same variant. Both identify some of the files and Registry keys left by the malware, but ThreatExpert identifies the packer, which means another means of detection may include Scout Sniper, from the illustrious Don Weber!
Think of the list of SHA1s as a list of references for a scholarly paper. Sometimes they can be used for actual detection if the malware doesn't change. And some security vendors have huge collections thus can pull the actual sample from their database and use the fact that we associated them together to better build generic signatures.
ReplyDelete...if the malware doesn't change
ReplyDeleteBut there's four hashes for the latest variant. If that doesn't indicate that the malware changes, I'm not sure what would.
Honestly, there's nothing that prevents AV vendors from improving the information they provide to customers, or even improving their own processes.