Summary

The website content discusses how the SolarWinds hackers utilized cloud services from AWS and Azure to execute their attacks, detailing the methods used to compromise the SolarWinds update system and the subsequent actions taken to control affected servers.

Abstract

The article by David Jones at Cybersecurity Dive delves into the SolarWinds hack, explaining how the attackers became customers of AWS and Azure to set up their command and control (C2) and DNS infrastructure. The hackers exploited the SolarWinds update server to insert malware, which then communicated with the attacker-controlled infrastructure. The malware, once installed on victim networks, requested domain names that were resolved by Azure DNS servers to AWS C2 servers, thus establishing a channel for the attackers to send commands. The article also touches on the potential for better security configurations in Azure and the broader issue of weak cybersecurity practices that allowed the initial breach. It concludes by promoting a multi-cloud security class offered by 2nd Sight Lab, which has been updated to cover the SolarWinds breach, emphasizing the importance of being prepared before a breach occurs.

Opinions

The author suggests that AWS and Azure were used legitimately by the attackers, similar to any other customer, highlighting the challenge of detecting malicious activity within cloud services.
The article implies that AWS would have taken action against the attackers had they been aware of the malicious activity, in line with their acceptable use policy, as demonstrated by their response to the Parler breach.
It is noted that Amazon's testimony before lawmakers could provide valuable insights into the breach and offer advice to prevent future incidents, despite the public knowledge being limited.
The author expresses that excessive permissions and network access in cloud environments are significant risks, as evidenced by the SolarWinds breach.
There is an opinion that the root cause of the breach was weak cybersecurity practices related to deployment systems and update servers, indicating a need for improved security measures.
The author promotes proactive cybersecurity education and preparedness, advocating for the multi-cloud security class offered by their company as a means to understand and mitigate such attacks.

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.

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.

Follow for updates.

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!

Get an email whenever Teri Radichel publishes.

Get an email whenever Teri Radichel publishes. By signing up, you will create a Medium account if you don’t already…

2ndsightlab.medium.com

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