Bedep’s DGA: Trading Foreign Exchange for Malware Domains

By: Dennis Schwarz -

As initially researched by Trend Micro [1] [2], Zscaler [1] [2], Cyphort, and Malware don’t need Coffee, the Bedep malware family focuses on ad / click fraud and the downloading of additional malware. ASERT’s first sample dates from September 22, 2014, which is in line with when Trend Micro started seeing it in their telemetry. In early 2015, the family got some more attention when it was being observed as the malware payload for some instances of the Angler exploit kit, leveraging the Adobe Flash Player exploit (CVE-2015-0311) which at the time was a 0day. It was also observed that this newer version was using a domain generation algorithm (DGA) to generate its command and control (C2) domain names.

This post provides some additional notes on the DGA including a proof of concept Python implementation, a look at the two most recent sets of DGA generated domains, and concludes with some sinkhole data.


The following Bedep samples were used for this research:

  • MD5 e5e72baff4fab6ea6a1fcac467dc4351
  • MD5 1b84a502034f7422e40944b1a3d71f29

The former was originally sourced from KernelMode.


I’ve posted a proof of concept (read: works for me) Python implementation of the DGA to ASERT’s Github.

At the time of writing, I’m aware of two DGA configs. Each config contains three constants and a table of magical dwords used throughout the algorithm. The screenshot below highlights the table from the first sample:


Bedep’s DGA starts by downloading an XML file from:


This legitimate web service provides the time zone and local time at latitude zero and longitude zero. The <utctime> timestamp is parsed out and converted to milliseconds since year zero (0000-00-00). Then, 1-3 days are subtracted from it (depending on tick count timing–this feels like an anti-analysis technique) and it is converted to days since year zero. This value will be used in the next step.

Next, Bedep downloads an XML file from:


This legitimate file from the European Central Bank (ECB) contains the last 90 days of “Euro foreign exchange reference rates” and is updated daily. Each date is extracted from the <Cube time=”…”> tags then the days since year zero is calculated for “date minus one”. If the days since value is less than or equal to the value calculated in the first step AND if it falls on a Monday, then the foreign exchange reference rates for “date” are extracted and used. Here’s a visual showing this process:


After testing, my analysis reveals that Bedep updates using “last Tuesday’s” foreign exchange reference rates—where “last Tuesday” refers to “the preceding week’s Tuesday” until “this week’s Thursday”. After this, it means “this week’s Tuesday.”

From here, the algorithm becomes a bit opaque. Various values such as “days since,” the first parsed currency’s abbreviation, the low dword of the first parsed currency’s rate, the magical dword values from the extracted table (noted above), and various other constant and calculated values are transformed a number of times. I wasn’t able to deduce the “big picture” of these transforms, so I’m treating them as a blackbox where the output is the number of domains to generate and three values that that will be used to calculate a modular exponent starting seed. If anyone has more details on this blackbox, please reach out!

The number of domains to generate is 22 for the first config and 28 for the second for a total of 50 domains per set. To generate each domain, the starting seed and foreign exchange reference rates are transformed a number of times to calculate the domain length and the domain characters themselves:


The minimum domain length is 12 and the maximum is 18. I’ve only seen “.com” TLDs so far.


At the time of writing and using the foreign exchange rates from 2015-04-07, here are the eight registered domains from this set:


The first two were registered on 2015-04-13, the next two on 2015-04-11, then 2015-04-10, and the last two on 2015-04-08. All of them used the following registrant info:


This info is inline with what Zscaler observed.

Using the foreign exchange rates from 2015-04-14, here are the domains registered out of the set, so far:

  • (
  • (

The first two were registered on 2015-04-19, then 2015-04-17, and the last two on 2015-04-15. All six used the same registrant noted above.


To get a better idea of how active and widespread the above campaign is, we setup a sinkhole. The sinkhole was and from 2015-04-13 13:47 UTC to 2015-04-16 17:06 UTC (about 3 days) it received phone homes from about 82,127 unique source IPs. The top 10 TLDs of the resolved source IPs were:

  1. net (31578)
  2. com (11952)
  3. de (3193)
  4. mx (2611)
  5. tr (2104)
  6. it (1521)
  7. pl (1500)
  8. fr (1440)
  9. br (1360)
  10. au (1247)
  11. ca (1107)
  12. jp (1054)
  13. es (769)

And, except for Russia, infections were all over the map:



This post has taken a closer look at Bedep’s DGA and the recent campaign around it. Compared to some of the other date based DGAs we’ve looked at in the past, this algorithm is quite a bit more complicated and involved—effectively relying on the foreign exchange markets to generate its C2 domains. Based on the domain registration and sinkhole activity, Bedep is a current and active threat and will likely remain so for the foreseeable future.

Neverquest: A global threat targeting Financials

By: Arbor Networks -

By: ASERT Research Team

On March 31st, Arbor’s Security Engineering & Response Team (ASERT) published a detailed threat brief on the Neverquest malware for Arbor customers. Along with thousands of IOC’s (indicators of compromise), the brief details Neverquest’s current inner workings and describes some reversing techniques ASERT uses to unravel and monitor this stealthy and quickly evolving malware. Applying this research at scale to malware and data acquired by our global ATLAS initiative allows us to develop targeted defenses and security context that enables customers to mitigate advanced threats and enhance their security posture over time [1].

This blog post provides excerpts from the Neverquest threat brief along with some new data that was not available at the time the brief was released to customers. In doing so, it also highlights the results of ASERT research activities that feed Arbor products.

Historical Threat Context and Prior Research

Originally, a malware family known as Ursniff was used to build newer malware called Gozi. After some success and a time of inactivity, Gozi was revitalized as Gozi Prinimalka, which has evolved into the modern Vawtrak/Neverquest (referred to as ‘Neverquest’ herein). Foundational threat analysis work has been performed for years on the Gozi banking Trojan and the Russian threat actors associated with it. From the “Hang-up Team” running the illicit business 76service all the way to the modern era, a group of experienced cybercriminals have been working this threat, apparently with substantial success that has kept the operation rolling for years. Recent changes in mid-2014 have brought the threat back to the attention of the security industry and law enforcement. The threat evolves frequently, and has been propagated by various tactics including but not limited to spambot delivery with the Kulouz spambot, exploit kit distribution, malicious MS-Word documents, and downloads from the Chanitor downloader malware. Researchers from Sophos published operational details of the threat in December 2014 that discuss the evolution of Neverquest into a crimeware-as-a-service platform. In January of 2015, additional observations were made public about the expansion of the criminal infrastructure and targets by researchers at PhishLabs.

On March 24, 2015 anti-malware firm AVG published research about the latest Neverquest activity, including the use of tor2web domains to download updates. Tor2web domains have been visible inside Neverquest binaries for months, however the actual use of these sites was not observed within our analysis environment until mid-March 2015.

Readers with the need or desire for a more complete picture of this evolving malware are encouraged to review this important prior work.

Malware Threat Overview

Having evolved from earlier malcode, Neverquest incorporates advanced techniques honed from years of underground experience. In the quest for financial gain, Neverquest is used to gain access to victim bank accounts and other financial processing systems on behalf of the compromised victim. Stolen accounts are harvested and delivered back to the threat actors behind the attack campaign. These credentials can be used in conjunction with a series of webinjects where Neverquest injects malicious code into an otherwise authorized and legitimate web session that has been selected by URL or keyword criteria, AKA “man in the browser”. The capability to leverage webinjects and proxy through victim machines allows the threat actors to bypass security restrictions such as multi-factor authentication and encryption, as well as to take advantage of existing session data and transactions. More basic credential theft capabilities are present as well since Neverquest has incorporated, in form or in essence, the functionality of the famous Pony Loader malware which scours a system for saved credentials that are then exfiltrated to the attackers. Threat actors also can connect via a Virtual Network Computing (VNC) interface to the target, and have also been observed proxying transactions through VPN’s likely to obfuscate the trail that might lead back to themselves or their criminal infrastructure. Other functionality includes the ability to steal certificates and cookies, execute commands, locate files on the disk, setup a SOCKS server, download bot updates, and more.

Investigation suggests that the threat actors are coordinated and experienced and continually evolve their tactics, techniques, and procedures (TTP’s) in response to security industry advancements and public disclosures. Examples of this evolution are the increased use of encryption to protect the configuration elements from easy interception at multiple levels, an increase in the number of targets and C2 domains being pushed in configurations, use of steganography to update C2 lists, and emergent use of the tor anonymity network to obfuscate and protect back-end criminal server infrastructure.

Neverquest Configuration

First-stage configuration

Neverquest typically contains an internal, first-stage configuration stored within the malware binary itself. This configuration provides initial static parameters that will be used during the first contact with C2 infrastructure. First-stage configuration information includes the following:

  • C2 information: A list of IP addresses and/or domain names used for C2. Each malware binary contains numerous C2’s, with lists as small as four C2 and up to 28 C2.
  • Project ID: a numerical value associated with the campaign at hand. Each project ID appears to be useful for partitioning the botnet into active campaigns that may be targeting one or more targets.
  • Update version: the version of the software.
  • Build: The build number of the software.
  • URI Template: a format string that will be used, along with dynamically and statically generated data in the POST to the C2.
  • Tor2web domains: a listing of tor2web domains (not found in all variants).
  • Encryption seed material: various encryption seeds used dynamically by the bot in encryption and decryption processes.

Second-stage configuration

Once Neverquest reaches out to its C2, it receives a larger configuration file that contains a wealth of target information. This second-stage configuration contains three general sections:

  1. Web Inject Rules: instruct where to inject malicious content into an HTTP session

Each injection rule is formatted as such:

($target_url_regex, $injection_point, $content_to_be_injected, $flags)

An example:

(‘’, ‘</body>’, ‘<script>\r\nLoadPageGood();\r\n</script>\r\n</body>’, ‘\x0c\x07 ‘)

This means for any URL matching ‘, replace the first </body> element with the malicious Javascript provided.

  1. Trigger URL’s: Theft of HTTP requests

The Trigger URL’s are a list of URL’s that will have their HTTP requests forwarded to a Neverquest C2.

Each trigger URL is formatted as ($trigger_url, $flags)

An example:

(‘’, 32)

  1. Trigger Strings: Theft of HTTP responses

When Neverquest encounters a trigger string in any HTTP response, it will send a copy of that response to a C2.

An example:

‘available balance’

Neverquest is a global phenomenon

As of March 27th, ASERT’s collection of Neverquest malware artifacts was as follows:

Table 1

Our sample set indicates that 25 different countries are hosting at least one site targeted by a Neverquest webinject. While there are many ways to assess the degree to which a given country is impacted by Neverquest, we offer two below. The first chart ranks the 25 countries according to the number of different Neverquest project ID’s (campaigns) targeting each country. Note that a single project ID typically contains webinjects for sites in multiple countries:

Figure 1

As an example, the graph above tells us that 72% (36 of 50) of all project ID’s in our sample set contain a webinject URL targeting a site in Great Britain.

Another way to view Neverquest country impact is to look at the geo-location data for the IP addresses of the sites associated with Neverquest webinject URLs. This data is graphed in Figure 2. Note that the line for the United States is cut off so as not to obscure the rest of the chart. While the chart cuts off at 30, there are 230 IP addresses associated with US sites targeted by our current list of Neverquest webinjects:

Figure 2

To the degree it assists with interpreting these graphs, we note that while Canada (CA) ranked 8th, in Figure 1, based on the 25 different Neverquest Project ID’s targeting Canada, it ranks 2nd in Figure 2 in terms of the number of IP addresses in Canada hosting sites targeted by Neverquest.

We can also determine from the prior two charts that the 27 different project ID’s targeting Saudi Arabia (SA), are all targeting the same single site within Saudi Arabia.

As noted above, a single Neverquest project ID usually targets different domains hosted in various countries. Similarly, different Neverquest project ID’s often target the same domains. The following chart graphically illustrates the connections between the 50 Neverquest project ID’s (yellow circles) and the 25 targeted countries (blue circles):

Figure 3

As visually suggested by the diagram, there exist certain groupings of project ID’s and countries. Indeed there are ten sets of Neverquest project ID’s in our sample set such that all project ID’s within a given set target the exact same countries:

Table 2

Different project ID’s with the same targets lends credence to the Crimeware as a Service model envisioned by the Sophos paper. For example, different adversaries may target the same set of victims using different campaign ID’s for tracking purposes. It may also be the case that purchasing the service comes with a default configuration that can subsequently be tweaked by the adversary.

In the full ASERT Threat Intelligence Brief, we leverage these groupings to provide further insight into the specific domains targeted by each group. Specifically, for each group of project ID’s, the full ASERT brief provides a high level geographical view of the sites being targeted by webinjects, followed by a list of the target domains and the corresponding number of webinjects for that domain.

As resources permit, ASERT can provide targeted customers with details concerning the precise injection points and content to inject for each target URL. Targeted organizations seeking additional insight are encouraged to contact Arbor Networks for further collaboration.

Victim Analysis

As a result of sinkholing numerous Neverquest Command & Control domains, ASERT has obtained insight into a sample set of compromised machines reporting back to the C2 domain(s). Each point of compromise, represented by a unique IP address may be the result of a trigger URL, a trigger string, or a webinject target URL being present in the victim environment which caused data to be POSTed to the C2 servers. While DHCP churn and mobility are going to provide for variability in the accuracy and confidence of these maps, monitoring reveals that approximately 64,500 unique IP addresses contacted our Neverquest sinkholes during the period of March 1 – March 26, 2015.

Figure 4

Further analysis is required in order to correlate victim locations with Neverquest webinject targets.

Figure 5

As expected, major population centers display a high number of compromises in the US and elsewhere around the world. While many population centers are hit hard, the UK appears to have been hit very hard.

Figure 6

In the Asia Pacific region, Japan shows substantial compromise activity, with a smaller amount of victims appearing in South Korea.

Figure 7

Trigger URL Frequency

Recall that when Neverquest detects a trigger URL in a POST request, it will forward a copy of the posted data to a C2. As of March 25th, we have observed 153 unique trigger URLs in Neverquest configurations. Of the 1,066,608 POST requests picked up by our sinkhole, we have observed 60 of these 153 trigger URL’s. The following table lists, by count, the current top 25 trigger URL’s posting data to our sinkhole.

Figure 8

Importantly, note how Neverquest is hijacking more than communications with targeted financial institutions. From above, we see that it also exfiltrates email being posted to or

Attacker Infrastructure

Based on a sample of available data, C2’s are scattered all around the world, with a higher concentration in various European countries and Ukraine. These plots are only a representative sample of C2 activity and should not be considered to be comprehensive.

Figure 9

Figure 10

Recent Advances in Threat Construction: Tor2Web Indicators

Recent samples of Neverquest contain code designed to connect to hidden tor servers via the site in a manner similar to the tactic used by the Chanitor downloader malware, which is using tor2web for Command & Control (C2) purposes. Neverquest variants are downloading digitally signed updated C2 lists stored within favicon.ico files that appear legitimate but have been modified with the use of steganography. While the first tor2web domains appeared inside Neverquest malware samples by at least December 27, 2014, Neverquest has only been observed in our sample set obtaining these updates over the network since at least March 12, 2015. A complete list of C2 indicators as of March 27th, including onion domains is included in the full ASERT Threat Intelligence Brief.

Visual Indicators of Compromise

In some cases, attackers may define a webinject that produces a visual indicator of compromise. Past research suggests that attackers have spent a lot of time working on the webinjects in order to make them functional and effective. Bypassing the average user’s suspicions is an important goal for the attackers, yet in some cases users may notice something amiss, especially if the financial institution has alerted their users of any visual or behavioral changes that can indicate a problem.

The attackers may attempt to reassure the victim by explaining that the visual changes are due to extra security measures being implemented by the financial institution for the customer’s protection. The attacker may request a secondary authentication code in an attempt to target high value accounts using multifactor authentication methods. If the end user has already successfully authenticated and a secondary authentication factor is not necessary, the message can be used as a stalling tactic, allowing criminals enough time to hijack the user’s session. Stalling tactics can include asking a user for an authentication code from a device the user does not possess, validation of security parameters, or the site being unavailable for maintenance.

Injections may often contain errors such as requesting a password in three places on the same form. The victim is often asked for information the bank should already know such as the user’s name, or the victim’s work, mobile, and home phone numbers. The attackers sometimes leave accidental artifacts in their injections. In one example, a static user id was pre-populated into an injection field.

Threat Velocity

Neverquest threat actors are keeping busy. New campaigns are coming on-line frequently that are aimed at a wide variety of targets. Additionally, ongoing development has been observed. If recent development trends observed by ASERT continue, we can expect approximately one new build per month and somewhere between ten and twenty new project ID’s although these numbers are only estimates and could vary greatly depending upon the ongoing success of these attack campaigns.

As an example of the velocity of this threat, we have observed various additions within a sample monitoring window (March 9 – March 27, 2015) that are worthy of note. Ten new project ID’s have been observed, each one representing a new criminal campaign aimed at a variety of targets. Additionally, we observed the following changes in other malware campaign activity:

Table 3

Figure 11


Neverquest is a rapidly evolving malware family that has borrowed malicious code and techniques from a variety of other malware with the intention to provide a best-of-breed cybercrime platform. One or more criminal threat actors utilize the malware for the purposes of building botnets to facilitating banking fraud and the use or sale of various credentials through a variety of means. These means include credential theft, proxying through victim machines, HTTP transaction data theft, and injecting malicious content (webinjects) into authorized transactions between the victim machine and a target site. Campaigns are ongoing, as part of a long-running and evolving cybercriminal operation that has been active over the course of several years. In order to thwart analysis and increase compromise incidence and longevity, threat actors behind the malware are taking steps to obfuscate and encrypt both malware operations and aspects of the back-end infrastructure. Additionally, new development on the code is taking place at least monthly. New Command & Control nodes are appearing at a rapid rate, along with new project ID’s, new samples, and new webinject configurations. Additionally, sinkhole data obtained from sinkholing one or more expired C2 domains indicates that a substantial volume of compromised machines continue to fuel the Neverquest cybercrime apparatus and the underground economy. Many organizations have been targeted, therefore increased and ongoing awareness of this threat as it evolves is crucial. Considering the rate of change observed during our monitoring periods, the threat actors are not standing still and have invested substantial resources into planning, development, back-end criminal infrastructure and associated operations that enable attack campaigns to continue at a rapid pace. Detection across all points in the cyber-kill chain is recommended in order to minimize losses and more rapidly detect malicious activity as financial customers and others continue to be targeted.

[1] On a daily basis, ASERT gathers well over 100,000 malware samples from ATLAS and other sources. With a focus on Advanced Persistent Threats, geo-political campaigns, financial fraud and DDoS, the malware samples are processed through an automated threat analysis system that applies advanced research techniques to classify malware and extract indicators that can be used by customers to detect and mitigate attacks.


Let’s Talk About NewPosThings

By: Dennis Schwarz -

by Dennis Schwarz and Dave Loftus

NewPosThings is a point of sale (PoS) malware family that ASERT has been tracking for a few weeks. It operates similarly to other PoS malware by memory scraping processes looking for credit card track data and then exfiltrating the spoils to a command and control (C2) server. Based on compilation times, it has been in active development since at least October 20, 2013—with the latest timestamp being August 12, 2014. Since we haven’t come across any public details of this family, we’re releasing our malware analysis for posterity and to get ahead of the threat.

The analyzed sample has an MD5 of 4196c67648003a18f61573a77b6d3be6.


Its name comes from an embedded PDB pathname string from the analyzed sample:

C:\Users\Tom\documents\visual studio 2012\Projects\NewPosThings\Release\NewPosThings.pdb


The malware initializes itself as follows:

  • Sets some insecure file flags in the Registry:
    • “LowRiskFileTypes” in “HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations”
    • “1806” in “HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0”
  • Copies itself to “%APPDATA%\Java\JavaUpdate.exe”
  • Checks whether it is running as 64-bit and if so, exits with a MessageBox of “Use 64bit version.”
  • Kills any existing “JavaUpdate.exe” processes
  • Sets up Registry Run persistence (HKCU\Software\Microsoft\Windows\CurrentVersion\Run) under “Java Update Manager”
  • Executes copied executable passing the original executable’s pathname and “RM” as command line arguments
  • Original process exits

Second copy continues:

  • Deletes original executable
  • Phones home to the C2
  • Searches the Registry for VNC passwords. The following keys and values are checked:
    • HKLM\SOFTWARE\RealVNC\vncserver[Password]
    • HKLM\SOFTWARE\RealVNC\WinVNC4[Password]
    • HKCU\SOFTWARE\RealVNC\WinVNC4[Password]
    • HKCU\Software\TightVNC\Server\[Password]
    • HKCU\Software\TightVNC\Server\[PasswordViewOnly]
    • HKCU\Software\TigerVNC\WinVNC4\[Password]
    • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Ultravnc2_is1[InstallLocation] (then opens ultravnc.ini looking for “passwd=/passwd2=”)
  • Sets “SeDebugPrivilege” privilege
  • Starts memory scraping thread
  • Starts C2 communications thread
  • Starts key logging thread

C2 Communications

The initial C2 phone home is HTTP POST based and looks like:



Header-wise: there is a bug with Accept as, per the code, it is supposed to be “*/*” and the User-Agent is hardcoded to “Mozilla/4.0(compatible; MSIE 7.0b; Windows NT 6.0)”. The POST parameters break down into:

  • cs – is in base64 and decodes to “insert”
    • The base64 charset used in this malware is “ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_”
    • p – contains Windows version, “+32” is hardcoded (most likely a placeholder for architecture type), and computer name
    • m – the volume serial number of the root drive (used as an identifier)

An example response from the C2 is:



If any VNC passwords were found in the Registry they are exfiltrated to the C2:



The parameters are:

  • cs – base64, decodes to “log”
  • m – the volume serial number of the root drive (used as an identifier)
  • ls – base64, example below
>>> myb64.b64decode("dm5jX3Bhc3N3ZAoK")

The response from the C2 can contain a couple of other commands:

  • “update => url” – update self
  • “install => url” – download and execute
  • “not found” – remove self

Update and install both download to and execute from “%APPDATA%\Java\Explorer.exe”.

Credit Card Track 1 and 2 Memory Scraping Thread

Running in a loop, this thread takes a snapshot of all running processes it has access to on the system. For each process it:

  • Skips if it is a system process, one of:
    • svchost.exe
    • System
    • smss.exe
    • csrss.exe
    • winlogon.exe
    • lsass.exe
    • spoolsv.exe
    • alg.exe
    • wuauclt.exe
  • Skips if the process is the malware itself
  • Reads all accessible read/write memory
  • Parses each byte looking for “^” or “=” – field separators used in credit card track 1 and track 2 data respectfully
  • If there’s a match, further checks are done (track 1 and 2 are checked similarly):
    • Working backwards from the separator looks for 13-20 digits that could make up the Primary Account Number (PAN). Ends at a non-digit start sentinel
    • Checks the possible PAN with the Luhn algorithm—used to validate credit card numbers
    • Checks that the expiration date is reasonable: year is between [20]13 and [20]19 and month starts with a 0 or 1
    • Checks whether rest of the characters after the separator are digits
  • If the checks pan out, the track data is RSA encrypted with an embedded PUBLICKEYBLOB, see IDA screenshot below
  • It is then base64 encoded
    • If RSA encryption fails for whatever reason, the track data is just base64 encoded
  • Encrypted data is stored for later exfiltration to the C2



Credit card track data is exfiltrated very similarly to VNC passwords:



The “ls” parameter decodes to newline-separated entries:

 >>> ls = myb64.b64decode("U2Nhbm5pbmcgc3RhcnRlZAo0MUR1ekN5NF9oOGJiOVpUSDV0blRpWXhUbG5INnB4V0g2OXhZcVBLckJ2SjN0RXlvT1ZaanJnei1EOVpsOURPVTlsYVBnejVpWndkZ3FxUkw3U3RzeEdwVUs1YWwzRHR3aTZvTW9hNjRXWF9LSm9Da0QxRENmTHRwQ1NTTUhvYkNKY3lJVWJJanBBR2hfUWlaMDNYOHRPZUpZTmJrbDRzclptU05qMjlPUmM9CmV2NzA2QXYyZTlKTUpKRmlWZzZOaGMwSE85dlFvNy15RFJ2ZlJ5TmpFVVA0SlVTQU8wYUh3eUFERTVDWWRQVWNYWWhmRThqX0Q0b1I2NnNxejZ1ZzlyVmR2N0c4ZTRPLWdQYW9aVjdVSmJaaS1pN2NWUDJlb3hxb0ZCZTdkZ2pJeWZUNTRNelRDamlqanF4VzV1a080ek1HaThvVUdkUGpEamVoN0RiMEtYQT0K")
 >>> ls.split("\n")
['Scanning started', '41DuzCy4_h8bb9ZTH5tnTiYxTlnH6pxWH69xYqPKrBvJ3tEyoOVZjrgz-D9Zl9DOU9laPgz5iZwdgqqRL7StsxGpUK5al3Dtwi6oMoa64WX_KJoCkD1DCfLtpCSSMHobCJcyIUbIjpAGh_QiZ03X8tOeJYNbkl4srZmSNj29ORc=', 'ev706Av2e9JMJJFiVg6Nhc0HO9vQo7-yDRvfRyNjEUP4JUSAO0aHwyADE5CYdPUcXYhfE8j_D4oR66sqz6ug9rVdv7G8e4O-gPaoZV7UJbZi-i7cVP2eoxqoFBe7dgjIyfT54MzTCjijjqxW5ukO4zMGi8oUGdPjDjeh7Db0KXA=', '']

After the first entry, the rest are base64 and RSA encrypted credit card track data:

 >>> myb64.b64decode("41DuzCy4_h8bb9ZTH5tnTiYxTlnH6pxWH69xYqPKrBvJ3tEyoOVZjrgz-D9Zl9DOU9laPgz5iZwdgqqRL7StsxGpUK5al3Dtwi6oMoa64WX_KJoCkD1DCfLtpCSSMHobCJcyIUbIjpAGh_QiZ03X8tOeJYNbkl4srZmSNj29ORc=")

Credit Card Track 2 Key Logging Thread

The last thread starts by extracting a DLL from an executable resource and writes it to “%APPDATA%\Java\DLLx64.dll”. The filename is hardcoded even though the DLL is 32-bit. The “InstallHooks” export is executed which installs a keyboard hook via the SetWindowsHookEx function. After hook installation, the thread loops looking for Windows messages with an ID of 2023 (sent by the hook function). On receiving the message, a buffer of 400 keystrokes is collected and is searched for track 2 data as above—not particularly sure why the malware is looking for credit card track data in typed input though.

Command and Control Login


Samples and Campaigns

The following are the samples and campaigns known to ASERT:

MD5: 87f6385a4cb0520e19782350c30826bc

C2: hXXp://

Compilation date: 2013-10-20 23:15:49

Notes: I believe this is an earlier development version that differs somewhat from the above analysis. Copies itself to “%APPDATA% \Java\javaj.exe”.


MD5: 3cee6591a0ec2e1e1bdd317ec8777c58

C2: hXXp://

Compilation date: 2013-10-22 00:40:30

Notes: Also an earlier development version using “javaj.exe”.


MD5: ec0e8edbab6575e167689cca533f75f0

C2: hXXp://

Compilation date: 2013-12-21 20:34:39

Notes: Also an earlier development version using “javaj.exe”. This IP has hosted a Citadel C2 at hXXp:// in the past.


MD5: fefeb6a27f34b35a6a43c65c188bcde7

C2: hXXp://

Compilation date: 2014-05-11 10:31:02

Notes: Per Google Translate, “eklemek” is the Turkish word for “adding”.


MD5: 68dbce1053450a4395368835367d20b5

C2: hXXp://

Compilation date: 2014-05-12 19:00:35


MD5: 2576bc49e3c796b5b94695241d0d4359

C2: hXXp://

Compilation date: 2014-05-12 19:03:08


MD5: 3d58e0b2b9303e0bc4bb282c1ee2dd18

C2: hXXp://

Compilation date: 2014-05-15 12:30:47


MD5: 40e556c77948037497b9205932e69b97

C2: hXXp://

Compilation date: 2014-05-15 12:32:05


MD5: 4196c67648003a18f61573a77b6d3be6

C2: hXXp://

Compilation date: 2014-05-20 19:32:42

Notes: Live C2 panel at time of writing. hXXp:// is also a live C2 at the time of writing, but I don’t have the associated sample.


MD5: ae9899722707fc2c9716138580787026

C2: hXXp://

Compilation date: 2014-08-12 15:43:20

Notes: This sample returns to copying to “%APPDATA% \Java\JavaJ.exe”, just using camel-case. The PDB pathname has also changed to “C:\Users\Tom\documents\visual studio 2012\Projects\jsd_12.2\Release\jsd_12.2.pdb” so the author may have rebranded it from “NewPosThings” to “jsd”. At the time of writing, the C2 panel is live and the domain has hosted an Andromeda C2 at hXXp:// in the past.

Yara Rule

We’ve been using the following Yara rule for tagging and hunting:

// newposthings, Dennis Schwarz, Arbor Networks ASERT, September 2014
rule newposthings
    $pdb1 = "C:\\Users\\Tom\\documents\\visual studio 2012\\Projects\\NewPosThings\\Release\\NewPosThings.pdb" nocase
    $pdb2 = "C:\\Final32\\Release\\Final.pdb" nocase
    $pdb3 = "C:\\Users\\Tom\\documents\\visual studio 2012\\Projects\\jsd_12.2\\Release\\jsd_12.2.pdb" nocase
    $str1 = "install =>"
    $str2 = "update =>"
    $str3 = "cs=bG9n&m="
    $str4 = "cs=aW5zZXJ0&p="
    (any of ($pdb*)) or (all of ($str*))


This post has been an analysis of a point of sale malware known as NewPosThings. Its modus operandi is similar to that of other PoS malware where it memory scrapes for credit card track data, does some basic verification with the Luhn algorithm, and then exfiltrates to a command and control server. While it appears to be in active development, the scope and distribution of this threat is currently unknown. ASERT continues to monitor NewPosThings and other PoS malware threats.

Five Sinkholes of newGOZ

By: Dennis Schwarz -

By Dennis Schwarz and Dave Loftus

It has been a few weeks since news broke of the Zeus Gameover variant known as newGOZ. As has been reported, the major change in this version is the removal of the P2P command and control (C2) component in favor of a new domain generation algorithm (DGA).

The DGA uses the current date and a randomly selected starting seed to create a domain name. If the domain doesn’t pan out, the seed is incremented and the process is repeated. We’re aware of two configurations of this DGA which differ in two ways: the number of maximum domains to try (1000 and 10,000) and a hardcoded value used (0x35190501 and 0x52e645).

Date based domain generation algorithms make for excellent sinkholing targets due to their predictability, and provides security researchers the ability to estimate the size of botnets that use them. With this in mind, we have gathered five days worth of newGOZ sinkhole data. Our domains are based on the first configuration, since this configuration seems to be used the most in the wild.

As with all sinkhole data, many variables can affect the accuracy of victims such as network topology (NAT and DHCP), timing, and other security researchers. However, we feel that the data provides a good estimation of the current scope of this new threat.

Monday, July 14


Four days after the discovery of newGOZ, our first sinkhole saw 127 victims. To corroborate our initial data set, SecureWorks reported seeing 177 victims connect to their sinkhole a few days earlier on July 11.

Friday, July 18


An 89% increase to 241 victims.

Monday, July 21


Over the weekend we saw a 78% increase to 429 victims, mostly in the eastern half of the United States.

Friday, July 25


As reported by Malcovery Security on July 22, they saw a large spam campaign distributing newGOZ by the Cutwail botnet. This campaign appears to have been very successful. On July 25, we saw an 1879% increase to 8494 victims—the rest of the United States is covered.

Monday, July 29


Over the weekend and 19 days after its discovery, our fifth and final sinkhole for this post saw a 27% decrease to 6173 victims. This is most likely due to victims cleaning themselves up from that last spam campaign. Latin America, South Africa, South East Asia, and New Zealand start filling in.


In aggregate and over three weeks, our five sinkholes saw 12,353 unique source IPs from all corners of the globe:


The most infected country was the United States followed by India. The top 10 were:


In addition, a number of organization types were affected, the top being:



Pondering on the five days worth of newGOZ sinkhole data above, some thoughts come to mind:

First, will the threat actor continue to use the same DGA configuration that they’ve been using so far? Empirically, there seems to be more security research sinkholes populating the DGA namespace than actual C2 servers. There is also the second DGA configuration that hasn’t received much use yet. Additionally, as we’ve seen, the actor is willing to completely replace the C2 mechanism altogether.

Second, will the botnet continue to grow and at what rate? The sinkhole data for July 25 suggests that the second Cutwail spam campaign was relatively successful. Will future waves continue this trend?

Finally, with the infection numbers at a fraction of what they were in the P2P version of Zeus Gameover, how long will the threat actor focus on rebuilding their botnet before they return to focusing on stealing money?

The Citadel and Gameover Campaigns of 5CB682C10440B2EBAF9F28C1FE438468

By: Dennis Schwarz -

As the infosec community waits for the researchers involved to present their Zeus Gameover take down spoils at the next big conference; ASERT wanted to profile a threat actor that uses both Citadel, “a particularly sophisticated and destructive botnet”, and Gameover, “one of the most sophisticated computer viruses in operation today”, to steal banking credentials.

Citadel Campaign

When a threat actor decides that they would like to start a Citadel campaign they: buy the builder software, build the malware, distribute it to the wild, and then, unfortunately, usually profit. A “login key” in Citadel parlance identifies a specific copy of the builder. This key is also copied into the generated binaries so a link between malware builder and malware is formed. Login keys are supposed to be unique, but due to builders being leaked to the public, some aren’t. For all intents and purposes though, malware researchers use login keys to distinguish between distinct Citadel campaigns.

On October 29, 2013, security researcher Xylitol tweeted that login key 5CB682C10440B2EBAF9F28C1FE438468 was not associated with any of the defendants in Microsoft’s Citadel botnet lawsuit:


ASERT has the following command and control (C2) URLs linked with that campaign. Most of these were hosted in the netblock—owned by EuroByte:

MD5 Command and Control URL


Using archived copies of the campaign’s configuration files from and ZeuS Tracker it can be seen that the threat actor was using 28 webinjects to target 14 financial institutions in the Netherlands and Germany:

set_url: **
set_url: **html*
set_url: **
set_url: **
set_url: **
set_url: **
set_url: **
set_url: **
set_url: **
set_url: **
set_url: *mijn**
set_url: *
set_url: *
set_url: **action_prepareStepTwo=Inloggen
set_url: *
set_url: *
set_url: **
set_url: *
set_url: *
set_url: **action_prepareStepTwo=Inloggen
set_url: *
set_url: https**
set_url: https*de*portal/portal*
set_url: https*paypal*


As an example and reference for later, here are a few snippets of one of the webinjects:


Per ZeuS Tracker and VirusTotal passive DNS data, it seems as if this particular campaign started fizzling out around the end of 2013.

Zeus Gameover Campaign

As noted by security researcher Brian Krebs, the “curators of Gameover also have reportedly loaned out sections of their botnet to vetted third-parties who have used them for a variety of purposes.” Analyzing webinject data from the global configuration file that was being distributed on the peer-to-peer network shortly before its takedown on June 2, 2014; it looks as if the threat actor behind Citadel login key 5CB682C10440B2EBAF9F28C1FE438468 had joined the ranks of Gameover’s coveted third party. Checking historical versions of the config show that this collaboration goes back to at least January 2014.

In the analyzed configuration, there was 1324 total web injects targeting many financial institutions. 12 of these were associated with the profiled actor and will be focused on here.  First, the banking credentials extracted by this group of injects were being exfiltrated to IP address This IP had previously hosted a C2 panel of the above Citadel campaign. Second, there were eight financial institutions targeted; seven of which were a subset of the previous campaign: 

match: ^https.*?de.*?portal/portal.*?
match: ^https://.*?
match: ^https://.*?
match: ^https://.*?*?
match: ^https://.*?*?
match: ^https://.*?*?
match: ^https://.*?*?
match: ^https://.*?*?
match: ^https://.*?
match: ^https://.*?
match: ^https://.*?
match: ^https://.*?*?


Finally, the coding style, function/variable naming, and formatting of the webinjects themselves were akin to the above and looked to have been retrofitted from Citadel to work with Gameover:


The drop site itself is a Ruby on Rails application that logs and displays the data sent from infected hosts:



Each entry can be formatted a bit better by clicking “Show”:


Some of the logging text seen in these screenshots—for example: “Wait tan from holder”—can be correlated back to the earlier snippets of the webinjects.

The initial entries in the list are dated from around March and June of 2012, but these entries may be old or in error as there is a jump to December 2013 and then consistent logging from there. At the time of this writing there were approximately 1089 entries.

In addition, up to five Jabber IDs can be configured in the application and then messaged on receipt of freshly stolen credentials:


At the time of writing, the configured Jabber IDs were:


But, there wasn’t much open source intelligence on these.


Pondering on the data available…this threat actor ran a fairly targeted Citadel campaign focusing on a small set of banks in the Netherlands and Germany. Based on ZeuS Tracker data, most of the Citadel C2s became active after the start of Microsoft’s lawsuit on June 5, 2013, so this likely explains the exclusion of 5CB682C10440B2EBAF9F28C1FE438468 from the legal notices.

The Citadel campaign looks like it closed up shop at the end of 2013. In December 2013, logging on the out-of-band Gameover drop site started in earnest, so this might be when the threat actor moved to stealing banking credentials via Gameover.

So far, it seems as if this threat actor has escaped the clutches of the great Citadel take-down and, since the drop site is still receiving stolen credentials, has evaded the Zeus Gameover take-down as well. In the spirit of “see something, say something” and with the recency of the legal action, ASERT has provided the data available to our law enforcement contacts.

Illuminating The Etumbot APT Backdoor

By: Arbor Networks -

The Arbor Security Engineering Response Team (ASERT) has released a research paper concerning the Etumbot malware.

Etumbot is a backdoor used in targeted attacks since at least March 2011. Indicators suggest that Etumbot is associated with the Numbered Panda group, also known as IXEHSE, DynCalc, and APT12.  Although previous research has covered related malware, little has been publicly discussed regarding Etumbot’s capabilities.

Indicators suggest that the Etumbot dropper is delivered via spear phishing and is contained inside an archive file intended to be of interest to the target. The attackers use the Unicode Right to Left Override technique and document icons to disguise malicious executable content as document files. Once the dropper is executed, the backdoor is activated and a distraction file of interest to the target is opened for viewing.  ASERT has observed several Etumbot samples using distraction documents involving Taiwanese and Japanese topics of interest, and has also observed recent development activity which indicates that attack campaigns are ongoing.

Once installed, the backdoor connects to it’s Command & Control server and receives an encryption key. RC4 encryption, along with HTTP transactions intended to blend in with typical traffic are used for backdoor communications. Etumbot’s core functionality allows for the execution of commands and the capability to upload and download files.

Attackers attempt to obfuscate the malware by using a technique known as “byte strings”, also known as “string stacking”. Through the use of ASERT tools, these byte strings are deobfuscated and revealed herein.

A timeline containing distraction documents along with backdoor and dropper indicators to include MD5 hashes, Command & Control server information, file system and process artifacts are included herein. Some use of the HTran connection bouncer has been observed, indicating that selected C&C’s were simply compromised sites used to relay traffic elsewhere.

It is our aim to assist incident response and security teams and to provide meaningful insight into this threat.

Download the full report: ASERT Threat Intelligence Brief 2014-07: Illuminating the Etumbot APT Backdoor

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 0x62042 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

Into the Light of Day: Uncovering Ongoing and Historical Point of Sale Malware and Attack Campaigns

By: cwilson -

Point of Sale systems that process debit and credit cards are still being attacked with an increasing variety of malware. Over the last several years PoS attack campaigns have evolved from opportunistic attacks involving crude theft of card data with no centralized Command & Control, through memory scraping PoS botnets with centralized C&C and most recently to highly targeted attacks that require a substantial amount of lateral movement and custom malware created to blend in with the target organization.

While contemporary PoS attackers are still successful in using older tools and methodologies that continue to bring results due to poor security, the more ambitious threat actors have moved rapidly, penetrating organizational defenses with targeted attack campaigns. Considering the substantial compromise lifespans within organizations that have active security teams and managed infrastructure, indicators shared herein will be useful to detect active as well as historical compromise.

Organizations of all sizes are encouraged to seriously consider a significant security review of any PoS deployment infrastructure to detect existing compromises as well as to strengthen defenses against an adversary that continues to proliferate and expand attack capabilities.

In addition to recent publications discussing Dexter and Project Hook malware activity, Arbor ASERT is currently tracking other PoS malware to include Alina, Chewbacca, Vskimmer, JackPoS and other less popular malware such as variants of POSCardStealer and others. Attack tactics shall also be explored through analysis of an attackers toolkit.

The longevity and extent of attack campaigns is a serious concern. In organizations with security teams and well managed network infrastructure, point of sale compromises have proliferated for months prior to detection. If attackers are able to launch long-running campaigns in such enterprise retail environments, one can conclude that many other organizations with less mature network and infrastructure management are also at serious risk. A sample of high-profile incident timelines, showing the date of the initial compromise, compromise timespan and compromise scope (number stores in this context) is included to highlight this point.

Download the full report: ASERT Threat Intelligence Brief 2014-06 Uncovering PoS Malware and Attack Campaigns

ASERT Threat Intelligence would like to thank fellow ASERT team members Dave Loftus, Alison Goodrich, Kirk Soluk and Matt Bing and also wishes to thank David Dunn of FIS Global and the Shadowserver Foundation for providing additional information.

Trojan.Eclipse — A Bad Moon Rising?

By: Dennis Schwarz -

ASERT’s malware collection and processing system has automatic heuristics that bubble up potentially new and interesting DDoS malware samples into a “for human analysis” queue. A recent member of this queue was Trojan.Eclipse and this post is my analysis of the malware and its associated campaigns.

Analysis was performed on the sample with an MD5 of 0cdd10cd3393d3fe916a55b946c10ad6.

The name Eclipse comes from two places: a mutex named “eclipseddos” and a hardcoded Cookie value used in the command and control (C2) phone home. We’ll see in the Campaign section below that this threat is also known as: shadowbot, gbot3, eclipsebot, Rhubot, and Trojan-Spy.Win32.Zbot.qgxi.

Based on the C2 domain names, GeoIP of the C2 IP addresses, and a social media profile of the owner of one of the C2 domains, I suspect this malware to be Russian in origin. In addition, Eclipse is written in Delphi and empirically Russian malware coders have a certain fondness for this language.

Command and Control

The analyzed binary has a hardcoded C2 domain string. This string is protected from modification by running it through a simple hashing algorithm and comparing it against a hardcoded hash at certain points of the code. The following Python function replicates this algorithm:

 def decrypt(string):
    table1 = "qwertyuiopasdfghjklzxcvbnm.1234567890"
    table2 = "asdfghjklqwertyuiopnbmcvxzeasdfghjklv" 
    out = ""
    for orig_char in string:
        index = table1.find(orig_char)
        if index == -1:
            char = orig_char
            char = table2[index]
        while char in table1[index:]:
            index = table1.find(char)
            char = table2[index]
        out += char

    print out

For example, the domain “” hashes to “zopterrweoxyezpz.”

An example phone home request looks like this:


It is a HTTP GET based C2 protocol where the query string breaks down into the following parameters:

  • bot – 15 random lowercase letters and digits
  • botkey – possibly a hardcoded campaign key
  • os – OS name
  • ram – amount of RAM
  • user – username
  • cpu – estimated CPU speed
  • number of CPUs

After the Host line, the remaining headers are static—note the aforementioned Cookie value. An example phone home response looks like this:


The returned content is a single <base> tag containing base64-encoded data. Once decoded, an XML-like configuration file emerges (newlines added for clarity):

<cmd>stop;</cmd><tcp>GET /index.php HTTP 1.1
Host: $RANDOM$.net
User-agent: $RANDOM$

Another example:

<cmd>type=slow-post; threads=10; timeout=1;; script=/contact-us.php;
port=80;</cmd><tcp>GET /index.php HTTP 1.1
Host: $RANDOM$.net
User-agent: $RANDOM$

Relatively speaking, for a DDoS bot, Eclipse has a fairly rich configuration mechanism. Starting with the <cnfg> tag, it has four possible options:

  • control-timeout – set C2 poll time
  • control-path – set C2 pathname
  • control-domain – set C2 domain
  • stream-timeout – minimum wait time between attack packets, in milliseconds

The <cmd> tag can contain multiple commands delimited by a “\r\n”, and each command has three possible formats: standalone command, command requiring parameters, and a shortcut command. An example of the first format is:


Identified commands in this category are:

  • stop – stop attacks
  • wait – sleep for one day
  • die – exit process

An example of the second format:

<cmd>type=slow-post; threads=10; timeout=1;; script=/contact-us.php; port=80;</cmd>

There are a bunch of types, here are the ones identified:

  • update – update self
  • execute – download and execute
  • tcpint – custom TCP flood
  • browser – HTTP GET flood, look like a web browser
  • dirtjumper – HTTP GET flood
  • sincere – TCP flood
  • http – HTTP GET/POST flood
  • httpspoof – HTTP GET flood with spoofed X-Forwarded-For header
  • slowloris – broken Slowloris attempt
  • tcp – TCP flood
  • udp – UDP flood
  • http-data – HTTP POST flood
  • slow-post – broken slow HTTP POST flood
  • connect – TCP connect flood
  • tcp-oneconnect – TCP flood
  • icmp – broken ICMP echo request flood
  • http-post – referenced in the code, but not implemented

Command parameters depend on the type and include:

  • threads – number of attack threads, defaults to 30
  • timeout – wait time between attack packets, in milliseconds
  • target – target host
  • script – URI path and file
  • port – target port, defaults to 80
  • connint – unknown, defaults to 1
  • dataint – unknown, defaults to 1
  • data – referenced, but unused
  • template – template attacks

Two interesting features here. First, the script parameter can contain variables: $RANDOM$ is replaced with 15 random lowercase letters and digits and $INTEGER$ is replaced with a random integer between 0 and 998.

Second, the template option configures various attacks based on hardcoded templates. They include:

  • nginx – slowloris attack, 30 threads, 10 ms timeout
  • ssh – tcp attack, 45 threads, 10 ms timeout, destination port 22
  • ftp – tcp attack, 45 threads, 10 ms timeout, destination port 21
  • https – tcp attack, 70 threads, 10 ms timeout, destination port 443
  • dns – udp attack, 10 threads, 10 ms timeout, destination port 53

Finally, the shortcut command format looks like this:


This launches an http attack with 100 threads and a timeout of 10 ms.

The <tcp> tag is used in conjunction with the tcpint command and defines a custom TCP flood payload template. The template supports $RANDOM$ variables which are replaced with 15 random lowercase letters and digits.


Campaign-wise, Eclipse can be broken down into roughly four groups: shadowbot, gbot3, eclipsebot, and eclipseddos. The malware implementation used in each campaign varies a bit from what was describe above, but I feel that they’re earlier development versions and warrant being categorized under the same family name.

shadowbot Campaign

The shadowbot campaign was active from July 21, 2013 to August 10, 2013 (using VirusTotal’s first submission timestamp). Its name comes from the use of the shadowbot mutex. Other notable differences include:

  • Use of a shortened query string, “index.php?bot=”, in the C2 phone home
  • Missing Referer and Cookie headers in the C2 phone home
  • Does not use the <base> tag or base64 encoding
  • The <cmd> tag is much simpler and is delimited by “#”s
  • Does not use <cnfg> or <tcp> tags
  • Uses !random instead of $RANDOM$ variables
  • Smaller command set: connect, slow-post, http-data, cs, udp, tcp, and http

Some sample MD5s and C2 URLs:



The last entry in this table is the sample that Microsoft documented at They have named the malware “Win32/Rhubot.A”, but to be honest I couldn’t figure out why or find any good source material on “Rhubot”.

gbot3 Campaign

Next is the gbot3 campaign, which was active from August 9, 2013 to January 1, 2014 VirusTotal time. Its name also comes from the mutex that it sets. The distinguishing features of this version are:

  • As with shadowbot, uses shortened C2 phone home query string, “index.php?bot=”
  • Does not use base64 encoding, but does contain <cmd>, <cnfg>, and <tcp> tags
  • <cmd> is space delimited and still fairly basic
  • Implements “#” shortcut command
  • Implements tcpint command with <tcp> template. The template supports !randomchar, !random-ug, !random-lang, !random-encoding, !random-ac, !random-accept variables instead of $RANDOM$
  • Supports !random instead of $RANDOM$ in URI
  • Command set includes the more novel tcpint, browser, dirtjumper, slow-post, and tcp-oneconnect commands

Some sample MD5s and C2 URLs:



The last entry in this table is the sample referenced in SourceFire VRT’s “MALWARE-CNC Win.Trojan.Rhubot variant outbound connection” rule.

eclipsebot campaign

Third is the eclipsebot campaign, which was active from September 12, 2013 to November 4, 2013. Naming is based on the mutex. Sans some minor changes, this version is very similar to the eclipseddos analyzed in the beginning of the post. Notable features are:

  • Introduction of C2 domain hash check
  • Still uses shortened C2 query string, “index.php?bot=”
  • Introduction of rich <cmd> configuration via type, threads, timeout, target, script, etc. options
  • Has support for attack templates
  • Uses $RANDOM$ and $INTEGER$ variables

Some sample MD5s and C2 URLs:



eclipseddos campaign

The eclipseddos campaign has been active since November 28, 2013 VirusTotal time.

Some sample MD5s and C2 URLs:

0b450a92f29181065bc6601333f01b07 http://


The last two samples in the above table are referenced in the Emerging Threats rule called “ETPRO TROJAN Trojan-Spy.Win32.Zbot.qgxi Checkin”. As with Microsoft’s AV detection, I couldn’t find any source material on why they decided to name it this way.

The Trojan.BlackRev Connection

Back in May 2013, I released a blog post titled “The Revolution Will Be Written in Delphi” that profiled a DDoS bot named Trojan.BlackRev. Since that post, there have been a few updates that provide for a preamble to a possible relationship between Eclipse and BlackRev. On June 5, 2013 the author of BlackRev, going by the handle “silence”, posted to an underground forum saying that he had sold the project:


A few months later on October 4, 2013 on another underground forum, somebody going by the handle “chef” leaked the BlackRev source code:


While tracing one of the Eclipse C2 URLs from the shadowbox campaign:

I came across a C2 URL with a similar URI pathname:

The complete C2 protocol looks like this:


This traffic came from a binary with an MD5 of 8da35de6083aa9aa3859ce65e0e816df and I believe this sample to be a “missing link” between the BlackRev and Eclipse code bases.

In addition to the timeline proximity and the feeling of “code sameness” while reversing engineering, some of the major pieces linking this variant to BlackRev are:

  • The query string used in the phone home
  • Comparison against the “|stop|” string
  • Bot command is pipe “|” delimited
  • Launches the same “bot killer” code in a thread
  • Launches the same “memory reduction” code in a thread
  • Uses a similar random character generator
  • HTTP header overlap in some of the attacks
  • Names a command “antiddos”, which is fairly novel

The major pieces linking it to Eclipse (shadowbot specifically) are:

  • Shared C2 infrastructure
  • HTTP header overlap in the C2 phone home
  • Use of XML-like tags in the phone home response
  • Names a command “nginx”, which is a fairly novel
  • Eclipse variants also contain the same bot killer, memory reduction, and similar random character generation code
  • Name overlap in some of the attacks
  • HTTP header overlap in some of the attacks

With silence’s claim of selling the project and the leak of the source code to the public, it is unclear how or if the threat actors behind the Eclipse and BlackRev campaigns are related. I do feel strongly though that Eclipse is a descendant of the BlackRev code base.


This post has been an analysis of the Trojan.Eclipse family of DDoS bots. This malware is interesting because it has a fairly rich configuration mechanism, some novel attack types, and a nice development trail leading back to the either the Trojan.BlackRev code leak or sale of the project by the author.

ASERT is just ramping up attack monitoring of this family. So far we’ve seen a handful of attacks on a consumer complaint website, a venture capital company, a forum for a Russian town, and a rating site for Russian apartment repairs. Monitoring of the attacks and family continue.

Dexter and Project Hook Point-of-Sale Malware Activity Update

By: cwilson -

An increase in credit and debit card theft via Point of Sale (PoS) malware campaigns over the late 2013 holiday season has resulted in significant media attention and has likely emboldened threat actors as the success of past campaigns comes to light. Media attention has decreased since news of the Target breach and associated fallout, however threat actors targeting PoS systems are still engaged in active attacks.

Point of Sale Malware Overview

Certain malware, such as Dexter, Project Hook, Alina, ChewBacca, JackPoS and VSkimmer have been written specifically to compromise Point of Sale machines. Other malware not designed specifically for PoS attack, such as ever-popular Citadel, has the capability to exfiltrate data from the target organization. In short, any system that contains credit/debit card data in any clear-text form in memory or on disk or sends clear-text card data over the network is potentially at risk regardless of whether that machine is a PoS terminal or not.

In addition to Alina, Chewbacca, JackPoS and other Point of Sale malware, ASERT continues to track the Dexter and Project Hook PoS campaigns we originally reported on in December of 2013.  Indicators  suggest that Dexter Revelation may have been in existence as early as April 2013. A new ASERT threat intelligence brief sited at the end of this post provides a significant amount of updated material about Dexter and Project Hook including:

  • Additional actor insight
  • Reverse Engineering information
  • Potentially vulnerable Point of Sale solutions
  • An extensive list of file and network indicators
  • An analysis of possible attack vectors
  • An updated infection map
  • Mitigation suggestions

This information should prove valuable for incident responders and those responsible for protecting cardholder data environments. Additionally, since many of the network and file indicators have not been previously released, these indicators may be useful for identifying environments that are already compromised. The brief also provides scripts for decoding dump files that may help incident responders determine the scope of a compromise.

The following map shows Dexter and Project Hook infections as of January 24, 2014:

Project Hook_Dexter

Continued PoS campaign activity suggests that organizations still need to be vigilant. This new ASERT intelligence brief will help. The full document is available here.

*Author credits: Curt Wilson, Dave Loftus, and Dennis Schwarz

Go Back In Time →