Attackers abused Microsoft Power BI to deliver unauthorized ScreenConnect remote monitoring and management (RMM) clients, using trusted Microsoft infrastructure to disguise phishing links and establish persistent access.
Huntress observed the campaign beginning September 10, 2026, across several endpoints.
A retrospective hunt linked one distinctive ScreenConnect client configuration to 22 additional endpoints across separate incidents, rather than confirming all belonged to this phishing campaign.
The operation combined public dashboard lures, browser fingerprinting, delayed executable downloads, and redundant remote access installations.
Huntress subsequently observed a concealment utility and an automated repair task, demonstrating how legitimate remote administration software can become an attacker’s persistence mechanisms.
The intrusion began with an Outlook phishing email containing a link to a fake reference document hosted on app.powerbi.com.
Huntress could not recover the original message or its precise lure. The landing page displayed a blurred form and instructed recipients to click “Download Reference,” moving them from Microsoft’s legitimate domain to attacker-controlled infrastructure.
According to Huntress’s investigation, attackers can publish publicly accessible Power BI dashboards containing malicious outbound links.
This exploits the reputation of a legitimate cloud service, rather than a documented Power BI software vulnerability, and can bypass email controls that trust Microsoft-hosted URLs.
Clicking the download button opened dailylifeproject[.]site/S/. Other observed delivery domains included burnsworth[.]site, essaywritingservice[.]site, and openpediatrics[.]site.
These pages inspected browser versions, operating systems, device characteristics, automation indicators, screen dimensions, iframe context, and cloud-provider-associated cookies before allowing delivery. Visitors failing the checks were redirected to check.vykyn[.]click/E/.
The landing pages also embedded a Telegram Bot API credential and chat identifier to transmit victim telemetry, including IP addresses, geolocation, browser details, and download activity.
One variant restricted access to Windows desktops while filtering Microsoft-associated or unknown internet service providers, helping exclude scanners and analysis environments.
Instead of immediately serving the payload, page scripts waited several seconds before programmatically activating a hidden download link.
A notification then claimed that a “Reference Verification Form” had downloaded successfully, encouraging victims to inspect their Downloads folder.
The downloaded file was a ScreenConnect installer, not a reference document.
The installer originated from hamham27[.]screenconnect[.]com. Campaign variants reused that tenant and installer path while changing guest-access parameters, including ILEAYEASAN, PERFECTO, and PAPASUPE.
The first unauthorized client, 2b302081e9e777d0, connected to instance-g01s1n-relay[.]screenconnect[.]com and established a second client, 43773b3da4ccb17b, associated with onthegotree[.]site.
In one incident, LyN03DvVjUKPrun.cmd launched SCAutoFix.ps1 from a temporary directory.
The PowerShell script downloaded another ScreenConnect installer and removed the initial instance, which Huntress assessed as likely detection evasion.
Attackers also executed HideUL_x64.exe, assessed as a tool for concealing activity, and created SCAutoRepairEvery2Min to run the script every two minutes. Huntress’s SOC stopped the attack at this stage.
The redundancy resembles earlier Huntress investigations into browser-in-the-browser phishing, where fake Adobe Reader prompts delivered multiple ScreenConnect clients and concealment binaries.
Similar techniques do not establish shared attribution, but reinforce the operational value attackers place on maintaining alternative remote access paths.
Defenders should investigate unexpected ScreenConnect installations, unauthorized relay connections, remote access scripts, and recurring scheduled tasks.
Remediation must identify every installed client and associated persistence mechanism; removing only the first visible instance can leave another operational foothold intact on compromised systems.
| Item | Description |
|---|---|
ScreenConnect.ClientService.exe (2b302081e9e777d0)SHA256: 5956f9afb3ba610c38b2cfda88dd15be98783963769a12020c93ce05e749b3c3 | Initial rogue ScreenConnect client |
ScreenConnect.ClientService.exe (43773b3da4ccb17b)SHA256: f048400c23add8c75abe189393d33c873c02c74eeaf43d47b950c8d643763b35 | Secondary rogue ScreenConnect client |
SCAutoRepairEvery2Min | Runs SCAutoFix.ps1 every two minutes |
HideUL_x64.exe | Observed executing on an affected endpoint |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
Stops Cyber threats before impact with 21 min faster MTTR. Integrate ANYRUN’s Sandbox in your SOC.
A December intrusion to Storm-2603, the China-based group Microsoft ties to Warlock ransomware. The attackers…
A decade-old authentication bypass in OpenSSH on musl-based Linux lets attackers log into accounts that…
Bitdefender researchers have revealed a vulnerability called GhostMap that affects Android devices. This vulnerability can…
Microsoft has announced a vulnerability in Windows Paint that could let unauthenticated attackers execute malicious…
An autonomous penetration-testing framework linked to South Korean banking breaches and cloud supply-chain attacks is…
Shopify is making IP allowlisting mandatory for all public apps to limit abuse of stolen…