Trojanized ScreenConnect installers evolve, dropping multiple RATs on a single machine

Authors: Ilia Dafchev, Eliad Kimhy

• Surge in ScreenConnect abuse: Since March 2025, Acronis TRU has observed an increase in attacks leveraging trojanized ConnectWise ScreenConnect installers to gain initial access to U.S.-based organizations. What we're seeing is a long-term, ongoing trend in RMM tool abuse that continues to draw attackers, perhaps due to how effective it is.

• Evasive ClickOnce installers: Attackers now use a ClickOnce runner installer for ScreenConnect, which lacks embedded configuration and instead fetches components at runtime. This evolution makes traditional static detection methods less effective and complicates prevention, leaving defenders with few reliable options.

• Automated Dual-RAT deployment: Immediately after ScreenConnect installation, attackers use its automation features to rapidly deploy two remote access trojans: the well-known AsyncRAT and a custom, PowerShell-based RAT. This dual deployment may serve as redundancy, tool testing or reflect shared infrastructure among multiple threat actors.

• Custom PowerShell RAT: The TRU team has discovered a new home-made RAT, not seen in open-source repositories, performs system reconnaissance, exfiltrates data via Microsoft.XMLHTTP, and uses several obfuscation techniques. Its unique codebase suggests it was developed by the attacker, potentially to evade signature-based detection.

• Evolving infection chains: Two weeks post-compromise, attackers upgraded their infection chain to use batch and VBS loaders that fetch and execute encoded .NET assemblies in order to deploy AsyncRAT, demonstrating adaptability and infrastructure evolution.

• Social engineering and infrastructure reuse: Malicious installers are distributed using filenames mimicking official or financial documents, likely via phishing. Threat actors also reuse preconfigured Windows Server 2022 VMs (with consistent hostnames) across campaigns, enabling quick redeployment and infrastructure rotation.

• Defensive takeaways: Organizations should closely monitor RMM tool usage and scrutinize ScreenConnect deployments.

Over the past months, Acronis TRU (Threat Research Unit) has identified multiple active and ongoing campaigns leveraging trojanized versions of ConnectWise ScreenConnect to gain initial access to victim networks and compromise target machines. Our research shows that the frequency of these campaigns has increased since March 2025, and at the current moment, most victim companies are in the United States, although currently, there is no indication of where the threat actors are based.

While the use of ConnectWise ScreenConnect to establish an initial foothold is not a new phenomenon, these recent campaigns introduce several changes, such as the deployment of smaller ClickOnce runner installers instead of the full installers. These ClickOnce installers are more evasive than previously observed installers, as they no longer rely on embedded configuration, which in turn offers less opportunities for detection. Once installed, attackers are able to gain control over the compromised machine, allowing them to install additional malware, steal information, establish persistence and move laterally across the network.

Abuse of RMM (remote monitoring and management) software such as ScreenConnect is becoming increasingly common, adding to the growing list of legitimate tools repurposed for malicious activity. In these types of attacks, ScreenConnect installers are often signed and appear as trusted applications but grant the attacker extensive control over the compromised machine.

IT teams typically use ScreenConnect to remotely access systems for support or incident response. Threat actors can weaponize RMM software through multiple avenues, from exploiting vulnerabilities to cracking or misusing the legitimate product. Whatever the case may be, the end result is an executable that links the victim’s machine to an attacker-controlled server. Attackers may wait days or even weeks before taking action, so long as the malicious RMM software remains undetected.

This research examines the recent campaigns that leverage ScreenConnect for initial access and details the malware deployed after compromise. Security teams can use the findings and recommendations outlined here to strengthen defenses and counter similar threats.

The attack begins with a malicious executable named agreement_support-pdf.Client.exe, which appears to have been downloaded via the Microsoft Edge browser. This file is a ClickOnce installer, disguised as a legitimate support document — a social engineering method often used to trick users into running untrusted code. The attack is likely to have originated with a social engineering campaign, likely distributed via email phishing, but possibly through other means as well.

Upon execution, the installer launches ScreenConnect.ClientSetup.exe, which once installed, connects the victim machine to the attackers’ C2 server.

As mentioned, these installers differ from previous attacks involving ScreenConnect in that they use a ClickOnce runner installer. This installer version is smaller in size and doesn't have the configuration embedded. Rather, it connects directly to the configured ScreenConnect server, downloading the necessary components and configurations to proceed with installation. This highly improves the installers’ evasiveness. In previous iterations of these attacks, a security product could look for specific phrases found in the embedded configuration in order to detect and stop suspicious executions of ScreenConnect. However, in this new version, this is no longer possible. The only two reliable prevention methods remaining would be blacklisting the C2 domain (which is difficult to know in advance), or blocking ScreenConnect entirely.

TRU researchers observed the malicious address via the install parameters present in the installer. The installer was executed with the parameters: e=Support&y=Guest&h=morco[.]rovider[.]net&p=8041 which connects to an attacker-controlled domain, morco.rovider[.]net. The domain was recently registered and is hosted on a virtual private server (VPS) associated with stealthrdp[.]com. It has also been observed distributing other malicious samples, indicating that it is part of a broader malware campaign infrastructure.

This attack abuses a type of on-premises installer for ScreenConnect. Since on-premises installations need to be independent of cloud infrastructure, ConnectWise provides customers with the means to both set up a server and clients inside their network, without having to rely on any cloud components. This system has two components, a server installer and client installer, and in legitimate applications, the server installer will be configured with an address and will also be able to create installers for the clients.

In this attack, the attackers likely obtained a cracked version of the server installer that allowed them to change the server address. This modification lets the attackers create installers that connect to their own malicious ScreenConnect server while appearing legitimate to security products. Without knowledge of the embedded server address, detection is difficult.

With ScreenConnect installed and connected to the attacker’s C2 server, a complex attack pattern unfolds over the span of approximately two months. TRU researchers analyzed the attack progression over time, and found the attacker deploying multiple RATs simultaneously and using them interchangeably. One was a PowerShell-based RAT with basic functionality, while the others were well-established and widely used tools such as AsyncRAT. This overlap makes it unclear whether a single attacker is responsible or if the infrastructure is shared among several operators, with access sold to multiple individuals who may be unaware of each other.

As ScreenConnect installs, two payloads are dropped in a matter of minutes. This is due to functionality in ScreenConnect that allows administrators to define specific automations, such as running a script when the user first connects to the server. This allows the attacker to automatically install a set of different RATs in a matter of minutes after installation.

For its first malicious payload, the attacker uses ScreenConnect to drop and execute a batch file, BypaasaUpdate.bat. This initial batch file acts as a downloader and stager for all remaining stages of the first payload infection, downloading and then extracting a zip file containing:

• 1.txt- A text file containing AsyncRAT.

• Pe.txt- A text file containing a .NET AMSI bypass and persistence mechanism.

• Skype.ps1- A PowerShell script to process and loads the above txt files as .NET assemblies.

• b.bat- A batch script used to run the above PowerShell script.

With the files extracted, b.bat is called first, which in turn executes Skype.ps1. Skype.ps1 then loads pe.txt and 1.txt as .NET assemblies in memory.

The latter, 1.txt, is AsyncRAT, a well-known, popular remote access trojan (RAT) that is widely used by both legitimate penetration testers and cybercriminals, whereas the former, pe.txt, is used both to bypass AMSI (anti-malware scan interface), thereby allowing the script to continue to run malicious scripts, and for establishing persistence.

Persistence is achieved by creating an additional file called Microsoft.vbs, whose sole purpose is to rerun Skype.ps1. Then, a scheduled task is created to run Microsoft.vbs, a single time, one minute in the future. When the task runs, Microsoft.vbs executes Skype.ps1 again, which in turn loads AsyncRAT and pe.txt again, which sets up a new scheduled task for one minute in the future, and thereby creating a persistence mechanism where every minute AsyncRAT is reloaded into memory, and the entire persistence mechanism is recreated.

Although this means that Skype.ps1 attempts to load AsyncRAT into memory every minute, 1.txt (aka AsyncRAT) checks for a specific mutex, AsyncMutex_al026, to see if AsyncRAT is already running, and if it is, it exits. In this way, AsyncRAT will not be reloaded every minute, but rather only when it’s not already running.

It should also be noted that this persistence mechanism is incredibly noisy. Running a PowerShell script every minute leaves an enormous number of traces, something the attackers will correct at a later stage of the attack.

A few minutes after AsyncRAT is loaded and set up, we observe another script being dropped and executed by ScreenConnect. But while the first script dropped a well-known tool, AsyncRAT, this second script dropped a surprising new payload — a sort of homemade RAT. This RAT is written as a PowerShell script, and provides some basic functionalities such as running programs, downloading and executing files and a simple persistence mechanism. It does not seem like any open-source tool we’ve seen in the past, and it was, perhaps, written by the attacker.

This is very likely another automatic execution, which begs the question, why drop two RATs on the infected machine? There are no clear answers, but there are a few possibilities:

     1.      The attackers might be acting with an abundance of caution. If one tool is caught, another might be used to maintain a backdoor. Or perhaps this second RAT is evasive in ways the first one isn’t.

     2.      The attackers might be testing a new tool that they are writing and decided to drop both.

     3.      Multiple attackers are using the same infrastructure (or have been sold access to the same infrastructure).

Whatever the reason, we do see a new C2 address, and we have seen both RATs used in the following weeks in our analysis of the attack.

The attack chain seems more straightforward as well — it starts with a JavaScript file, seemingly named after the port of the C2 address, which is dropped into a temp folder. The script then essentially executes the entire RAT as a PowerShell command.

The command itself, when deobfuscated, reveals a script which acts as a sort of homemade RAT — one that disables AMSI, sets up a listener for commands, does some initial reconnaissance, establishes persistence and starts an infinite loop which acts as a command handler.

The script first conducts system reconnaissance, collecting information regarding antivirus names by querying WMI for installed antivirus products, as well as OS name and architecture, UUID, computer name and user name. This is all then beaconed to the attacker’s C2, using Microsoft.XMLHTTP, which is also used to listen for commands. This is a fairly interesting usage of this COM object, as it is more commonly used in VBS scripts. It is possible that the attacker chose to use this over PowerShell’s built-in commands in order to evade detection, as many security products will look for PowerShell commands that establish internet communications.

The command handler is composed of a loop which sends POST requests to the C2 server every three seconds and awaits a response. The loop then executes the following commands, based on the response:

     1.      RF (run file): This command allows the attacker to write a binary file to a temporary folder and execute it.

     2.      TR: Receives PowerShell code from the attacker, writes it to disk as a .ps1 file, and runs it. In addition, it sets up a persistence mechanism using a VBS script. The VBS script is set up to run at startup via the startup folder and is used to launch the PowerShell script. This can be used to set up any number of additional backdoors, or any other script the attacker might want to persist.

     3.      Exc: Allows the attacker to write a VBS script onto a temp folder and execute it.

     4.      Sc: Performs a similar action to the RF command; however, this command is used to write in plain text and likely used to write and execute scripts.

     5.      Cl: Terminates the loop and closes the script.

     6.      Un: Terminates the loop and closes the script.

Persistence is established by creating a copy of 8911.js (the JavaScript file that originally launches the RAT script) in the startup folder under the name FirefoxUpdate.js.

The script employs several obfuscation techniques to evade detection and hinder analysis. Variable and function names are deliberately long, nonsensical or unrelated to their purpose, while command execution is hidden behind dynamically calculated aliases. Key payloads, such as the VBS persistence script, are stored as charcode arrays and only decoded at runtime, and the AMSI bypass is stored as a base64-encoded .NET assembly. The command handler uses short, cryptic codes (like RF, TR, SC) instead of descriptive names, and dropped files are given randomized or GUID-based names.

The script leverages built-in Windows objects such as Microsoft.XMLHTTP for C2 communication and Microsoft.VisualBasic.Interaction for object creation, blending in with legitimate activity. System reconnaissance data is exfiltrated via HTTP headers rather than obvious parameters, and error messages are suppressed to avoid drawing attention. Together, these layered obfuscation strategies make the script’s true behavior harder for security products to automatically detect and prevent.

All in all, this script is fairly interesting to see, especially since we couldn’t find it used anywhere else. While parts of the code seem to be reused, this homemade RAT appears to be mostly written by the attacker. This perhaps advantages the attacker in that it can fine tune the tool to their needs, and avoid detection based on specific, well-known patterns or signatures, while on the other hand, it may lack some of the more advanced features offered by other tools. It is, all in all, an interesting finding, and does raise the question of whether more than one attacker is using the same infrastructure.

Two weeks after the initial compromise, the threat actors leveraged their ScreenConnect access to deploy a new version of AsyncRAT, along with a revamped infection chain.

The updated infection chain begins with a batch script that launches MicrosoftUpdate.vbs - a simple wrapper for a PowerShell one liner that functions as a loader. This PowerShell script downloads two files, logs.ldr and logs.ldk, to the C:\Users\Public directory.

Both files, logs.ldk and logs.ldr, are encoded .NET assemblies. The PowerShell script decodes and executes logs.ldk first, which is a .NET DLL named Obfuscator.dll and serves a dual purpose: establishing persistence and acting as a secondary loader for logs.ldr, the actual AsyncRAT payload.

Persistence is achieved through a scheduled task named "Skype Updater," configured to execute C:\Users\Public\Ab.vbs at user logon. This VBS script mirrors the behavior of MicrosoftUpdate.vbs, functioning as a wrapper that invokes the PowerShell-based loader.

AsyncRAT (logs.ldr) is ultimately decoded and loaded in memory via the Obfuscator.dll method call [Obfuscator.A]::Main($f2) used from inside the powershell script.

The newly deployed AsyncRAT instance featured an updated configuration. Notably, it used a new mutex string: “AsyncMutex_alosh20215” and communicated with the command-and-control (C2) server over the following ports: 4501, 4502, and 4503.

The C2 infrastructure remained unchanged, still hosted at 185.196.9.158.

Several days after the updated AsyncRAT was deployed, we observed an additional RAT being delivered via WMI. The activity occurred just minutes after AsyncRAT related scripts execution, and although definitive attribution is not possible with the available evidence, the temporal proximity suggests a strong likelihood that the two may be related.

The process WmiPrvSE.exe was observed executing a PowerShell command that used Invoke-WebRequest to download a script named NvContainerRecovery.ps1 to the C:\Users\Public directory. Immediately afterward, the same WMI process invoked PowerShell again to execute the downloaded script.

The NvContainerRecovery.ps1 script first establishes persistence by creating a VBS script in the Startup folder. This VBS file simply acts as a wrapper to execute the same PowerShell script on each user logon.

Following persistence setup, the PowerShell script loads a .NET DLL implementing process hollowing. This method is used to inject another .NET assembly into a spawned instance of RegAsm.exe. The injected assembly is responsible for decrypting and loading a final .NET payload — identified as PureHVNC RAT.

The PureHVNC instance is configured to connect to 169.156.208.185 on port 8020.

An investigation of the attack infrastructure reveals several different domains that we believe could be in use by the attacker. Those include, in addition to morco.rovider.net, two other domains: gaza.rovider.net, and lightc.rovider.net. Both are related to ScreenConnect installers, with servers hosted on stealthrdp.com. They are observed in connection with XWorm and DCRat, which may indicate a broader attack infrastructure than what we’ve observed so far.

We identified numerous cases involving the use of ScreenConnect installers that connected to likely-cracked, on-premises ScreenConnect servers. The vast majority of these incidents occurred in the United States, and the installer filenames strongly suggest distribution via phishing or other social engineering techniques.

The executables were typically named to appear as legitimate documents, likely to trick users into executing them. Examples include:

• Social_Security_Statement_Documents_386267.exe MD5: 2EECA7166487DDC0B4C36B718DF31C93

• ssa_view.exe MD5: C92D37BC45F6088458C70C1CF53C06F6

• Social-Security-Available-Statement-3025147.ClientSetup.exe MD5: BA261666A657BDE2E8E071EE6E7D5357

• agreement_support-pdf.Client.exe MD5: 34ED21AC2399CC08BD051A283FD59FCE

• SSADocumentViewer-nXpJ2.exe MD5: A58719D9DDE0179C25215637766C2AB0

• 2024 BUSINESS SCHEDULE COMPLETE ORGANIZERpdf.exe MD5: 316119C77032A24822A64C86C1E4B2A0

This naming pattern indicates a clear attempt to impersonate official or financial documents, primarily themed around social security or legal agreements.

In these cases, we primarily observed the deployment of AsyncRAT and Remcos RAT.

With regards to Remcos, we identified that the threat actor reused the same virtual machine across multiple campaigns, though it was hosted at different IP addresses. According to Shodan results, the VM ran Windows Server 2022, had RDP enabled and was hosting a ScreenConnect Server. The hostname of the machine was consistent across sightings: WIN-BUNS25TD77J.

Gathering additional samples from threat intel sources, we also discovered another common hostname used by various campaigns: COPY-OF-VM-2022. It looks like attackers may have preconfigured VMs which they host at different addresses, allowing for quick setup and infrastructure changes.

Network:

• 169.156.208.185

• 185.196.9.158

• 185.196.8.100

• morco[.]rovider[.]net

• hxxps://eywordvailabom[.]com/sa/16-05.txt

• hxxps://systemwindowsupdate[.]com/alosh/logs.ldk

• hxxps://guilloton[.]fr/x.zip

Mutexes:

• AsyncMutex_al026

• AsyncMutex_alosh20215

Files:

• agreement_support-pdf.Client 67A32455A94B3396AD956CBDDA81D8ED1CD3727315159E025299057118DEB6AC

• Skype.ps1 BB182B8545B8C825811C6D09C738C230FE54BC96ADF1F10A3683B7E5294B5289

• 1.txt C260779FB1C9FF775739F6CF1853C9C33131ECF176737F6AF26B0AC60A6081DC

• Pe.txt 53AAD05571E86F22E2C75ED4FA6C8F553C3EBD58DCA8BE9FE8A143784AEF29D7

• BypaasaUpdate.bat 973A02FF597864E3920ED1041D24D629A0762CDE932EB69AEA066CD2235404F8

• Pe.txt decoded (Amsi Patcher) 1DA9428DF9A04E6CA1D836D1E941B61E30B6AF952D24D7B451A8D1E906ECE0C0

• 1.txt decoded (AsyncRAT) E7C482E66EFA99EA98E2C79BEB0A31C5120B73E4951A5F33133066B17E009DA1

• logs.ldr A4BF71F97C3A2F3FDA496D204B5E744D6F1DA8D888ACE3867DA08D072AF01245

• logs.ldk 6FA549F446A541856784695DB808DE2E5C67DA271C64ECC966C7C0B02622D58B

• Logs.ldr (decoded) 10EEB21202E7EB055F9FAC37DAB96F86DFEB9F28C0510F33E4324D12087CACF2

• Logs.ldk (decoded) 6AE546DA4D6D78D4262F3A2FF5E4F58C345294383ED9FF5E4DAA52466FE79E2F

• Powershell RAT B82E616E956A956FF5D9AFFCC13C907CF5054439FB5EE5A6F7AA5FFEE030DA56

• NvContainerRecovery.ps1 EF66D80511CD46C5173BF13E750C51114EE891E833F4F256A23E7DE4790ACC73

• PureHVNC RAT 068504CB4AC18D504247EF7A2C19A76B17A85E795B52E541FA8A49DE69B91F01