Teamwork for the Win: A Technical Breakdown and Response to the Kaseya Attack

On Friday, July 2, the cybercartel REvil launched a supply chain attack on Kaseya VSA servers that reached scores of Managed IT Service Providers (MSPs), hundreds of their clients, and enterprise Kaseya users, spanning at least 17 countries. In keeping with the working model we have seen emerge in 2021, REvil first leveled the high profile JBL ransomware attack, gaining notoriety, and immediately followed with an even bigger attack, covering a broader scale and with much higher stakes. AKA $70m in ransom demands. It is predicted that with the “corporatization” of hacking group working models, we are likely to see this trend continue– one high profile attack followed by a more far-reaching, higher-stakes attack. We will explain why over the coming weeks. This week, our Senior Incident Response Engineer, Kerry McQuarrie, is giving you a breakdown of everything you need to know about the Kaseya attack. Maybe you’ve been affected, or maybe you have a penchant for voyeuristic observations of the carnage. Either way, you’re sure to learn something. Then, in the coming weeks we will interview Kerry and other experts to explore broader trends that merit a mid-year update to the way people are currently thinking about ransomware – and how we can work together to create safer, more secure business communities.

Anatomy of the Attack

1. This Was an Exploit, Not an Injection

   When you hear the term “exploit”, you can automatically distinguish an attack as opportunistic, versus an injection. In this case, attackers took advantage of an existing vulnerability in the software that, because of the function of Kaseya servers as enabling remote management of IT environments, created a supply chain attack that could spread to software end-users and, in some cases, their clients. Kasey VSA Servers commonly deploy software and automate IT tasks (like SCCM servers). Exploit of these VSA servers means bad actors can also exploit any attached clients. There is no evidence, however, that Kaseya’s infrastructure was compromised in the process.

   Multiple flaws appear to have been exploited in this smash-and-grab attack (meaning attackers were not in systems long-term):

   • Authentication bypass
   • Arbitrary File Upload
   • Code Injection

   Because they were able to bypass authentication, attackers started an authenticated session during which they gained direct shell access to the Kaseya database on the VSA servers. Interestingly, there is no evidence of data exfiltration during this attack. That is a departure from the rash of recent attacks we have seen this year, in which attackers not only unleash ransomware, but exfiltrate, advertise, and threaten to publish an organization’s sensitive data. Apparently in this case, $70m was enough of a motivator to go for a quick win, instead. Of note here is a message of caution to all software, hardware, and technology service providers, as well as enterprise IT teams responsible for managing sprawling, connected environments.

   If you fear you have been compromised, you can access the check and mitigation tool here: https://github.com/Truesec/Kaseya-CheckandMitigate

2. Breakdown of the Exploit Lifecycle – AKA, A voyeuristic chance to be thankful this wasn’t YOU

   Code executed by bad actors on Kaseya VSA servers triggered the following procedures on computers managed by the VSA servers:

   1. Deletes log files: IIS, database log files
   2. Disables core malware and anti-ransomware features of Windows Defender (real-time protection, script and download scanning, etc.)
   3. Uses certutil to decode agent.crt (previously uploaded by attackers) to agent.exe
   4. Newly decoded agent.exe is executed and drops two files:
   • MsMpEng.exe: legitimate (but outdated and vulnerable to side-loading attacks) Windows Defender binary that is used to sideload the second, malicious file
   • Mpsvc.dll: REvil ransomware
   5. MsMpEng.exe is executed and triggers the load of mpsvc.dll, executing the REvil ransomware in the context of MsMpEng.exe
   6. Encryption begins…
   7. Local firewall is changed to allow the infected system to be discovered on the local network by other computers…chaos ensues
3. Indicators of Compromise (IOCs) – AKA, Wait, could I be in trouble, actually?

   For anyone affected by this exploit, you will find these key signs:

   1. The following files were uploaded to VSA server by bad actors:
      • agent.crt
      • screenshot.jpg
   2. IOCs for these files can be found in Kupload.log, unless it has already been wiped by bad actors or encrypted by ransomware.
   3. The following UP addresses are associated with the incident:
      • 18.223.199.234
      • 162.253.124.162
      • 161.35.239.148
      • 35.226.94.113
   4. MsMpEng.exe and mpsvc.dll are dropped in C:\Windows on the endpoints
   5. VSA procedure used to deploy the encryptor was named “Kaseya VSA Agent Hot-fix”
   6. User agent: curl/7.69.1
   7. AWS IP addresses using curl to access the /userFiterTableRpt.asp
   8. Uses legitimate Windows Defender for sideloading malicious DLL
   9. 18.223.199.234: IP address present in the POST indicator request.
   10. jpg uploaded as part of the attack chain. Not a JPEG image file, but executable code that disables existing user sessions, removes IIS logs, and other cleanup activities. A large portion of the code is removed, so finding the specific file, or even fragments, is difficult.
   11. Mpsvc.dll Sodinokibi DLL creates the registry key HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\BlackLivesMatter on the endpoints
4. Lesson Learned – AKA, Hurry up and literally go through this checklist…As in right now.
   
   1. Remind yourself that BREACH HAPPENS…and it can happen to anyone.
   2. Supply chain attacks WILL happen, and you are in the chain somewhere. We all are. Does your supplier (or do you, if you ARE the supplier) participate in programs like bug bounties? Find out.
   3. Set aside what you are doing in light of the current landscape, and focus on:
      1. Minimizing your risk of a breach
      2. Reducing recovery time subsequent to breach
      3. Preparing a response to various breach scenarios (Incident Response Plan)
   4. Breach preparation is key.
      1. Who will you contact first in the event of a breach? Hint: outside legal counsel should be your first contact.
      2. How will you notify your organization, clients, etc.? Failure to disclose a breach can lead to legal issues, longer recovery time, compliance fines, etc.
      3. Have you conducted a risk analysis of your environment?
      4. Do you have an inventory of your systems so you can prioritize assets in the event of a breach?
      5. Do you have a breach response plan in place?
      6. Are you regularly testing and updating your breach response plan via tabletop exercises?
      7. Are your backups safe? Do you have current copies of your backups in offline (air-gapped), secure storage?
      8. How will you preserve your data (evidence) in the event of a breach investigation can be performed? This can be key in determining how bad actor accessed your infrastructure.
      9. Who will you contact to conduct the breach investigation?
   5. In light of the recent supply chain attacks, including Kaseya, a zero-trust methodology is key. Implement that asap. If you need help, contact us.

   In Conclusion, The Silver Lining

   Contrary to how major compromises have been approached in the past, the IT and IR community came together across industries, without regard for competition, to assist organizations with remediation. We saw cybersecurity professionals who on paper would be competitors working side-by-side. We need so much more of this. We’re all in it together, working to protect our economy, our communities, the security of our cities and infrastructure. Collaboration and a team approach are what forward thinkers have been calling for in recent years– more collaboration, approaching security threats as a community where everyone is stronger. We can save competition for tomorrow. Today, we need to be working together. As our founder, Jerald Dawkins, PhD, likes to say, “Security is a team sport.”