Unpacking SolarWinds

This is by far the most significant cybersecurity moment in our lifetime. Most of us are in the same boat, worried and reviewing our infrastructure for any incidents. Some of us might not even be a direct customer of SolarWinds, yet we have to review to ensure nothing made through other software products I use in our infrastructure.

At Araali, we spent a lot of time researching the breach, so we wanted to share a quick summary of what we have learned.

The attack was extensive as it leveraged the “supply chain attack” vector (mitre) where an adversary compromises an application software before receipt by the end customer. This is not a very common attack vector but has a large blast radius if the adversary is successful. In the case of SolarWinds, it impacted as many as 18,000 customers.

The attack was so well executed that it went under the radar for some of the top firms, including consulting, technology, telecom, and governments in North America, Europe, Asia, and the Middle East.

Attack Progression as reported by FireEye

  1. The payload remained dormant for a while and then used the SolarWinds protocol to hide network traffic as it scanned and collected information on the infrastructure.

  2. Then it resolved a subdomain avsvmcloud(.)com to get CNAME that pointed to Command and Control domain.

  3. It used the backdoor to deliver a malware called “Teardrop” that loads in memory without any trace on the disk.

  4. The attackers used file replacement technique where they modified legitimate file and after use replaced it with the original one (If you examine logs, you can find “delete-create-execute-delete-create” pattern in a short amount of time)

  5. This was a systematic attack, and adversaries might have been able to compromise domain controllers and identity and access management, which might open the flood gates for internal resources as well as partners and customers (B2B companies).

What did we understand from this attack

  1. Adversaries are getting highly sophisticated and are often state-sponsored.

  2. They can get in, but still, they have to move around your network (within on-prem or cloud, and between on-prem and cloud) to get to assets.

  3. Monitoring and ongoing proactive detection are underappreciated and underinvested. It is very costly to clean up once compromised by sophisticated attacks.

  4. Build time software scanning is not enough. We have to focus on runtime security as many software in our infrastructure is not built by us.

How are we approaching this problem

  1. We set our time window to 7 days at a time, starting on Dec 17, and systematically went back in time.

  2. We inspected our network for anomalous connections and C2 activities. Since we protect ourselves with Araali (zero trust) we have detailed networking audits that are very easy to inspect visually for deviation.

  3. We also looked at our cloud logs for any abnormal patterns.

At this watershed moment, we at Araali are offering our full support to any organization looking to get a better understanding of this breach. Please feel free to contact us if you want to discuss any ideas or have questions.

Also, feel free to contact us for 30 days of free access to Araali to scan your cloud infrastructure (AWS, GCP, Azure) k8s or VMs. If you have any ongoing Command and Control channels, we should detect them for you.

May the force be with you!

10 views0 comments


Icons made by Flaticon



39812 Mission Blvd. Suite 224
Fremont, CA 94539 USA

  • White LinkedIn Icon
  • White Twitter Icon