Bishop Fox named “Leader” in 2024 GigaOm Radar for Attack Surface Management. Read the Report ›

What We Know (And Don’t) About The SolarWinds Orion Hack So Far

Up close time on a stopwatch

Share

FireEye made the news last week for responsibly disclosing an incident to the public in which they themselves were the victim. We wrote up an informational piece about what, exactly, was exposed to attackers in the “red team tools” drop, as it was dubbed in the press.

There’s so much information (and misinformation) floating around in the headlines and online within the security community that we wanted to pull together what information has been confirmed and discuss how it could impact businesses going forward. In this post, we’re going to dive into the SolarWinds side of the story, which is the latest news that was released yesterday.

The FireEye breach in the headlines last week was attributed to their third-party software vendor, called SolarWinds, specifically their Orion platform software. Malware was distributed along with ordinary Orion software updates, and actively exploited by some malicious party. That much we know, but we’re firmly within the fog of war on this hack, and it seems like a big deal.

  • What else do we know about the hack?
  • How do we know it?
  • What do we still not know?

SOLARWINDS ORION

If you’re not a professional IT system administrator, you might have never heard of the Orion platform, from company SolarWinds. It’s an IT management stack that describes itself in terms of the “One Ring” from the Lord of the Rings:

SolarWinds description

In retrospect, this metaphor is more telling than it was meant to be. Orion is a highly privileged piece of software that has wide-ranging capability to do most anything on a network. It’s the thing that sysadmins at big organizations use to actually implement changes, get visibility, etc… And just like the One Ring, its influence was twisted by malice. Exploiting this component can give an attacker extremely privileged access into an organization’s internal (almost surely Windows domain) network.

WHO WAS COMPROMISED?

Part of why this is such a big deal is because of who Orion users are. Exploits that affect big businesses come and go all the time, but this one seems different. Users of the Orion platform include a lot of U.S. government agencies: All five branches of the U.S. Military, The U.S. Pentagon, State Department, NASA, NSA, Postal Service, NOAA, Department of Justice, and the Office of the President of the United States.

This according to SolarWinds’ own website:

SolarWinds customers



This customer list has since been replaced by a pug wearing a track suit, but public information indicates that around 18 thousand customers out of their over 30 thousand userbase were expected to have been impacted.

SolarWinds 404 page showing a pug wearing a track suit.

The Orion platform isn’t the sort of thing that some small tech startup uses. It’s meant for large organizations. Targeting it is a bit like targeting the software that runs a Rolls-Royce: there is clearly an intended kind of target behind it and that lets you know something about the attacker.

WAS THIS A NATION-STATE ATTACK? HIGHLY LIKELY.

We don’t know for sure, but it seems highly likely. When these sorts of big hacks come out, there’s usually a chorus of people in the Twitterverse opining that it was so sophisticated that it simply must have been a nation-state actor. And most of the time, it turns out to be a college student just messing around. I’m usually a dissenter to the knee-jerk reactions on calling hacks necessarily a nation-state, so why is this different?

It really comes down to motivation and methodology, not so much “sophistication level.” Any cool hack can look really amazing and sophisticated if you phrase it just the right way, and this one has some of that. The attackers disguised themselves using an existing communication mechanism called the Orion Improvement Program (OIP) protocol, used all-custom software and not just existing malware tools, and make custom forged SAML credentials. All of that is somewhat impressive, but it’s about the level of capability you get from a good pen test. It doesn’t inherently indicate a nation-state in the way that the Flame spyware’s MD5 0-day collision attack did.

The thing that screams “nation-state” to me here is the fact that seemingly no targets were hit with any financial threats, such as a CryptoLocker, and the targets have such a political value. Whoever did this sure didn’t seem to be in it for the money, and it was just too sophisticated and professional to be a casual college student just messing around. FireEye says that the initial indicators of compromise came around Spring of 2020, and the attackers took their time slowly and manually going about lateral movement. That’s not the sort of thing you see from a smart teenager with a penchant for troublemaking; it’s a coordinated team without a profit-motive.

Though when talking about nation-state actors, the first jump is immediately to Russia. It would make some geopolitical sense for it to be Russia, after all. There’s even some reporting out there that states as fact that the hack came from a Russian APT group. This may or may not wind up being true, but isn’t known at this time. Russian officials appear to be denying attribution, but… that’s not worth very much. Even so, I would be cautious before jumping to a Russian attribution just yet.

COULD AN EXPOSED FTP PASSWORD BE THE CULPRIT? VERY UNLIKELY.

There is some reporting that an exposed FTP password might have been the initial entrypoint into the SolarWinds systems. It’s true that this vulnerability did seem to exist back in 2019, so it’s possible, but personally I don’t buy it.

In particular, FireEye made it very clear that the malware present inside the Orion packages were legitimately digitally signed by SolarWinds. This means that the attacker almost surely had some level of access into their buildchain systems, where the signing would happen. The FTP account referenced would only have let someone upload a file to the Akami CDN, but not digitally sign it. I suppose it’s possible that there was some automatic system that would digitally sign any file as it was uploaded to the CDN, but that seems far-fetched.

Additionally, the timelines don’t match. The FTP password was apparently fixed in November of 2019, while new malicious Orion software files were uploaded as late as March 2020.

Perhaps we’ll learn more information in the coming days about the nature of the initial compromise into the SolarWinds system, but it smells to me like someone snuck code into an internal repo. Spearphishing a developer would be a much more plausible explanation (and much more in a nation-state’s M.O.) but we’ll have to wait and see.

WHAT IS THE LESSON I SHOULD BE LEARNING FROM THIS?

I suspect that we might wind up putting greater scrutiny into 3rd party providers of proprietary systems that are critical to business. But it’s not clear that anything especially negligent happened on the SolarWinds side. So, I don’t know what that scrutiny would look like. Perhaps we’ll learn more about this if and when more information about the initial intrusion vector is discovered and disclosed. Right now, it’d be easy to just point the finger at a single cause or vendor, but there really isn’t enough evidence to back that up at this point.

Big takeaways are elusive here. What should a SolarWinds customer have done differently? Not apply updates? That’s not great. Inspect software updates? They were digitally signed and sent over the official mechanism. So, if you’re left feeling helpless and unsure about what to do, that’s probably normal. Until we know more about what went wrong, it’s hard to draw the right conclusion about what to do about it for next time.

Subscribe to Bishop Fox's Security Blog

Be first to learn about latest tools, advisories, and findings.


Dan Petro Headshot

About the author, Dan Petro

Senior Security Engineer

As a senior security engineer for the Bishop Fox Capability Development team, Dan builds hacker tools, focusing on attack surface discovery. Dan has extensive experience with application penetration testing (static and dynamic), product security reviews, network penetration testing (external and internal), and cryptographic analysis. He has presented at several Black Hats and DEF CONs on topics such as hacking smart safes, hijacking Google Chromecasts, and weaponizing AI. Dan holds both a Bachelor of Science and a Master of Science in Computer Science from Arizona State University.

More by Dan

This site uses cookies to provide you with a great user experience. By continuing to use our website, you consent to the use of cookies. To find out more about the cookies we use, please see our Privacy Policy.