It was inevitable, but we’re finally seeing what we all knew was going to happen. With the recent attack on Brian Krebs’ blog [1], as well as the effective takedown of half of the internet last Friday [2], "Internet of Things" (IoT) devices, and really, the lack of security in these devices, has finally made it into the mainstream.

One of the largest "Internet of Things" botnets, Mirai, is believed to be responsible for the record DDoS attack against Kreb’s blog [3] and the DDoS attack against Dyn’s Managed DNS infrastructure [4].

Last week, researchers from Level3 and Flashpoint published the list of Mirai servers [5]. In the blog, the researchers listed Mirai servers including command and control (C2), reporting, and malware distribution servers. Using our patent-pending technology, we use data on the infrastructure of the internet and Machine Learning to predict threats before they materialize as part of an actual attack. We checked the server IPs against our predictions.

Of the 56 C2 servers, we predicted 12 IPs to be involved in some type of attack. Our predictions took place in the end of 2015 and the middle of 2016. Figure 1 shows an example of one of these predictions.

Of the 23 reporting servers, we predicted 8 IPs. Figure 2 shows one example of these predictions that was made in September 2016.

Lastly, we predicted both of the malware distribution servers, and in Figure 3 we show one example of these predictions that was made in May 2016.

To summarize, of the 91 infrastructure IPs reported as part of this attack, Seclytics analytics predicted 22 of these IPs before they were used as part of this attack. As we’ve seen in sophisticated attacks such as this one, it’s not uncommon to see predictions taking months before they become active.

References

  1. https://krebsonsecurity.com/2016/09/krebsonsecurity-hit-with-record-ddos/
  2. http://www.usatoday.com/story/tech/2016/10/21/cyber-attack-takes-down-east-coast-netflix-spotify-twitter/92507806/
  3. https://krebsonsecurity.com/2016/10/source-code-for-iot-botnet-mirai-released/
  4. https://www.flashpoint-intel.com/mirai-botnet-linked-dyn-dns-ddos-attacks/
  5. https://blog.level3.com/security/grinch-stole-iot/

Whenever we share our predictions, like when Seclytics’ Predictive Analytics predicted IPs used in ProjectSauron months before it was known, the first question we get is: How do I know you made that prediction on that date?

We needed a trusted third party that we could easily store our predictions and make it simple for our users to verify themselves. After a suggestion from a colleague, we decided to store proof of our predictions in the bitcoin blockchain.

Bitcoin transactions allow you to store some arbitrary data using the OP_RETURN op code. There are many services built around this concept like Proof of Existence. But since the bitcoin protocol is pretty straightforward and distributed in nature, we decided to manually create our transactions instead of depending on a centralized service

Currently, it costs us about eight cents to store a single hash in the blockchain. We have over 5 million predicted IPs which means storing each IP would be cost prohibitive and too cumbersome for a someone to verify all our predictions. To work around this obstacle, we group all our predictions made in the day and create a hash of the group. Not only is this more cost effective, it also allows users to verify that we have not hidden any false positives because removing a single prediction would completely invalidate the hash.

Let’s walk through the process of storing a prediction in the blockchain:

We predicted 45[.]32[.]196[.]115 to be malicious on August 27.

  1. We create a salted SHA256 hash for the individual prediction:

    45.32.196.115
    ---BEGIN HASH SALT---
    $2b$12$n/DsF2cZcvST6WsAcBf70e

    Which gives us a hash of: 2646e2918253883d85bb696f7a2e623ad112b4b16a023367f0f3c1aa0d87ef5b

  2. We then calculate the hash for each of the 7500 ips predicted in the day and create an alphabetically sorted list of their hashes and calculate that group’s hash.

    ....
    2646e2918253883d85bb696f7a2e623ad112b4b16a023367f0f3c1aa0d87ef5b
    c9d92d07f9c5f0d9f2429f8872d578256fe2f77abf025e6e585b8ea59b1caebf
    dfd080784078874884a6375e7754438b7a73f45743226566dacc22b3397ff866
    ffb4e693c34ad28da31d96b761ea70964a5e8ec7cbe1cc4f0b195167cf10d1d8
    ....

    The hash of this group of predictions is 693dfe8d6c2594e1197b31991c22de0e55332a55b67e296522b9d3e20b2ad304

  3. The prediction group's hash is stored in the bitcoin transaction using the OP_RETURN op code and submitted to the blockchain. Once the transaction is confirmed, we can’t revoke or change the hash.

    To verify, search for the hash of the group (693dfe8d6c2594e1197b31991c22de0e55332a55b67e296522b9d3e20b2ad304) in the bitcoin transaction page.

To verify our predictions, we aggregate over 140 premium and open source threat feeds and check to see if any of the IPs were predicted have been reported or seen. In this case the IP was reported by Phishtank, 10 days after we predicted it.

Ultimately, we are using the bitcoin blockchain to establish trust which is especially needed when we are making predictions for events that have not yet happened or detected by other vendors.

Hello, we are Seclytics and we predict threats before they launch.

Over the past two years, our team built a truly predictive threat intelligence platform and we are now ready to introduce the next stage in the evolution of internet security.

First, there was hash based detection of malicious binaries.
Then, there were signatures and heuristics.
Those were good at stopping known threats. But what about the threats we haven’t seen?
Then came zero day protection products.

What's next? How do you get better than 0 day?

With our predictive platform we can identify malicious infrastructure before they even launch the attack. That makes us negative day protection.

Sounds too good to be true?

Just a few days ago, multiple security vendors reported on the high profile APT ProjectSauron/Remsec [1] which targeted multiple government agencies, telecoms and financial institutions. Detecting sophisticated attacks like this is very difficult which explains why this attack went undetected for 5 years [2].

According to Kaspersky, Running an expensive cyberespionage campaign like ProjectSauron requires vast domain and server infrastructure uniquely assigned to each victim organization and never reused again. This makes traditional network-based indicators of compromise almost useless because they won’t be reused in any other organization.

Of the 6 IP IOCs mentioned in Kaspersky’s recent post [3] about ProjectSauron, we predicted 3 of the IPs earlier this year and two of the predictions are valid from 2014.

  • 81[.]4[.]108[.]168
  • 5[.]196[.]206[.]166
  • 178[.]211[.]40[.]117

We are different than traditional network-based solutions because our classifiers analyze the global infrastructure of the internet. We don’t depend on any kind of reputation or previous malicious activity to generate our predictions.

We will continue tweeting specific attacks as they are seen with our predicited date. So be sure to follow us.

Follow @seclytics

We hope that together we can help change the security landscape from reactive to proactive.

If you would like to protect your organization with our predictive analytics, please contact us.

References

  1. https://securelist.com/analysis/publications/75533/faq-the-projectsauron-apt/
  2. http://www.bbc.com/news/technology-37021957
  3. https://securelist.com/files/2016/07/The-ProjectSauron-APT_IOCs_KL.pdf