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.

Killswitch for WonnaCry ransomware
Killswitch for WonnaCry ransomware

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 Tech sinkhole
Malware Tech sinkhole

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.

WannaCry infections
WannaCry infections

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).
SOC test alert for sinkhole detection
SOC test alert for sinkhole detection

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

Advertisements

2 thoughts on “The WannaCry journey from a SOC point of view – internal sinkholing of killswitch servers

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s