In the span of just 10 days, two large-scale, wormable attacks grabbed international headlines. First, a phishing campaign posing as a Google Docs sharing request gained access to Google accounts then spread across its victim’s contacts, and now, a ransomware campaign with a bite, named WannaCry, autonomously infected vulnerable systems leveraging an exploit leaked on the internet.

In the early minutes of the attack, we worked with our Talos counterparts to analyze the behavior of WannaCry and protect our customers. We were also particularly proud to see that our Investigate product helped MalwareTech reduce WannaCry’s impact. In this post, we hope to give you a retrospective analysis of what we’ve observed during the first critical hours of the event.


WannaCry couldn’t have been so impactful without the dramatic sequence of events in the months leading up to the attack. We brroke down those events and how we protected our customers  in the below infographic:

The Spread

Upwards of 250,000 infections have been reported in various news articles and social media posts. Our unique view of the Internet allows us to visualize how these infections spread over time. We can do this by looking at the queries made to ‘kill switch’ domains. We first discussed these domains on the Talos blog and will look at them more in upcoming sections. The below graphic shows the countries with machines making queries to these domains (considered infected) using our resolvers over time and the percentage of queries each country was responsible for in each period:


We’ve also looked at the number of hosts that had TCP 445 open to the internet at the time of this writing. This port is important because the SMB service that listens on it is what the initial exploit targets (MS17-010,CVE-2017-0143). As you might expect, a very large percentage of these domains had TCP445 open and were likely vulnerable.

The above graphics focus on the first two kill switch domains. A third also began to appear during the time of this writing:

  • iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com
  • ifferfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com
  • ayylmaotjhsstasdfasdfasdfasdfasdfasdfasdf[.]com

Queries to these domains implies that a system was compromised by the malware, but was not further infected, since we’re redirecting those requests to our block page. The query volume of these domains illustrates a very dramatic story:

The query volume to these known kill switch domains continues to spike, however, lost in those spikes are the actual number of machines querying the kill switch. A single machine may query these domains multiple times. To help shed deeper light into this, let’s look at the number of machines (per hour) querying the kill switch domains over the last 168 hours.

Unique Machines

Notice, the three kill-switch domains appear to start and exhibit a sort of power law in their magnitudes. That is, the iuq… domain is largest, the iff… domain smaller, and ayy… smallest of all. This is not a coincidence for multiple reasons. For starters, we known iuq… was the first kill-switch domain used in WannaCry, iff… second, and ayy… the latest.

But another interesting observation is what appears to be the magnitudes. The breadth of reach of each kill switch, in terms of the number of machines querying the domains, appears to be dropping off, the more kill switch domains exist. In a way, what we might be observing here is a sort of law to Ransomware more generally. That is, given a successful campaign, each successive iteration, will only have a fraction of the success rate of the previous.


Another helpful perspective on these queries is the number of machines repeating from hour to hour. Here’s that information for the last 168 hours.

The big spike on the ayy.. domain jumps out. This means that 100% of the machines from the previous hour made queries in the current hour. This spike occurs at a very early stage in this particular domain’s life, when the queries to this domain was limited to only a very small number of machines. It might mean reinfection, further spread of the malware, or just a researcher investigating the domain.


Finally, the last data point to take into account when looking at query volume is the median number of other domains queries by machines querying the kill switch domains. The intuition here is that the more active a specific machine is, the more likely they’ll come across something malicious.

Its interesting to note that just as with the previous graph,  the ayy.. domain is an outlier here as well. Machines querying the ayy.. domain seem to query many more other domains.


WannaCry uses the InternetOpenUrl function when requesting the kill switch domain. This leaves off the User-Agent HTTP request header resulting in an HTTP request that looks like the following:

We looked at the percentages of blocks that had User Agent strings compared to those without. The thought here is that those with User Agent strings are people browsing to the domain and those without are from the malware itself. Plotting these two groups over time you can see an interesting dip where infections slowed down then picked back up:

The Kill Switch

Probably one of the most interesting parts of WannaCry is the kill switch. While this may not be the first time such a mechanism was found in a piece of malware (e.g. Necurs), its intent is undeniably curious. It might have been for the attacker to control the worm, for the attacker to uncover when it was discovered by checking when it got sinkholed, or simply a sandbox evasion gone wrong. Whatever the reason, it played a huge part in halting the infection.

Testing for Exposure

Our Newly Seen Domains was a big help in protecting many of our customers, however many were concerned that blocking the domain would actually cause an infection. We created a simple test to mimic the logic of WannaCry, hopefully you’ll find it useful as well:

If you’re not accustomed to Visual Studio, you can use the binary attached to the gist, it was tested on 32bit Windows 8.1 with VS2015.

Domain Composition

As we mentioned in the Talos blog post, the construction of the domain jumped out at us. It literally looked like someone smashed a few keys on the upper rows of the keyboard to arrive at it. Just for fun we plotted character distance and frequency:

It’s hard to say for sure how the domain was created, but it surely feels as if someone with two hands on the keyboard at home row position just alternated back and forth with little movement. Its even as if partway through they reminded themselves to be more random and reach all the way up to that top row with their middle finger for the nine!


There will alway be copycats and WannaCry was no different. These little Frank Abagnales patch the binary to include different kill switch domains, bitcoin payment addresses, then let the worm spread. We continue to see these pop up:

These domains are so similar that we decided to illustrate how little work copycats are putting into creating new variants by calculating the Levenshtein distance between them. These low distances help quantify exactly how lazy they are:

Here is a list of domains we found with simple pattern matching, you might also notice that most are the same length.

  • iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]de
  • iuqerfsod9ifjaposdfjhgosurijfaewergwea[.]com
  • iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]info
  • iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]net
  • dp9ifjaposdfjhgosurijfaewrwergwea[.]com
  • iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]world
  • iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]us
  • iuqssfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com
  • iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]co
  • ifferfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com
  • iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]org
  • iaaerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com
  • iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com
  • iuqerfsodp9ifjaposdfjhgosurijfaewrwergweb[.]com
  • iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]xyz
  • iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]kr
  • iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]cn
  • ayylmaotjhsstasdfasdfasdfasdfasdfasdfasdf[.]com


Infected Websites

Common with most ransomware infections, the malware displays a ransom note when its encrypted files on the systems. WannaCry did this using its own executable, named @WanaDecryptor@.exe. We decided to look for websites hosting these executables and uncovered a slew. We’re not entirely sure if the website was actually compromised or there was something else going on, but we wanted to dig in a little to see what we could uncover. Below is the queries to 10 domains known to have the file, we anonymized them in the chance they are actually infected:

Notice, all these domains appear to have increased volumes of activity in the last 3(or so) days. In fact, the amount of activity within the most recent period (the last day or so) appears to show the most dense period, so far. There are two take-aways from this: either 1) the WannaCry campaign is still in full throttle, or 2) the WannaCry campaign is dwindling as security researcher gain an edge into cracking the malware.

Regardless of which interpretation of the events transpiring, these 10 domains offer insight into how the kill switch and domains hosting @WanaDecryptor@.exe compare. The largest take away is that the proportion of queries occurring to these domains hosting @WanaDecryptor@.exe is significantly smaller than to the smallest kill-switch domain query count. And yet, while smaller, these @WanaDecryptor@.exe domains exhibit more uniform amounts of queries: i.e. there isn’t one or two domains that seem to receive all the queries. This more uniform distribution of domains containing @WanaDecryptor@.exe information leads one to conjecture something about the infrastructure used to store the payloads required to download the ransomware.

In Conclusion

We’ll continue to monitor this event and others so that we can protect our customers! Stay Tuned!

The post The Hours of WannaCry appeared first on OpenDNS Umbrella Blog.

Earlier in February, a few of us from Security Research at Cisco Umbrella and Sarah Brown (from Security Links, based in Delft, The Netherlands) headed to Oakland for the 2nd annual Enigma Security Conference (Jan 30-Feb 1). Enigma is a 3-day conference that focuses on threats and defenses in the growing intersection of society and technology. There were a great number of fascinating talks and opportunities to network with the security community. We also gave a talk on “Behaviors and Patterns of Bulletproof and Anonymous Hosting Providers”: research that Dhia Mahjoub and Sarah Brown had been working on for several months.


Here are some insights from those who attended.


Overall, I found Enigma to incorporate an excellent blend of technical and high-level presentations with ample time for Q&A sessions and a healthy dose of intermissions to socialize with colleagues. Enigma’s reputation for providing a premier level of quality talks was exemplified through its various speakers, who are experts and leaders in the public sector, academia, and industry, including our own Dhia Mahjoub.

One of the most compelling presentations was Matt Jones’ session on reducing spam in WhatsApp while implementing e2e messaging encryption for 1 billion users – this illustrated the immense power of user metadata in tracking and blocking abusers of the platform. Content is important – no arguments there – but metadata serves as a ripe treasure trove for researchers to sculpt algorithms aimed to block spam and/or malicious content.

Another interesting, albeit frightening, presentation was Yongdae Kim’s hacking sensors session where he demonstrated that spoofing, disrupting, and blocking sensor data was relatively easy. A basic understanding of a device’s internal components, coupled with a simple over-the-counter piece of hardware such as an infrared laser or speaker, can empower a nefarious person to cause serious damage to institutions and other individuals. The most interesting segment of Kim’s presentation occurred when he used an external speaker plugged into his laptop to disrupt a drone’s gyroscope and caused it to crash in the auditorium – theatrical, but point taken.


One of Sarah’s favorite aspects of Enigma is the requirement for all speakers to work with their session chair and colleagues in the session to give three practice talks in advance of the conference. The emphasis on speaker training comes from the TEDx conference approach, where speaker coaches are provided to all presenters, to ensure succinct, high quality talks and accessibility to the audience. This requirement had clear benefits during the event. The conference contained one excellent talk after another, with a clear desire from the speakers to connect with their audience.

Highlights included:

  •      Susan Mernit (Hack-the-Hood) on cyber security and IT education for underprivileged San Francisco youth.
  •      Yongdae Kim (Professor, Korea Advanced Institute of Science and Technology (KAIST) on IoT sensor attacks
  •      Hudson Thrift (Uber) on engaging with early stage startups to bring new product features, and cause slight roadmap pivots, to address Uber’s security needs
  •     Tom Lowenthal (Committee to Protect Journalists) work to support journalists across the world.
  •      Daniela Oliveira (University of Florida) on the susceptibility of older adults to spear-fishing emails.
  •      Nathaniel Gleicher (Illumio) on methods used by the US secret service to physically protect their key asset (the president) in their service environment (public places where the president speaks).
  •      Matt Jones (WhatsApp) on preventing spam without access to message content
  •      Damian Menscher (Google) on metrics and recovery against DDoS attacks at Google.
  •      Ian Levy (UK NCSC) on the UK’s new central organization for all things cyber security in the UK.


Our talk at Enigma was about bulletproof hosting patterns in the Netherlands and it showcased the joint research between Dhia and Sarah.

The premise of the talk was that there are legit needs for hosting providers as they offer outsourced IT services to ordinary businesses, but for all the legitimate uses, abuse of hosting providers is widespread. This abuse is significant, despite efforts from registrars, LE, and researchers to combat the problem. The challenge is similar to ideas like: criminals abuse encryption, but we cannot get rid of encryption. How do we manage it?

We approached our research from both a technical perspective and a field intelligence perspective, using large scale network data mining, OSINT research, and on the ground HUMINT investigative work. We came away with investigative analysis to understand how these hosting providers operate and what can be done to fight against them more effectively.

As a use case, we focused on the Dutch IP space and its use/abuse for bulletproof hosting and anonymous offshore hosting. The Netherlands is a great use case from a technical and cultural perspective because:

  •      NL is one of the top internet transit and hosting countries with an advanced infrastructure and the presence of major internet exchange points for the European and global internet.
  •      NL IP space has been abused for distributing malware, sending spam as well as hosting of phishing sites, illegal hacker forums, stolen credentials dump shops and other toxic content.
  •      NL places a high value for privacy, tech/IT
  •      NL places a high value on entrepreneurs/small businesses

The talk combined the long-standing technical experience we have at Cisco Umbrella in investigating bulletproof hosting [1] [2] [3] [4] [5] [6] with interviews we conducted with local law enforcement, lawyers and subject matter experts. We supplemented that with OSINT research using social networks, government records, and open web information. As a result, we were able to provide a technical overview of detection methods of bulletproof hosting, identified patterns and behaviors as well as a synthesis of the legal climate, processes for reporting abuse and take downs and we concluded with some promising perspectives for the future.



The videos and decks for all the talks have been posted and can be found here:

The post Enigma 2017 Recap appeared first on OpenDNS Umbrella Blog.

The massive phishing attack disguising itself as a Google Docs sharing request is dominating headlines. We’re proud to say that our Sender Rank algorithm detected the attack before the blogs began to roll! Not only that, our unique perspective gives us insight into how successful the attack was. While most reports are looking at the email content itself, our focus is on network traffic, so let’s look there to see the staggering impact of the attack and what Sender Rank looked at to catch it.


Timeframe and Domains

Our data shows the attack was mainly concentrated between 2017-05-03 18:00:00 and 2017-05-03 19:00:00, consisting of the following domains that share the lexical attributes doc and cloud among them:

  • gdocs[.]pro
  • gdocs[.]win
  • g-docs[.]pro
  • g-docs[.]win
  • docscloud[.]win
  • docscloud[.]info
  • gdocs[.]download
  • g-cloud[.]pro
  • g-cloud[.]win
  • docscloud[.]download

These domains had another common characteristic: a sharp increase in traffic volume. Further, the volume of traffic for these domains happened as most spam does: i.e. early in the morning and typically blasted. Below is an example (g-docs[.]win) of how the domain is dormant, with little or no query volume, prior to its release:

Domain volume to g-cloud[.]win domain.

The Click

The phishing email contains an ‘Open in Docs’ button, which when clicked, sends the user to Google’s OAuth page for authentication and to grant permissions to the victim’s account. In the email we looked at, the URL assigned to the button click contained a redirect parameter, which, once allowed or denied at Google’s OAuth page, would redirect the user to an attacker-controlled website. As identified by our Sender Rank algorithm and confirmed in other articles, the domains listed above were found to be used in this attack, and likely the value of this redirect parameter.


The button and the redirect sequence is particularly noteworthy since, in our testing, the user needs to click the ‘Open in Docs’ button, then either click ‘Allow’ or ‘Deny’ on Google’s OAuth page to contact one of these domains. There also were reports of other variants of the phish that just had a link to the attacker-controlled system. Regardless of how many steps it takes for the user to arrive at the attacker-controlled site, the fact that they always need to click something first makes the query volume particularly staggering. For instance, if we just look at four of the ten domains, we see an approximate average of 15,000 queries:

Query Volumes


10 domains averaging 15,000 queries might suggest an upwards of 150,000 of our users actually clicked ‘Open in Docs’. Now, it’s hard to say how many users were affected using DNS data alone. Each DNS query does not equate to a single person, compromise, or even system. Nor does a DNS query mean that the system which queried the domain did so as a result of this attack. That being said, even if the actual number was 1/10th of the query count (which, as we’ll show shortly, is more likely the case), it is still staggering to think that many people let their guard down and clicked away.

Sender Rank

Like all our models, Sender Rank provides visibility into what makes these attacker domains unique. For example, the queries to the attacker-controlled domains were at the same rate as some of the most popular and trusted sites on the internet:, and! The following section will break down some of the behavioral attributes that Sender Rank used to detect these attacker domains.

Query Behavior

A unique perspective we have in attacks like this is the ability to identify the behavior patterns within the queries made to the domains in the campaign. One interesting question you might ask is, what other malicious domains were being queried during the same time frame as these? In the following table, we highlight a few aggregated metrics that give insight into the domains used in this attack.

First, we can see that approximately 1,200 unique queries were made at the peak of the attack for the three domains shown below. This gives us a little more clarity to the impact. The interesting thing here is that the query count was sustained for roughly two hours, then saw a rapid decline in the 3rd hour (a 95% decrease on average).


The number of unique systems querying these domains

As we alluded to previously, we can also characterize simultaneous queries over the attack time frame. In other words, we can identify if these attacker domains caused additional queries outside of the norm. In the below chart we report the median number of unique queries made in the same hour (we use the median, rather than mean, due to outliers).

The median number of unique queries occurring in the same hour as those made to the attacker controlled domains

We observe about 100 (or so) unique queries were simultaneously made during the time of the attack. This is an interesting comparison to the first chart since here we don’t see a decline in the 3rd hour of the attack.

The Email Server Ripple

Email servers will often use internet-based block list services when evaluating messages for spam and malicious content. Similar to Sender Rank, email block lists have the ability to aggregate and collate the reactions of a horde of mail servers, giving them a perspective that allows them to recognize large broad campaigns.

In the following table, we show the percentage change in the block list volume for the attacker controlled domains .

Domain 2017-05-03 18:00:00 2017-05-03 19:00:00
docscloud[.]win 509% 4.7%
g-cloud[.]win 537% 1.8%
g-docs[.]win 509% -31.4%

TABLE 1: Percent change from one hour to the next.

To provide additional context, here are a few other domains Sender Rank is tracking (not blocking) with same popularity:



This attack used a common approach to target users accounts in an unsuspecting way and had a staggering impact. We’ll continue to build systems like Sender Rank to quickly detect the next attacks, protect our customers, and keep you informed!

The post Detecting the Google Docs Phishing Attack Using Traffic Analysis appeared first on OpenDNS Umbrella Blog.

A Brief History of Pastes

For more than 25 years, people looking to share computer code and snippets of text have used pastebins, web applications designed to store text. Often chosen because they would preserve formatting, pastebins were also an attractive option for IRC enthusiasts who wanted to talk about problems they were having with their programs without flooding channels with irrelevant information. 14 years ago, Pastebin ( was created. Created to be a global repository for code review, the site has blossomed into one of the most popular sites on the net. As of this writing, Alexa’s global rank for it was 1,100.

Like so many other things on the internet however, Pastebin has been abused by malicious actors. Taking advantage of the anonymity and specificity that Pastebin prides itself on, malware authors and hacker groups use the site for a variety of purposes, including sharing stolen login credentials and credit card information, kits for compromised sites, and most recently to host malware samples and complete malware chains. The site’s status as a data dump is well known, so let’s look at some of its other uses.

How To Compromise Websites and Influence People

The vast majority of content on Pastebin is benign. Plenty of users share legitimate snippets of code on it, everything from router firmware to online shopping carts. Though there’s plenty of other content that has little to do with computing or computer code, most of what is on Pastebin are pieces of scripts or programs, shared with the intention of helping anyone who needs it. The shadier side of Pastebin is still interested in helping people, but it’s more interested in helping people abuse vulnerabilities and compromised websites.

Hacker groups will use Pastebin to share their defacing code. IndoXploit, a hacking group operating for at least a year, hosts a good deal of their scripts under the Pastebin user account named “Tu5 b0l3d”, presumably the same user on the IndoXploit forums and YouTube channel.

The Pastebin account of “Tu5 b0l3d”, a member of the INdoXploit team

Not all groups are so brazen, but the need to share is compelling all the same. Here, we see the PHP for a r57/c99 shell hidden behind an anonymous account:

c99 shell on Pastebin

c99 shells are for use by malicious actors when they’ve compromised a domain’s server. Acting as a backdoor, a c99 shell lets malicious users navigate the compromised domain, grants file and password access, and comes with a host of other tools.

c99 shell distributed on Pastebin

Umbrella Investigate graph for r57c99[.]com

As seen in the graph above, Pastebin’s views on individual pastes aren’t a great indicator of the malicious actor’s success or failure. Though anonymity is one of Pastebin’s key features, the ability to store multiple copies of the same code must also be seen as an advantage for malicious actors: if a URL proxy cuts off access to one instance of your malicious paste, you may have dozens more lying in wait.

Hidden in Plain Sight

Beyond offering compromising scripts and compromised accounts, Pastebin has recently become a vector for malware attacks itself. Malware authors are using the site to host obfuscated code samples, usually encoded in Base64 (, but we’ve also seen examples in binary ( as well as hex ( These obfuscated samples are called by compromised websites in order to complete the kill chain: When a user accesses the compromised site, the site quietly makes a request to specific Pastebin URLs which then execute. The victim doesn’t need a Pastebin login (or even to know what Pastebin is), and the pastes can be set to remove themselves after a given amount of time. The small URLs pastebins employ in order to make sharing easier adds another problem for security professionals by making Twitter a particularly effective medium for infection and propagation. Used to distribute commands and code, the social media platform becomes another tool bent towards malicious purposes.

Because of the website’s popularity and ease of use, tens of thousands of pastes are added per day. Administrators might be hesitant to block the domain because of its utility, but malicious actors have been abusing it for years. The earliest blogs about this technique are two years old, and similar services such as Github’s Gist or Ideone are just as vulnerable to the underlying problems. Any service in which anonymous users can host code indefinitely is going to be a double-edged sword, and one that security professionals must be mindful of allowing.

The post A Wretched Bin of Scum and Villainy appeared first on OpenDNS Umbrella Blog.

Zum Seitenanfang