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
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.
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_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 [System Process] svchost.exe dwm.exe winlogon.exe explorer.exe taskhost.exe taskeng.exe smss.exe MOM.exe CCC.exe conhost.exe services.exe
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
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 check
InternetQueryOptionA() 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
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
The first 6 bytes of the original
PR_Write function were saved and are executed before returning past the 6 bytes into the original
Soraya uses this same technique to hook the
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
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
vstealth – Stealthily open a URL invisible to the user with
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.
a95dacba360e45fc03769ea55c546a7b 1483d0682f72dfefff522ac726d22256 1661aab32a97e56bc46181009ebd80c9
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/geoip.inc c94285b73f61204dcee5614f91aaf206 login.php d9e7f69822821188eac36b82928de2a0 logout.php e5dadfff0bc1f2113fedcf4eb3efd02f settings.php 22888a7b45adc60593e4fc2fe031be98 statistics.php ecf98e76c99f926e09246b02e53f2533 style.css 3f391740cbbd9623c4dfb19fb203f5bc trackgrab.php ea9a242932dfa03084db3895cf798be5 viewlog.php