Trusteer

FFsearcher is a malware (with rootkit components) that steals money from... Google...
It does so via a variant on the well known theme of click-fraud. The scheme in general is this:

• Infect a PC
• Take over the user's browser
• Wait for the user to search via google.com
• Silently reroute the user's search request to the fraudster's site (which mimics Google)
• Whenever the user clicks one of the advertisements, Google shares the revenue with the fraudster's site

The malware is pretty sophisticated. The malware dropper installs a hidden DLL by writing it as an Alternate Data Stream (ADS) of a legitimate DLL. The malware also modifies a registry entry so that Windows runs this ADS on startup. When the DLL is run, it writes two other ADS streams and loads them into the kernel. It then deletes the streams.
The first kernel module is responsible for hiding the other components (it is the rootkit component), e.g. when the registry is viewed from userspace, the regular entry is displayed, instead of the modified entry. Likewise, it protects several malware files from being accessed from userspace.

The second kernel module subscribes to LoadImage notifications. When mswsock.dll image is loaded into a process, the kernel module issues an APC call to the process, whose target is LoadLibraryExW, with a DLL name in the format \\?\globalroot\Device\__max++>\HHHHHHHH.x86.dll, where HHHHHHHH are 8 hexadecimal digits that change in each boot (but remain the same throughout a session). The second kernel module also provides this file for the process to read (but the file is made unavailable to userspace immediately thereafter).

The HHHHHHHH.x86.dll DLL checks that wininet.dll (indication of MSIE) or xul.dll (indication of FF) is present - if not, it unloads itself. If wininet.dll/xul.dll is found, the DLL hooks ntdll!LdrGetProcedureAddress (the hook function replaces the resolution of mswsock!WSPStartup with the malware’s own, thereby virtually patching mswsock!WSPStartup). Now, when mswsock.dll (the DLL that implements the base service provider for WinSock) is initialized via a call to WSPStartup, it is actually the malware's code that runs first. It calls WSPStartup internally, and modifies the table of functions that the genuine WSPStartup returns, so that it virtually patches:

• WSPRecv
• WSPSend
• WSPCloseSocket
• WSPSocket
• WSPAccept
• WSPConnect

This allows the malware to fully control all TCP traffic. In other words, the malware can monitor and change HTTP requests and HTTP responses at its will. In contrast, it cannot effectively monitor/change HTTPS traffic, since HTTPS traffic is encrypted before it reaches WinSock (and is decrypted after it leaves WinSock).Note that this method is as flexible as LSP injection, yet much stealthier - there are no registry entries or permanent DLLs involved.

This explains how the malware can force the user to land in the fraudster's site - it simply redirects the user (e.g. via an injected 302 response) to the fake site. So from the browser's perspective, the user navigates to the fake site, and thus the browser traffic generates (Referer header, etc.) is very accurate, and Google can't tell that the fraudster's site isn't simply a very popular site.
But since, from the browser's perspective, the site rendered is not Google, there will be visible differences - e.g. address bar, page properties, etc. And here the malware pulls another trick. It hooks a set of display functions to spoof the browser GUI so that the user cannot tell that the site rendered is not the genuine google site. The functions patched are:

• user32!DrawTextExW
• gdi32!TextOutW
• gdi32!ExtTextOutW
• xul!??0gfxTextRun@@IAE@PBUParameters@gfxTextRunFactory@@PBXIPAVgfxFontGroup@@II@Z
• xul!?CopyGlyphDataFrom@gfxTextRun@@UAEXPAV1@IIIH@Z
Additionally, the malware installs a window procedure hook that enables it to spoof the address bar.

More information:
http://secureworks.com/research/threats/ffsearcher/?threat=ffsearcher (thanks Joe, you've been of great help!)
http://vil.nai.com/vil/content/v_174013.htm