Hackers as Cloud Customers
How SolarWinds Hackers used AWS and Azure
Part of my blog series on the SolarWinds Breach and Data Breaches.
Free Content on Jobs in Cybersecurity | Sign up for the Email List
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.
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*MSXA7tgibx8LSFWhKdrGcA.png)
The attacker breached the SolarWinds update system
The attackers inserted malware into the SolarWinds product by inserting code into the SolarWinds update server.
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*JVhNehlbX0sGm6HatNGBzQ.png)
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.
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*EuZePUckM5rb0sBzWfDz4A.png)
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.
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*F7G4X1VAHbe2LE7796Pc2A.png)
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.
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*xQNhrk2iNAqSW7Dx5eVi2Q.png)
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.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2021
The best way to support this blog is to sign up for the email list and clap for stories you like. That also helps me determine what stories people like and what to write about more often. Other ways to follow and support are listed below. Thank you!
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
Author: Cybersecurity for Executives in the Age of Cloud
Presentations: Presentations by Teri Radichel
Recognition: SANS Difference Makers Award, AWS Security Hero, IANS Faculty
Certifications: SANS
Education: BA Business, Master of Software Engineering, Master of Infosec
Company: Cloud Penetration Tests, Assessments, Training ~ 2nd Sight Lab
Like this story? Use the options below to support this blog.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Clap
❤️ Referrals
❤️ Medium: Teri Radichel
❤️ Email List: Teri Radichel
❤️ Twitter: @teriradichel
❤️ Mastodon: @[email protected]
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
❤️ Buy a Book: Teri Radichel on Amazon
❤️ Request a penetration test, assessment, or training
via LinkedIn: Teri Radichel
❤️ Schedule a consulting call with me through IANS Research
Cybersecurity for Executives in the Age of Cloud
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/0*H9Ew1KCl-29nZiPR.jpeg)