We haven’t seen the worst problems of cybersecurity yet, but the most recent Sunburst / SolarWinds hack was remarkable. Instead of targeting single machines or users the attackers target a software that helped administrators modify the systems they are responsible for. A modern variation of Odysseus plan to win the trojan war (CheckPoint now calls this: elaborate supply chain attack).
Could the massive intrusion be detected much earlier? Yes, and even quite easy by observing DNS requests.
The problem is already inside your network
The old paradigm to protect computer networks is to control what enters. This concept call perimeter security lends itself from a clean room thinking. I filter all the air coming in and with a slight excess pressure, I assert that no unfiltered air enters by any uncontrolled gap. In a computing world we have an internal network (clean) and external networks (polluted) and components like proxies, firewalls, inspectors and traffic shapers (depending on network layer) try to clean anything to enters.
In today’s world the separation became impossible. People bring their own devices (with individual access), web applications communicate in a myriad of ways with outside systems (and have connections to the internal network) and many applications depend on bidirectional data exchange with the outside. Or in other words: The problem is already inside, and you can’t trust in controlling the gates.
Have a look at the outgoing traffic
A modern approach, in addition to protecting the “old way”, is to look at all outgoing traffic to find suspicious patterns. So back to the Sunburst / SolarWinds hack and domain generation algorithms as a piece of the puzzle.
Hackers need to communicate with the external network. Either to transport data they are stealing or to import logic and/or signals needed to make their hack a success. This is mostly done by hiding their traffic in existing communication (piggyback on legit traffic). But here comes the challenge: the endpoint. The data needs to be exchanges with systems owned by the attackers. If they would choose static IP addresses the attack is too easy to be stopped by filtering/blocking on a global scale. So they became more dynamic by addressing endpoints using domain generation algorithms.
DNS queries tell you that your hacked
Domain name system (DNS) is a service that translates human readable addresses (such as stuker.com) to the numbers needed by the network. Malicious software uses that mechanism to dynamically connect to endpoints so they can’t be filtered/blocked too easily. But doing this, they peril aspect of human readability (and increase number of DNS requests in general and failed DNS requests in particular).
They distributed their requests by registering a large number of (algorithmically created) domains. So they might register kjhdshkjhds.net, lasjdasldkj.net and many more. They then multiply by creating 3rd level domains the same way and create hundreds of addresses such as aaa.kjhdshkjhds.net, bbb.kjhdshkjhds.net, ccc.kjhdshkjhds.net… Here some sample patterns of the real attack where the generated part of the domain name (4th level) most conveniently encoded machine- and domain name of the infected computer.
Looking at your DNS logs you will immediately see that the number of DNS requests growth in an unusual pattern and many of them are first time requests and some may even fail (because they begin being blocked). That old and well documented mechanism was used by the Sunburst / SolarWinds hack but the US government didn’t see this for many months and was forced to shut down and restore large parts of the network by issuing the Emergency Directive 21-01 much too late.
Closure
My post was inspired by an article by David Gugelmann, Founder and CEO of Exeon (I am investor of the company). The offer a solution that analyses outgoing traffic using sophisticated algorithms and are able to detect yet unknown cybersecurity issues quickly.
It astonished me, that this attacks against US government agencies was so easy to discover and yet was so successful. That brings me back to my statement that we haven’t seen the worst cybersecurity problems yet.
