SecNews in collaboration with CIVITAS presents you with the analysis of the Soraya malware, which was detected by the security company Arbor Networks. Analyst Matt Bing, ASERT security analyst at Arbor Networks, presents the full analysis of the malware on SecNews.
Localization
Recently, we discovered a new malware family that combines various techniques to steal credit and debit card information. Known as 'Soraya' (meaning "rich"), this malicious code uses the memory scraping technique, like Dexter, to target electronic payment terminals at various points of sale. At the same time, it also steals data sent by a web browser, in a manner reminiscent of the Zeus family of viruses. Neither of these two techniques is new, but their combined use in the same piece of malware is something we have encountered for the first time.
Initial installation
Initially, Soraya injects itself as a thread into several processes of the operating system, including Windows explorer.exe. It then creates a copy of itself in the AppData folder (with the name servhost.exe), and commands it to execute using the registry key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\WinServHost.
After this, any new process started from the -infected- explorer shell, and especially web browsers, carries Soraya's code embedded.
[quote] For this purpose, the virus uses the routine ntdll.dll!NtResumeThread(), which is responsible for process initialization. At the same time, it also uses ntdll!NtQueryDirectoryFile() to prevent servhost.exe from appearing. Both of these techniques are similar to those of the Zeus family of viruses. [/quote]
Memory Scraping
One of the system threads takes over scraping memory for credit card details. It does this by creating a POSMainMutex to ensure that it is the only active thread. Every 5 seconds, the thread iterates through the list of processes using Process32Next() and ignoring system processes that have the following names:
- 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
At the same time, the VirtualQueryEx() routine checks the memory areas used by each process, ignoring those with values in the PAGE_NOACCESS or PAGE_GUARD fields. Valid memory areas are copied via ReadProcessMemory() and examined to determine if they contain credit or debit card information. A similar technique is used by the Dexter family of viruses.
Soraya scans memory for patterns that resemble valid credit card information. For this purpose, it does not use regular expressions, but the format code “B”, followed by numeric strings and the standard “^” separator, according to the ISO/IEC 7813.
A unique feature of Soraya is that it uses the Luhn algorithm to detect valid credit and debit card numbers, a memory scraping technique first seen in POS malware. The Luhn algorithm uses a simple checksum check on the card number to determine if it is valid. Track 1 and track 2 data are packaged and sent to the command & control (C2) center as a “mode 5″ message, according to the following protocol:

Form Grabbing
After its first login, Soraya starts checking some specific DLLs to see if a new process started in the shell is related to a web browser. All functions that handle POST data are targeted, with the goal of stealing the data and sending it to the C2 as a “mode 4” message. This applies to all POST data, not just payment card data.
In Internet Explorer, the virus hooks into wininet!HttpSendRequestW() and checks checkInternetQueryOptionA() with INTERNET_OPTION_URL to see if a size > 1 byte has been sent. If so, the data is copied and extracted.
In Firefox, it hooks into the nss3!PR_Write function, which checks if the word “POST” is contained, and then extracts the data.
In Chome, nspr4.dll!PR_Write() is used accordingly. Here too, the existence of the word “POST” is checked, and then the data is extracted. At the same time, Soraya manually checks chrome.dll and hooks into other unexported functions.
Soraya manages to hook into these functions by overwriting the initial part of the code (function prologue) with the PUSH and RET commands, essentially giving a new saved return address and returning to it. For example, the code below is the normal, unhooked version of nss3!PR_Write in Firefox.
Once Soraya enters, the first 6 bytes of the function are changed with the PUSH 62042h command, which points to the address of the intercept function, and with the RET command which returns to that address.
The intercept function itself at 0x62042 checks if EBX points to “POST” at address 0x6206A. Before that, it has made sure to execute the normal PR_Write function by calling address 0x640EC.
The code at 0x640EC used to execute the normal PR_Write function uses a similar technique. The first six bytes of the normal PR_Write function are stored and executed before returning the 6 bytes of malicious code that have been replaced with them.
Soraya uses the same technique to hook into ntdll.dll!NtResumeThread() and ntdll!NtQueryDirectoryFile(), quite reminiscent of Citadel's method.
Contacting Command & Control
One of the system threads is responsible for communicating with the command & control server. This is achieved by creating the mutex JDWJDd8a2 and checking C2 every 5 minutes, so that useful data is sent to a specific URL that has been embedded in the executable code. C2 and the corresponding URL have been embedded in the code, after first being XORed with the Unicode string “SorayaV1.1″.
To avoid being triggered on every browsing session, the C2 backend only accepts messages that have a specific User-Agent. In the code we found, this value is static, which should be unique for that particular instance.
Several HTTP POST variables can be sent to C2, such as:
mode – specifies the type of message sent to the C2 by the virus
uid – A unique string-identity generated by the virus itself and stored in HKCU\SOFTWARE\Microsoft\Soraya2\UID of the registry
osname – A hex string describing the version (major and minor) of the operating system, the service pack version, and the architecture type (“x86″ or “x64″)
compname – A hex string containing the current computer and user name
browser – One of “FireFox”, “Chrome” or “InternetExplorer”, depending on the browser that created the message
url – A hexURL to which the data is sent
grabbed – Rawdata that is collected by a POST and sent to a URL
compinfo – Same as compname
ccnum – Encoded (Hex) credit card number
type – “Track 1″ or “Track 2″ depending on the type of data captured
track – Hex encoded raw track data
comid – A numeric jobID defined by C2
The following values for “mode” have also been identified:
Mode 1 – Registers a new bot in C2
Mode 2 – Receiving the latest commands from C2
Mode 3 – Informing C2 that the current job has completed
Mode 4 – Adding information from a grabbed form
Mode 5 – Send skimmed track information to C2
The thread responsible for communicating with C2 sends messages “mode 1″, “2″, and “3″. In response to the “mode 2″ message, the server responds with one of the following:
vweb – with ShellExecuteA() open a URI
vstealth – with URLDownloadToFileW(tmpfile) open a URL, invisible to the user
down – Download a file from a URL and execute
update – Download a file from a URL, send a “mode 3″ message, create a new process in the code, and then self-destruct
uninstall – Reply with a “mode 3″ message, and then self-destruct



Web Panel / Back-end
Version 1.0 of Soraya's panel includes the following files:
login.php
login.php is the login page for the panel. This file accepts the password sent via the “p” parameter of the GET request. If the login is successful, the session variables are set and the administrator is redirected to “statistics.php”.
auth.php
This file stores various information about the session.
statistics.php
The statistics.php page gives an overview of the bots that can check the C2. It includes information about the total number of bots online, the number of infected computers per country, and the 25 most recent connections.
bot.php
Processes infected by Soraya declare their presence in the command & control and send POST requests to the file “bot.php”. Soraya is designed to send a specific user-agent which acts as a connection password to the panel. If the password is correct, then the file accepts the registration of a new bot in the panel, requests for new commands to be executed by the targeted computer, and confirmation of the correct execution of each command. It also accepts stolen form data and track data. All this information is then stored in a backend database, just like in many normal C2s.
commands.php
The “commands.php” page is used to send commands to bots that have registered in the control panel. Among the modules are the ability to open random URLs, with or without the user’s knowledge, downloading and executing files, upgrading the bot, or the command to uninstall it. On the same page we find information about the times a particular bot should execute a command, as well as the total number of times a command has been executed.
logout.php
The page that ends an active session.
settings.php
The file includes the panel login definitions, database information, and the connection password used by the malware.
formgrab.php
The page shows the list of bots that have intercepted form data, and more specifically, the bot's identity, IP address, browser type, target URL, and the date the form data was intercepted.
viewlog.php
The page displays the intercepted POST data and the corresponding URLs.
trackgrab.php
The page displays the stolen card numbers, raw track data, the type of intercepted track data, and the name of the infected computer. The same page saves the track data to a dump file, whose name is defined as “dump-YYYY-mm-dd.txt”, while from here the panel administrators can delete track data from the database.
funcs.php
Contains various functions, useful in other components of the control panel.
/inc/GeoIP.dat
The country code of an infected computer is assigned a specific value once the bot registers in the control panel. This file contains the MaxMind GeoIP data used to identify each country.
/inc/geoip.inc
Contains the MaxMind PHP code used to map the IP address of an infected computer to the corresponding country.
Stolen payment card details
According to the analysis and data we have gathered for Soraya, the stolen cards number in the thousands. We were able to see the track data from a command & control, once the stolen card details were found temporarily stored on a public server.
Analysis of track 1 data showed that the countries of origin of the banks that had issued the stolen cards were the following:
65.16% of the cases involved cards issued by US banks. Costa Rican banks were also the most affected, with 21.45% of the cards, followed by Canadian banks with 11.20%, South African banks with 0.82%, Brazilian and Russian banks with 0.40%, and finally, banks in the UK, Poland, Mexico and Panama with 0.14% each.
Additionally, we were able to identify the type of cards that Soraya stole. The majority were debit cards (63,934% of all track 1 data). Credit cards followed at 34,153%. For the remaining 1,913%, we were unable to find their type.
[box_alert]
Conclusion
It is clear that Soraya's creators were inspired by the Dexter and Zeus viruses. The dual mode of simultaneous memory scraping and form grabbing is what makes Soraya unique. In previous attacks, memory scrapers targeted point-of-sale terminals, while form grabbers targeted online banking users.[/box_alert]
MD5s
To aid further investigations, we are listing the MD5 values from the samples 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
Study/analysis
The study was conducted by Matt Bing, ASERT security analyst at Arbor Networks and was published through CIVITAS .











