Contemplation of the SolarWinds Hack !

Introduction

I have been a fan of social engineering for years now ever since I was 15 years old and heard about Kevin Mitnick adventures with the coin-operated public telephone, there is just a certain human centric appeal to it that is hard to resist. I always have and still do believe that social engineering is the most effective way of adversarial attack yet I find myself struggling with the SolarWinds hack and having to do some serious contemplation on how threat actors, threat vectors, threat actions and target victims are changing.

Weeks after the attack was discovered and months after it actually started, security firms worldwide involved directly such as FireEye and CrowdStrike or indirectly such as Kaspersky and Symantec are still presenting new findings on the complexity of the attack and the extent to which attackers went to hide its presence let alone its effectiveness.

The last we know is that a third malware strain has been identified which leaves us as of now with Sunspot which ran on the SolarWinds Orion build servers allowing attackers to change/inject code into the software build and eventually ended up in the production release of Orion in thousands of customer production environments, Sunburst malware which was embedded into Orion build/updates and was used to send information to attackers C&C in order to decide if the victim was worth pursuing (deletes itself if the victim is not worth it), and Teardrop which was the injected payload backdoor Trojan for further command and control of a worthy victim environment.

An interesting find by Symantec was that the attackers used a very rare domain generation algorithm which allowed them a very stealthy level of communication with their C&C and bypass network security for the likes of FireEye and government entities. DNS queries do not directly reach a C&C server so attackers where able to embed ids in the DNS request to determine and differentiate different victims on top of identifying the kind of endpoint security present on each compromised system.

Add this to the 14 days delay with Sunburst before activating (which is  time most environments use for testing and validating updates) and the very detailed security components (processes, applications, services, registry, and file) check/disable done before activating communications with the C&C, we get a one of a kind APT.

A very important aspect of this hack that is still unknown or undisclosed is how did the attackers first gain entry to SolarWinds network and eventually build servers. A group that went this far would not have had any issues gaining access to SolarWinds systems in my humble opinion one way or another but still its very important to understand how it happened. Was SolarWind chosen because of the possibility of network breach to begin with or was this decided way before and the initial breach was the easy part?

Did SolarWinds practice their due diligence and due care security wise and if they actually did, what hope is there for the rest of the vendors let alone companies out there,  Very chilling thought !!! that is why its imperative we understand how this all started especially the point of entry, how attackers pivoted their way to the build servers, and how on earth did this pass a code review of the update !!!

Contemplation

  • First and foremost, I sympathise with SolarWinds and all the organisations effected by this attack, but I wont have any empathy until I understand the first point of breach and how it all started. The latter will dictate if this actually can happen to any vendor to this extent or what we know as a fact can actually happen to any vendor, can be stopped at a much earlier point in time not causing this kind of ripple effect we saw with SolarWinds. Understanding the malware and techniques involved is great but I want to know how the hell did attackers reach the build servers and how did the update pass review and audit.
  • Zero Trust is a myth, at least the what the name proposes/implies, and as I have been advocating for long now, this needs to be called Minimal Trust since we intrinsically trust security vendors. There is so much due care and diligence we can do as organizations, reviewing code for an update is not one ! Yes we can have more security in place to prevent lateral movement, pivoting and further damage but that also relies on other security vendors that may have security issues of their own .. I do not want to sound dystopian, nothing changes in the concept of Zero Trust which is the way to go, we just need to rename it and add more controls over server/network/security solutions as well not just users/apps/network/data .
  • Never Ever whitelist or exclude applications, processes, and/or file locations from your endpoint and/or network protection solutions. I see this more often than not and unfortunately many vendors do recommend this but this is a recipe for disaster and the SolarWind hack is the ultimate evidence. When malware is embedded inside a trusted system, excluding it means excluding the malware within it, in case your EPP or EDR or Proxy or App Firewall or NG-Firewall or Sandboxing was able to detect the attack, it would disregard it if the apps involved where whitelisted or excluded.
  • Never Ever use a domain admin or local admin as a services account for your systems that being virtual or physical. When malware is embedded inside a trusted system with administrative permissions, things be come very easy for attackers to bypass local security and prevent further damage to other systems on the network.
  • The sophistication of this attack clearly shows that it is somehow sponsored and only adds to what we already know that targeted attacks will eventually succeed. The question here is to what extent would they succeed and how early on can an attack be detected and responded to. A supply chain attack or otherwise, that is not the case,  a persistent attack will somehow find a way in so having adequate controls in place is not enough neither is buying more security products. My answer here is the public cloud, a reputable public cloud is much better risk mitigation technique then all the money you want to waste. Different cloud services will mitigate and transfer different types of attacks, you are still vulnerable but with a much smaller surface of attack. People will argue this and I have had my share of that, and yes its about context, but generally speaking for most organizations out there, the public cloud (certified/audited) with a good SLA and insurance is a safer bet especially SaaS.

Conclusion

I still believe that Social Engineering is the most effective adversarial attack our there even after contemplating the SolarWinds hack. A sponsored sophisticated attach is a major risk to any company but realistically its targeting specific entities mostly government and hence is not a big risk to SMBs or even enterprises with a low profile. Do not get me wrong, it is a risk to everyone, but these groups do not invest this amount of time, money, and expertise on any company out there.

Only time will tell if we will ever know how this attack got started and my hope is that at one stage the attackers will let us know the stages of this attack from their side, especially on how the decision was taken to target SolarWinds if it was prior or after its network/systems where breached. Until then, practice due diligence and due care while thinking about risk resilience, mitigation, and transference.