Alpha Testing the AlphaLeon HTTP Bot


ASERT was initially alerted about an emerging threat called AlphaLeon by Deep & Dark Web intelligence provider Flashpoint in August 2015. It caught and kept our interest because it sounded like it could be a new “banker” malware family. While it took some time to find samples of the malware in the wild, this post goes through the details of what we found. It is a malware analyst’s “alpha test” of the AlphaLeon HTTP Bot.


The first sample analyzed for this post has the following hashes:

  • 945e4455e1b553186768ef890a7d2c15 (MD5)
  • 6043a9d69eee2994d330b891d29115e95d5466fb0673932e85c16a4c0232b81b (SHA256)

This sample contains a helpful PDB string (H:\Alpha\Bot\Release\Loader.pdb) indicating that it is the loader component of AlphaLeon. Analysis of the sample’s PE header reveals it was recently compiled (2016-02-06 03:00:08). The first actions taken by the loader include resolving a bunch of Windows functions via API hashing. Here is a Python snippet of the hashing algorithm:

hash_val = 0
for b in api_name:
    hash_val = ((ord(b) << 16) ^ (ord(b) + 257 * hash_val)) & 0xffffffff
print "%s: 0x%x" % (api_name, hash_val)

Our Github will contain a file mapping these API names to their hash values for posterity. There are two other anti-analysis items to note. The first is that most of the strings in the loader are obfuscated with base64. Second, the malware performs a virtual machine check where all process names are checked against the following list:

  • vmwareuser.exe
  • vmwareservice.exe
  • vmwaretray.exe
  • vboxservice.exe
  • vboxtray.exe
  • vmtoolsd.exe

If any of these process names exist, the loader deletes itself with a batch script and exits. Next, the loader extracts a file from its resource section. In the process, AlphaLeon continues a long malware tradition of showing investigative reporter Brian Krebs some affection:


When viewed as a bitmap, the resource displays what looks like a highly distorted and cropped banner for Krebs’ “Krebs on Security” site. The image is distorted because it contains a DLL file. The boundaries of the hidden DLL are marked by “WELOVEBRIAN” tags and the file can be extracted with the following Python snippet:

fp = open("loader_rsrc", "rb")
data =
start = data.find("WELOVEBRIAN") + 11
end = data.rfind("WELOVEBRIAN")
fp = open("loader_rsrc.dll", "wb")

It will be saved to a file similar to:

C:\Documents and Settings\Administrator\Local Settings\Application Data\Microsoft\45996078.dll

The numerical portion of this filename is generated by the GetTickCount function. Persistence is maintained by adding an “InternetUpdate” registry entry with the following value:

C:\WINDOWS\System32\rundll32.exe C:\Documents and Settings\Administrator\Local Settings\Application Data\Microsoft\45996078.dll,Entry

The registry entry is added to the Run key:


Before transitioning to the next component, the loader gathers some system information and stores it encoded to the “Cancer” registry entry under the following key:


The data is base64 encoded with the following characters replaced:

  • + to –
  • / to _
  • = to ,

The system information string looks like:

5|1|Service Pack 3|1|COMPUTER1|Administrator|x86|1

The string contains:

  • Major Windows version
  • Minor Windows version
  • Service pack
  • Windows product type
  • Computer name
  • User name
  • Architecture
  • Whether token is elevated?


The above loader loads the following sample:

  • 6f07ae114652dffe767b03d4d67cb301 (MD5)
  • 2085db7e7764e0693fe128fa7530338af8c8c598d1f3a85a2299991248ec553a (SHA256)

The PDB string in this sample (H:\Alpha\Bot\Release\Core.pdb) indicates that it is the core component of AlphaLeon. An embedded string further indicates that it is version Per its metadata it was compiled shortly before the loader (2016-02-06 01:17:50).

As with the loader, the majority of the Windows functions are resolved using an API hashing technique. Most of these resolutions use the same algorithm as above, but some use Carberp’s GetApi method.

Most strings in the core component are obfuscated, but instead of using base64 like in the loader, a much more secure XOR encoding is used. They can be decoded with the following IDA Python snippet:

key = "030e180c1a1f".decode("hex")
start = ScreenEA()
encstr = GetString(ScreenEA(), -1, ASCSTR_C)
#encstr = GetString(start, -1, ASCSTR_UNICODE)
plain = []
for i in range(len(encstr)):
    plain.append(chr(ord(encstr[i]) ^ ord(key[i % len(key)])))
print "".join(plain)

Execution starts off with a mutex:


The numbers used for the mutex are the root volume’s serial number returned by the GetVolumeInformation function. Next, system information stored in the registry by the loader is retrieved from the “Zodiac” key and HTTP POSTed to the command and control (C2) server (alpha[.]highclasssoftware[.]ru):


The “d” parameter contains the system information encoded as before in the registry. The “b” parameter is the bot id and consists of the hexadecimal CRC32 hash of the root volume’s serial number. After the phone home, AlphaLeon starts its web browser form grabber and then enters a command poll loop. The command poll is a barebones HTTP GET request:


The “id” query parameter contains the bot id. The C2 returns commands in plaintext. There are two possible commands:

  • $execute <url> – download and execute
  • $update <url> – update self

Depending on whether the command was successful or not, the next command poll will append a “&task=ok” or a “&task=no” to the query string.

Form Grabber

The web browser form grabbing functionality is composed of a few parts. First AlphaLeon injects itself into “explorer.exe” and starts a thread that performs the following:

  • Hooks the “CreateProcessW” function
  • Creates a named pipe called “\\.\pipe\zodiac”
  • Reads a process ID from the pipe
  • Injects AlphaLeon into the process

The “CreateProcessW” function hook performs the following:

  • If the new process is Firefox, disables SPDY functionality in the user’s Firefox profile
  • Executes the legitimate “CreateProcessW”
  • If the new process is a web browser, opens the “zodiac” named pipe
  • Writes the web browser’s process ID to the pipe

Web browser processes are determined by looking for the following process names:

  • iexplore.exe
  • MicrosoftEdge.exe
  • firefox.exe
  • mozilla.exe

Once inside Firefox, AlphaLeon hooks the “PR_Write” function. A quick aside: it is possible that a third party function hooking library is used. This function hook executes the legitimate “PR_Write” function then examines the write buffer for signs of HTTP form data. If found, it exfiltrates the data back to the C2 like this:


Here, “bid” is the bot id; “type” is “fg” for “form grabber”; and “data” contains the stolen form data. Similar to before the data is encoded with base64 and replacing some characters—only the “+” and “/” characters are replaced though. Here is an example decode to show the delimiters added by AlphaLeon:

POST /html/action_page.php HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20100101 Firefox/21.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: _ga=GA1.2.1186174243.1434549841; _gat=1; ASPSESSIONIDQSDTQADR=CIJPAHMDHLCGEPOIFFDFECGE
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 14

For Internet Explorer, it is similar. First, based on the Firefox hook, it appears that the intention was to disable SPDY in Internet Explorer, but due to a bug in the code the “EnableSPDY3_0” registry entry is set to “1” instead of a “0” for off. In addition, the “TabProcGrowth” registry entry is turned off so that browser tabs run within the same Internet Explorer process. Then, its “HttpSendRequestW” function is hooked to search for and exfiltrate form data.

Form Grabber Version 2

During the course of this research, a second version of AlphaLeon’s form grabber plugin (S:\Projects\AlphaLeon\Release\AlphaFGrab.pdb) was discovered:

  • 5df0e520286e14e5c093c67e9187519e (MD5)
  • e8bddb5e77c354876de17db907c4686d53a0bea712a73d7a1eaae0c208563a43 (SHA256)

This version was compiled (2015-09-20 21:58:47) about five months before the samples above and is packaged as a standalone DLL—its loader and core component weren’t found. Based on the coding, it feels like another developer wrote this code. While it contains some similarities with version 1 (mostly the hooking library and exfiltration method) it has a number of differences:

  • Determines if it is injected into a web browser by looking for the following process names:
    • iexplore.exe
    • firefox.exe
    • chrome.exe
  • In Internet Explorer, additionally hooks:
    • InternetReadFileExW – just a wrapper for the legitimate function
    • InternetQueryDataAvailable – just a wrapper for the legitimate function
    • InternetConnectW – more on this hook below
    • HttpOpenRequestW – more on this hook below
  • In Firefox, additionally hooks “PR_Read”, but it is just a wrapper for the legitimate function
  • The details of the Chrome hooking were left to a future study, but looks to be similar in functionality to the “HttpSendRequestW” and “PR_Write” hooks described above
  • Exfiltrates form data to “/krebsonsecurity/plugins_fg.php”
  • The User-Agent used in the exfil is:
    • Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0)

The most interesting addition is that it contains what looks like the beginnings of web injection code–the underpinnings of a “banker” malware. It’s more accurate to call these snippets “placeholder” code as they aren’t particularly functional. The first snippet tries to parse XML-like data from two places: hardcoded in the DLL as a string or stored in a PE file resource. This sample doesn’t contain data in either of those places, but based on the parser a web inject rule would look similar to:

<target url="$URL" uri="$URI"></target>

After parsing, the data isn’t used or referenced anywhere. The second code snippet is hardcoded in the Internet Explorer hooking function and is an example web inject that can be interpreted similar to:

  • $URL =
  • $URI = /login/identify?ctx=recover&lwv=
  • $OLD_SOURCE = <td><div>Email, Phone, Username or Full Name</div></td>
  • $NEW_SOURCE = <td><div>THIS PAGE HAS BEEN ALTERED!</div></td>

$OLD_SOURCE and $NEW_SOURCE aren’t further referenced in the code, but $URL and $URI are compared to “lpszServerName” in the “InternetConnectW” function hook and “lpszObjectName” “HttpOpenRequestW” function hooks respectively. If they match, a global flag is set.

A half finished and non-functional web inject implementation isn’t quite a threat, but it allows for some musings on where the code may be headed.


As the “plugins.php” and “plugins_fg.php” in the URLs of the form grabber imply and the notes in Flashpoint’s report say, AlphaLeon supports additional plugins. For now though, we’ve only been able to uncover the loader, core, and two form grabbing components. The pieces we’ve reverse engineered so far feel like they are still being developed, so it is entirely feasible that future functionality will be uncovered. ASERT continues to monitor the AlphaLeon threat and it will be interesting to see if it continues to develop and grow into a full fledge “banker” malware.

Comments are closed.