Fake Adobe Reader Delivers ScreenConnect via Stealthy Loader

A newly uncovered attack campaign is actively tricking users into installing remote access software on their systems. This sophisticated threat masquerades its malicious payload as a legitimate Adobe Acrobat Reader download, exploiting a common user expectation for trusted software.

The attack uses a sophisticated chain of techniques — including in-memory execution, process masquerading, and privilege escalation — to deploy ConnectWise’s ScreenConnect without leaving obvious traces on the victim’s machine.

What makes this campaign particularly dangerous is the level of trust users place in well-known software brands like Adobe. When someone visits a website and sees a familiar download button for Adobe Acrobat Reader, most people click without hesitation.

Attackers behind this campaign have exploited that trust entirely. Instead of delivering a real installer, the fake page silently pushes a heavily obfuscated VBScript file named Acrobat_Reader_V112_6971.vbs directly to the victim’s browser. This single file sets the entire attack in motion.

Researchers at Zscaler ThreatLabz first identified this attack chain in February 2026, tracing it from the initial lure all the way through to the final deployment of ScreenConnect.

According to ThreatLabz analyst Kaivalya Khursale, the attackers leveraged multiple layers of obfuscation and direct in-memory execution to reduce the number of artifacts left on disk, making detection and forensic analysis significantly harder for security teams.

The campaign stands out because it weaponizes a legitimate remote monitoring and management (RMM) tool — a growing trend among threat actors seeking to blend malicious activity with normal IT operations.

ScreenConnect itself is not malware. It is a legitimate remote desktop tool used by IT administrators worldwide.

However, when installed without a user’s knowledge, it hands attackers complete remote control over the compromised machine, allowing them to steal files, deploy additional payloads, or maintain long-term persistence.

Since the ScreenConnect behaves like genuine software, many antivirus and endpoint detection and response (EDR) solutions do not flag it, making this a particularly effective delivery method.

The fraudulent page used in this campaign, hosted at eshareflies[.]im/ad/, closely impersonates Adobe’s official website. Once a victim lands on it, the download begins automatically — no extra clicks required.

The VBScript loader is the first malicious file dropped, and from that point forward, the attack operates almost entirely in memory to avoid leaving evidence behind.

How the Attack Operates from Start to Finish

The attack unfolds in a carefully ordered series of stages, each designed to prepare the ground for the next. It begins the moment the VBScript file lands on the victim’s system.

The VBScript loader is built to resist analysis. Rather than referencing system objects directly, it constructs them dynamically at runtime using nested string replacement functions.

For example, instead of writing WScript.Shell in plain text, the loader assembles that name from a long jumbled string that only resolves to a readable value when the script actually runs.

This approach prevents the name from appearing clearly in the file, making automated scanning tools far less effective.

The loader then executes a follow-on command assembled from dozens of Chr() calls with arithmetic expressions, each one resolving to a single ASCII character during execution.

The command runs silently in a hidden window, with no visible indication to the victim that anything unusual is happening.

Once the VBScript fires, it launches PowerShell with -ExecutionPolicy Bypass, allowing scripts to run even on systems with restrictive local policies.

PowerShell then downloads a file from Google Drive, reads it entirely into memory, and compiles it as C# source code — critically, without ever writing the compiled result to disk.

This is the in-memory loader, a .NET assembly embedded inside a large byte array. By using .NET reflection with Assembly.Load(byte[]) and EntryPoint.Invoke(), the loader executes the next stage entirely within the running process.

To further evade detection, the loader implements a technique called Process Environment Block (PEB) manipulation. The PEB is a Windows memory structure that stores information about a running process, including its name and file path.

The loader overwrites these fields to make itself appear as winhlp32.exe — a harmless Windows help binary. Security tools and user-mode monitoring software that rely on PEB metadata will see a legitimate-looking process rather than the malicious loader.

In addition to process masquerading, the attackers abused Windows’ auto-elevated Component Object Model (COM) objects to bypass User Account Control (UAC).

Normally, UAC would display a prompt asking the user to approve administrator-level actions.

By targeting specific COM class IDs that Windows automatically runs with elevated privileges, the loader gains administrative access silently.

The elevation moniker string is stored in reverse within the code and only flipped at runtime, making static signature detection even more difficult.

With full elevated privileges in hand, the final stage executes. A PowerShell command, decoded at runtime, creates the C:Temp directory, downloads ScreenConnect.ClientSetup.msi from x0[.]at/qOfN.msi, and installs it using msiexec.

Once installation completes, the attacker gains remote access to the victim’s machine through ScreenConnect’s legitimate infrastructure.

Users should avoid downloading software from unofficial or unfamiliar websites, even if the page looks legitimate. Organizations should deploy application whitelisting to prevent unauthorized RMM tools from being installed.

Security teams are advised to monitor for unusual PowerShell execution with -ExecutionPolicy Bypass flags and alert on unexpected MSI installations.

Blocking access to untrusted file-hosting URLs such as those on Google Drive when initiated by scripts can also reduce exposure. Enabling EDR solutions capable of detecting PEB manipulation and COM-based UAC bypass activity is strongly recommended.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.