Power BI Phishing and Rogue ScreenConnect: How the Lure Works and What to Check

Direct answer

The campaign began on September 10, according to Huntress. An Outlook phishing message sent a recipient to a public lure on the legitimate app.powerbi.com service. A fake “Download Reference” prompt opened an attacker-controlled page, which fingerprinted the browser and then initiated a ScreenConnect installer download. Huntress observed rogue clients and persistence activity, but no confirmed theft, ransomware, Microsoft breach or Power BI software vulnerability.

What Huntress disclosed on October 7

Huntress’s October 7 report is the original public technical disclosure covered here; it is not the date the campaign started. The company described a phishing chain that used Power BI as the first visible destination and ScreenConnect as the remote-management component installed later in the sequence. IT Security Guru independently summarized the same research on October 7, corroborating the broad flow and the defensive recommendations.

That distinction matters for readers trying to understand what is new. The public report is new on October 7, while the observed activity dates back to September 10. A headline that describes this as a new Power BI exploit or a Microsoft-wide breach would go beyond the evidence presented by the two sources.

The campaign also demonstrates why allow-listing a cloud service by domain is not the same as validating the content hosted there. A real service can contain a public dashboard or document created by an attacker, a compromised account or a throwaway account. The domain may be genuine while the page, link and requested action are malicious.

The campaign timeline: observation versus disclosure

The available timeline is short but consequential:

Huntress said it saw the delivery method reach a handful of endpoints. It also reported 22 additional endpoints associated with a unique ScreenConnect client and configuration during a retroactive hunt across separate incidents. Those are different observations, not two piles to add together. They do not establish 22 unique victims, 22 organizations or a total number of compromised machines.

• September 10, 2026: Huntress said it first observed this campaign pattern, including its delivery method, ScreenConnect clients and related network indicators.
• After the initial observations: Huntress found related activity during a retroactive threat hunt. Those findings came from separate incidents and should not be treated as a single campaign-wide victim count.
• October 7, 2026: Huntress published its original disclosure. IT Security Guru published an independent report the same day.
• October 8, 2026: Evidence-review date for this article, not the campaign's start or original disclosure date.

How the Power BI lure turns trust into a trap

The recipient-facing sequence was designed to make each step feel ordinary. The initial Outlook message contained an embedded link. Huntress could not obtain that original email and lure, so the exact sender, subject line and wording should not be presented as known facts.

The link led to a blurred or obscured reference document hosted through the legitimate Power BI service. The page invited the visitor to click “Download Reference.” That wording is a useful warning sign: a business document that suddenly requests a download, especially after arriving in an unexpected email, deserves scrutiny even when the page is on a familiar cloud domain.

Clicking the prompt opened a new browser tab to an attacker-controlled landing page. Huntress described that page as checking characteristics such as the operating system, browser and version, device type, screen size, automation indicators, iframe context and certain cloud-provider cookies. One reported variant limited the flow to Windows desktop systems and filtered out some network categories. These checks are consistent with traffic filtering intended to avoid automated analysis and reduce exposure to researchers or scanners.

The page also collected visitor telemetry and reported it through an attacker-controlled messaging channel. That is not the same as proving that files or corporate data were stolen. It does show that the landing page was more than a passive download screen and that a visitor’s network and browser details could be exposed before the installer appeared.

The page then delayed the download rather than presenting it immediately. After a few seconds, script activity activated a hidden download link, while the visible page claimed that a “Reference Verification Form” had downloaded successfully. That mismatch—an unexpected new tab, a delayed download and a message that does not match the user’s intended document—is a practical detection clue.

Why ScreenConnect appears in the chain

ScreenConnect is legitimate remote-monitoring and management software used by administrators and service providers. The product itself is not malware, and the report does not describe a Power BI software vulnerability. In this incident, attackers abused ScreenConnect by creating or using rogue tenants and client configurations so that an installed client could provide unauthorized remote access.

That distinction is important in both policy and triage. An organization should not block or uninstall every legitimate remote-management tool without checking ownership and business need. It should, however, know which ScreenConnect instances are approved, which tenant or connection details belong to its service provider, who can authorize a client installation and what normal deployment looks like.

Huntress described more than one client in the chain. The first client connected through one ScreenConnect-related infrastructure path. A second client used a different connection path. Multiple remote-management clients can create resilience for an attacker: removing one does not necessarily remove the other. That is why an unfamiliar ScreenConnect entry should prompt a broader endpoint review rather than a single uninstall action.

What was actually observed on endpoints

Huntress reported two rogue ScreenConnect client instances in the activity it examined. In one incident, the first client executed a command file that launched a PowerShell script. The script installed another remote-management client and then removed the first one, which Huntress assessed as a likely attempt to reduce visibility or evade detection.

The same incident included execution of a file Huntress assessed as a defense-evasion tool. A scheduled task was configured to run the repair script every two minutes. The Huntress security operations center shut down the attack at that point, according to the report.

These details support a focused defensive conclusion: look for unauthorized remote-management software, unexpected client connections, scripts associated with its installation or repair, and scheduled tasks that repeatedly relaunch them. They do not justify claiming that every endpoint in the retroactive hunt ran every component, or that every affected endpoint reached the same stage.

What the reporting does not establish

Several stronger claims should be avoided:

Keeping these boundaries visible protects readers from both panic and false reassurance. The activity is serious because a trusted path can lead to unauthorized remote management; the evidence is limited because Huntress did not have the initial email and the observations came from a small set of investigated and retroactively linked incidents.

• No confirmed data theft: The landing page collected browser and network telemetry, but the reviewed reporting does not confirm theft of corporate files, credentials or other sensitive business data.
• No confirmed ransomware: The sources describe remote-access tooling and persistence-related activity, not a ransomware deployment.
• No Microsoft breach: The use of Microsoft’s Power BI domain shows abuse of a trusted service, not compromise of Microsoft’s infrastructure.
• No Power BI vulnerability: The evidence describes attacker-created content and redirection, not a software flaw in Power BI.
• No verified victim total: “A handful of endpoints” plus 22 retroactively associated endpoints cannot be converted into a unique victim or organization count.
• No universal ScreenConnect verdict: ScreenConnect is a legitimate product. The security question is whether a specific client, tenant and installation were authorized.

If ScreenConnect is unexpected on one device

Start by treating the client as an incident lead, not as a nuisance application. Record the hostname, logged-in user, installation time, client identity and connection details. Ask the system owner or managed service provider whether the installation is authorized. If nobody can explain it, follow the organization’s containment process before removing files.

A clean-up decision should account for secondary access. Check whether another client, service, task or script was installed around the same time. Review recent authentication and endpoint events for the period before and after installation. If the device handled privileged sessions, use a clean device to assess and rotate relevant credentials after containment.

For a personal computer, disconnecting from the network and contacting a trusted administrator or security professional is safer than clicking through a remote-support session or accepting a new installer. The key question is not whether the ScreenConnect brand is familiar; it is whether the specific installation was requested, traceable and still needed.

FAQs

Question: Is this a Power BI hack?

No. The reviewed evidence indicates abuse of a legitimate public Power BI hosting service to present a phishing lure. It does not establish a Power BI software vulnerability or a breach of Microsoft. Treat the page’s content and requested action as untrusted even though the hosting domain is genuine.

Question: Is every ScreenConnect installation malicious?

No. ScreenConnect is legitimate remote-management software. An installation becomes suspicious when it is unexpected, belongs to an unapproved tenant, uses an unknown connection path, appears alongside a phishing event or is paired with unexplained scripts and persistence. Confirm authorization before taking disruptive action, then investigate any client that cannot be accounted for.

Limitations and source notes

This article relies on Huntress’s original disclosure published October 7, 2026 and an independent IT Security Guru report published October 7, 2026. Huntress did not obtain the initial email and lure. Its endpoint observations and the 22 retroactively associated endpoints came from separate incidents; neither source supplies a reliable unique-victim total. The reporting reviewed here also does not confirm data theft, ransomware, a Microsoft breach or a Power BI vulnerability.

Decision checklist

• Treat the message as the starting point. Report an unexpected “reference,” invoice, shared document or download email through the organization’s established phishing-reporting channel. Preserve the message and headers if your response team requests them.
• Inspect the action, not only the domain. A genuine Microsoft-hosted page can contain attacker-controlled content. Be cautious when a document asks for an unexpected download, opens a new tab or claims a form completed without the normal workflow.
• Inventory ScreenConnect. On endpoints and in management consoles, identify all installed clients, services, connection names, tenants and owners. Compare them with the organization’s approved remote-support inventory.
• Check for duplicates. Multiple ScreenConnect clients or a newly appearing client on a device that should not have remote support deserve priority review.
• Review persistence. Look for recently created or modified scheduled tasks, startup entries, services and scripts that repeatedly launch remote-management components. Focus on ownership, timestamps and change records rather than deleting evidence first.
• Use endpoint telemetry. Correlate the browser event, installer execution, client installation, outbound connection and any script or task activity. A single alert may not show the entire chain.
• Contain carefully. If an unauthorized client is confirmed, isolate the endpoint according to the incident-response plan and preserve relevant logs. Do not rely on uninstalling one client as proof that access is gone.
• Validate accounts and secrets. After containment, review sign-ins and privileged activity tied to the user and host. Rotate credentials only through the organization’s approved process and from a clean administrative environment when compromise is plausible.
• Tighten allow-listing. Permit remote-management software only through approved tenants, installers, identities and support workflows. Domain allow-lists alone are too broad for cloud-hosted content.
• Test reporting and escalation. Make sure users know that an unexpected download from a familiar service is reportable, and that the service desk can distinguish an approved support session from a rogue client.

Limitations

• Evidence was reviewed on 8 October 2026; advisories, telemetry and package status can change.
• General defensive guidance is not a diagnosis of a particular system or a guarantee of complete cleanup.
• Capabilities, exposure and sensor attempts do not alone establish confirmed data theft or a customer breach.
• Source guidance and indicators must be rechecked before making operational decisions.

Evidence sources

1. Huntress — Huntress — “Phishing Campaign Abuses Microsoft Power BI to Deploy Rogue RMMs”
2. IT Security Guru — IT Security Guru — “Power BI phishing campaign drops rogue ScreenConnect clients”