What is SD-WAN?
Learn about the capabilities you should expect to find in a full-featured SD-WAN design and how these features operate within the larger Secure SD-WAN architecture.
Futuriom outlines the market trends for SD-WAN in their June 2020 report and provides their predictions for growth and change in the space.
NTT Communications and Versa Networks provide McLaren with reliability, security, stability, and flexible management of their data traffic flows so they can set up a secure, optimized network connectivity in preparation of race weekend.
Learn about the Versa Secure SD-WAN solution in a high-level, one minute overview.
Versa Secure SD-WAN is a single software platform that offers multi-layered security and enables multi-cloud connectivity for Enterprises.
Researchers are still uncovering new details of the SolarWinds hack, with surprising updates emerging every day about how deep the malicious code have penetrated different organizations. This attack is unlike any other previous state-sponsored hacks because the malicious binary seems perfect at first glance with all the approved, digital signatures in place allowing the malicious code to be undetected within an organization’s network for months on end without being discovered.
The growing list of organizations that installed the dubious binary includes but is not limited to FireEye, Cisco, Intel, Deloitte, VMware Inc., and several state organizations. The extend of the attack has reached over 18,000 (Eighteen Thousand) customers who have been compromised, after attackers inserted malicious code into a routine software update.
In a statement from SolarWinds representative, the hacker’s activity has been traced to October 2019 and SolarWinds is now actively working with law enforcement agencies to uncover more details about the incident. Versa’s Threat Research Team has uncovered more details about the hack and how the malicious code was able to stay unnoticed for quite a long time, and why security sleuths need to be more vigilant than ever before.
The SolarWinds attack leaves many unanswered questions and the most prominent amongst them is the question of how the attacker entered internal systems of SolarWinds network and was able to infiltrate and move inconspicuously across the development chain. The malware was able to camouflage its activity among the highly secure network of the prominent organization for an extended period of time, evading all their security detection and prevention defenses. Because of the magnitude of the attack surface, many different threat research teams have published their technical reports on this hack: the prominent one being from Microsoft. In this particular blog, our team will mainly focus on the chain of events that occurred, and the evasive methods employed to remain completely stealthy despite moving around and compromising a highly secure network environment.
There are many reports claiming that the hacker group actively exploited the VMWare platform (CVE-2020-4006) to gain initial entry into SolarWinds’ network but the authenticity of reports is yet to be verified. VMWare has claimed that internal investigation has not revealed any indication of exploitation, which is in line with the investigation carried at SolarWinds. It is still unknown how the attackers have gotten the initial foothold into the SolarWinds network.
Technically, entering an organizations’ network is one small but critical event. Once the network is breached, a backdoor is established to gain persistent control of critical systems within the network (ex: Server Farms, Firewalls), which is the more challenging part of the attack. Compromising systems becomes easier depending on which system is compromised first. In this case (SolarWinds) details are not yet revealed but it very likely that the attacker moved laterally for some time before finding a vulnerable system within the network.
Once the attackers were able to compromise the highly secured SolarWinds network and leverage their software as a supply chain. Attackers were able to insert malicious code in the main development chain and thus multiply the damage and attack surface. Selecting the Orion Platform to exploit, attackers knew that this SolarWinds component was statistically the best way to achieve the highest privileges so it can sniff network traffic and act as spyware.
When a customer updates their Orion Platform, they unknowingly install the malicious code to their internal networks. Exact details about how many organizations installed the update are not yet available. Details about the compromised version are available on SolarWinds Security Advisory.
Since the Orion Platform demanded the highest privileges from the customer network to be able to monitor and parse through their network traffic, the malicious code that was now inserted into customer environments were able to steal data and then send that information back to their command and control (C&C) without raising any suspicions.
Based on the information available and analysis of technical details, it can be concluded that Sunburst Backdoor used the SolarWinds Orion component as a supply chain as well as disabling various Anti-Viruses (AV) and defense platforms to safeguard against detection on targeted systems. If at any point there was a discovery that malicious code was running within the network, that compromised component would be shut down and the attack chain would have ended. If none of the malicious processes were observed, the malicious code would further check for the list of security services running in the network, terminating and disabling any service necessary to be able to move laterally. Further, the malicious code would check that all the drivers associated with the security products and ensure that those programs would be shut down completely.
Here, you can see that the attacker inserted malicious piece of code in DLL component of SolarWinds.Orion.Core.BusinessLayer.dll library under the method RefreshInternal, which executes the method OrionImprovementBusinessLayer.Initialize parallelly so that RefreshInternal is not altered:
A quick go through of the DLL reveals that RefreshInternal is part of the class SolarWinds.Orion.Core.BusinessLayer.BackgroundInventory.InventoryManager and initialized by a series of methods tracking back to the CoreBusinessLayerPlugin class. To conceal the identity, threat actors used terms that would blend easily with the code, instead of using traditional jargon words like backdoor, keylogger, etc. Also, attackers would further obfuscate their activity with strings that were encoded using base64 and their hashes.
The initial entry point on execution checks for several conditions to verify if the code is running in a real environment and to protect the code from being discovered by a security analyst. If any of the below conditions are not satisfied, the backdoor ceases the execution:
The Initialize() method first checks for various pre-execution steps:
Looking through the code, there are two tricks that help hide obvious behavior of the malicious binary:
Under the context of the Update() method, another method UpdateNotification() is called upon which checks for a hard-coded list of processes, services, and drivers.
The list of running processes that are checked includes gdb, Ollydbg, pebrowse64, pestudio etc. among others, which are essentially debugging tools. Designers here have essentially tried to stop further dissection of binary and any attempts to learn code functionality by security researchers.
If none of the listed processes are found, it then proceeds to check for the hardcoded list of services and Registry service subkeys again using a pre-calculated list of hash values. Meanwhile, the code also attempts to disable services, by modifying the Start value in the service registry configuration. If no services and processes from the blacklist are detected or disabled, the code then proceeds to check for installed drivers used for endpoint solutions and monitor the security of the systems like groundling32.sys, groundling64.sys, safe-agent.sys etc. which included a total of 17 drivers list.
Assuming if none of the process, services, and drivers list are found, the code then proceeds to the heart of the execution loop. Before the code proceeds with the request, a final attempt to resolve “api.solarwinds.com” is performed and verified against a pre-set of hardcoded IP and subnets.
10.0.0.0 / 255.0.0.0
22.214.171.124 / 240.0.0.0
fc00:: / fe00::
126.96.36.199 / 255.255.255.0
188.8.131.52 / 255.255.255.0
184.108.40.206 / 255.254.0.0
220.127.116.11 / 255.255.255.0
18.104.22.168 / 255.255.252.0
22.214.171.124 / 255.255.255.0
126.96.36.199 / 255.255.254.0
188.8.131.52 / 255.255.0.0
184.108.40.206 / 255.255.255.0
220.127.116.11 / 255.255.0.0
18.104.22.168 / 255.255.248.0
22.214.171.124 / 255.255.255.0
126.96.36.199 / 255.254.0.0
Before the actual request is sent out, the DNS Query will be sent out against avsvmcloud.com, to resolve the IP address. A note: if the address resolves to a private IP address, then it will be no-op: to make sure the system is not being tested against some lab environment. For example, if the DNS resolves to 87.238.80.X, then the next thread will be created and the HTTP request/response handle from Command and Control will be activated. If the DNS resolves to 10.0.0.0, then it will cease its operation.
Going forward from here, the first request sent to avsvmcloud.com will be a HEAD request having the header “If-None-Match” with the value of md5 hash of the UserID that was created earlier. A few of the fields/values added to HEAD request are listed below:
Wireless / UI
NPM / Apollo
Nodes / Volumes
Interfaces / Components
The response handling code is most complex and yet more damaging as it controls the entire system using various commands. The functionality ranges from staying in IDLE condition (by default), and 17 other additional commands which include EXIT, SetTime, CollectSystemDescription, UploadSystemDescription, RunTask, GetProcess, KillTask, ReadRegistryValue, SetRegistryValue, DeleteRegistryValue, and even the ability to reboot the system using Reboot.
Supply chain attacks are not a new industry term and every organization that leverages software development takes necessary steps to safeguard the critical parts of the development environment. However, the sophistication with which the Solarwinds supply chain has been compromised poses difficult questions for both researchers and analysts. State-sponsored attacks as such, which the primary reports indicate, are extremely complete and difficult to be executed properly, but when done well: can lead to irreparable damage.
Going forward, organizations need to be more vigilant and safeguard their interest through close monitoring of traffic, accounts, and unusual activity. This need for more visibility and control includes any attempts to compromise the network through insiders, or otherwise called “insider threat”. Versa offers robust protection against supply chain threats with product and security modules that are versatile and effective, looking dynamically at threat patterns and leveraging a single-pass architecture for faster detection and remediation. Detection of Lateral Movement could come in handy in detecting propagation of malicious traffic and attempts within the organization, a persistent tactic employed by attackers to proliferate within the network.
For more details about the coverage using Versa, please refer to the set of rules released to detect the adverse traffic here.
Gartner 2020 Magic Quadrant report analyzes the various vendors in the WAN edge market and Versa is positioned as a Leader.