Security insights from ThreatLocker
On a quiet day, security is a challenge to digest. The list of latest breaches seems to never end. Cybersecurity professionals are expected to digest and implement a plan for the various landscapes of threats, however, it’s virtually impossible to keep up with them.
When you run software on your computer, it can access all applications, data, and resources that you have permission to access. Software is typically a combination of executable files and libraries (DLL files).
Software tends to run as an authorized user. This could be a system or service account or a normal user. When the application is running, it assumes all of the rights of the user. it’s highly likely the Orion software also included login accounts embedded in its configuration to grant additional access to monitored systems.
Software-driven breaches often start with one of two methods:
During the Orion breach, the malicious software originated from a vulnerability in the code. This attack is unique because it did not result from a bug in the code. Instead, it stemmed from a malicious actor who altered the code at the source. The attacker injected code that opened a backdoor, known as the Sunburst Backdoor. From there, SolarWinds published the update to their customers, and the patch was downloaded as expected.
Notwithstanding that the backdoor was intentional, the use of backdoors in code is not uncommon in cyberattacks, and software vendors release hundreds of patches to fix them every year.
In this case, the backdoor was part of the SolarWinds.Orion.Core.BusinessLayer.dll library and was loaded into SolarWinds.BusinessLayerHostx64.exe service. ThreatLocker has reached out to all clients running this DLL to advise them on the risks.
The backdoor came with a timed release, making it difficult to detect while testing. As a result, SolarWinds and FireEye could not detect it. After a certain period of time, the code in the DLL reached out to a server on the internet to get instructions. Prior to contacting the server, the code verified the country of the server to avoid triggering any alarms and only communicated with attack servers residing in the same country.
Once activated, the malicious code sought instruction from the attackers. From there, the Orion software appeared to use a few different attack metrics. Essentially, the process would launch "Attack Jobs." The jobs ranged from disabling Windows services, profiling the system, and copying and executing files, or swapping out applications that are scheduled in the Windows Scheduled tasks. The attack also ran malicious code in memory.
While we don't expect federal agencies to disclose the full damage for several years, it’s likely the attack methods allowed extensive lateral movement and potential data collection throughout the affected environment. There is also the potential for RSAT tools being used to allow further remote access or ransomware attacks.
How can you stop these types of attacks?
No two vulnerabilities are the same. Whether it’s an intentional backdoor or accidental bugs, vulnerabilities often leave open doors in organizations. In this case, the patch caused the vulnerability. Normally, patching your system protects you from vulnerabilities.
Most antivirus software will not prevent this attack from running, as the initial malicious code is buried inside the Orion application. However, it might help detect malware that is created by the application.
There are steps you can take to significantly limit the damage caused by these types of attacks. First, all systems should run under a least-privileged user account at all times. Do not give your users or service accounts more access than they require to perform their function. While it might seem convenient to grant privileged accounts to monitoring tools that require a lot of access, it’s safer to grant the minimal access needed to function properly.
Monitoring tools like Orion often need connections to servers and resources, however, they don’t require untethered access to the internet. It’s straightforward to block outbound internet traffic from your servers and permit exceptions. If the application could not seek instruction from the remote server, it could foil this type of attack. As a result, egress of data would be prevented as there would not be a path for the data to exit.
It’s critical to understand that an application has access to everything the user account has. Ringfence™ your applications to limit what those applications can access. Ringfencing an application can block it from interacting with other applications like PowerShell, stop it from accessing network resources or the internet, and restrict it from copying or modifying files. If you Ringfence™ applications, you have granular control over what can be accessed.
Injecting code into an application can allow it to cause a lot of damage. If you stop applications from calling tools like PowerShell and accessing your files, you prevent lateral movement and further damage.
Adding additional monitoring and alert tools goes a long way in preventing breaches. When combined with Application Whitelisting, you stop breaches that would normally occur as a result of permitting untrusted software to run.
Are other tools susceptible to these types of attacks?
Any application can be compromised. Once this happens, significant damage can be caused as a result of malware, weaponization of built-in tools, data extraction, and file encryption.
You should limit the number of applications permitted to run in your organization to the smallest amount. Every time you permit software, you increase your surface area of attack.
Monitoring tools and RMM tools are prevalent entry points. These tools are often exploited to become mass distribution ransomware or are used as data extraction tools. Sometimes, a compromise begins as a result of a vulnerability, a weak username and password, or compromised API keys. It’s best to ensure your applications can’t push any software out without checks and balances like Application Whitelisting. In order to stay ahead of cyberattacks, reduce access at a user and an application-level wherever possible.