A Power BI report link in an Outlook phishing message led to two attacker-operated ScreenConnect clients on Windows endpoints. Huntress traced the September campaign from a fake reference page on Microsoft’s real app.powerbi.com domain to a downloaded installer, a second remote-access client and, in one incident, a task that ran every two minutes. A legitimate cloud link was the invitation; the remote-control software was the prize.
Huntress saw the same delivery route, clients and network indicators on a handful of endpoints starting September 10. Its retrospective hunt also matched one client’s distinctive configuration on 22 other endpoints across separate incidents. The company sells endpoint detection and response services and investigated activity on protected systems; its SOC stopped the observed chain in one incident.
A trusted report leads outward
The lure looked like a blurred reference document with a “Download Reference” button. Huntress says the click opened an attacker-controlled page at dailylifeproject[.]site/S/. The page fingerprinted the browser and device, then used a Telegram bot to report the visitor’s IP address, location, browser, operating system and download activity. It diverted visitors that failed its checks to check[.]vykyn[.]click/E/. Huntress observed other staging pages at burnsworth[.]site/S/main.html, essaywritingservice[.]site/S/main.html and openpediatrics[.]site/S/main.html.
The staging page waited a few seconds before activating a hidden installer link and told the visitor the “Reference Verification Form downloaded successfully,” according to Huntress. The download was ScreenConnect.ClientSetup.exe from the attacker-operated tenant hamham27.screenconnect.com, on a legitimate ScreenConnect hosting service. Huntress observed changing guest-access parameters on that tenant’s installer URL, including ILEAYEASAN, PERFECTO and PAPASUPE. The domain app.powerbi.com is likewise a legitimate shared service abused for the lure, so its presence alone is a poor blocking rule.
Microsoft documents that a Publish to web report can be viewed without authentication when that tenant feature is enabled. Restrict public report publishing for reports your tenant owns, and keep link-to-download and endpoint controls in place for reports published elsewhere.
One installer opens two sessions
Huntress says the first rogue client, with ScreenConnect.ClientService.exe SHA-256 5956f9afb3ba610c38b2cfda88dd15be98783963769a12020c93ce05e749b3c3, connected through instance-g01s1n-relay.screenconnect.com. It then established a second client, with SHA-256 f048400c23add8c75abe189393d33c873c02c74eeaf43d47b950c8d643763b35, connected to onthegotree[.]site. The relay hostname belongs to the legitimate ScreenConnect service; the named tenant and client relationships identify the suspect access.
In one observed incident, the first client ran LyN03DvVjUKPrun.cmd, which launched SCAutoFix.ps1 from a temporary directory. That script fetched and ran another installer, C:\Temp\ScreenConnect.ClientSetup.msi, from onthegotree[.]site, leading to the second instance. It also uninstalled the first client. Huntress assessed the removal as likely evasion; the second client still required separate investigation. After the clients were installed, attackers executed HideUL_x64.exe, which Huntress assessed as a defense-evasion tool. The task SCAutoRepairEvery2Min was set to run SCAutoFix.ps1 every two minutes in one incident.
This is the trap in a one-client cleanup: the first client can disappear while the second keeps remote access. A browser download alone identifies exposure to the installer; the observed service processes, outbound connections and repair task are the evidence of access on an endpoint. Huntress lacked the original email and lure, so start a case review with browser, download and endpoint records as well as whatever message telemetry your mail system retained.
Search for both remote clients
Start with endpoints that fetched ScreenConnect.ClientSetup.exe from hamham27.screenconnect.com or visited the listed staging sites. Join browser downloads to process creation for ScreenConnect.ClientSetup.exe, installation of ScreenConnect.ClientService.exe, and connections to instance-g01s1n-relay.screenconnect.com or onthegotree[.]site. Match the two service hashes against stored binaries. Look for LyN03DvVjUKPrun.cmd, SCAutoFix.ps1, HideUL_x64.exe and the scheduled task SCAutoRepairEvery2Min; those artifacts help distinguish this chain from an authorized ScreenConnect session. A hash mismatch alone should send you to the tenant and service inventory, because Huntress observed separate clients and installer parameters.
Contain any affected endpoint, revoke unauthorized remote sessions and remove both unapproved ScreenConnect instances and the recurring task under your response procedure. Compare installed RMM agents and remote destinations to your approved tenant list; restrict new remote-management installations and outbound connections to approved instances where operationally possible. Huntress recommends investigating endpoints with multiple RMM clients. For Windows fleets using Microsoft Defender, Microsoft’s ASR reference documents the Block executable files from running unless they meet a prevalence, age, or trusted list criterion rule (01443614-cd74-433a-b99e-2ecdc07bfc25). It requires Defender Antivirus and cloud-delivered protection. Test that policy against approved RMM installers before enforcement; its hunting actions are AsrUntrustedExecutableAudited and AsrUntrustedExecutableBlocked. Treat the rule as an additional execution control, with allowlisting and tenant restrictions aimed at unauthorized remote tools.
Verify the second access path is gone
On each affected endpoint, compare the installed ScreenConnect services, scheduled tasks and outbound remote destinations with your approved RMM inventory. Then confirm neither reported service hash, the SCAutoRepairEvery2Min task nor connections to the reported rogue instances recur after containment. Repeat the check after the next scheduled-task interval: removing a visible client while its repair script still runs gives the attacker another way back. Keep the phishing-link investigation attached to the endpoint case: the trusted app.powerbi.com URL led into the remote-access chain.