The Best Of Both Worlds – Soraya

By: Matthew Bing -

By Matt Bing & Dave Loftus

Arbor Networks’ ASERT has recently discovered a new malware family that combines several techniques to steal payment card information. Dubbed Soraya, meaning “rich,” this malware uses memory scraping techniques similar to those found in Dexter to target point-of-sale terminals. Soraya also intercepts form data sent from web browsers, similar to the Zeus family of malware. Neither of these two techniques are new, but we have not seen them used together in the same piece of malware.


Soraya begins by injecting itself as a thread on several system processes, including the Windows Shell explorer.exe. The malware maintains persistence by writing a copy of itself into the AppData directory with the name servhost.exe, and setting itself to execute with the registry key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\WinServHost.

New processes launched from the infected explorer.exe shell, notably web browsers, will have Soraya code injected. The malware does this by hooking calls to the ntdll.dll!NtResumeThread() function, which is responsible for process initialization. The function ntdll!NtQueryDirectoryFile() is also hooked to hide displaying the servhost.exe file. Both of these techniques are similar to functionality found in the Zeus family of malware.

Memory Scraping

One thread on the system is responsible for scraping memory for credit card data. It does this by creating the mutex POSMainMutex to ensure it is the only thread operating. Every 5 seconds, the thread will iterate through the list of processes with Process32Next(), ignoring system processes with names shown in Figure 1. It will check memory regions for each process with VirtualQueryEx(), ignoring those with the PAGE_NOACCESS or PAGE_GUARD values set. Valid memory regions are copied with ReadProcessMemory() and examined for payment card data. The Dexter malware family uses a similar technique.

[System Process]

Figure 1 – Process Names Ignored For Memory Scraping

Soraya will scan memory for patterns matching valid payment card data. It does not use regular expresssions, but matches the format code “B”, patterns of digit strings, and the standard “^” separator as defined in ISO/IEC 7813. One unique aspect of Soraya is that is uses the Luhn algorithm to identify valid credit and debit card numbers, a new technique for memory scraping point-of-sale malware. The Luhn algorithm leverages a simple checksum over credit card numbers to ensure that they are valid. Track 1 and track 2 data are packaged and sent to the command and control (C2) site using the protocol described below as a “mode 5″ message.


Figure 2 – Luhn Algorithm

Form Grabbing

After injecting itself, Soraya will check if the new process is a web browser by locating several unique DLLs. The functions targeted are those responsible for sending POST data, which are intercepted and sent to the C2 as a “mode 4″ message described below. All POST data is captured, not just payment card information.

Internet Explorer has the function wininet!HttpSendRequestW() hooked, and will checkInternetQueryOptionA() with INTERNET_OPTION_URL to see if > 1 byte is being sent. If so, data is copied and exfiltrated.

Firefox has the function nss3!PR_Write hooked. The hooking function will check for the “POST” verb, then exfiltrate data.

Chome has the function nspr4.dll!PR_Write() hooked. The hooking function will also check for the “POST” verb, then exfiltrate data. Soraya will also manually examine chrome.dll and similarly hook unexported functions.

Soraya hooks these functions by overwriting the function prologue with the instructions PUSH and RET, essentially providing a new saved return address and returning to it. As an example, this is what a normal, unhooked version of Firefox’s nss3!PR_Write looks like in WinDBG.


After being injected with Soraya the first 6 bytes of the function are overwritten with PUSH 62042h, the address of the intercept function, and RET which returns to that address.


The intercept function itself at 0×62042 will check if EBX points to the string “POST” at 0x6206A. Before this, it will execute the original PR_Write function by calling the address at 0x640EC.


The code at 0x640EC to execute the original PR_Write function uses a similar technique. The first six bytes of the original PR_Write function were saved and are executed before returning past the 6 bytes of the hook code that now constitute PR_Write.

The first 6 bytes of the original PR_Write function were saved and are executed before returning past the 6 bytes into the original PR_Write function.


Soraya uses this same technique to hook the ntdll.dll!NtResumeThread() and ntdll!NtQueryDirectoryFile() functions, in a very similar fashion to the Citadel malware.

Command and Control Communication

One thread on the system is responsible for communicating with the command and control server. It does this by creating the mutex JDWJDd8a2 and checking in with the C2 every 5 minutes by posting data to a specific URL embedded in the executable. The C2 site and URL are encoded in the executable by XORing with the Unicode string “SorayaV1.1″.

To discourage casual browsing, the C2 backend will only accept messages with a specific User-Agent set. In the samples we’ve identified, this value has been static, which we believe is unique to this particular campaign.

Several HTTP POST variables may be sent to the C2:

mode – Identifies the type of message the malware is sending to the C2
uid – A unique idenifier string generated by the malware, which is stored in the registry at HKCU\SOFTWARE\Microsoft\Soraya2\UID
osname – A hex encoded string of the major version, minor version, service pack version, and “x86″ or “x64″
compname – A hex encoded string of the current username and computer name
browser – One of “FireFox”, “Chrome”, “InternetExplorer” depending on the browser generating the message
url – A hex encoded URL for which data is being submitted
grabbed – Raw data captured by a POST to a URL
compinfo – Same as compname
ccnum – Hex encoded credit card data
type – “Track 1″ or “Track 2″ depending on the data captured
track – Hex encoded raw track data
comid – A numerical job ID set by the C2

The following “mode” values have been identified:

Mode 1 –  Identify a new bot to the C2
Mode 2 - Receive the latest commands from the C2
Mode 3 – Tell C2 that the current job has completed
Mode 4 – Add grabbed form information
Mode 5 – Send skimmed track information to the Command & Control

The thread responsible for C2 communication will send “mode 1″, “2″, and “3″ messages. In response to a “mode 2″ check for the latest commands, the server will respond with one of the following:

vweb – Open a URI with ShellExecuteA()
vstealth – Stealthily open a URL invisible to the user with URLDownloadToFileW(tmpfile)
down – Download a file from a URL and execute it
update – Download a from for a URL, respond with a “mode 3″ complete message, spawn a new process with the executable, then self destruct
uninstall – Respond with a “mode 3″ message, then self destruct

When Soraya is installed, it sends a POST request to the C2 server. The request consists of a “mode 1″ message, the operating system version, computer name, and unique UID identifying the bot.


Soraya sends a “mode 2″ message to obtain any pending commands from the C2 server.


Any web browser process infected with Soraya is capable of sending “mode 4″ messages. The thread responsible for memory scraping sends “mode 5″ messages, as seen below:


Web Panel / Backend

Version 1.0 of the Soraya panel consists of the following files:

The login.php page is the administrative login page used for the panel. This file accepts the control panel password sent via the “p” parameter in a GET request. If the login is successful, session variables are set and the administrator is redirected to “statistics.php”.

This file stores session information.

The statistics.php page provides a general overview of any bots that are able to check into the C2. The total number of bots online, the number of infections per country, and the last 25 connections are displayed on this page.


Soraya infections checking into the command and control send POST requests to the file “bot.php”. Soraya is designed to send a specific user-agent that acts as a connection password to the panel. If correct, this file accepts new bot registrations to the panel, requests for new commands that should be executed by Soraya bots, and acknowledgments that commands have been successfully completed. It also accepts stolen form data and track data. All of this information is subsequently stored in the backend database, which is typical of many C2s.

The “commands.php” page is used to send commands to Soraya bots that have registered with the control panel. Commands include the ability to open arbitrary URLs that are visible or not visible to the victim, download and execute files, update a bot, or request that a bot uninstall itself. This page also displays the number of times a bot should perform a particular command, and the total number of times a command has been performed.


This page ends the current session.

The panel password, database information, and connection password used by the malware are defined in this file.

Displays a list of bots that have acquired form data. The bot identifier, IP address, browser used, URL visted, and date form data was received are displayed on this page.

Displays the exfiltrated POST data and their respective URLs.

Displays stolen card numbers, raw track data, the type of track data exfiltrated, and computer name of the compromised machine. This page is also used to save the track data to a dump file using the format “dump-YYYY-mm-dd.txt”. Panel administrators have the ability to delete track data from the database using this page.


Contains miscellanous functions used by other components of the control panel.

The country code of compromised machines are identified when a bot registers with the control panel. This file contains MaxMind GeoIP data that is used to identify the country.

Contains PHP code from MaxMind that is used to map IP addresses of compromised machines to their respective countries.

Payment Card Data

Our analysis of Soraya revealed that thousands of payment cards have been compromised. We were able to acquire track data from one command and control after the attacker temporarily placed the card data in a publicly accessible location.

An analysis of the track 1 data revealed the country of origin of the financial institutions issuing the cards that were compromised:


Our analysis revealed that 65.16% of the payment cards compromised were issued by financial institutions located in the United States. Costa Rican financial institutions were also deeply affected, having issued 21.45% of cards that were compromised. Canadian financial institutions issued 11.20%, South African institutions issued 0.82%, Brazilian and Russian based institutions each issued 0.40%, and institutions in the UK, Poland, Mexico, and Panama each issued 0.14%.


Additionally, we were able to determine the type of many cards compromised by Soraya. Debit cards were the most compromised, representing 63.934% of the track 1 data obtained. Credit cards consisted of 34.153%. We were unable to determine the type of cards for 1.913%.


Soraya has clearly taken inspiration from the Dexter and the Zeus families. The “split brain” functionality of both memory scraping and form grabbing is Soraya’s most unique trait. In past campaigns, memory scrapers have been uniquely targeted at point-of-sale devices and form grabbers have been uniquely targeted at online bank users.


To support further investigation by researchers, below are the MD5 values for samples we’ve identified as Soraya.


The following MD5 hashes are associated with the panel files:

1df57b31a4bca7a1c93ecd50bd8fd8bf auth.php
67a6bf5b9b23c6588c756c2f2a74635c bot.php
c3e9d1dda7f1f71b4e1e2ead7c7406dd commands.php
515232eb815b7bafab57c7cdca437a7a formgrab.php
ff8cc2e792a59d068f35cb3eb2ea69bc funcs.php
b64ea0c3e9617ccd2f22d8568676a325 /inc/GeoIP.dat
d2ba8b27dc886b36e0e8ec10e013d344 /inc/
c94285b73f61204dcee5614f91aaf206 login.php
d9e7f69822821188eac36b82928de2a0 logout.php
e5dadfff0bc1f2113fedcf4eb3efd02f settings.php
22888a7b45adc60593e4fc2fe031be98 statistics.php
ecf98e76c99f926e09246b02e53f2533 style.css
3f391740cbbd9623c4dfb19fb203f5bc trackgrab.php
ea9a242932dfa03084db3895cf798be5 viewlog.php

Comments are closed