Fake Adobe Reader Pages Hide Rogue RAT

Security researchers at Huntress have flagged an ongoing phishing campaign that dresses itself in Adobe's branding and then slips through the front door using a browser-in-the-browser (BitB) trick, ultimately planting rogue ScreenConnect clients that give attackers persistent remote access to victim machines. The attack starts with a link that lands on a typosquatted domain — adoube[.]vu — styled to look like an Adobe landing page. From there, the victim is walked through fake update prompts until something unwanted is running in the background.

When the address bar lies

Phishing pages have always had one obvious tell: the URL. If the domain doesn't match the real thing, the scam usually falls apart. BitB exists to kill that tell. Using HTML, CSS, or JavaScript, an attacker can render an entirely fake browser window — address bar, URL, padlock icon and all — inside the actual page content. A careless glance at the fake chrome shows what looks like a legitimate address, and the illusion holds.

In this campaign, that fake window displays a blurred PDF document. Overlaid on it is a message claiming the file is "secured" and created with "the latest version of Adobe." The only way to read it, the message says, is to "update or download Adobe PDF Reader." A large "View Files" button sits beneath the notification. Clicking it opens a second fake BitB page showing a download in progress, while an actual file is pulled down in the background. Victims believe they're installing a PDF reader. They're installing a rogue version of ScreenConnect instead.

What ScreenConnect becomes in wrong hands

ScreenConnect is not malware by itself. It's a legitimate remote access and support tool, in the same family as TeamViewer, AnyDesk, or Remote Desktop, used by IT professionals to connect to and control machines remotely. The problem is that these particular variants are tainted to give threat actors persistent access to endpoints, according to Huntress.

In its report, Huntress described the initial payload and what followed. The first rogue client was configured to communicate with a relay domain that used a legitimate ScreenConnect Trial Relay address to avoid detection. From there, the attacker used the native Windows command shell and curl to fetch and install a second malicious ScreenConnect client configured to talk to an attacker-controlled IP. Both clients established service-based persistence, keeping remote access alive across reboots.

"The first initial remote client installed was the rogue ScreenConnect Client configured to communicate with instance-uxh86b-relay[.]screenconnect[.]com. The attacker used a legitimate ScreenConnect Trial Relay domain to further avoid detection. This initial malicious ScreenConnect Client used the native Windows command shell and curl to retrieve and install a second malicious ScreenConnect Client configured to communicate with attacker-controlled IP. Both clients established service-based persistence for continued remote access."

— Huntress researchers

Once the second session was up, the attackers ran HideCursor.exe, an executable whose name describes its purpose: hiding mouse activity from anyone watching the screen. At that point, Huntress researchers say they don't know what the endgame was, because the threat actors were spotted and shut down during this stage of the attack.

The gaps in the public picture

There are real limits to what Huntress has been able to establish. The researchers say they could not find the lure itself, so they can't describe what the initial scam email looked like. They saw victims click a link in an email and get redirected to the typosquatted Adobe page, but the email that started it all remains unaccounted for.

Huntress also did not disclose details about the target — the size of the organization or the industry it operates in. Without that, it is impossible to speculate on the nature of the attack, or whether the threat actors intended to deploy ransomware. The campaign was interrupted before those later stages could play out.

It's also worth keeping in mind that this account comes from a single research team, reporting what it observed on the endpoints it could examine. The relay domain and the typosquatted page are the concrete artifacts Huntress has published. Everything downstream of the second ScreenConnect session is unknown by the researchers' own account.

The numbers behind the campaign

• adoube[.]vu — the typosquatted domain spoofing an Adobe landing page.
• instance-uxh86b-relay[.]screenconnect[.]com — the relay address used by the first rogue client.
• Two malicious ScreenConnect clients installed in sequence, both establishing service-based persistence.
• One executable, HideCursor.exe, used to conceal mouse activity.

Why the BitB layer matters here

Browser-in-the-browser isn't new, but it changes the arithmetic for anyone relying on visual inspection to spot a phishing page. The fake window inherits the look of a real one, including the padlock that users have been trained to look for. When defenders tell people to "check the address bar," this is the technique that undermines the advice.

The Adobe disguise compounds the problem. PDF viewers and reader updates are routine, boring, and constant — exactly the kind of prompt users are conditioned to click through without much thought. Layering a blurred document behind the update message gives the victim a reason to act, and the "View Files" button gives them a place to click.

For IT and security teams, the second half of the attack is where the real leverage sits. The rogue ScreenConnect clients didn't exploit a software vulnerability. They were installed the way legitimate remote management agents are installed, and they persisted the same way. Detecting them means watching for behavior that looks like normal RMM activity but isn't tied to an approved deployment.

What Huntress says defenders should do

The researchers stressed the importance of training employees to "treat unexpected software update prompts and file-viewing pages with caution," and to make sure they know how to verify downloads through trusted channels.

On the technical side, Huntress recommends that IT teams restrict who can install remote-management tools, maintain an approved inventory of RMM software, and alert on new or unapproved ScreenConnect clients, unusual relay connections, and executables launched from user Downloads folders. Businesses should also monitor for the indicators of compromise (IoC) listed in the report.

The pattern to watch for is a remote management client appearing where no one approved one — particularly one reaching out to a relay domain rather than an internal or known vendor endpoint. The Downloads folder is another place worth watching, since the second-stage client and HideCursor.exe both have to land somewhere before they run.

The stakes for anyone running an IT estate

Remote management tools are a double-edged capability by design. The same features that let a helpdesk fix a laptop from across the country let an attacker sit on that laptop indefinitely. Because this campaign didn't require a vulnerability in ScreenConnect itself, patching alone wouldn't have stopped it — the defense has to sit at the policy and monitoring layer, controlling which RMM software is allowed and flagging anything that shows up outside that list.

The BitB element also suggests that user education built around "check the URL" needs revisiting. Training that assumes the address bar can be trusted is training that this campaign is built to defeat. Prompting employees to verify downloads only through trusted channels, and to treat unsolicited update pages as suspect regardless of how legitimate they look, addresses the behavior the attackers are counting on.

For the organizations that were targeted, the interruption came early — before the attackers moved past establishing access. What the second session would have been used for remains unknown. But persistent remote access is the foundation nearly every serious intrusion is built on, and a tool that blends into normal IT traffic is a difficult thing to find by signature alone. The practical takeaway is that visibility into what RMM software is running, and who put it there, is now part of the baseline.