WannaCry no more: ransomware worm IOC’s, Tor C2 and technical analysis + SIEM rules

Good news everyone!

After a rather long day, night and morning of studying the news, researching and hunting the #WannaCry ransomwareworm there are some discoveries to be shared.. This includes Host and Network IOCs, their analysis obtained with help of fellow security researchers and practitioners, review of C2 infrastructure and its interactions with Tor. Last but not least are some free SIEM use cases that can immediately help you to detect and start blocking above mentioned disaster from escalation. And there is a quick review of SIGMA signatures that I just recently discovered (Yara for SIEM). Disclaimer: goal of this post is to provide IOCs and guidance how to detect and block the #WannaCry ransomware threat by leveraging SIEM tools, OSINT, firewalls, proxies/security gateways and do this all in a shortest time-frame possible. This is not a malware reverse analysis or a media article, there’s a huge job done in latter regard by many people already (you know who you are, thank you for help!)

Macro analysis

Just in case you missed the whole media explosion about #WannaCry / #WannaCrypt ransomware worm outbreak that hit the world on Friday 12^th 2017, these 2 high-level articles stand out to me as most comprehensive and quick to grasp out of 40-ish I’ve read this far: forbes.com, blog.qualys.com.

And an attack map recording by MalwareTech who took control of one of the malware domains.

But why no Cisco Talos? Here’s the link http://blog.talosintelligence.com/2017/05/wannacry.html, but that article is a long read and arises questions on the technical part (read on to see why). And if you are reading this it means we’re together into resolving the technical nature of this incident and preventing it and similar attacks of happening in future.

Concluding the macro analysis, a from a fellow security colleague:

“Fair enough, but my real point is that, now CIA / NSA hacking tools have been leaked, I’m sure this will happen again … firms will need to be proactive, query their CMDB , and locate these out-of-support systems, and quickly upgrade them, harden them by disabling any non-essential Windows services, and submit the most critical ones for 3rd partypenetration testing… if the business chooses to ‘accept the risk’ (to avoid the cost) , it’s only fair that the risk is fully explained to them.”

On to the fun part!

Network IOCs and their usability

As far as OSINT goes we could dig up 39 IP addresses, sometimes with ports, protocols and comments. This came from McAfee, Cisco Talos and Payload Security sandbox sample. We all know that IP is by itself is not a good #threatintel so lets make some analysis of what we see and how it can help us to Detect and Block WannaCry / WannaCrypt or anything that’s #wannamesswithourproperty. Each IP was pinged, analyzed via VirusTotal and with SOCPrime DetectTor feed. The latter is collection of 1,5 years of Tor network activity that is gathered in real-time. Initial table for your reference.

So what do we see? 36 out of 39 IPs or the 92% of C2 addresses reported are, behold! Tor nodes. And 37 IPs are flagged as malicious by VirusTotal within days or 1,5 months of incidents and that’s a 87%. But why do we see almost no ports? Let’s analyze further, no time to draw a pretty picture (also my drawing skills are bad) so I’ll share 2 pictures of another .XLS table:

What’s up with the tables and colors? To name a few things:

1) There is only 1 Hidden Tor Bridge (orange). This means attacker was in a rush to get things launched and is likely a cyber criminal and not a state-sponsored APT actor (unless this is an ultra-sophisticated deception plan to pretend like you are not an APT actor). If we compare this outbreak to serious APT campaigns, the Hidden Tor bridges makes infrastructure much more stealthy and harder to deal with, also more expensive.

2) The transport used on all Tor nodes is not obfuscated and is not using modern Tor meek and Obfs4. This means traffic is relatively easy to distinguish in corporate environment, you don’t even need a DPI to do that.

3) All reported IP’s were compared with Detect Tor that has over 18 months of Tor node, transport and reputationhistory. This allows us to discover ports used by Tor nodes and attribute them, thus enriching IOCs. Also you can find fresh nodes (31 and 37), just 2 out of 39 this means there was no new special Tor infrastructure rolled out for the attack- existing Tor network was used with C2 domains hidden behind in .onion web.

4) In reported C2’s 13 ports e.g. 33% are 443 and 13 are 9001 (default Tor port) and 3 more are 900X ports. With properly segmented networks outbound connections to port 9001 will not go through from any segment of most enterprises. In enriched data set we are dealing with 59 ports, ports 443 and 9001 making up 59% of all ports. We also see 4 of IP’s reported by Talos got no ports, however they are active as of 13.05.17 and we discovered the ports.

5) #28, 38 and 39 are NOT Tor nodes, however they are flagged as Malicious by VirusTotal and no ports reported again by Talos. This are likely distribution sites.

6) #62 is a false-positive reported by Talos, as it leads to deb.torproject.org and other multiple subdomains of torproject which are pretty bening – they host Tor browser which is does not make them a C2 or Malicious website.

So what to do with C2 information? You can use it as hardcoded IOC for next 1-2 weeks but their accuracy will degrade with each passing our. What is more important is that C2 network is fully behind Tor and by making live blacklists on corporate perimeter and endpoint devices we can prevent C2 traffic altogether. At least for this variance for wannacry? ransomware worm, since DNS tunneling capabilities were not reported as of time of this write up.

Host based IOCs:

There is a SIGMA signature created by the project author Florian Roth on github: github.com

Quote from project site “Sigma is a generic and open signature format that allows you to describe relevant log events in a straight forward manner. The rule format is very flexible, easy to write and applicable to any type of log file. The main purpose of this project is to provide a structured form in which researchers or analysts can describe their once developed detection methods and make them shareable with others.

Sigma is for log files what Snort is for network traffic and YARA is for files.

Use cases include:

• Describe your once discovered detection method in Sigma to make it sharable
• Share the signature in the appendix of your analysis along with file hashes and C2 servers
• Share the signature in threat intel communities – e.g. via MISP
• Provide Sigma signatures for malicious behaviour in your own application (Error messages, access violations, manipulations)
• Integrate a new log into your SIEM and check the Sigma repository for available rules
• Write a rule converter for your custom log analysis tool and process new Sigma rules automatically
• Provide a free or commercial feed for Sigma signatures”

We are working together with Sigma team to expand capabilities to more SIEM technologies.

You can find more host IOCs on Payload Security’s sandbox here: hybrid-analysis.com

Additional host IOCs are being prepared and will be included in article in next 24 hours.

Mitigation, aka CryNoMore

• No incoming or outgoing Tor access from corporate premises. Use ACL’s on FW / NGFW, security gateways / proxies and DNS RPZ if you got unix DNS. You can get Tor feed from OSINT or from our UCL, review and register here my.socprime.com/en/ucl/tor/ , the use case is now free forever for all enterprise and public sectororganizations. This would block the major part of Delivery and C2 coms.
• Got outdated MS OS running and can’t patch? Use this as a hotfix “dism /online /norestart /disable-feature /featurename:SMB1Protocol” or your any preferred method of disabling SMB services. Source idea:
  

• Patch MS17-010 if you have not by now: technet.microsoft.com And patch against all exploits revealed by Shadow Brokers ASAP. Need help measuring the risk? Scan network with Qualys, Tenable or anything that understands CVE IDs. List of CVE’s can be obtained here: https://github.com/misterch0c/shadowbroker
• Got SMB on perimeter? Then you’re probably already encrypted 🙁 Use Shodan to find open ports on your perimeter, its free. Though continuous port mapping and scanning would do better, even the good ol’ NMAP can do the job.
• If you would check every outgoing port 443 connection with VirtusTotal you would likely block >87% of C2 traffic in this attack. Think about it.
• As a rule of thumb ask yourself this: why do you allow outgoing traffic to port 9001 anyway? Or in fact any port except 80 and 443.
• Block all Outgoing requests on port 80 and 443 to IP addresses that do not resolve into domain. You can get more creative and limit this with whitelist of Alexa top 1M and exclude dsl/home internet/mobile internet subnets. If you have advanced security web gateway then block access to not just all malicious but also uncategorized URLs.
• Still opening unknown email attachments on emails you did not expect? Don’t do it. Just don’t.

p.s. Last 48 hours were a hell of a “fun”: first I searched by laptop inside out for HP backdoor in audio drivers and found none. Then it suddenly turned out that MS17-010 did not install properly on my machine.. So here we have it, the transition from old school “Trust but verify” to the Cyber 2.0 motto of “Never trust and always verify”. It was never so right, time to live by it.

/Stay safe. And test your backups regularly.

Upvote / Share / Comment /Invite to discuss

CSV: WannaCry_IOCs_public sources and VT
CSV: WannaCry_IOCs_cross check with Tor feed