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.


DDoS Attacks in the Wake of French Anti-terror Demonstrations

By: Kirk Soluk -

On January 15th, France’s chief information systems defense official, Adm. Arnaud Coustilliere, announced a sharp rise in online attacks against French web sites:

“Calling it an unprecedented surge, Adm. Arnaud Coustilliere, head of cyberdefense for the French military, said about 19,000 French websites had faced cyberattacks in recent days, …” [1].

As we’ve done in the recent past for North Korea [2], Hong-Kong [3], and Israel [4], we can leverage Arbor’s ATLAS initiative to observe how real world conflict is reflected in the digital realm. ATLAS receives anonymized Internet traffic and DDoS event data from over 330 participating Internet Service Providers worldwide. In particular, we are interested in DDoS attacks before and after Sunday, January 11th. As reported in [1],

“Coustilliere called the attacks a response to the massive demonstrations against terrorism that drew 3.7 million people into the streets Sunday across France.”

In order to gauge this response, we compare the DDoS attacks that took place between January 3rd and January 10th to the DDoS attacks that took place between January 11th and January 18th inclusive.

Attack Frequency

Between January 3rd and January 18th, a total of 11,342 unique attacks were reported as targeting France – an average of 708 attacks per day. The following series of graphs depict the frequency and size of these DDoS attacks for the 8 days before and after January 11th, 00:00:00 GMT.

Figure 1 illustrates the total number of reported DDoS attacks targeting France for the eight-day period before January 11th, and for eight days after January 11th:


Figure 1: Total Number of Attacks

We observe a 26% increase in the number of DDoS attacks in the period after January 11th.

Attack Size

Figure 2 compares the average size of DDoS attacks in terms of bandwidth (Gbps) before January 11th, and afterwards:

Figure 2: Average Attack Size (Gbps)

Figure 2: Average Attack Size (Gbps)

Here we observe a 35% increase in average DDoS attack size after January 11th. Specifically, in the eight days prior to January 11th, the average attack size was 1.21 Gbps. After January 11th, the average attack size was 1.64 Gbps.

Attack Size Distribution

Figures 1 and 2 above illustrate that not only were there more attacks after January 11th, the attacks were larger, as well. The following table details this observation:

France-Table1-AttackSizeDistribution247 (5%) of the DDoS attacks in the period prior to January 11th were greater than 5 Gbps while 678 (11%) of the attacks after January 11th exceeded 5 Gbps in size. Thus, while Figure 2 describes a 35% increase in average attack size post January 11, the percentage of attacks larger than 5 Gbps more than doubled.

Peak Attack Sizes

Figure 3 depicts the size of the largest attack before and after January 11th 00:00:00 GMT:


Figure 3: Peak Attacks

January 9th saw a 40.96 Gbps attack, while a 63.02 Gbps attack was reported on January 11th. The January 11th attack was 54% larger than the attack observed on January 9th.


On January 11th, the largest demonstration in French history took place as millions marched in anti-terrorism rallies across the country [5]. On January 15th, Adm. Arnaud Coustilliere, announced an unprecedented surge in online attacks against French websites, calling these attacks “a response to the massive demonstrations” [1]. Arbor’s ATLAS data presented above appears to support Adm. Coustilliere’s claims.

Comparisons of DDoS attack data over the eight-day periods before and after January 11th show:

  • a 26% increase in the number of attacks,
  • a 35% increase in the average attack size,
  • a 100% increase in the number of attacks larger than 5 Gbps and
  • a 54% increase between the peak attack events in the two time periods.

This is yet another striking example of significant online attacks paralleling real-world geopolitical events.








DDoS Activity in the Context of Hong Kong’s Pro-democracy Movement

By: Kirk Soluk -

In early August, we examined data demonstrating a striking correlation between real-world and online conflict [1], which ASERT tracks on a continual basis [2-7]. Recent political unrest provides another situation in which strong correlative indicators emerge when conducting time-series analysis of DDoS attack data.

The latest round of pro-democracy protests in Hong Kong began on September 22nd when “. . . Students from 25 schools and universities go ahead with a week-long boycott to protest Beijing’s decision to proceed with indirect elections for Hong Kong’s Chief Executive position.” [8]. The protests ramped up on September 28th when a larger pro-democracy group, Occupy Central with Love and Peace, combined forces with the student demonstrators [8-9]. On October 1st, protesters vowed to increased the level of civil disobedience if Hong Kong’s Chief Executive, Leung Chun-Ying, did not step down [10].  Since that time, tensions have increased, with police crackdowns, tear gas, barricades, skirmishes, shutdowns of government buildings and infrastructure, and heavy use of social media to promote both pro-and anti-protest sentiment.  By examining Arbor ATLAS Internet-wide attack visibility data we have identified DDoS attack activity in the APAC region which correlates strongly with the ebb and flow of protest activity in Hong Kong.

Arbor’s ATLAS Initiative

The DDoS information provided in the remainder of this report is derived from Arbor’s ATLAS Initiative. Arbor ATLAS receives anonymized Internet traffic and DDoS event data from over 290 ISPs worldwide which have deployed Arbor’s DDoS Mitigation solutions.  While many observed events are symptomatic of attacks during this period, it is important to note that we cannot definitively identify the motivations behind any given event.

Hong Kong as a Target of DDoS Attacks (September-October)

Number of Observed DDoS Attacks

The following graph illustrates that the number of observed DDoS attacks targeting Hong Kong-related online properties more than doubled between September and October, from 1,688 discrete attacks in September to 3,565 attacks in October:

Figure 1: Total Number of Attacks Targeting Hong Kong (September and October, 2014)

Figure 1: Total Number of Attacks Targeting Hong Kong (September and October, 2014)

Although the sheer number of DDoS attacks increased significantly from September to October, there was not a significant difference with respect to other attack attributes such as size or duration.  For example, the following charts break out the percentage of DDoS attacks within a given size range for both September and October, along with the raw number of DDoS attacks in that size range:

Figure 2: Percentage of Attacks within a given Size Range

Figure 2: Percentage of Attacks within a given Size Range

Overall, the percentage of DDoS attacks within a given size range remain fairly consistent from September to October, with the biggest difference being a relative 4% decrease in the number of DDoS  attacks within the 2gb/sec-to-5gb/sec range.

In summary, the analysis of the number and size of Hong Kong-related DDoS attacks depicted by Figures 1 and 2 above can be summed up by stating that “October saw more of the same – a lot more!

Size of Attacks and Related News Events

Figure 3 illustrates the largest DDoS attacks per day, in terms of bandwidth, targeting Hong Kong-related online properties during the month of October:

Figure 3: Peak Attack Sizes per Day (Gbps)

Figure 3: Peak Attack Sizes per Day (Gbps)

Three large DDoS attacks on October 14th (45.4gb/sec), 17th (38.3gb/sec), and 19th (45.6gb/sec) stand out. The total number of observed DDoS attacks targeting Hong Kong-related online properties (289, 419, and 427 respectively) also peaked on these days.  Since the vast majority of DDoS events reported via ATLAS are anonymized, it cannot be definitively determined how these specific DDoS attacks were related to the ongoing protests.  However, it appears that these attacks coincide with reports on Twitter and  by the Wall Street Journal of anti-protest crowds attempting to physically prevent pro-democracy newspaper publisher Apple Daily from distributing its newspapers. Specifically, the Journal noted that Apple Daily “simultaneously faced a cyberattack that brought down its email system for hours” [11]. On October 14th, Computerworld Hong Kong quoted an employee from Next Media (Apple Daily’s parent company), as follows: “The network was a total failure, affecting not just Apple Daily, but all the publications under Next Media” [12].

What’s Next?

Based on in-region DDoS attack statistics for the first week of November, continued DDoS attacks on Hong Kong-related Internet properties appear to be taking place. The following graph illustrates peak DDoS attack sizes in the 30gb/sec-plus range on four consecutive days (November 3rd – 6th):

Figure 4: Peak Attack Sizes per Day (Gbps) in the first week of November

Figure 4: Peak Attack Sizes per Day (Gbps) in the first week of November


While establishing definitive causal relationships and attribution are challenging  it is apparent that DDoS attacks have become the ‘new normal’ during periods of political unrest worldwide. In this case, we observed a 111% increase in the number of DDoS attacks targeting Hong Kong-related Internet properties when analyzing the months immediately before and after protester demands, on October 1st, for Hong Kong’s Chief Executive to step down. Additionally, large-scale DDoS attacks were observed targeting Hong Kong-related Internet properties that coincide with reports of debilitating disruptions of online media outlets sympathetic to the protest movement.





[4] ASERT Threat Intelligence Brief 2013-5: Observed Syrian Cyber Adversary Capabilities and Indicators. Available to Arbor customers upon request.

[5] ASERT Threat Intelligence Brief 2013-7: The Impact of Protest Activity on Internet Service in Thailand. Available to Arbor customers upon request.

[6] ASERT Threat Intelligence Brief 2013-4: Potential Targeted Attacks Against Various International Interests. TLP Amber. Available to Arbor customers upon request.

[7] ASERT Threat Intelligence Brief 2014-04: Counter Terrorism Expo and Bulgarian State Agency for National Security Cyber-Threat Alert. TLP Amber. Available to Arbor customers upon request.






NTP attacks continue – a quick look at traffic over the past few months

By: Chris G. Sellers -

In February, Kirk Soluk’s post on NTP Attacks: Welcome to The Hockey Stick Era reported that we have seen a increase in NTP-based application attacks.   We thought we would take a few minutes to post an update on the state of traffic metrics.

The graphs below are depicting aggregate traffic based on the NTP network port (123).  The first graph shows observed NTP traffic via UDP since December of 2013 until early March.


You can see that the observed traffic increase started at the end of 2013 and increased to nearly 800Gb/s in early March across the participants of Arbor Network’s ATLAS  system.   Let us dive in a little closer.


Looking at the late January until early March timeframe, we can see the increase continues with February’s NTP/UDP bandwidth traffic being fairly sustained, approaching and exceeding 400Gb/s most days.   It appears that as we get into March the bandwidth of NTP traffic is waining slightly, but remains at 300Gb/s on most days, far above the 50Gb/s even in late January.   March 04 was a significantly troublesome day as traffic peeked at nearly 800Gb/s on that day shortly before midnight UTC.


To see where traffic typically is, let’s take a look at one more graph, showing the level of traffic in late 2013 before the campaigns began.


Here you can get a view of what the NTP/UDP traffic was, hovering around one to two (1-2) Gb/s of time sync traffic in early December.

To learn more about defending your network against NTP-based attacks, we recommend attending the upcoming Arbor Webinar on Friday, March 14th at 3pm UTC /11am EDT, entitled ‘Too Much Time on My Hands:  Network-Scale Mitigation of NTP DDoS Attacks,’ presented by Arbor’s Roland Dobbins, Senior ASERT Analyst, and Ben Fischer, Product Marketing Manager.


Introducing the Digital Attack Map

By: Dan Holden -

What our ATLAS data highlights is just how commonplace DDoS attacks have become – both in terms of frequency but also in terms of how many Internet users are impacted by DDoS. It’s not just a problem for large, global organizations and service providers, but anyone with an Internet connection can be caught in the crossfire of an attack. The ‘collateral damage’ of an attack against a large organization or service provider are the people that rely on those networks every single day.

That’s why Google Ideas and Arbor have collaborated on a Digital Attack Map – a project we’re very excited to announce today.

Digital Attack Map 2013-10-21 09-27-31[1]

The Digital Attack Map utilizes anonymous traffic data from our ATLAS® threat monitoring system to create a data visualization that allows users to explore historical trends in DDoS attacks, and to make the connection to related news events on any given day. The data is updated daily, and historical data can be viewed for all geographies.  This collaboration brings life to the ATLAS data we leverage every day to uncover new attack trends and techniques, sharing it in a visual way that connects the dots between current events and cyberattacks taking place all over the world.

We invite you to explore the Digital Attack Map to see for yourself how DDoS has become a global threat to the availability of networks, applications and services that billions of people rely on every day.

Syria taken offline

By: Darren Anstee -

ATLAS is Arbor Networks innovative, one-of-a-kind Internet monitoring system. ATLAS is a collaborative effort with 250+ ISPs globally who have agreed to share anonymous traffic data on an hourly basis (leveraging Arbor’s technology that sits on ISP networks), together with data from Arbor dark address monitoring probes, as well as third-party and other data feeds. In total, ATLAS is seeing 42Tbps of peak IPv4 traffic. With this unique vantage point, Arbor is ideally positioned to deliver intelligence about malware, exploits, phishing and botnets that threaten Internet infrastructure and services. The information is aggregated, analyzed and fed back to our customers via our product deployments.

You can clearly see the traffic we are tracking for Syria drop to virtually 0 at 2000 UTC on the graph.  This will be approximately 1 hour after the drop happened in the ‘real’ world given that ATLAS participants only report hourly.


We’ve seen entire countries in the Mideast taken offline before. Here is a look back to January-February 2011 and Egypt,

Egypt Returns







Digging Through an “Administrative Network Stressor” Provider’s Database

By: Dennis Schwarz -

On March 15, 2013, Brian Krebs of Krebs on Security wrote “The World Has No Room For Cowards.” In it, he writes a fascinating story about a DDoS attack against his site and also a physical attack against his person. The part where Krebs’ notes that “… there are strong indications that a site named may have been involved in the denial-of-service attack on my site yesterday. For some bone-headed reason, the entire customer database file for appears to be available for download if you happen to the [sic] know the link to the archive” stood out to me. advertises itself as “The Ultimate Administrative Network Stresser [sic] Tool.”

blog image 1

As a security researcher, getting access to a database dump associated with an incident is always interesting. An earlier version of the Krebs’ article linked to the database file, so the following are some quick bits and pieces I pulled out of it. Here is a geo IP location map of the ‘lastip’ field of the ‘users’ database table. The assumption here is that these are the last login IPs for the 312 users of the service. It is important to note that proxies, VPN services, the Tor network, and other IP anonymizing services come into play here and the IPs might not trace back to a user’s actual physical location.


blog image 2

The ‘attacks’ database table contains attacks from January 23, 2013 to March 15, 2013. There were 48,844 entries. Resolving hostnames and parsing out some junk IPs, close to 11,000 unique IPs were targeted. Here is a geo IP location map of the IPs.

blog image 3


The targeted IPs roughly map into the following organization types.

blog image 4

Assuming the ‘duration’ field is in seconds, the average attack duration was 34 minutes. Here is a breakdown of the different attack types:

blog image 5

This posting was a quick visualization of some of’s database data as referenced by Krebs. I am glad that he and his family were unharmed during the associated “SWAT”ing attack and I look forward to reading his updates on this fascinating story.

Lessons learned from the U.S. financial services DDoS attacks

By: Arbor Networks -

By Dan Holden and Curt Wilson of Arbor’s Security Engineering & Response Team (ASERT)

During the months of September and October we witnessed targeted and very serious DDoS attacks against U.S. based financial institutions. They were very much premeditated, focused, advertised before the fact, and executed to the letter.

In the case of the September 2012 DDoS attack series, many compromised PHP Web applications were used as bots in the attacks. Additionally, many WordPress sites, often using the out-of-date TimThumb plugin, were being compromised around the same time. Joomla and other PHP-based applications were also compromised. Unmaintained sites running out-of-date extensions are easy targets and the attackers took full advantage of this to upload various PHP webshells which were then used to further deploy attack tools. Attackers connect to the compromised webservers hosting the tools directly or through intermediate servers/proxies/scripts and issue attack commands. In the September 2012 attacks there were several PHP based tools used, the most prominent of which was “Brobot” along with two other tools, KamiKaze and AMOS which were used a bit less often.  Brobot has also been referred to as “itsoknoproblembro”.

The attack tactics observered were a mix of application layer attacks on HTTP, HTTPS and DNS with volumetric attack traffic on a variety of TCP, UDP, ICMP and other IP protocols. The other obvious and uncommon factor at play was the launch of simultaneous attacks, at high bandwidth, to multiple companies in the same vertical.

On December 10, 2012 the group claiming responsibility for the prior attacks, the Izz ad-Din al-Qassam Cyber Fighters announced “Phase 2 Operation Ababil”.  A new wave of attacks were announced on their Pastebin page:  which described their targets as follows:

“Continually, the goals under attacks of this week are including: U.S. Bancorp, JPMorgan Chase&co, Bank of America, PNC Financial Services Group, SunTrust Banks, Inc.”

On December 11, 2012, attacks on several of these victims were observed. Some attacks looked similar in construction to Brobot v1, however there is a newly crafted DNS packet attack and a few other attack changes in Brobot v2.

These attacks have shown why DDoS continues to be such a popular and effective attack vector. Yes, DDoS can take the form of very large attacks. In fact, some of this week’s attacks have been as large as 60Gbps. What makes these attacks so significant is not their size, but the fact that the attacks are quite focused, part of an ongoing campaign, and like most DDoS attacks quite public. These attacks utilize multiple targets, from network infrastructure to Web applications.

Lessons Learned

While there has been much speculation about who is behind these attacks, our focus is less on the who or why, but how we can successfully defend. There are multiple lessons to be learned from these attacks, by everyone involved – the targeted enterprises, their managed security providers, Website and Web application administrators, and the vendor community.

For enterprises, it is clear that typical perimeter defenses such as firewalls and IPS are not effective when dealing with DDoS attacks, as each technology inline to the target is actually a potential bottleneck. These devices can be an important part of a layered defense strategy but they were built for problems far different than today’s complex DDoS threat. Given the complexity of today’s threat landscape, and the nature of application layer attacks, it is increasingly clear that enterprises need better visibility and control over their networks which require a purpose built, on-premise DDoS mitigation solution. This could sound self-serving, however, visibility into a DDoS attack needs to be far better than the first report of your Website or critical business asset going down. Without real-time knowledge of the attack, defense and recovery becomes increasingly difficult.

For providers of managed security services, they have begun to evaluate their deployments and mitigation capacity. These attacks were unique in that they targeted multiple organizations within the same vertical, putting a strain on the capacity of provider’s cloud-based mitigation services.

What these attacks have continued to demonstrate is that DDoS will continue to be a popular and increasingly complex attack vector. DDoS is no longer simply a network issue, but is increasingly a feature or additional aspect of other threats. The motivation of modern attackers can be singular, but the threat landscape continues to become more complex and mixes various threats to increase the likelihood of success. There have certainly been cases where the MSSP was successful at mitigating against an attack but the target Website still went down due to  corruption of the underlying application and data. In order to defend networks today, enterprises need to deploy DDoS security in multiple layers, from the perimeter of their network to the provider cloud, and ensure that on-premise equipment can work in harmony with provider networks for effective and robust attack mitigation.


Snapshot: Syria’s Internet drops, returns

By: Darren Anstee -

The Arbor ATLAS system leverages Arbor Networks’ world-wide service provider customer base to gather data about Internet traffic patterns and threats.  Currently 246 of Arbor’s customers are actively participating in the Arbor ATLAS system, and are sharing data on an hourly basis. The data shared includes information on the traffic crossing the boundaries of participating networks, and the kinds of DDoS attacks they are seeing. The graph below shows the cumulative ‘total’ traffic ( to / from) Syria across all of these participating networks. This does not the total traffic into and out of Syria, this is simply a snapshot taken from the vantage point of 246 network operators around the world.

As you can see traffic dropped sharply at around 1730 in the graph below.  The low level could either indicate a reduction in traffic to / from Syria or an outage for less than an hour (as the data is at one hour granularity). The actual traffic interruption is likely to have occurred at around 1630, the graphs show traffic interruption an hour later than this due to the variable, hourly reporting from ATLAS participants to our servers.

How likely is a DDoS Armageddon attack?

By: Carlos Morales -

The recent DDoS attacks against many of the North American financial firms had some unique characteristics that put a strain on the defenses in place and resulted in a number of well publicized service outages. The escalating threat is not new.  It’s been steadily building up over the last few years as botnet command and control has matured, the tools available to exploit those botnets have gone mainstream, and the cost of using the tools has plummeted.  What the attacks did do is raise the industry’s collective consciousness around how bad the situation has gotten.    The effectiveness of the attacks has changed the way that Internet operators, whether service provider, hosting provider, government or enterprise think about their defenses.   It has also raised a number of troubling questions.

The most common question that I have been asked is around the growing size of attacks and the capacity of Internet operators to withstand such threats.   How big does an attack have to be to overwhelm the biggest, most prepared financial company?   How big does an attack have to be to overwhelm the biggest and most prepared service provider?   Is there an Armageddon attack on the horizon that threatens to take down the entire Internet?  There are indications that this could be the case.

It should be noted that size is by no means the only means by which an attack can be effective.  It’s a very visible way of taking down a network similar to the way a 7 mile backup on a local highway is a visible sign that you’re not getting to your destination quickly.   Application layer attacks, IP protocol attacks, connection attacks and other stealthy attack methods can be just as effective in taking down a victim while being much more difficult to detect and mitigate.  The financial sector attacks were multi-vector and had aspects of both volumetric and application layer attack traffic.

This article is going to focus on larger sized attacks and the possibility of an Armageddon attack.   First, there are a few different measures of size including bandwidth (bps), packets (pps) and connections (cps).    In all three cases Internet operators such as enterprises will have a limit which they can handle.   Bps is the most commonly considered measure of size and it is easy to estimate network bandwidth limits.  If the internet operator has 10Gbps worth of upstream bandwidth, then attacks bigger than this will overwhelm the links.   Packet per second (pps) limits are more of a challenge to estimate limits because each device that is in-line with traffic will have limits in handling pps that will be dependent on the configurations that they are running and the type of traffic seen.   High pps attacks often cause more challenges than high bps attacks because multiple bottlenecks may exist on the network.     High cps attacks are typically targeted at stateful devices on the network that have a connection table.   These tend to be the harder to measure because network traffic analyzers tend to focus on just bps or pps.

With all three attack types, all enterprise, government and hosting provider networks will have bottlenecks that can be over-run relatively easily by big DDoS attacks.  Most enterprise and government datacenters have no more than 10 Gbps with some ranging slightly higher than this.   Arbor Network frequently sees attacks much larger than this.  As an example, Arbor’s ATLAS system receives anonymous attack statistics from hundreds of Arbor Peakflow SP deployments.   The largest bandwidth attacks measured in 2011 and 2012 were 101.4 Gbps and 100.8 Gbps respectively.   The largest packet per second attacks measured in 2011 and 2012 were 139.7 Mpps and 82.4 Mpps respectively.   Another source of data is the annual security survey of Internet operators that Arbor runs.   One of the survey questions is about the largest bps attacks seen over the previous year.    The chart below reflects that biggest attacks reported each year since the survey was first conducted in 2002.

Based on the data from the chart above, there have been DDoS attacks capable of overwhelming a 10 Gbps datacenter since 2005.   All this means that enterprises, governments and hosting providers need help from their upstream service providers to deal with threats of this magnitude.   Many of these providers offer managed security services that will provide protection against bigger attacks.   At a certain point, the attacks are big enough that the providers consider them their responsibility anyways because of the potential impact to multiple customers.  However, it’s heavily recommended to have an agreement in place to ensure SLAS and guaranteed response times.

That brings me back to the question on whether an Armageddon attack is possible that can not only overwhelm the end victim but also all the Internet providers in between.   Based on the current Internet environment, this is all too possible.   The first thing that you need to consider what the available bandwidth is to generate an attack.   There have been botnets discovered that have contained more than 1M infected hosts.   Assuming an average of 1 Mbps worth of upstream access per host, a conservative estimate based on the number of broadband subscribers, 4G and 3G users deployed in the world, a 1M host botnet could generate an attack of 1 Tbps.   Now what if this botnet and multiple other large botnets attack at the same time?   Service providers have a lot of bandwidth throughout their network but there are limits to how much traffic they can handle.   Attacks of that magnitude described would have profound effect on the Internet as a whole exploiting bottlenecks in many places simultaneously.  No single service provider, even the largest tier ones, would be able to handle all this traffic without adversely affecting their user base.

Is this possible?  It certainly seems so.  Is it likely?   It doesn’t seem so since it would affect everyone on the Internet and not just a single victim.   That said, many attacks that didn’t seem likely before are now becoming commonplace as motivations have shifted.   It is something that CSOs from within the carrier community are likely considering and hopefully taking steps to plan for the worst.


Go Back In Time →