Huntress has identified a phishing campaign that publishes malicious public Power BI dashboards to steer victims toward ScreenConnect remote monitoring and management (RMM) installers. The attackers rely on Microsoft’s legitimate infrastructure to host the dashboards, and the resulting installs give them persistent remote access to compromised endpoints.
Public Power BI Dashboards Carry the Malicious Links
Recipients receive phishing messages built around fake reference documents. The attackers publish public Power BI dashboards that contain malicious outbound links, so the first page a victim sees sits on Microsoft’s own infrastructure rather than on an unfamiliar domain.
Huntress observed the campaign beginning on September 10, and the first public report followed on October 12.
Landing Pages Fingerprint Browsers and Delay Downloads
The pages the dashboards link to perform browser fingerprinting, delay the download, and send Telegram-bot telemetry to the attackers before serving a ScreenConnect installer. The delay and fingerprinting steps filter visitors and give the operators visibility into who has reached the page.
The installer is delivered from hamham27[.]screenconnect[.]com. Other domains named in the investigation are dailylifeproject[.]site, burnsworth[.]site, essaywritingservice[.]site and openpediatrics[.]site.
Multiple ScreenConnect Clients Installed in Sequence
After the first download, the attackers install several ScreenConnect clients one after another. They remove the first client and keep the others, which leaves access in place if a defender finds and removes a single instance.
Scheduled Tasks and Concealment Utilities Maintain Access
Persistence comes from scheduled tasks, and the attackers also use concealment utilities to hide the tools. Together these keep the remote-access software running on the endpoint and out of casual view.
ScreenConnect is a legitimate remote-support product, which is why it appeals to attackers. Its presence on a machine can look like normal IT activity, and Huntress’s findings describe how this campaign works to blend in and survive partial cleanup.
Impact and Indicators Published by Huntress
The result for victims is persistent attacker remote access on compromised endpoints. The reporting does not state how many recipients were targeted, how many installed the software, or what the attackers did after gaining access.
Huntress identified and investigated the campaign and published indicators of compromise and detection details. Those include the domains and installer host listed above.
The campaign combines several evasion layers in sequence. Hosting the first-stage link on a Microsoft service, filtering visitors with fingerprinting, and installing redundant remote-access clients each address a different point at which a defender might intervene. The use of Telegram-bot telemetry means the operators receive information on visitors in a channel separate from the infrastructure serving the installer.
Defenders reviewing their environments have a concrete set of artifacts to check: outbound links from Power BI dashboards, connections to the named domains, ScreenConnect clients that were not deployed by the organization’s own IT team, and scheduled tasks tied to those clients. The campaign’s reported start date of September 10 means that activity may predate the public report by roughly a month, so endpoints that received fake reference-document lures since early September are within the observed period.
What Huntress Did Not Report
The reporting on the Power BI campaign leaves several questions open. It does not state how many people received the fake reference-document emails or how many clicked through. It does not describe what the operators did once a ScreenConnect client was running on an endpoint, and it does not identify the attackers.
What is documented is the chain from email to installed software. A recipient opens a lure about a reference document, follows a link on a public Power BI dashboard, lands on a page that fingerprints the browser and holds back the download, and then receives a ScreenConnect installer. The Telegram-bot telemetry sent during that process tells the operators who reached the page.
Domains and Installer Host in the Huntress Findings
The domains in the case include four .site addresses with names that have no obvious connection to one another, plus the ScreenConnect-hosted installer subdomain. Huntress’s published indicators allow defenders to match these against logs.
