The WannaCry journey from a SOC point of view – internal sinkholing of killswitch servers

[ see also: The WannaCry journey from a SOC point of view ]

In the previous post I described how our Security Operation Center managed the WannaCry news.

We also made a lot of side activities in the past hours and one of these was to implement an internal sinkholing of the killswitch servers in case some clients where infected; with a working local sinkholing we where able to avoid the ransomware spreading in case of infection.

How? Let me explain.

What are the killswitch servers for WCry? In few words: before start spreading WannaCry make a simple check (see reversed code in above figure and read more here from Cisco Talos) trying to contact two hardcoded web sites:

• www [dot] iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea [dot] com
• www [dot] ifferfsodp9ifjaposdfjhgosurijfaewrwergwea [dot] com

Notice from the above code that WannaCry is not proxy aware (check here for details).

If the connection fails (as expected from the authors in real life scenario) the ransom continue the attack, spreading on local lans and Internet; if the connection works (not expected e.g. you are in a sandbox) it exits doing nothing. While the two servers above are up&running and reply to the ransom connections, the ransom won’t spread; that’s why we call them killswitch servers.

Malware Thech was the one that on past friday registered (accidentally, this is called domain sinkholing) the first killswitch server, slowing down the Internet infection of WannaCry: the ransom successfully connected to his siknkhloled domain and didn’t spread.

Always? No. If you are using a proxy to connect to the Internet you not benefit from the killswitch. The sinkholing in your case is ineffective.

It’s also likely that your internal DNS won’t resolve Internet domain names (internal clients that use proxies don’t need to resolve public domains, just the proxies need this). So this means that in the unfortunate case where someone in the company network runs WannaCry (usb key, phishing, web site download etc) and you are vulnerable, the ransom spread around because can’t connect directly to the Internet sinkholed killswitch servers due to:

1. missing DNS resolution;
2. missing direct connection to Internet.

As a Security people I cannot be sure that all the clients in my company network are secure, I have always to put my mind in the worst case scenario, and I need to put in place all the needed mitigations.

In this case (yes, we have proxies and our internal DNS won’t resolve Internet domain names) we implemented an internal sinkholing as follow:

• made two new zones on our internal DNS infrastructure:
  • iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea [dot] com
  • ifferfsodp9ifjaposdfjhgosurijfaewrwergwea [dot] com
• in each zone created a new A record called www that point to an internal IP (SOC web server) fully routed in our corporate network;
• configured a dedicated virtualhost in our SOC web server to receive the connections sent from an infected client. In this case a compromised client won’t spread locally;
• adapted our Security application with a new search on the SOC vhost logs that alerts SOC analysts in case of a connection to the internally sinkholed killswitch servers (infection symptom).

As of today we don’t have report of infected clients and no connection to the internal killswitch servers. Great 🙂