VB2014 paper: Notes on click fraud: American story

Since the early version of the downloader (from February 2012), we have observed the evolution of its structure. The variant described in early 2014 [3] distributed its own trojan features via drive-by download. The binary layout of the first stage starts with an x86 downloader, followed by procedures responsible for the x86 UAC privilege elevation, an x64 downloader and x64 UAC procedures. This downloader then requests the second stage, containing the debug string ‘Pigeon’. This is the main module, which contains x86/x64 code, the rpcss.dll inject and C&C domain list, and is responsible for downloading clickbot modules (the third stage).

The latest variant of the Blackbeard downloader, which lacks the drive-by download feature, was discovered in April 2014. The code corresponding to the previous second stage is embedded and packed with LZO compression [4] in the body of the binary. The clickbot module might or might not be embedded at the end of the binary and encrypted with the same 32-bit RC4 cipher. This altered variant can use a different final payload (e.g. a proxy client) and it can be distributed by a different exploitation chain (in countries outside of the USA). All the parts of the malware – the downloader, Pigeon and the clickbot modules – are included in one binary package. Their layout is shown in Figure 2. It is interesting to note that the Pigeon module is compressed with LZO compression and the clickbot modules are encrypted with the RC4 algorithm with a hard-coded 32-bit key.

Figure 2. Evolution of the Blackbeard/Pigeon structure.

(Click here to view a larger version of Figure 2.)

As is the case with almost all high-profile malware, the first stage is custom packed with a cryptor. After extracting the proper downloader, we can see that it is written in a robust way. The same code can be run in either a 32-bit or 64-bit environment, which the code itself decides on the fly, based on the entry point of the unpacked layer. The malware authors can therefore encapsulate their downloader in either a 32-bit or 64 bit cryptor and it will be executed in both environments.

At first, we notice a sequence of push, pop, rol, test, jnz instructions. When run in different environments, these instructions produce different results. Depending on the result, a conditional jump is either taken or not taken. These initial instructions run in both 32-bit and 64-bit environments. After the first conditional jump (jnz) there are two branches running in 32-bit and WoW64 64-bit environments, respectively.

Figure 3. The initial instructions run in both 32-bit and 64-bit environments. After the first conditional jump (jnz) there are two branches running in 32-bit and 64-bit environments.

(Click here to view a larger version of Figure 3.)

Under the 64-bit environment, the value 0x40000000 is pushed into the RCX register. Even after rotation by two positions to the left, ECX remains zero (ZF is set), so the conditional jump is not taken, and the 64-bit code is executed. The downloader simply gets its image base, adds the relative virtual address of the 64-bit payload function, and executes it.

Under the 32-bit environment, the value 0x40000000 is pushed into the ECX register, which is then rotated by two positions to the left, causing ECX to hold value 1. The instruction ‘test ecx, ecx’ does not set a zero flag (ZF), so the conditional jump is taken and the 32-bit branch of code is executed.

32-bit applications can be executed on both 32-bit and 64 bit operating systems. The processor architecture is decided by the GetNativeSystemInfo function. The expected result is either 0x00 or 0x09, which stands for PROCESSOR_ARCHITECTURE_INTEL (x86) or PROCESSOR_ARCHITECTURE_AMD64 (x64), respectively.

The wProcessorArchitecture information is compared at address 0x4010e0. Depending on whether the x86 or x64 architecture is detected, the conditional jump at this address decides whether the inWin32 function or the inWoW64 function is executed.

When executing a 32-bit application on a 64-bit operating system, the 32-bit application runs an emulation of a 32-bit operating system, which is called Windows on Windows64 (shortened to WoW64). WoW64 intercepts system calls made by the 32-bit application, converts 32-bit data structures into 64-bit data structures, and invokes 64-bit system calls. After the 64-bit system call has finished, it translates any output data structures from 64-bit back to 32-bit data structures. The WoW64 subsystem is implemented using three dynamic link libraries: Wow64.dll, Wow64win.dll and Wow64cpu.dll. Wow64.dll takes care of translations from 32-bit to 64-bit, Wow64win.dll provides entry points for 32-bit applications, and Wow64cpu.dll switches the processor from 32-bit mode to 64 bit mode. The interesting part of downloader starts at address 0x40112c, where it calls the function at 0x401000.

The called function then resolves base addresses of the three above-mentioned fundamental WoW64 libraries. In addition to these, it also retrieves the virtual address of an important structure from Wow64win.dll – the sdwhwin32JumpTable table.

At 0x40105f, it resolves the address of GDI32!BRUSHOBJ_hGetColorTransform, which is a function that is exported from the gdi32.dll library. The resolved address is stored in the EBX register. Later, at 0x401066, the system call ordinal is extracted from the first instruction of the call.

If we want to get the address of a function in sdwhwin32JumpTable, we first subtract 0x1000 from its ordinal number, then multiply it by eight (in the 64-bit system, each pointer has eight bytes) and add it to the beginning of the sdwhwin32JumpTable. In our case:

0x78bbfae0 + 0x129 * 8 = 0x78bc0428

However, in the analysed downloader, something more stealthy happens. At 0x401083, the address corresponding to BRUSHOBJ_hGetColorTransform in sdwhwin32JumpTable is overwritten by a user-specified address (0x40ad70). Figure 4 shows the situation before and after the overwriting has been done.

Figure 4. Before and after the overwriting has been done.

(Click here to view a larger version of Figure 4.)

Next, the instruction ‘call ebx’ is executed at the address 0x40108a, which is supposed to invoke BRUSHOBJ_hGetColorTransform. The instruction flow then continues into the gdi32.dll library (BRUSHOBJ_hGetColorTransform), until it reaches the call to the address stored at fs:[0xc0], which points to the wow64cpu!X86SwitchTo64BitMode function.

The DWORD at address fs:[0x0c0] contains an address with a jump causing a switch to the 64-bit environment (segment 0x33 determines the 64-bit environment). The 64-bit environment starts at wow64cpu!CpupReturnFromSimulatedCode, which contains the call toWow64SystemServiceEx. Before calling Wow64SystemServiceEx, several interesting parameters are passed: 0x7559fae0 is the beginning of sdwhwin32JumpTable in wow64win.dll; 0x129 is an ordinal of BRUSHOBJ_hGetColorTransform in sdwhwin32JumpTable; and 0x766e5c55 is the beginning of BRUSHOBJ_hGetColorTransform in gdi32.dll. Inside Wow64SystemServiceEx, the address of BRUSHOBJ_hGetColorTransform in sdwhwin32JumpTable is computed and called at 0x755bcf84 (call r12). Instead of the original address, code from the patched address is executed. At this point, a 64-bit payload is executed within the loader. The 64-bit payload begins at address 0x40ad70.

You might wonder why such a complicated transition from 32 bit to 64-bit environment is made. The malware could, of course, run only in the 32-bit environment, and a 64-bit version would not be necessary. However, the malware described is just a downloader and a loader which downloads another payload. Access to 64-bit running processes (e.g. web browsers) is desirable for the payload due to the possibility of easier code injection. Although there have been some hacks [5] which describe how to access the memory of a 64-bit process from a 32-bit process, it is easier to use straightforward 64-bit to 64-bit access.

Before executing the payload itself, it is important to make sure that it is running with elevated privileges. Without those, the privilege for taking ownership (SeTakeOwnershipPrivilege) cannot be acquired, security permissions for system files cannot be changed, and persistence cannot be established. An important part of the code occurs around the address 0x409a2e. Depending on the function parameters, getDelta can be resolved in four different addresses and later at 0x409a90, calling four different functions. If one function fails, another one is called. The first function (0x409bcc) does nothing special, it just tries to acquire SeTakeOwnershipPrivilege. If the malware is not running with elevated privileges, this function fails. The second function (0x409efc) is more interesting. The system API ShellExecuteW is resolved with the parameter ‘runas’ to run a file with elevated privileges. The code uses the System Preparation tool (sysprep.exe), which is a tool that ‘prepares an installation of Windows for duplication, auditing, and customer delivery.’ Sysprep is an application that needs administrative rights every time it is executed, and it is also a whitelisted UAC application [6]. Whitelisting allows users with lower than administrative rights to run applications with full administrative rights while UAC settings are still set to the highest security.

There is a proof-of-concept for Windows 7 UAC whitelisting [7], which uses the above-mentioned feature. At first, a random DLL library is copied from the %WINDOWS%\System32 folder to the %APPDATA%\Roaming folder under a randomly generated name. The newly copied file is patched and then, with the help of IFileOperation, it is copied into the sysprep directory under the name ‘cryptbase.dll’. When sysprep.exe is executed, it loads the cryptbase.dll library from the System32 directory. If we put a fake cryptbase.dll library into the sysprep directory, it will load the fake library instead of the real one. Sysprep is an elevated process, so everything it loads is also elevated. To bypass UAC on Windows 7, it is necessary to be an administrator. A second function also checks SIDs to make sure an administrator account is present. If it is running under only a standard user account, the second method fails.

The third function (0x4086c0) exploits CVE-2013-3660 [8]. If this function succeeds, a standard user can run programs under administrator privileges.

The last function (0x409c40) tries to run rundll32.exe <random dll>, System1. A random DLL is created with the same method as described for the second function; it is also stored in the same location (%APPDATA%\Roaming).

We have mentioned a few times that a particular system DLL is copied into %APPDATA%\Roaming and patched. The main function of the DLL is overwritten. Instead of its original function, it opens a previously created section object with the downloaded payload and calls its entry point function, which is 0x40ad70. It uses just four imported functions: NtOpenSection, NtMapViewOfSection, NtOpenEvent and NtSetEvent. To resolve the addresses of these imports, references to these libraries are overwritten in the DLL’s import table. Finally, the main function of the library is overwritten.

If an attempt to bypass UAC via the above-mentioned methods is not successful, users may encounter (depending on UAC settings) one or more dialogs. The user is presented with a prompt where important system programs request higher privileges in the following order: File Operation, System Preparation Tool, Windows host process (Rundll32). If the user does not grant the privileges, the infection does not happen. However, if the UAC bypass is successful, the user is infected and no UAC is displayed (no matter what the UAC settings are).

The initial stage of the downloaded payload establishes persistence on the infected system. Unlike many other pieces of malware which modify registry keys or copy themselves into the Startup folder, we encountered a much stealthier and more complicated form of persistence. Instead of modifying the above-mentioned registry keys, an important system DLL is patched so that the payload is executed every time the operating system starts. Rpcss.dll is the chosen library to be patched. RPCSS stands for Remote Procedure Call System Service, which is a core service of RPC (Remote Procedure Call). This is an important technology for creating distributed client/server programs, running on all Windows machines. It is an important system file, so the malware needs to perform a few steps before being able to overwrite it.

First, it attempts to acquire SeTakeOwnershipPrivilege. This privilege allows it to take ownership of any file. The default owner of rpcss.dll is a user called TrustedInstaller, who is the only one with full access (read, write, execute) to this system file. All other users, including SYSTEM, have only read and execute privileges by default. However, with SeTakeOwnershipPrivilege enabled, the owner of rpcss.dll can be changed to the current user. The malware then creates a new access control list (ACL) with two access control entries (ACE): current user and SYSTEM. This access list is then assigned (using SetNamedSecurityInfoW) to the rpcss.dll file. The result is that there are only two users with read/write/execute access – the current user and SYSTEM. Now it is possible to patch the DLL.

When patching the existing library, the best practice is to locate a block full of zeroes and replace it with executable code. However, the payload related to Blackbeard/Pigeon is more than 100KB, and it is not possible to find such a big block of zeros within rpcss.dll. Rpcss.dll contains only a small stub, which reads, decrypts, and executes the previously encrypted payload from a randomly named file in the %WINDOWS%\System32 directory. The payload is encrypted with a single-byte XOR operation.

If a regular user notices a suspiciously named file in the %WINDOWS%\System32 directory and tries to open the file and read it, access to the file will be revoked, because only the SYSTEM user has the right to do this. Rpcss.dll is executed by SYSTEM, so there is no problem in locating and reading the payload. Under Windows XP, there are two instances of rpcss.dll: one located in %WINDOWS%\System32 and one in %WINDOWS%\System32\DllCache. Both instances must be patched. The loader also disables the Windows File Protection (WFP) mechanism by calling an undocumented API with ordinal 5 from the sfc_os.dll library. SfcFileException [9] should disable WFP on a specific file for one minute.

Rpcss.dll is a dynamic linked library. It is not patched at the entry point of its main function (Dllmain). The malware localizes the gaServiceEntryTable structure and offset where the pointer to KernelServiceMain is stored. The pointer to this function is patched so that it points to the newly inserted block of data.

Figure 5. The malware localizes the gaServiceEntryTable structure and offset where the pointer to KernelServiceMain is stored.

(Click here to view a larger version of Figure 5.)

Figure 6. The pointer to the function is patched so that it points to the newly inserted block of data.

(Click here to view a larger version of Figure 6.)

The patched KernelServiceMain function starts with the getDelta assembly sequence (call $+5, pop), which returns the current address. Then it keeps subtracting 0x1000 until it finds the signature (MZ), which is the base address of the currently loaded library. The Decrypt_string procedure is a simple XOR loop, which decrypts the block of memory with the name of the file with the encrypted payload.

At this point, the malware is persistent on the compromised system. There are no traces of infection in the registry. A standard user may notice randomly named files in the %WINDOWS%\System32 directory, but neither he/she nor even an administrator has access to them (only SYSTEM can access them). Now it is time to spawn an Internet communication thread, download another payload and install it on the compromised system.

The Pigeon clickbot is distributed as a DLL file with two exported functions: Start and Stop. When the clicking module is activated, it first needs to hook several system API functions which cause some effects that are noticeable by end-users (e.g. playing sound, displaying message boxes, etc.). The Pigeon clickbot therefore hooks several functions in a few libraries. These functions are shown in Table 1.

Hooking these functions has the effect of a user-mode rootkit. For instance, waveOutOpen silences the waveform-audio output device volume by calling waveOutSetVolume with dwVolume = 0, which means silence. The ole32 functions revoke access to the HKEY_CLASSES_ROOT\CLSID entries belonging to Internet Explorer and Video MP4 Moniker Class (a plug-in used by Internet Explorer to play/stream videos in websites). The wininet functions modify HTTP Accept-Language headers to correspond to the system’s locale settings. DirectSoundCreate prevents the creation and initialization of an object that supports the IDirectSound interface. Messages and dialogs using user32.dll APIs are completely bypassed. The Ws2_32 functions modify the host name (pNodeName) parameter.

Later on, it modifies several keys in the Windows registry. These keys influence the behaviour of the web browser window in specific situations. For example, Pigeon sets ‘HKCU\Software\Microsoft\Internet Explorer\Main\NoNewWindows’ to 1. According to the documentation, setting this entry to 1 blocks the window.open event. A new window becomes an in-place navigation event instead. Setting the value of the ‘Error Dlg Displayed On Every Error’ registry key to ‘no’ disables script error notifications. The clickbot also modifies several keys in the Internet settings zones, ‘Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones’, namely 1400, 1601 and 1803. In the Internet zone, 1400 enables active scripting, 1601 enables the submitting of non-encrypted form data, and 1803 disables file download. The registry key ‘Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION’ is set to the value 0x22b8, which forces IE8 standard mode, and the value ‘MAXHTTPREDIRECTS’ raises the redirection limit of the IE browser.

After all the necessary registry modifications have been made, the clickbot reads a job task. The job task URLs are hard coded in the binary and have the following format:

http://<url1>/task/<number>/;http://<url2>/task/<number>/. 

Listing 6: Job task URLs.

The GET request to one of the above-mentioned click job servers returns several lines of plaintext. The first line is the length of the payload, the second line contains the link to be clicked, user agent, etc. The redirection chain from the initial task URL to the actual advertisement link is shown in Listing 7.

request:
GET /task/3033/ HTTP/1.1
Accept-Language: cs-CZ
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0; MATP; MATP; VER#7C#80837569566745484877484849)
Host: rummerstain2.com
reply:
cc
http://find-everything.info/?query=how%20long%20does%20a%20judgement%20stay%20on%20your%20credit%20report|88.198.188.106|8|Mozilla/5.0 
(compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0; BOIE9;ENUSMSCOM)
0

Listing 7: Redirection chain from initial task URL to the actual advertisement link.

Figure 7. The find-everything.info search engine.

Figure 7 shows the find-everything.info search engine, which is an ad redirection server. Querying this server gives another payload pointing to the ad control server. Notice that the user agent string is the same as the string obtained in the task command.

request:
GET /?query=how%20long%20does%20a%20judgement%20stay%20on%20your%20credit%20report HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0; BOIE9;ENUSMSCOM)
Host: find-everything.info
reply:
c2
<body><a id=”lnk” href=”http://88.214.241.192/click?sid=403f00deeffc1d7fdd41b7d3f33695e79a210a39&cid=1”></a></body><script type=”text/javascript”>document.getElementById(“lnk”).click();</script>
0

Listing 8: Querying the find-everything.info server.

Clicking to the supplied link with a proper referer and user agent causes the HTTP redirection to the ad server itself (Listing 9).

request:
GET /click?sid=403f00deeffc1d7fdd41b7d3f33695e79a210a39&cid=1 HTTP/1.1
Referer: http://find-everything.info/?query=how%20long%20does%20a%20judgement%20stay%20on%20your%20credit%20report
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0; BOIE9;ENUSMSCOM)
Host: 88.214.241.192
reply:
In reply, HTTP Location header then causes one more redirection to 
Location: http://delivery.seroads.com/display?p=11095&ad=...4

Listing 9: HTTP redirection to the ad server.

One more redirection follows, as shown in Listing 10.

request:
GET /display?p=11095&ad=Y...4 HTTP/1.1
Referer: http://find-everything.info/?query=how%20long%20does%20a%20judgement%20stay%20on%20your%20credit%20report
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0; BOIE9;ENUSMSCOM)
Cookie: CLICK=CLICK_16
Host: delivery.seroads.com
reply:
HTTP/1.1 302 Found
Location: http://bakingforlife.tv/r-bakingforlife.html?lp=1&externalID=S-CTM-BFL-US1&subExternalID=sero_11095-22-2

Listing 10: Final redirection.

The contents of the Location HTTP header show the final destination, with parameters identifying the source of the ad network.

An Internet Explorer window is then started in embedding mode. An invisible browser window is a COM object with CLSID=8856f961-340a-11d0-a96b-00c04fd705a2 (Shell.Explorer.2). This window then navigates to the URL obtained from the task server. To behave more realistically and to simulate human behaviour more accurately, a user simulation thread is spawned. This thread randomly moves the mouse, sets the cursor or clicks. One of the web pages that Pigeon redirects to in its hidden window is shown in Listing 10.

The Alureon module is very similar to the Pigeon module. The Alureon module does not have Start and Stop exports. It also checks command-line parameters to make sure it is running inside the ‘svchost.exe -netsvcs’ process.

The format of the task URLs are the same (only the URL addresses and task numbers are different), and the incoming reply also has the same format. Alureon’s browser window and user simulation thread are programmed in the same way as Pigeon’s. The Alureon clicker modifies some registry keys at startup, but not the same ones. The Alureon clicker, in addition, contains many calls to the WritePrivateProfileStringA and GetPrivateProfileStringA functions, which read or update configuration information stored in the corresponding ini files. The Alureon and Pigeon modules share a significant portion of code, and were probably coded by the same programmer(s).

The Wowlik clickbot module (named module_clk1.20) has a different structure from the previously described modules. It hooks even more APIs than Pigeon and Alureon. In addition to those hooked by Pigeon, it hooks the functions listed in Table 2.

Hooking the functions implements a user-mode rootkit. Hooking ntdll functions blocks access to HKEY_CLASSES_ROOT\CLSID entries belonging to Internet Explorer and the audio core API. Hooking SHGetFolderPathW blocks access to the browser history directory and browser cookies directory. GetAddrInfo replaces the searcher URL with a localhost URL when queried for information.

It then randomly chooses one of the hard-coded searchers and one of many hard-coded keywords. For example, the searcher name takes the format: ‘http://<US state name>-searcher.com/?q ={keyword}’, and for the keyword something like ‘low+cost+car+insurance’ might be selected (see Figure 8). In the analysed sample, we had just three searchers and about 550 keywords.

Figure 8. Wowlink randomly chooses one of the hard-coded searchers and one of many hard-coded keywords.

Now it is time to get advertisements to click. This is done by querying the ad links from a link feeder, which is hard coded in the clicker module. The format of the request to the feeder is shown in Listing 11.

http://95.211.231.195/feed?version={version}&sid={aid}&q={keyword}&ref={ref}&ua={ua}&lang={lang}

Listing 11. Request to link feeder.

Here, ‘version’ is the software version; ‘aid’ is an affiliate ID (taken from the variable ‘aid’ in the configuration file wow.ini); ‘keyword’ is a randomly chosen string; ‘ref’ is a referer formed by the a concatenation of the searcher string and the keyword string; ‘ua’ is a user agent string; and ‘lang’ is language. The reply from the feeder (shown in Listing 12) contains various information – the clickurl parameter is the most relevant for revenue generation.

reply:
<result status=”OK” records=”2” searchRequest=”inner knee pain” processTime=”0.0732”>
<record>
<title><![CDATA[Get The Latest Celebrity and Relationship News @ Cupid’s Pulse!]]></title>
<description><![CDATA[Launched in November 2010, CupidsPulse.com is a one-of-a-kind relationship site that analyses trending celebrity news to provide relatable love advice for singles and couples.]]></description>
<url><![CDATA[http://www.cupidspulse.com/]]></url>
<clickurl><![CDATA[http://46.165.240.227/r/8m8739v3/cfa9eaf4f02606798528293d9bc8dfe4/AA/0]]></clickurl>
  <bid>0.0035</bid>
    <tag>6921:114625:</tag>
  </record>
  <record>

...
  </record>

</result>

Listing 12: Reply from the feeder.

Getting the URL for clicking (GET /r/8m8739v3/0ce110ef35bfe90f53b583174a24963c/AA/0) causes redi-rection via the HTTP Location header.

Location: http://www.cupidspulse.com/?utm_source=clickpayz&utm_medium=CPC&utm_campaign=u_28490

request:
GET /?utm_source=clickpayz&utm_medium=CPC&utm_campaign=u_28490 HTTP/1.1
Referer: http://arkansas-searcher.com/?q=best+foods+for+weight+loss
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0)
Host: www.cupidspulse.com

Listing 13: Redirection via the HTTP Location header.

This is the final redirection we were looking for. The Urchin Tracking Module (utm) mentioned in the redirection request is the format used by Google to track unique URLs. So, basically, at the end of this redirection chain, the cupidspulse.com website thinks that someone clicked on a link at arkansas-searcher.com (referer), and was redirected to it. The owners of the cupidspulse.com may therefore believe it has more visitors than it really has. A browser window is again created as a hidden COM object.

The ZeroAccess clickbot is one of the most prolific and most heavily analysed clickbots, so we will reference one of its previous analyses [10]. Similarly to the other modules, it blocks access to several registry keys and hooks a few APIs related to the sound device. The ZeroAccess fraudulent click module first parses the raw data received from the task server, which consists of a set of referer URLs, each with one or more accompanying ad URLs. Task data is then parsed into referer/ad structures. The structures are then sorted and fraudulent clicks are performed.

Several redirections are made before reaching the ad server. The clickbot client is redirected first to an ad redirection server, secondly to an ad control server, and finally to the ad server itself.

Unlike other clickbots, ZeroAccess does not use threads to simulate user behaviour. The interfaces IHTMLDocument2, IMoniker and IBindCtx are used to perform an ad redirection chain instead.

Table 3 shows a comparison of the clickbot modules. Even though the droppers of Pigeon and Alureon largely differ, the minimalistic clickbot payloads are similar in most features. The ZeroAccess trojan enjoys the greatest complexity and imitates a real user the most accurately. The Wowlik clickbot lies somewhere in between.