�Ӱɴ�ý

For many of us in the Managed Services Provider market, we were rocked with news of a vulnerability in . The purpose of this blog is to shine technical light on what the �Ӱɴ�ý ThreatOps team observed and analyzed thus far. For official Kaseya guidance, make sure you reference their �����Ի��� (kudos Kaseya Security Team on the discovery and quick response efforts!)

Background Information

Over the last few weeks, our team uncovered dozens of suspicious Scheduled Tasks used to execute a persistent payload with Local System privileges. When run, the footholds launched PowerShell to run Base64 encoded files stored within the Windows Registry and on Dropbox hosted domains. The original script used to infect the hosts looked like this:

Monitoring for PowerShell Execution

As illustrated above, a persistent foothold is established with a single PowerShell command that downloads and executes the PowerShell script at:

• hxxps://dl[.]dropboxusercontent[.]com/s/namkbc37wtx2mdq/reg_load_subsequent.ps1

When run, the script first validates whether its payload is already running. To do this, it gathers the list of running processes and won’t execute any further if more than one PowerShell process is already running.

As silly as it sounds, this particular threat could be temporarily “immunized” against by running two or more long running PowerShell processes :)

Choosing and Storing 32 and 64-bit Payloads

When delivering malware to victims, some attackers take the time to make sure their payloads match the same architecture of the compromised systems. In this case, the following code performs this check:

For those unfamiliar, the attacker chose to measure the size of an . If the size is 4 bytes (32 bits), the malware downloads the content of the x86 payloads from the appropriate URLs (notice they end in _32.txt). If the structure is any other size, it assumes the host is a 64-bit system.

With this payload data, the malware stores the contents within several registry key values along with another heavily obfuscated PowerShell script. The data was stored within the following paths:

• Key: HKLM\SOFTWARE\Microsoft\Powershell\Scripts | Value: a
• Key: HKLM\SOFTWARE\Microsoft\Powershell\Scripts | Value: b
• Key: HKLM\SOFTWARE\Microsoft\Powershell\Scripts | Value: c
• Key: HKLM\SOFTWARE\Microsoft\Powershell\Scripts | Value: d
• Key: HKLM\SOFTWARE\Microsoft\Powershell | Value: ScriptInit

Scheduled Tasks Configurations

As mentioned earlier, the infection script leveraged scheduled tasks for its foothold. Many attackers use schtasks.exe and its  to create/configure tasks to run:

• the desired payloads
• at expected intervals
• with specified privileges

However, this actor decided to create the scheduled tasks from an XML template that’s also downloaded from DropBox.

Hiding Scheduled Tasks in Plain Sight

Rather than simply create a scheduled task with a hard-coded name, the infection script cleverly generates a “random” name. It does this by combining the path and task name of two legitimate, randomly selected scheduled tasks with the following code:

To better illustrate how this works, let’s use these examples as the randomly selected scheduled tasks:

• \Microsoft\Windows\UPnP\UPnPHostConfig
• \Microsoft\Windows\SettingSync\BackupTask

The above code splits each of them into a “task path” and “task name”:

• Task Path #1: \Microsoft\Windows\UPnP
• Task Name #1: UPnPHostConfig
• Task Path #2: \Microsoft\Windows\SettingSync
• Task Name #2: BackupTask

Now the script joins the second task path to the first task name to create a scheduled task name that easily hides in plain sight from human analysis:

• \Microsoft\Windows\SettingSync\UPnPHostConfig

With this custom task name and the downloaded XML template, the infection script executes schtasks.exe with to create the malicious scheduled task.

schtasks /CREATE /XML $file /TN “$fullTaskName” /F

Updated PowerShell Code

On the evening of January 29th, 2018, the attackers updated the PowerShell command described in this blog to evade Kaseya’s Automated Removal Procedure.

Most notably, the registry key path and value name were updated from:

• Key: HKLM\SOFTWARE\Microsoft\Powershell\Scripts | Value: *
• Key: HKLM\SOFTWARE\Microsoft\Powershell | Value: ScriptInit

to:

• Key: HKLM\SOFTWARE\Microsoft\Policies\System| Value: *
• Key: HKLM\SOFTWARE\Microsoft\Policies| Value: Start

This caused Kaseya’s initial Automated Removal Script (XMR.xml) to no longer delete all of the malicious registry key values.

Unfortunately, the attacker designed this change to prevent any new Scheduled Task based footholds from being removed as the original “signature” matched on the presence of “ScriptInit” within the command’s arguments (which is now “Start”).

Lastly, the attacker got extra crafty and decided to backdoor one of Microsoft’s legitimate Scheduled Tasks: “sihboot”.

Using the Scheduled Task XML template from the URL above, the attacker added an extra  which once again runs the malicious PowerShell payload:

 from Kaseya has already updated the official �����Ի���.

File & Script Takedown

To help mitigate the impact of these payloads, the �Ӱɴ�ý ThreatOps team has coordinated with Dropbox to remove the following malicious URLs

On the afternoon of January 30th, 2018, the Dropbox team took these suckers down :)

If you’d like to analyze these files and scripts for yourself, drop us a line at support[at]huntresslabs.com and we’ll gladly send them your way.

Curious if You’re Still Compromised?

We offer a  of �Ӱɴ�ý for an unlimited number of computers. Simply deploy our agent, setup a reporting integration into your ticketing system, and we’ll deliver step-by-step remediation procedures for each compromised host we discover. When the trial ends, our team can remotely uninstall our agents with a single click (no extra cleanup). Contact sales[at]huntresslabs.com for demos and more details :)