WannaCry seen from the perspective of an SMB server

On 12 May 2017, the cryptoworm WanaCrypt0r 2.0, also known as WannaCry, infected hundreds of thousands of computers around the world. Our investigation into this ransomware reveals some worrying trends.

(Re)read part 3 : WannaCry, a chronological order


This is the first in a series of articles on WannaCry. In it, we analyse the logs of one of our Samba (SMB) servers. Following the attack, the number of IP port scans targeting this server grew considerably.

We implemented a test Samba server when researching a topic that had nothing to do with WannaCry. Samba is a file-sharing software program for Unix and Linux servers which uses the Microsoft SMB/CIFS protocol. It is therefore not affected by EternalBlue, an exploit targeting a vulnerability in Windows operating systems. Nevertheless, we were surprised to see a significant increase in the number of connection attempts to our server when we consulted its logs during a routine check on the morning of 13 May. For this reason, we have decided to share the results of our log analysis for the period before and after connections peaked.

How does WannaCry work? WannaCry is a cryptoworm, meaning it is a self-propagating ransomware. It infects computers by exploiting a vulnerability in Microsoft’s SMB/CIFS file-sharing protocol. Once it has been installed on machines, it encrypts documents and generates a random list of IP addresses. It then scans these addresses and sends malicious SMB packets containing the code it requires to self-replicate to remote hosts. Our Samba server is not affected by the EternalBlue exploit. Nevertheless, the cryptoworm still scanned it in an attempt to find an open port 445 (used by SMB). While the server was not compromised, we opted to revoke its read-write access and activate the read-only mode for security purposes. The article below focuses on these attempts to connect to our server – not how the worm works.

To protect our clients’ confidentiality and the results of unpublished research, we have not discussed absolute values. Instead, we have mentioned relative values, calculated using a coefficient proportional to the total number of connections received. This coefficient was used to smooth the curve. The values that appear here are proportionate to the total number of connections, not an exact figure.

A significant increase in connections

During the attack, our server received a high number of connections from unique IP addresses. The number of connections was 50 times higher than the daily average before the attack.

As seen in the graph below, before the attack, the number of connections was generally stable, despite peaks and troughs. The trough around 7 May was caused by the temporary shutdown of the server for research purposes, and is statistically insignificant. The server was restarted on 10 May.

The WannaCry attack began on 12 May and resulted in the following events:

  • On the first day of the attack, the number of unique IP addresses attempting to connect to our server was 13 times higher than during the period before the attack.
  • On 13 May, the number of unique connections was 50 times higher than the average recorded before the attack.
  • On 14 May, the number of connections fell sharply to temporarily stabilise at pre-attack levels.
  • On 16 May, the number of connections began to increase again, ending two times higher than during the period before the attack.
  • Over the next few days, the curve flattened off: the number of connections was generally stable, despite peaks and troughs, although the average was between two and five times higher than before the attack. On 29 and 30 May, for instance, the number of unique connections peaked at a level five times higher than the pre-WannaCry average. Apart from the “collapse” on 14 May, signifying a return to normal, the lowest connection values were still twice as high as those prior to 12 May.


Graph showing a coefficient proportional to the number of connections per day. The peak on 12 May is clearly visible, as is the significant increase in the average number of connections after the attack.

When looking at the days of 12 and 13 May, we observed an initial increase in connection numbers at around 2 pm (UTC) on 12 May. Connection attempts then increased steadily until peaking at 11 am on 13 May (UTC). Connections then decreased before stopping around 9 pm and then stabilising at rates similar to those prior to the attack.

These statistics are especially interesting when considered alongside the kill switch discovered by MalwareTech (1). The kill switch is a domain name that the worm attempts to connect to when entering a new environment. If the connection request is successful, the malware exits. If not, the malware executes the program. This kill switch could be a security feature designed to prevent the malware from being studied. The domain name was a random series of characters and figures, meaning there was little chance of it being registered (and accessible). If the malware found itself trapped in a research environment created by a cybersecurity expert (a sandbox, for example), the connection request would be successful, even if the domain name was not accessible. Determining whether the domain name was accessible would have been a good way of checking that the worm had infected a vulnerable computer and not a test machine.

The expert registered the domain name around 2 pm (UTC), when the first connections to our server were recorded. The connection peak ended on 13 May at 11 am. It therefore took approximately 24 hours for the kill switch to work. Thanks to the expert’s work, we now know that shortly after the domain name was registered, the initial WannaCry sample could no longer infect machines. The fact that connections to our server only peaked after the domain name was registered could mean that the worm self-propagated fairly slowly.

Over the next few days, connections increased slightly before growing steadily – at a slower rate than in the early days of the attack, but faster than before 12 May. This could indicate the presence of a WannaCry worm without a kill switch, self-propagating at a much slower pace. Alternatively, these connections could be from servers compromised by malware exploiting the same Windows vulnerabilities as WannaCry, such as EternalRocks or Adylkuzz. A final possibility is that the media coverage of SMB protocol vulnerabilities attracted the interest of hackers. Regardless, the increased focus on SMB servers is concerning, given the weaknesses highlighted by the Shadow Brokers and the large number of badly configured servers able to be read and written to.

Local connections

Surprisingly, most connections came from Canada and France. However, according to MalwareTech (1), very few computers were infected in Canada. Given that IP addresses could be hidden by proxies, it is difficult to draw conclusions from these observations.


Graph showing the locations of IP addresses scanning the SMB server. Canada, France and, to a lesser extent, the United States and the United Kingdom figure heavily.

However, this raises questions about the propagation method used by WannaCry. According to researchers (2), the worm sends malicious SMB packets to IP addresses from a random list generated beforehand. The fact that most of our SMB server’s connections came from France and Canada could mean that the worm used a particular propagation method. For example, given that our server is installed in France, the worm could generate IP addresses by geographic area, selecting targets based on proximity. We do not currently have enough information to draw appropriate conclusions.

This glimpse at our SMB server logs shows the impact of the WannaCry malware from an internal perspective. The results presented here, however, are unique to our SMB server and cannot be extrapolated. In our next article, we will discuss the attack’s timeline, to gain a better overall vision of the issue.

(1) https://www.malwaretech.com/2017/05/how-to-accidentally-stop-a-global-cyber-attacks.html

(2) https://nakedsecurity.sophos.com/2017/05/17/wannacry-the-ransomware-worm-that-didnt-arrive-on-a-phishing-hook/