Overview
A new phishing campaign is abusing Microsoft Power BI to deliver rogue ScreenConnect installations, turning legitimate business technology into a pathway for persistent remote access. The campaign is significant because there is no indication that Power BI itself has been compromised. Instead, attackers are exploiting something potentially more valuable than a software vulnerability: the trust organisations place in familiar cloud services and legitimate remote-management tools.
The Trusted Link Is the First Attack Path
The campaign begins with a phishing email containing a link to a legitimate Microsoft Power BI address. The victim is presented with what appears to be a reference document and a “Download Reference” prompt. Because the initial destination belongs to a trusted Microsoft service, conventional security controls that rely heavily on domain reputation may assign the link a lower level of suspicion. The danger appears only after the user interacts with the content. The Power BI page redirects the victim to attacker-controlled infrastructure, where the browser and device are profiled before a malicious ScreenConnect installer is delivered. This demonstrates an important security principle: a trusted domain does not make every resource or destination reached through that domain trustworthy.
Legitimate RMM, Malicious Ownership
ScreenConnect is legitimate remote-support software. Its presence on a Windows endpoint is therefore not inherently suspicious. The problem is who controls the remote-management relationship. In this campaign, attackers used ScreenConnect tenants and clients configured to connect victims to infrastructure under their control. A second ScreenConnect client could then be installed through the first, creating another route back into the compromised endpoint. This makes traditional application-based detection increasingly difficult. Blocking ScreenConnect because it can be abused may disrupt legitimate IT support, while allowing every ScreenConnect installation creates an opportunity for attackers to hide inside an approved technology. The more useful security question becomes whether the RMM instance, tenant, connection and installation context are authorised.
Persistence Changes the Risk
The observed activity went beyond simply installing remote-access software. Attackers used scripts, scheduled tasks and additional tooling to maintain access and conceal their activity. One variant used a scheduled task that repeatedly executed a repair script, while another component was used to remove an earlier ScreenConnect installation. This creates an important incident-response challenge: removing one known remote-management client does not necessarily mean the access path has disappeared. Multiple clients, scheduled tasks and secondary infrastructure can create layers of persistence.
Trust Must Include Context
This campaign demonstrates why cloud security controls increasingly need to evaluate context rather than reputation alone. A Microsoft-owned URL can still lead to malicious content. A legitimate RMM executable can still provide unauthorised remote access. A valid digital signature can confirm who developed software without confirming who is authorised to operate it on a particular endpoint. Effective detection therefore requires correlation between the user, device, application, installation source, RMM tenant, outbound connections and subsequent behaviour. An unexpected ScreenConnect installation followed by PowerShell activity, scheduled-task creation and connections to an unfamiliar remote environment is considerably more significant than any one event viewed independently.
Expert in the Cloud Insight
Modern attacks increasingly avoid breaking trusted technology. Instead, they assemble trusted technology into an untrusted chain. Security controls must therefore validate not only what an application is, but who deployed it, who controls it, where it connects and whether its behaviour matches the business purpose.
Leave a Reply