Over the last few months, we’ve seen a new and disturbing threat: rootkits. A rootkit is a sophisticated kind malware which hides itself, typically at the kernel level (and sometimes even below the kernel), so that regular scanning for malware processes, files, registry entries and malware activities at large would miss it. The theoretic possibility of rootkits has been known for many years, and few rootkits have emerged in the past, but only recently we have seen rootkit-enabled malware as a serious trend.
Operating at the kernel level (or below) is at the same time powerful and cumbersome. Powerful – because kernel residence enables malware authors to code practically anything into their malware, regardless of operating system restrictions and safeguards. Cumbersome – because kernel coding is limited to using kernel libraries (which are quite minimal) and kernel-space context. So while kernel coding enables everything in theory, in practice there are many tasks that are easier to code assuming user-space context.
To this end, MBR-Torpig uses an interesting technique known as APC (Asynchronous Procedure Call). Any kernel thread can queue an APC to any other thread (and can force its almost immediate execution, in contrast to user-space APC queuing). The APC request is dispatched in userspace, just before the target thread is switched into. The APC request needs to name an address of a function (in the process space of the target thread), as well as the function parameter (again, an address in the process space of the target thread), but this does not impose a serious obstacle – the kernel thread can force allocation of memory in the context of the target process, and can easily write into that memory – i.e. it can easily write the machine code it wants to execute in the context of the target thread, to the target process memory space. Using APC is not theoretically new – it has been discussed e.g. in https://www.blackhat.com/presentations/bh-usa-07/Butler_and_Kendall/Pres... [1].
Using this technique, MBR-Torpig injects into, and runs code in processes that belong to common browsers e.g. Microsoft Internet Explorer, Mozilla Firefox, Maxthon and Avant. The malicious code inside each browser patches the browser network stack (the HTTP/HTTPS level, e.g. for Internet Explorer – the WinInet library) so that all HTTP/HTTPS traffic is intercepted by the malware. MBR-Torpig then collects POST requests (which typically contain credentials) and forwards the data to the attacker’s server. It also, per configuration, replaces some login-flow pages with its own forms, in order to collect further user data (Man-in-the-Browser style phishing).