Power BI Phishing Lure Plants Rogue ScreenConnect Clients for Persistent Access

A phishing campaign is using Microsoft Power BI as a trusted front door. It ends with a rogue ScreenConnect remote-access client on the victim's Windows machine, and often a second one as a backup. No Power BI vulnerability is involved. The attackers are abusing the trust that email filters and users place in Microsoft-hosted links.

What happened

Researchers at Huntress say the activity began around 10 September 2026 and published their analysis on 7 October. The chain looks like this:

1. Delivery — An Outlook phishing email carries a link. Huntress could not recover the original message.
2. Lure — The link opens a public Power BI report on Microsoft's legitimate domain. The report shows a blurred "reference verification form" with a Download Reference button. According to the researchers, attackers publish these dashboards from accounts they control, including compromised or throwaway accounts.
3. Filtering — The button sends the visitor to an attacker-controlled page. That page fingerprints the operating system, browser, screen size, user-agent and signs of automation, then reports the data to a Telegram bot. One variant served only Windows desktops and turned away visitors on Microsoft or unidentified ISP networks, which helps it avoid sandboxes and researchers.
4. Payload — After a short delay, a hidden link downloads a ScreenConnect installer. The page then shows a fake "download successful" message.
5. Access and persistence — The first client connects to an attacker-run ScreenConnect relay. It then installs a second client that points to separate infrastructure and removes the first one, which Huntress reads as a likely evasion step. Investigators also saw a tool built to hide activity from users and security software, plus a scheduled task that re-ran a "repair" script every two minutes until the SOC stepped in.

Huntress saw several affected endpoints in this campaign. A separate historical hunt found the same client configuration on 22 more endpoints across other incidents, but those may not belong to this exact campaign.

Why it matters

• Trusted domains get past filters. The first link points to Microsoft, so gateways that trust that domain may let it through.
• Legitimate tools hide well. ScreenConnect is real, signed support software. The danger comes from who controls the connection, not from the binary.
• Removing one client is not enough. Because the attackers chain two clients, removing the first can leave a working back door in place.

Keep the scope in mind: the report does not name a threat actor or confirm data theft or ransomware. Its findings cover the delivery chain and persistent remote access.

What to do

• Inventory your RMM tools. List every ScreenConnect and other remote-support install, and allow only your organisation's approved instances and relay hosts.
• Alert on new RMM installs and outbound sessions to relays you don't recognise. Treat more than one RMM client on the same host as a red flag.
• Hunt for persistence. Look for new scheduled tasks that run every few minutes, scripts launched from temp directories, and PowerShell spawned by command files.
• Tighten controls on trusted-cloud links. Don't exempt Power BI, SharePoint or similar Microsoft URLs from link analysis by default. Consider limiting external "publish to web" Power BI content where your tenant allows it.
• Brief your users. A document "download" that delivers an .exe or an MSI installer is never a document.
• During incident response, remove every rogue client, block its relay, and rotate credentials that were used on affected hosts.

Credit: Based on research by Huntress and on reporting by Cyber Security News. Huntress's report includes the full list of indicators of compromise (IoCs). Summarised and analysed by the 4Tify Team.