- Password for update server published accidentally online by SolarWinds in 2019
- Key Orion software available online that enabled attackers to study code in order to create methods to hide
- Exploiting update server easy and highly likely
- Malicious software communicated via HTTP to third party servers, this is easy for any mature SOC to detect
- Malicious software has the ability to transfer files, execute files, profile the system, reboot the machine, and disable system services. Again, easy for any mature SOC to detect and should be huge red flags
- Companies buying from SolarWinds didn’t do comprehensive third party vendor operational security audits
- Leaked passwords on Github can be detected with automated tools
- Malicious software deployed Cobalt Strike Beacons which can be detected https://github.com/Apr4h/CobaltStrikeScan
- Disclaimer: I don’t work in digital forensics and incident response but I have been a professional hacker for over 10 years and ran adversary simulation programs and red team cyber operations for governments and fortune 500 clients.
DHS, FireEye, US Treasury and others were hit by a malicious SolarWinds application that was delivered via the official update server. The so-called advanced attack is probably nothing more than a basic case of accidentally posting a critical update server password online.
Their customer list is quite terrifying when you understand how much network access the threat actors have.
Some context, SolarWinds maintains open source code repositories. This means that a large amount of their source code is available openly and publicly online.
denoting software for which the original source code is made freely available and may be redistributed and modified.
Reports are talking about an advanced supply chain attack, possibly via 365 — I just don’t buy it and here’s why.
On the 19th of November, security researcher Vinoth Kumar reported a security issue to SolarWinds. SolarWinds had published their update server username and password to Github, remember, that is open and public. So effectively they published the update server credentials online, albeit unintentionally.
This is PRIMITIVE #1, we have access to the update server to deliver our malicious version of the software.
We know 100% it was deployed from this server because multiple trojanzied updates were digitally signed from March — May 2020 and posted to the SolarWinds updates website, including:
The C2 traffic to the malicious domains is designed to mimic normal SolarWinds API communications.
Ok so we need to know what to backdoor and how to look like ‘legitimate solar winds traffic’, this part is easy, their code is published openly online.
This is a dev copy of the PowerOrion module for SolarWinds, that is currently being rewritten to be more modular…
This project contains a python client for interacting with the SolarWinds Orion API For documentation about the…
This project contains the samples, SWQL Studio graphical query tool, and PowerShell module for the SolarWinds Orion…
In the repositories we have an abundance of object information, information that an attacker would need to ‘blend in’ to the protocol traffic and source code.
While studying the code and writing similar names and functions to blend it doesn’t make it advanced, it certainly indicates high levels of discipline and attention to detail.
I have included one such section to show how we documented the code is, making it easy for even unskilled attackers.
This is PRIMITIVE #2, we now have most of what we need to backdoor the software — Access to update server, access to code and object information.
But, the code was signed and main code modified which is not on GitHub.
This is where we need PRIMITIVE #3, access to developers and developer infrastructure.
This part is easy and possible in many ways:
- Find exploit on update server and laterally move through the network, possible imho since they use FTP and not SFTP so I assume they don’t know too much about secure systems.
- Backdoor tooling already on server and wait for a developer or development server to pull and run the malicious code. This is most likely.
- Exploit server and dump traffic to collect higher privilege credentials.
There are of course many ways to do this, so I don’t believe PRIMITIVE #3 would be an issue for amateur hackers let alone nation state actors.
With PRIMITIVE #3 we can code sign our update and also backdoor more hard to find/detect parts of the code.
So now we have everything we need to achieve the attack, let’s look at the timelines to see if that makes sense.
The bug was reported on 19th November and issue rectified on the 22nd of November.
First known attack confirmed March 2020, it slept for two months to remain covert so perhaps we can assume January 2020.
This timeline is perfect, even if it was March and not Jan it still would be, access server in November perhaps long before then escalate access, laterally move and monitor. Finally backdoor software and release in January. This is perfect.
In the offensive world we often talk about the least path of resistance, with that said is it likely they exploited office 365 when they already could access the update server? Not to me it’s not. Considering the server that could be accessed is also the server the malicious code was delivered from, coincidence? I think not.
FireEye handled this well, they couldn’t have known this was happening. However, it’s a good idea they start doing in-depth third party vendor operational security audits. I really don’t buy advanced supply chain attack on SolarWinds — I really do think it is this simple, they published password and got hacked. It happens all the time and I don’t see any other avenue here being feasible or even sensible. I bet the attackers are laughing at all these ‘advanced’ hypotheses.
Let’s be honest, if you’re a software company selling to the highest and most sensitive levels of government and you can’t even detect changes to your own source code then you should really re-think your entire approach to operational security.
And btw, sneaking c2 commands into an MD5 hash sent as XML packet is not advanced, everything published by FireEye and independent reporting is red-team 101 — absolutely nothing new.