FireEye and other US Government agencies suffer supply-chain attack.

On December 8th, we learned that a threat actor compromised security firm FireEye and other US Government agencies in a sophisticated supply-chain cyber attack. Threat actors compromised IT monitoring company SolarWinds and were able to get malicious code compiled into a build that reportedly published to 18,000 customers. Without a doubt, this type of attack is the work of a well planned and well-disciplined threat actor.

SolarWinds Orion products impacted by the compromise.

On a dedicated security advisory page, SolarWinds stated they have scanned all their products for indicators similar to the compromise of the Orion platform. According to their security advisory, SolarWinds says it is not aware of any other code compromise other than the Orion platform.

The product that is impacted by this compromise is Orion Platform versions 2019.4 HF 5, 2020.2 with no hotfix installed, or with 2020.2 HF 1, including:

  • Application Centric Monitor (ACM)
  • Database Performance Analyzer Integration Module (DPAIM)
  • Enterprise Operations Console (EOC)
  • High Availability (HA)
  • IP Address Manager (IPAM)
  • Log Analyzer (LA)
  • Network Automation Manager (NAM)
  • Network Configuration Manager (NCM)
  • Network Operations Manager (NOM)
  • Network Performance Monitor (NPM)
  • NetFlow Traffic Analyzer (NTA)
  • Server & Application Monitor (SAM)
  • Server Configuration Monitor (SCM)
  • Storage Resource Monitor (SRM)
  • User Device Tracker (UDT)
  • Virtualization Manager (VMAN)
  • VoIP & Network Quality Manager (VNQM)
  • Web Performance Monitor (WPM)

CISA issues Emergency Directive 21-01, others should follow

As a result of the SolarWinds breach, the Cybersecurity and Infrastructure Security Agency (CISA) issued a rare Emergency Directive 21-01. The clear directive from CISA calls on all federal civilian agencies to review their networks for indicators of compromise (IoCs) and disconnect or power down SolarWinds Orion products immediately.  Anyone with this product installed on their network, public or private organization, should take similar steps to contain this compromise.

Mitigating the threat of the malware compiled in SolarWinds Orion.

Looking at the Indicators of Compromise (IoCs), the domains involved have something in common. Truth be told, they offer little or no value to any audience or application. The primary IoC used in the attack avsvmcloud[.]com has no ranking in Securd’s domain rank system or any open-source third-party domain data set.


Compared to the thousands of websites that we all use daily, these domains have zero utility to an enterprise. These domains don’t drive content, enable applications, or support the SaaS applications we need to do business. The question we must ask is – why do we allow our networks and endpoints to access them?

Back to the well planned & sophisticated attack.

Threat actors often stage domains in advance of a cyber attack. The window of staging time and method varies. However, low-value domains are highly available, and they are cheap and easy digital assets to leverage and discard. It’s not difficult for a seasoned attacker to purchase domains and stand up websites to make them clean and established. When it comes to valuing a domain, traffic and content are kings. Most of these domains do not have either and usually lack many characteristics that come with well-managed websites. The SolarWinds attack is highly disciplined and executed with precision. However, the attack has a major weakness, which is frequent in modern malware attacks. The weakness of the attack is the use of “disposable” domains.

Once we add some context to where the compromise occurs, we end up saying, “wow.” Think about the fact that SolarWinds recommends its software to be installed on a Windows Server. If you add the context of the above domains resolving and connecting from a server, the non-obvious becomes pretty clear. If you got hit compromised by this attack, there is some serious basic cyber hygiene to fix. The attackers made a bet that target systems would 1) allow Windows Server access to the Internet and 2) no protection to defend against access to the primary and secondary IoCs. It’s also highly likely that these attackers already knew this egress weakness existed at their targets through various tests well before the attack plan was exercised.

How Securd helps mitigate the threat when IoCs are not known.

In the SolarWinds case, the domains used in the attack have different histories. For example, the primary IoC avsvmcloud[.]com has a WHOIS creation date of 2018-07-25T11:38:29Z. Relying on a “recently registered” block list would fail. Another method is to take time for a domain to work its way off zero-reputation lists for “behaving” for 90 days. Attackers know one thing to be true; most IoC defensive technologies can only absorb and maintain so many IoCs before their technology suffers a performance hit or technological limitation. How can we deal with some of these tactical issues?

If you look at the command and control (C2) domain from the perspective of suddenly interacting with your endpoints and with weak characteristics relative to trustworthy domains, things change. By forwarding DNS resolution to Securd, your trained tenant-level Greywall would force a delay of resolution that would drop connectivity. Using a zero-trust AND delay combination changes the “rules” of how a C2 resolution will happen. Since the domain has a weak rank in our Graph DNS and it’s a newbie in your DNS asset pool, your endpoints wouldn’t be able to resolve the domain for a day, week, month, or the time of your choosing. Now you have context and time on your side to help defend against an attack. Read more about how our Greywall process works.

It’s time to reduce the attack surface and threat actor opportunity space.

There will be many detailed technical articles about the SolarWinds attack, the compromise, and the code used to execute this attack. There needs to be just as much conversation about basics. If the attackers did not have this cheap and easy asset available, how much harder would it have been for them to succeed? How much more effort would it have taken to achieve the same success? How many more opportunities would have there been to detect and mitigate the threat? We do know one thing for sure; less is more. The fewer domains threat actors have available to them to use or resolve, it will take them more time, resources, effort, and mistakes to successfully compromise their targets.