Last Updated: 2011-07-25 19:14:17 UTC
by Bojan Zdrnja (Version: 1)
As I already wrote in many previous diaries, various FakeAV groups go through a lot of work to make their malware as resilient to legitimate anti-virus programs as possible – both on the server side where they abuse various search engines in order to poison results and get new users to visit their booby trapped sites as well as on the client side, where they constantly modify binaries in order to evade AV detection.
One of the most common ways of making detection more difficult is through packing. However, the authors behind FakeAV use a bunch of other techniques to constantly modify/change their client binaries. They pretty much employ all obfuscation techniques you can think of: anti-disassembly (destroying functions, opaque predicates, long ROP chains ...), anti-emulation, anti-VM, anti-debugging etc. We’ll take a look at last two of these.
Anti-emulation is used to prevent execution of malware (or to change the way it behaves) when it is executed in an emulated environment. The emulated environment can be some kind of a sandbox or, more commonly, isolated environment that is part of a legitimate anti-virus. Today’s AV products almost always use various heuristics in order to detect previously unknown malware. This heuristics is (besides other features) also based on actions that the sample performs in the isolated environment. Basically, the AV program executes the sample in the isolated environment and monitors its activities. If something bad is detected (i.e. the sample dropping something in the C:WindowsSystem32 directory) the AV program can block it and prevent it from infecting the machine.
Authors of malware usually try to detect if they are running in such an isolated environment by calling “weird” functions. FakeAV, for example, calls some of the following: LCMapStringA, GetFontData, GetKeyState, GetFileType, GetParent. The idea here is to call a function that the isolated environment (hopefully for the author) has not implemented properly and to detect that the return code is incorrect. As there are thousands of functions in the Windows API it’s impossible for the AV program to correctly implement all functions (although they take good care of those commonly used by malware). It’s a cat and mouse game.
Besides such artificial isolated environments, the malware authors (including the guys behind FakeAV) don’t like when their malware is being executed on virtual systems such as VMWare or VirtualPC or under real, hardware Hypervisors. The FakeAV used quite a bit of well known code to detect various virtual systems. One of the tests they use is the CPUID instruction. The CPUID instruction is a very useful instruction since both Intel and AMD CPUs have reserved bit 31 of ECX of CPUID leaf 0x1 as the hypervisor present bit. This allows applications to check if they are running in a guest (virtual) system by calling the CPUID instruction with EAX set to 0x1 and then checking bit 31 of ECX. If it is set, the application is running in a virtual system. This is what the FakeAV authors do as shown in the following picture:
Or … they failed (like, epic)? Check the picture above carefully. So, the bit 31 of ECX has to be set in order to indicate that we are in a virtual machine. What did the FakeAV author do? After calling the CPUID instruction, instead of checking the value of ECX against 0x80000000 (the 31st bit), the author overwrites ECX with this value and then check’s its own value against itself. This test always returns 0 so the FakeAV author fails on detecting if the program is in a virtual machine, even if the Hypervisor honestly set the 31st bit. And there are more failures in the code later ….
Before I end this diary, I’d like to congratulate my colleague Branko on winning the Hex-Rays’ IDA Pro plugin contest (http://www.hex-rays.com/contest2011/) with Optimice (http://code.google.com/p/optimice/). Of course, congratulations to Jennifer Baldwin from the University of Victoria for the Tracks plugin which looks very cool.
Last Updated: 2011-07-25 03:12:44 UTC
by Chris Mohan (Version: 1)
This is a hypothetical scenario to get the old grey matter thinking on how you, the incident handler, would respond. To make this a piece of light entertainment when sipping coffee, just focus on these three phase, containment, eradication and recovery, of the six step incident handling process. Feel free to apply your own incident response plans to this scenario and I don’t expect anyone to post their answers to the questions. This is simply something to warm up the brain after the weekend – or help those recover after the week that was SANSFire.
A very popular news web site is compromised and the front page is offering up known malware, AB, to any that visit it. You first discover this as the AV console frantically starts receiving notifications from client machines visiting the infected site. A quick bit of research reveals the malware AB exploits a vulnerability in only Internet Explorer 6 and then attempts to phone home uploading the compromised machine's IE protected storage details to any one of 30 drop web sites via http. If the malware infects the system, it then attempts to download, via FTP and https, a .exe file containing more malware designed to hunt over port TCP 445 for machines without patch MS08-067 (KB 958644) to drop a hidden .exe file on %SYSTEMROOT%/System32. The AV companies released a signature file to detect and protect against this three weeks ago.
You're the lone security person for a company of 5,000 employees, over 10 sites. The standard operating system is Windows XP with version of Internet Explorer from 6-8. The IT team use Microsoft’s System Center Configuration Manager to manage the Windows systems and deploy software and patches. You are the firewall and AV admin and the IT support staff are competent but over worked and under resourced. Two of the ten sites have no IT staff on site.
Over half your company, including all of senior management, visit that site daily to keep themselves informed or read the gossip of the day. From the IT team's best estimates at least 3000 machines have IE 6 and roughly 300 of those machines probably have don't have the right level of AV definitions on them to protect against it for any number of reasons. The news web site isn’t going to be able to remove the malware distribution for up to 12 hour. 10 server systems you know of don't have the MS08-067 patch due to operational issue with supporting from a 3rd party vendor but requires TCP 445 to be available to internal systems.
The AV console currently has 1200 alerts and growing by the minute.
- What do you do to contain this incident?
- How can you identify infected machine?
- What do you do with infected machines?
- How can you identify any other at risk machines?
- How can you protect the 10 servers without MS08-067?
- What information do you communicate to staff, IT and management?
Chris Mohan --- Internet Storm Center Handler on Duty