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 12th 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.

IP Port Proto Source Geo ASN Organization Tor type VT Status 104.131.84.119 443 McAfee US 393406 Digital Ocean Exit Node Clean 128.31.0.39 9101 TCP Payoad Security US 3 MIT Exit Node Malicious 128.31.0.39 Cisco Talos Yes Malicious 136.243.176.148 443 TCP Payoad Security DE 24940 Hetzner Online AG Exit Node Malicious 146.0.32.144 9001 Cisco Talos DE 24961 myLoc managed IT AG Exit Node Malicious 163.172.153.12 9001 TCP Payoad Security GB ONLINE SAS Yes Malicious 163.172.185.132 443 TCP Payoad Security GB ONLINE SAS Yes Malicious 163.172.25.118 22 McAfee GB Yes Malicious 163.172.35.247 443 TCP Payoad Security FR ONLINE SAS Exit, Guard Maybe clean 171.25.193.9 80 TCP Payoad Security SE 198093 Foreningen for digitala fri- och rattigheter Exit node Malicious 178.254.44.135 9001 McAfee DE 42730 EVANZO e-commerceGmbH Exit Node Malicious 178.62.173.203 9001 TCP Payoad Security NL 200130 Digital Ocean Exit Node Malicious 185.97.32.18 9001 TCP Payoad Security SE 44581 AllTele Allmanna Svenska Telefonaktiebolaget Exit Node Malicious 188.138.33.220 Cisco Talos DE 8972 intergenia AG Malicious 188.166.23.127 443 Cisco Talos NL 202018 Digital Ocean Exit Node Malicious 192.42.115.102 9004 McAfee NL 1103 SURFnet Exit Node Malicious 193.23.244.244 443 Cisco Talos DE 50472 Chaos Computer Club e.V. Exit Node Malicious 198.199.64.217 443 McAfee US 46652 ServerStack Exit Node Malicious 2.3.69.209 9001 Cisco Talos FR 3215 Orange Exit Node Clean 212.47.232.237 Cisco Talos FR 12876 Tiscali France Exit Node Malicious 213.239.216.222 443 McAfee DE 24940 Hetzner Online AG Exit Node Malicious 213.61.66.116 9003 TCP Payoad Security DE 8220 COLT Technology Services Group Limited Exit Node Malicious 213.61.66.116 Cisco Talos DE 8220 COLT Technology Services Group Limited Exit Node Malicious 217.172.190.251 443 TCP Payoad Security DE 8972 intergenia AG Exit Node Clean 217.79.179.77 Cisco Talos DE 24961 myLoc managed IT AG Clean 38.229.72.16 Cisco Talos US 23028 Team Cymru Malicious 50.7.151.47 443 TCP Payoad Security US 174 FDCservers.net Exit Node Malicious 50.7.161.218 9001 Cisco Talos NL 174 FDCservers.net Exit Node Malicious 51.255.41.65 9001 McAfee FR 16276 OVH SAS Exit Node Malicious 62.138.10.60 9001 McAfee DE 61157 Heg mas Exit Node Malicious 62.138.7.231 9001 TCP Payoad Security DE 61157 Heg mas Exit Node Malicious 79.172.193.32 Cisco Talos HU 29278 Deninet KFT Exit Node Malicious 81.30.158.223 Cisco Talos DE 24961 myLoc managed IT AG Vserver Netz Exit Node Malicious 82.94.251.227 443 McAfee NL 3265 XS4ALL Internet BV Exit Node Malicious 83.162.202.182 9001 TCP Payoad Security NL 3265 XS4ALL Internet BV Exit Node Malicious 83.169.6.12 9001 McAfee DE 20773 Host Europe GmbH Exit Node Malicious 86.59.21.38 443 McAfee AT 3248 Tele2 Telecommunication GmbH Exit Node Malicious 89.45.235.21 Cisco Talos SE 1653 SUNET/NORDUnet Yes Malicious 94.23.173.93 443 TCP Payoad Security FR 16276 OVH.CZ s.r.o. Exit Node Malicious

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.

Credits: Florian Roth and Tom U. for sharing hosts IOCs, developing and supporting SIGMA initiative for SIEM rules Aleks Bredikhin for waking up late night and starting the update on ArcSight use case. If you read this far, here are the links to all mentioned goodies: ArcSight rule package:at Use Case Library https://ucl.socprime.com/use-case-library/info/403/ and at Protect724: https://www.protect724.hpe.com/docs/DOC-15255 Splunk package at Use Case Library https://ucl.socprime.com/use-case-library/info/405/ QRadar package at Use Case Library https://ucl.socprime.com/use-case-library/info/404/ SIGMA signature that can be converted to Splunk, Elastic and LogPoint: https://github.com/Neo23x0/sigma/blob/master/rules/windows/sysmon/sysmon_malware_wannacrypt.yml SIGMA signature that can be converted to Splunk, Elastic and LogPoint:github.com Payload security sandbox results with IOCs and behavior indicators: hybrid-analysis.com

Upvote / Share / Comment /Invite to discuss

CSV: WannaCry_IOCs_public sources and VT

CSV: WannaCry_IOCs_cross check with Tor feed