On December 8th, 2020, US security firm FireEye did a press release confirming that they have been compromised by “Highly Evasive Attacker” that leveraged SolarWinds Supply-Chain vulnerability to hack FireEye and other major US companies. This article will discuss why this particular cyber-attack caused havoc in the industry and also try to unfold the attack’s sophistication.
What is SolarWinds?
SolarWinds is a US-based product used for various purposes based upon specific needs. Some of its uses are as followed:
- Monitoring Network Performance
- Server/Application Monitoring
- Analyze Database Performance
- Service Desk
- Analyzing Bandwidth
- Storage Resource Monitor
- Managing Network Configuration
- Security Event Management
As you might have noticed, SolarWinds covers a wide variety of services. If any threat actor performs a SolarWinds hack, then the whole IT Infrastructure would be at risk. As a result, it might have become a lucrative attack vector for threat actors because of its significant impact on the entire IT infrastructure.
What is Supply-Chain Attack?
A supply chain attack is a unique cyber-attack in which threat actor compromises a vendor and subsequently get access to all customer of that particular vendor. According to an estimate, a total of 18,000 organizations were affected by this cyber aggression.
Tech giants such as AT&T, Microsoft, Comcast were directly affected by this attack. This hack also harmed the US government. The attack is still ongoing, and we will keep you posted as the situation unfolds.
Moreover, threat actors have kept all data on sale on the below URLs:
Public Internet: http://solarleaks.net/
What Exactly happened During the SolarWinds Hack?
We will be discussing the series of events in two phases. The first phase is an executive summary. Also, we will be discussing a detailed analysis.
Executive summary, as its name suggests, will summarize the sequence of events that happened. Afterward, we will do a technical analysis of the SolarWinds hack in detail.
- Threat actors compromised the Orion updates of SolarWinds and backdoored it with malicious code, which FireEye named “SUNBURST.”
- It was a highly evasive backdoor and used multiple techniques to evade detection; hence it remained undetected for quite some time. In addition, updates between March and June 2020 were affected by it.
- After the initial compromise, threat actors did lateral movement and data theft as part of their post-compromise activity.
- While the compromise’s total count is still unknown, an estimated 18,000 public and private sector organizations were affected by this SolarWinds hack.
The SolarWinds hack started when threat actors accessed SolarWinds updates and injected trojonized backdoor “SUNBURST” into the Orion Updates. It is still unknown how this initial compromise happened. There are speculations that it might have been because the SolarWinds Github repo exposed the FTP credentials.
A security researcher from India named “Vinoth Kumar” reported this leak to the SolarWind’s PSIRT team. As a result, the team acknowledged and fixed the issue.
Vinoth reported the leaks on 11-19-2019. SolarWinds claimed that threat actors initially tested their code on 04-09-2019, and the last activity for this test activity was 04-11-2019. However, the threat actors initiated activity was before Vinoth leaked the FTP credentials to SolarWinds. In other words, this timeline of events creates a link.
Researchers suggested that this might cause the initial foothold of threat actors onto the SolarWinds infrastructure.
After gaining the initial foothold, threat actors trojonized the Orion updates of SolarWinds with their backdoor. Since this backdoor was ab digitally signed component of SolarWinds, so it was pretty hard for the threat hunters to detect this activity. Exact DLL responsible for that activity is allegedly “SolarWinds.Orion.Core.BusinessLayer.dll.” It was a digitally signed component of Orion software that contained a backdoor which also communicates with 3rd party servers via HTTP.
This DLL retrieves and executes commands called “Jobs.” These jobs are capable of transferring and executing files. Also, these jobs can profile the system, reboot the machine and disable system services.
Threat actors used various methods to evade detection. Above all, they masqueraded this malware traffic as Orion Improvement Program (OIP) protocol and stored all of their findings within the legitimate plugin configuration files. This step deceived various threat hunting tools as SolarWinds’ legitimate traffic since SolarWinds digitally signed all components under usage. Also, the network traffic was flowing under the hood of SolarWinds OIP protocol.
As detected by Crowdstrike researchers, SUNSPOT was the malware used to inject malicious SUNBURST code into the update packages. As per the CrowdStrike team:
“The design of SUNSPOT suggests StellarParticle developers invested a lot of effort to ensure the code was properly inserted and remained undetected, and prioritized operational security to avoid revealing their presence in the build environment to SolarWinds developers.“
Once the system installs the SolarWinds trojonized update, it executes malicious DLL under the hood of SolarWinds official executables (SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe) based upon the victim system configuration. After that, it resolves a subdomain of avsvmcloud[.]com. DNS response of the query comes back with a CNAME record that points to a Command and Control (C2) domain.
The C2 traffic masqueraded itself as official SolarWinds API communication. As a result, malicious communication went undetected by threat hunters.
Complete Flow of Attack During the SolarWinds hack
As stated earlier, this SolarWinds hack happened in various phases. Threat actors used multiple factors and evasion techniques to maintain access persistent and also keep themselves undetected. Also, threat actors exfiltrated data and compromised the SolarWinds Orion Update during this hack.
We will utilize our understanding by completely summarizing the flow of the SolarWinds hack.
Supply Chain Attack:
Attackers first compromised the Orion Updates of SolarWinds. After that, they injected their malicious backdoor SUNBURST through the SUNSPOT technique. Therefore, they remained undetected. The fact that all this was happening under digitally signed component of SolarWinds also aided their stealthy behavior.
When the software gets downloaded on the victim machine, it starts official executables. Next, the executables turn into load compromised DLLs.
Defense Evasion During the SolarWinds Hack:
The backdoor follows multiple techniques to make sure it stays undetected. For example, using digitally signed SolarWinds components, mimicking its official API call, and using OIP protocol was the most promising technique.
Carrying the attack for a more extended period also aided in their evasion during the SolarWinds hack.
The malware then gathers multiple information regarding the compromised system and its whereabouts. The list of its survey is long, but to summarize, it checks which Anti Viruses, EDRs are running, gathers system information, and moves laterally in the environment to gather business-critical information.
It then stores all of this information into the official SolarWinds configuration directory.
The backdoor then connects to its Command and Control Server. For instance, decision making on which subdomain of avsvmcloud[.]com was partly dependant on the system information gathered in the reconnaissance process. Hence, this makes a unique subdomain every time a compromise happens.
The backdoor then sends its gathered information to the attacking server.
Hands On Keyboard Attack:
Since the backdoor runs commands it receives from attackers, it gave the backdoor a wide range of capabilities to perform various post-compromise activities like credential theft, privilege escalation, lateral movement, etc.
Below is the list of commands that malware was able to perform as per FireEye:
|Exit||1||Terminate the current thread.|
|SetTime||2||Sets the delay time between main event loop executions Delay is in seconds, and varies random between [.9 * <delay>, 1.1 * <delay>]. If the delay is < 300, it is doubled on the next execution through the loop; this means it should settle onto an interval of around [5, 10] minutes. There is a second, unrelated delay routine that delays for a random interval between [16hrs, 83hrs]|
|CollectSystemDescription||3||Profile the local system, including hostname, username, OS version, MAC addresses, IP address, DHCP configuration, and domain information.|
|UploadSystemDescription||4||Perform an HTTP request to the specified URL, parse the results and compare components against unknown hashed values. Format a report and send it to the C2 server.|
|RunTask||5||Starts a new process with the given file path and arguments.|
|GetProcessByDescription||6||Returns a process listing. If no arguments are provided, return just the PID and process name. If an argument is provided, it also returns the parent PID and username and domain for the process owner.|
|KillTask||7||Terminate the given process by PID.|
|GetFileSystemEntries||8||Given a path and an optional match pattern, recursively list files and directories.|
|WriteFile||9||Given a file path and a Base64 encoded string, write the Base64 decoded string’s contents to the given file path. Write using append mode. Delay for [1s, 2s] after writing is done.|
|FileExists||10||Tests whether the given file path exists.|
|DeleteFile||11||Deletes the specified file path.|
|GetFileHash||12||Compute the MD5 of a file at a given path and return the result as a HEX string. If an argument is provided, it is the expected MD5 hash of the file and returns an error if the calculated MD5 differs.|
|ReadRegistryValue||13||Arbitrary registry read from one of the supported hives|
|SetRegistryValue||14||Arbitrary registry write from one of the supported hives.|
|DeleteRegistryValue||15||Arbitrary registry delete from one of the supported hives|
|GetRegistrySubKeyAndValueNames||16||Returns listing of subkeys and value names beneath the given registry path|
|Reboot||17||Attempts to immediately trigger a system reboot.|
Below is the complete graphical representation of attack.
FireEye has shared a list of IOCs (Indicator of Compromise) that can be used to check if your environment was compromised during this cyber espionage. This list includes IPs and Hostnames. Also, the list includes YARA and Snort rules, which should be detected. Click here to learn more.
Lessons Learned From the SolarWinds Hack
This sophisticated cyber-espionage has opened many frontiers of discussion regarding the detection techniques used by an organization’s Incident Response teams. For instance, attackers could mimic themselves as legit SolarWinds traffic hinders the Incident Response team’s strength. As a result, the team could not detect the malicious traffic, block it, and cut off the threat actors’ communication paths. It also limits their capability to determine the spread of the attack.
SolarWinds: Single Point of Failure
Most organizations completely trust traffic of management tools like SolarWinds. Therefore, they make the SolarWinds a vulnerable point of attack and a single point of failure. Also, this means that threat actors that hack into SolarWinds are putting the whole organization at risk.
Above all, the SolarWinds breach has taught us many lessons. For instance, we should revise our practice of blindly flagging every traffic from specific tools as “Trusted”.
Also, we can take the steps discussed below to avoid any security breaches.”
Consider Assume Breach:
When your internal team reviews network traffic as per their usual routine, always consider assuming a breach scenario. This approach will not only push the SoC teams’ limit and visibility to the next level, but also analysts will be able to discover undiscovered routes that a threat actor could take. Also, when you’re considering assume breach, you’ll not “trust” some traffic instead, you’ll review every traffic to its core.
Cut off the chatter:
Most malware will make outbound connections with their Command and Control server once they are in the corporate environment’s data center. The server will further instruct them to do various tasks like exfiltrate data, encrypt data, send decryption keys, send environment-related information etc.
Above all, you should always analyze your outbound traffic. If there are some unusual connections to unusual remote ports, this is a red flag that something under the cover is happening.
Indeed, cutting off all outbound connections can limit most malware impacts.
Stop Lateral Movement:
Another common post-compromise step of any malware is Lateral Movement in the environment. Above all, it is essential for any threat actor to achieve its maliciousness as it helps them analyze their whereabouts. Therefore, this can be a very vital “Stop” switch.
Also, Zero Trust architectures should be followed for corporate Data Centers. Furthermore, Least privilege access and proper network segmentation should also be followed.
In conclusion, these basic security measures can help any organization fight against SolarWinds hacks. Also, this steps can improve security posture. Indeed, all we have to do is just stick with the basics.