Rogue ScreenConnect Toolkit SCKit Targets 288 Hosts in Rapid Attack, Huntress Reveals

In a recent investigation, Huntress researchers uncovered a swiftly executed cyber campaign that exploited cloud-hosted ScreenConnect panels. This campaign led to the installation of unauthorized clients and a custom toolkit, named SCKit, across managed endpoints. During a mere 90-minute window on November 11, a staggering 288 hosts within 48 organizations protected by Huntress fell victim to this attack, with about a third of those compromises occurring within the first ten minutes of the incident.

The attackers employed a sophisticated strategy that circumvented direct exploitation of endpoints. Instead, they leveraged the legitimate Run Command feature of ScreenConnect to initiate commands as SYSTEM across numerous machines concurrently. This tactic enabled them to silently deploy an attacker-controlled ScreenConnect client on the compromised devices. Following this stealthy installation, a dropper was executed that fetched a decoder along with an encrypted 16-file package comprising PowerShell, batch, and configuration files. Notably, each file package was encrypted with keys linked specifically to the individual machine’s ID, further complicating efforts to counter the attack.

Disguised in Routine ScreenConnect Activity

At the heart of the SCKit toolkit lies a component known as RelayTrap. This component adeptly hijacks the legitimate client’s connection slot on the relay, ensuring the infected machine maintains an appearance of health to the managing technician. In addition, the toolkit performs several critical actions: it halts the genuine client, changes its status to manual start, establishes exclusions for Microsoft Defender, creates AppLocker/SRP rules, and sets up a scheduled task named TrapWatch to ensure long-term persistence on the compromised system. Furthermore, the attack introduces a second client controlled by the attackers.

A particularly concerning aspect of the SCKit toolkit is its built-in logic designed to facilitate the spread of the malware from an infected endpoint to any technician that connects to it. Theoretically, the malware is capable of capturing the technician’s .aspxauth session cookie and replaying it against the ScreenConnect panel. This would enable it to enumerate accessible sessions and upload a malicious payload to the panel’s Shared Toolbox, executing it as SYSTEM on other machines, albeit with the toolbox item being deleted approximately 60 seconds after execution.

Huntress emphasizes that this analysis of the worm-like behavior of the toolkit was largely inferred from the code. It is critical to note that during the review of logs from recovered hosts, the attempt to take over technician consoles failed on every occasion. As such, the firm has not verified any successful transitions to technician workstations or further endpoints.

In response to this alarming situation, ConnectWise issued an advisory on the evening of November 11, taking precautionary measures by disabling five third-party extensions across more than 400 partner environments. However, at the time of the advisory, the complete scope of the attack and the initial access vector had yet to be determined. The affected version builds identified by the investigation were 26.6.6.9747 and 26.7.6.9783.

Guidance for Defenders

In the wake of these findings, Huntress provided specific recommendations for defenders to mitigate the risks associated with the SCKit toolkit. These guidelines include:

1. Review Command Histories: Organizations should examine the Run Command and Toolbox histories in ScreenConnect for any commands that were not initiated by authorized personnel. Furthermore, endpoints must be scrutinized for the presence of any unauthorized clients.

2. Isolate Suspect Hosts: It is crucial to triage any suspicious hosts out of band using EDR live response or WinRM, rather than ScreenConnect. Technicians who have connected to potentially infected machines should be regarded as exposed.

3. Clean Affected Hosts: Affected systems should be isolated and cleaned meticulously, including the removal of the rogue client, the TrapWatch task, the directory located at C:\ProgramData\RelayTrap\, any SCKit files found in %TEMP%, and the RelayTrapLiteAlert Run key.

4. Manage Active Sessions: Active sessions on ScreenConnect should be terminated, and credentials rotated immediately, with particular attention paid to revoking browser and identity-provider sessions.

5. Utilize Network IOCs: Leverage network indicators of compromise (IOCs) provided in the report, but treat file hashes as weak indicators, knowing that scripts can be rebuilt per host.

The comprehensive research conducted by Huntress underscores the urgent need for enhanced vigilance among organizations that utilize ScreenConnect. For further details, the full Huntress report can be accessed here.

This alarming incident reveals a novel and concerning method of attack that highlights the importance of cybersecurity measures and the need for constant vigilance in a rapidly evolving digital landscape.

Source link