Could Kaseya VSA supply chain ransomware attack have been prevented?

The background story is that despite the existence of the Kaseya vulnerability, a decent endpoint security solution could have provided better outcome. Because in the worst case, the malware could have been installed, but the security solution would have prevented its execution - and thus also the encryption of the endpoints.

The media recently reported that a hacker attack via IT service provider Kaseya affects thousands of companies.

zdnet.com reported “attackers managed to compromise the vendor's software to push a malicious update to thousands of customers. (…) an estimated 1,000 companies have had servers and workstations encrypted. The vendor added that it is reasonable to suggest "thousands of small businesses" may have been impacted. (…) The cyberattack has been attributed to the REvil/Sodinikibi ransomware group who have ties to Russia, which has claimed responsibility on its Dark Web leak site, "Happy Blog."”.

This shows that the attack hit companies of all sizes, as well as across multiple verticals. So, irrespective of the budget or vertical, everyone is vulnerable.

At the time of an attack in a zero-day exploit - i.e. a targeted exploitation of a known or unknown vulnerability in a piece of software - we know nothing about the attack tactics or the attack vectors. But we know that we have to protect ourselves against the unknown. Therefore, I am not so much concerned with the vulnerability in the Kaseya infrastructure per se, but rather with how we can successfully prevent the exploitation of all vulnerabilities and thus allow companies to be secure.

Through a simplified summary of the somewhat complex process I would like to show where DriveLock solutions could have helped to avoid the attacks.
For the following sections I refer to the Sophos News website.

REvil was able to deploy and run its dropper locally to all customers’ endpoints without testing through the Kaseya agent. Certain directories on the endpoint are deliberately and intentionally ignored by the Kaseya agent through exclusions. This opened the way for a malicious payload agent.crt file to be written to the VSA agent's working directory for updates. After deploying the payload, the Kaseya agent then executed the following Windows shell commands concatenated into a single string:

source >>>

• The ping first initiated a kind of countdown of about 94 min before it started.
  
  
• The next part of the command string is a PowerShell command that attempted to disable the most important malware and anti-ransomware protection features of Microsoft Defender.

• The malicious payload file agent.crt was decoded and written to the executable file agent.exe in the Kaseya working folder. The files were then deleted, covering the tracks.

• Finally, Kaseya agent.exe was launched (with system privileges) - and the actual dropping of the ransomware began.

• agent.exe copied the unexpected msmpeng.exe file and also dropped a malicious file called mpsvc.dll along with the msmpeng.exe executable. msmpeng.exe is an outdated and expired version of Microsoft's Antimalware Service executable. This is a benign but vulnerable application of Windows Defender.

• This version of msmpeng.exe is known to be vulnerable to side-loading attacks. In this side-loading attack, the malicious code mpsvc.dll was inserted into a dynamic link library (which is required by the executable msmpeng.exe) in the same folder where msmpeng.exe was copied into. Agent.exe then ran msmpeng.exe which invoked the malicious mpsvc.dll file and loaded it into its own memory space.
  
  
• Once the DLL was loaded into memory, the malware deleted it from the hard drive.
  
  
• The msmpeng.exe, now under the control of the malicious mpsvc.dll, began to encrypt the local hard drive, attached removable drives and mapped network drives, all from a Microsoft-signed application that is normally trusted by security controls to run unhindered.

DriveLock Application Control can prevent the execution of the msmpeng.exe file. This application would never have been part of the whitelist and thus the DriveLock module would have denied execution.

DriveLock also includes out-of-the-box "Microsoft blocking rules" where it blocks old versions such as BGinfo.exe because they contain vulnerabilities. In exactly the same way, DriveLock would have blocked the old MSPENG.exe via blacklisting, or only allowed current versions of this application.

If at any point the attack is based on attackers deploying their own binaries (exe or dll) to run, then they too will be blocked because they are not whitelisted.

Likewise, the loading of DLLs can be controlled and monitored with DriveLock. Thus, no program would have loaded mpsvc.dll.

Even if these mechanisms would not have worked, DriveLock Application Behavior Control can learn the normal behaviour of a program and block all deviations from the norm after the learning phase is complete. This means that if a program did not start the application msmpeng.exe (or PowerShell et al.) during the learning phase, it will not be able to do so afterwards because this would be a deviation from the learned behaviour, even if the administrator has never heard of this application - this is protection against the unknown!

Think of Application Control as a guest list. Only those on the list are allowed into the party. Think of Application Behaviour Control as a code of conduct. Unwanted behaviour is suppressed, even if the guest is already at the party.

DriveLock also manages Microsoft Defender Antivirus with its Native Security Module. A response as a result of a DriveLock EDR rule would have immediately restarted Defender Antivirus.

• However, the ransomware did even more. It ran a NetShell command (netsh) to change the firewall settings so that the local Windows system can be detected by other computers on the local network (netsh advfirewall firewall set rule group="Network Discovery" new enable=Yes). Then it started encrypting files.

Again, DriveLock's new Native Security feature for managing the local firewall detects an event and can enforce the DriveLock policies to set the firewall settings in response! Other endpoints in the corporate network would have remained undetected and the lateral movement would not have occurred.

As you can see, with all the measures mentioned, we are really talking about a layered protection mechanism. This is why the deployment of the DriveLock Zero Trust Platform is so important.

DriveLock combines the elements of Data Protection, Endpoint Protection, Endpoint Detection & Response.