No organization is 100% secure – ever!
As FireEye continued to investigate and identify the root cause of their security incident, they identified a global campaign that introduced a compromise into the networks of public and private organisations through the software supply chain. FireEye identified that this compromise was delivered through a widely used IT infrastructure management and remote monitoring software – SolarWinds.
Although FireEye hasn’t attributed this attack to any particular group, based on several media reports, it is believed that this attack was carried out by a nation-state actor, likely APT29 or Cozy Bear, a Russian Intelligence agency. The threat actor used the SolarWinds Orion software to insert malicious code into legitimate software updates that were used by 18,000 SolarWinds customers worldwide, including some high profile customers like the U.S. Treasury and the U.S. Department of Homeland Security. This malicious DLL (software update package) with a backdoor was then used by the threat actor to carry out further activities on the victim network such as accessing mailboxes or impersonating any user of the victim organisation by forging SAML tokens. This malware is tracked as Sunburst (FireEye), Solarigate (Microsoft) or Dark Halo (Volexity).
The attackers’ post-compromise activity uses multiple techniques to avoid detection and blend into normal activity. Their mission was successful due to limited use of malware to avoid detection by endpoint security products, prioritisation of stealth to obscure their activity and high operational security conducting reconnaissance, continuously clearing their tracks and using difficult to attribute tools. FireEye and other industry experts have concluded that this campaign may have begun as early as Spring 2020.
The Malware(s)
The malware that led to the breach at FireEye was termed Sunburst. The SolarWinds Orion software was injected with malicious code to include a backdoor that communicated via HTTP to third party servers. A digitally signed version of the SolarWinds Orion plugin called “SolarWinds.Orion.Core.BusinessLayer.dll” was the identified malware. For up to two weeks, Sunburst would remain dormant in the victim network, after which it retrieves and executes commands to transfer or execute files, profile or reboot the system and disable system services. The highly skilled threat actor had ensured that the malware traffic could blend in with legitimate SolarWinds activity by initiating the Orion Improvement Program protocol. To learn more about the detailed working of this malware, visit FireEye’s technical details here.
As more organisations and the collective security industry investigated the SolarWinds supply chain attack, researchers have discovered a second threat actor that exploited the SolarWinds software to plan a malware on corporate and government networks. Researchers believe that the second entity is not related to the suspected Russian government-backed hackers. This malware, dubbed Supernova, was disguised as a DLL for the Orion app as “App_Web_logoimagehandler.ashx.b6031896.dll” Security analysts at Microsoft said that this DLL was not signed with a legitimate SolarWinds digital certificate and hence believes this is a separate threat actor from the Sunburst threat actor group who showed a very high degree of sophistication and attention to detail to their operation until then. This malware allowed remote code execution through SolarWinds web application server when installed in a specific location. The infected DLL could receive a C# script from a web request, compile it and then execute it.
Volexity, a cybersecurity company specialising in memory forensics, identified the malware in one of its customer environments, where there were two prior incidents involving separate tactics, techniques and procedures to compromise the victim network. Volexity stated that their investigations carried out is directly related to the FireEye report based on the overlap between command-and-control (C2) domains and other related indicators such as a backdoored server running SolarWinds Orion.
In one particular incident, Volexity observed that the threat actor accessed the email account of a user via Outlook Web App (OWA) service. This led to suspicion as the email account was protected by multi-factor authentication (MFA). Investigating the logs from the exchange server showed that the attacker provided a username and password but was not challenged for a second factor through Duo (a cloud-based two-factor authentication service provided by Cisco). The logs from the Duo authentication server did not contain any login attempts for the account in question, but the attacker had presented a cookie tied to a Duo MFA session. This incident confirms that there were additional attack vectors along with the SolarWinds Orion backdoor in this campaign. You can find the entire article here.
After obtaining access to the victim network, one of the major techniques used by the threat actor was to compromise the Security Assertion Markup Language (SAML) signing certificate using their Active Directory privileges. In an alert published by CISA, they explained that “once this is accomplished, the adversary creates unauthorized but valid tokens and presents them to services that trust SAML tokens from the environment. These tokens can then be used to access resources in hosted environments, such as email, for data exfiltration via authorized application programming interfaces (APIs)”. The “Golden SAML” attack technique was first reported by CyberArk in 2017 and the current attack is the first time that this technique is known to have been used “in the wild”.
Who are the victims?
As the investigation is ongoing, more and more organisations are confirming that they have been a victim of the SolarWinds supply chain attack. According to SolarWinds website, it has a customer base of 425 out of the Fortune top 500 companies in the U.S, top telecommunications companies, all branches of the U.S. military, the Pentagon, NASA, NSA and the Office of the President of the United States, to name a few. However, it is not necessary that all these organisations were using the SolarWinds Orion product that contained the backdoor. It is believed that at least 18,000 of their customers have been affected by this supply chain attack.
As a large number of Orion customers around the world have been infected with this malware, the threat actor had to implement a technique to determine which organization was contacting the attack C2 server to identify the real target for their attack. Security researchers and malware analysts reverse-engineered the malware and identified the domain name generation algorithm of the malware that includes the name of the organization.
Based on this observation, the list of confirmed victim includes FireEye, U.S. Department of the Treasury, U.S. National Telecommunications and Information Administration (NTIA), U.S. Department of State, The National Institutes of Health (NIH) (Part of the U.S. Department of Health), U.S. Department of Homeland Security (DHS), U.S. Department of Energy (DOE), U.S. National Nuclear Security Administration (NNSA), Some US states (Specific states are undisclosed), Microsoft, Cisco, Deloitte, VMware, Intel, Nvidia, Belkin International Inc, California Department of State Hospitals and Kent State university.
In a statement, Microsoft confirmed that they have identified malicious SolarWinds binaries in their environment (which they have isolated and removed) and they did not find any evidence that their systems were used to attack others. In a recent article published by Microsoft, they said “We detected unusual activity with a small number of internal accounts and upon review, we discovered one account had been used to view source code in a number of source code repositories. The account did not have permissions to modify any code or engineering systems and our investigation further confirmed no changes were made. These accounts were investigated and remediated.”
The kill switch
From the detailed technical analysis published, we can see that when the malicious binaries attempt to contact the command-and-control (C2) servers, they will perform DNS resolutions to get the IP address. If this IP address is part of a certain IP range, then the backdoor will terminate and prevent itself from executing again. Microsoft, FireEye and GoDaddy collaborated to create a kill switch for this malware. GoDaddy created a wildcard DNS resolution so that any subdomain of avsvmcloud[.]com resolves to the IP address 20.140.0.1, which belongs to Microsoft and is on the malware’s blocklist. If the DNS resolution resolves to this IP, then the malware will unload and no longer execute.
While this kill switch will disable the Sunburst backdoor connecting to the C2 servers, FireEye has stated that the threat actor may have deployed other backdoors as confirmed by Volexity’s investigation.
What Next ?
Based on several security advisories and technical reports, these are some of the next steps you should carry out if you have SolarWinds Orion software deployed in your environment.
- Immediately isolate any systems running the Orion platform versions 2019.4 HF 5 through 2020.2.1, released between March 2020 and June 2020.
- Scan your premises using endpoint solutions and look for any detection, and in particular Sunburst and Supernova (webshell).
- Perform a comprehensive security sweep to review and harden your physical and cloud infrastructure.
- Upgrade to Orion Platform version 2020.2.1 HF 2 and restore systems once you feel confident with the previous steps.
- Use the Indicators of Compromise to hunt within your logs, telemetry and other SIEM data to give a timeline perspective to any potential intrusion.
Some Indicators of Compromise (IOCs) can be found here. A detailed technical explanation of how it all started is available here:
References:
[2] https://github.com/fireeye/sunburst_countermeasures
[4] https://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html
[5] https://us-cert.cisa.gov/ncas/alerts/aa20-352a
[6] https://www.solarwinds.com/securityadvisory
[7] https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/
[9] https://msrc-blog.microsoft.com/2020/12/31/microsoft-internal-solorigate-investigation-update/
