Hackers as Cloud Customers
How SolarWinds Hackers used AWS and Azure
An article by David Jones at Cybersecurity Dive wrote an article about Amazon declining to appear at a Senate hearing on Solar Winds. Lawmakers may want to understand Amazon’s involvement in the SolarWinds Hack. I already explained the steps the attackers took in SolarWinds Hack Retrospective Part 2: What caused the breach and what does the malware do? This post adds some diagrams to show how hackers leveraged AWS, Azure, and SolarWinds. For all the articles in this series on the SolarWinds Hack, see the list of links at the bottom of this article.
The attacker was a customer of the cloud providers
Just like any other customer, the attackers signed up for an account on AWS and Azure. The attackers used AWS to set up C2 infrastructure on Amazon. They used Azure and set up DNS infrastructure to resolve the domain names used by the malware. No AWS customers would want Amazon spying on their business. However, as I explained in my prior blog post, AWS would shut down nefarious activity if they knew about it per their acceptable use policy.

The attacker breached the SolarWinds update system
The attackers inserted malware into the SolarWinds product by inserting code into the SolarWinds update server.

The attackers used AWS and Azure services to carry out their attack
About two weeks after installation at the victim organization, the malware made a request to attacker-controlled domain names. When the malware requested the domain names the DNS servers in Azure returned IP addresses for the C2 servers in AWS.

Then the malware’s requests were sent to those IP addresses for servers on AWS. The AWS C2 infrastructure then knew it had a victim and started sending commands to the malware on the SolarWinds host.

In some cases, the malware obtained credentials on the SolarWinds server that allowed them to take actions in the victim’s Azure account. The SolarWinds servers also had network access to make these Azure calls. So the AWS servers were sending commands to the SolarWinds malware that then executed commands in Azure as instructed.

Azure accounts could have been more securely configured
Asking Amazon to testify, based on what is publicly known, is like asking a cellular company to testify because someone used a cell phone on their network to carry out a crime. AWS would have shut down the malicious activity, had they known about it, just like they shut down Parler for their breach of the AWS terms of service. That said, Amazon may be able to contribute with some explanation of what happened and advice to help stop future breaches.
I explain in my related blog posts why the credentials with high privileges in Azure were a problem and how that might have been mitigated by leveraging Azure security controls.
My last post explained how a better network configuration could have helped and why that is hard.
Of course the root cause is that the malware got into SolarWinds and other products in the first place through weak cybersecurity practices related to deployment systems and update servers.
Be prepared before, not after a breach
My company, 2nd Sight Lab, teaches a multi-cloud security class that covers all three major cloud providers. In that class, students run commands across clouds so they would be familiar with how the attackers carried out this attack between AWS and Azure. That class also explains cloud risk caused by excessive permissions and network access. It explains things you should consider related to deployment system security. We are updating this class currently to cover the SolarWinds breach.
Contact Teri Radichel on LinkedIn if you are interested in an updated version of the class and would like hands-on experience to better understand how attackers carried out the SolarWinds hack.
Teri Radichel — Follow me @teriradichel
© 2nd Sight Lab 2021
____________________________________________
Have a Cybersecurity or Cloud Security Question? Ask Teri Radichel by scheduling a call with IANS Research.

Want to learn more about Cybersecurity and Cloud Security? Check out: Cybersecurity for Executives in the Age of Cloud on Amazon.
Is your cloud secure? Hire 2nd Sight Lab for a penetration test or security assessment.
Need Cloud Security Training? Curriculum: 2nd Sight Lab Cloud Security Training
For a recap of cybersecurity news last week check out the 2nd Sight Lab Cybersecurity News Blog. Malware, vulnerabilities, data breaches, cost of a data breach, cybersecurity laws, and interesting cybersecurity developments.
Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
____________________________________________
Articles on the SolarWinds Hack
SolarWinds Hack Retrospective Part 1: SolarWinds and the big picture for executives
SolarWinds Hack Retrospective Part 2: What caused the breach and what does the malware do?
Zero Trust for Software Updates: Consider network requirements when purchasing products
Hackers as Cloud Customers: How SolarWinds Hackers used AWS and Azure