Summary
- Two August attacks used fake Adobe Reader workflows to persuade victims to install attacker-controlled ScreenConnect clients.
- Browser-in-the-browser pages displayed a legitimate Adobe address inside a simulated browser interface.
- Multiple ScreenConnect instances provided redundant persistence before attackers deployed HideCursor and HideUL defence-evasion binaries.
Attackers are using fake Adobe Reader pages and simulated browser windows to persuade victims to install rogue ScreenConnect remote-management clients, converting a phishing interaction into persistent administrative access.
Huntress analysed two incidents in August that began with phishing messages and progressed through browser-in-the-browser, or BiTB, pages designed to resemble genuine Adobe websites.
BiTB attacks create a simulated browser window inside a webpage using ordinary web technology. The attacker can reproduce an address bar, browser controls and other interface elements, including a legitimate-looking URL, because the entire apparent window is part of the malicious page rather than the browser’s real interface.
In the first incident, detected on 25 August, a user clicked a malicious link in a Gmail message and was taken to a fake browser-check page before reaching an Adobe-themed lure containing blurred documents. The site told the victim that an updated PDF reader was required to view the files.
After the user selected the option to continue, the page displayed a simulated browser window containing what appeared to be Adobe’s legitimate get.adobe.com address. The download was not Adobe software. It was an attacker-controlled ScreenConnect installer.
Huntress found that the first client subsequently retrieved a second unauthorised ScreenConnect instance, creating two persistent remote-access channels. The attacker later used one of the sessions to execute HideCursor.exe, a utility intended to reduce visible signs of interactive activity on screen.
A second incident on 31 August followed a closely related chain after a victim interacted with a phishing message delivered through AT&T Office@Hand, which is based on RingCentral’s business communications platform.
The second lure used the same fake Adobe Reader template. An installer disguised as an Adobe update again deployed two unauthorised ScreenConnect clients, after which the attacker executed HideUL.exe.
Microsoft Defender identified part of the second chain, but Huntress said the rogue ScreenConnect installation still completed. Huntress ultimately contained both incidents before the attackers progressed further.
The research is notable because the attack does not depend on exploiting Adobe Reader or ScreenConnect. The attacker uses the Adobe brand to establish trust and ScreenConnect’s legitimate functionality to maintain access once the victim has been persuaded to run the installer.
That combination complicates controls based on simple malware classification. Remote monitoring and management software is widely used legitimately by internal IT teams and service providers. The security distinction is therefore not whether ScreenConnect exists on a device, but whether that particular client, relay and installation is authorised.
The fake browser also undermines familiar advice to check the URL before trusting a sign-in or download page. In a BiTB interface, the address shown to the victim can be entirely fabricated even when it displays a genuine corporate domain.
The installation stage consequently becomes an important control boundary. Restrictions on unapproved RMM software, monitoring for new remote-management services and an inventory of authorised administration tools can expose activity that a visually convincing phishing page may conceal from the user.
Huntress has not established the attackers’ final objective. Both incidents were interrupted before ransomware, data theft or another outcome was confirmed, so attributing a later-stage motive would go beyond the available evidence.
What the two cases demonstrate is a repeatable chain in which social engineering continues after the initial email. The attacker builds trust through several successive interfaces, then replaces the promised document software with a legitimate remote-administration tool configured for someone else’s control.
