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.

Timeline

WannaCry couldn’t have been so impactful without the dramatic sequence of events in the months leading up to the attack. We broke 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, or related to an infection) using our resolvers over time and the percentage of queries each country was responsible for in each period:

Update: We noticed a small issue in the timestamp in the lower left of this video, it has been corrected.

Exposure

Note: We’re monitoring port changes in machines with TCP 445 open and are seeing fluctuations in results that may impact the graph below – we’ll keep you updated as we find out more.
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 machines had TCP445 open and may still be 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.

Repeating

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.

Riskiness

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.

Researchers!

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!

Variants

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!