← Back to Blog

Threat Research

Operation BlueDash: Multi-RMM Workplace Phishing

ZeroBEC traced a Microsoft Teams lure from a compromised website to Level RMM and ScreenConnect, and uncovered the GitHub environment behind the campaign.

By ZeroBEC Team · July 21, 2026 · 15 min read

ZeroBEC investigated a live Microsoft Teams-themed phishing operation that began with a "secure document" email and ended with the silent enrollment of the victim endpoint into attacker-controlled remote monitoring and management environments.

Executive summary

The victim was directed through compromised web infrastructure to a counterfeit Microsoft Store page claiming that Microsoft Teams had to be updated before the shared document could be opened. The active download delivered supportdev.exe, an Inno Setup-based loader that launched PowerShell in a hidden window, retrieved the official Level RMM installer, and registered the endpoint using an attacker-controlled enrollment secret. The same command attempted to deploy ScreenConnect in parallel, providing a redundant remote-access channel.

The investigation then moved beyond the delivery chain. ZeroBEC recovered commands executed after RMM enrollment that queried reboot state, BitLocker protection, Windows Firewall configuration, and membership of the local Administrators group. This evidence shows hands-on assessment of the compromised endpoint rather than a purely automated installation workflow.

DNS, CNAME, GitHub Pages, repository, and commit-history analysis traced the campaign to a public development environment containing the phishing source code, custom-domain configuration, loaders, historical delivery URLs, and related infrastructure. The repository history documents the operation's evolution from direct ScreenConnect delivery to a multi-RMM loader and connects the Teams campaign to a parallel Zoom-themed operation that later deployed Tactical RMM through Windows JScript.

Related reporting: Microsoft's March 2026 analysis documented signed workplace-app impostors deploying ScreenConnect, Tactical RMM, and MeshAgent. ZeroBEC's May 2026 ScreenConnect investigation documented a separate authenticated-phishing campaign that used post-click web infrastructure to deliver a legitimate ScreenConnect client and establish redundant remote-access channels.

ZeroBEC tracks the activity as Operation BlueDash. We assess with high confidence that the identified GitHub environment was intentionally used to develop and operate the campaigns. Based on the convergence of repository ownership, contributor activity, infrastructure, code history, and broader OSINT, ZeroBEC attributes Operation BlueDash to a specific group of developers operating from Nigeria with moderate-to-high confidence. We found no evidence that the primary GitHub account was compromised or repurposed by an unrelated actor.

Public-reporting note. The attacker-controlled Level RMM enrollment key is retained because it is a campaign indicator. The Tactical RMM authentication token remains redacted. Individual developer handles and identity details are withheld. The attribution discussion is limited to the assessed Nigeria-based developer group.

Key findings

• Complete chain reconstructed. The investigation connected the original email, compromised sites, fake Microsoft Store pages, loaders, RMM enrollment, post-compromise reconnaissance, and developer infrastructure.
• Level RMM added to the observed toolset. The SupportDev loader silently installed the official Level agent using an attacker-controlled API enrollment parameter, while also attempting ScreenConnect deployment.
• Hands-on activity confirmed. The operators inspected system reboot state, disk-encryption protection, firewall status, and local administrative membership after access was established.
• Repository history exposed campaign development. Historical commits revealed repeated infrastructure rotation, older delivery paths, new loaders, and the gradual expansion from one RMM channel to several.
• A related Zoom campaign was connected. A second repository used the same operational model but evolved to a JScript payload that installed Tactical RMM.
• Attribution advanced. The development environment and wider OSINT support attribution to a specific Nigeria-based developer group rather than an unknown actor or a compromised repository account.

How Operation BlueDash extends Microsoft's March 2026 reporting

In March 2026, the Microsoft Defender Security Research Team documented multiple phishing campaigns attributed to an unknown threat actor. Microsoft described meeting and workplace-themed lures, fraudulent update pages, digitally signed executables impersonating trusted applications, and deployment of ScreenConnect, Tactical RMM, and MeshAgent. Microsoft assessed that the simultaneous use of multiple RMM frameworks was intended to improve access redundancy and operational resilience.

Operation BlueDash should be understood as an evolution and deeper reconstruction of that tradecraft. The ZeroBEC investigation does not merely identify another fake application installer. It follows the operation from the original lure through active delivery, exposes Level RMM as an additional remote-access platform, records the operators' reconnaissance, and maps the public source-controlled infrastructure used to develop and rotate the campaigns.

What is new. Microsoft documented the technique. ZeroBEC reconstructed the operator's working environment and campaign evolution, including the addition of Level RMM, the post-enrollment commands, the linked Zoom branch, and the Nigeria-based developer attribution.

1. Initial access: a "secure document" shared through Teams

The infection chain began with a phishing email telling the recipient that a document was too large to deliver directly and had therefore been shared securely through Microsoft Teams. The message asked the recipient to select "Access Your Secure Document" and recommended opening the file from a desktop or laptop.

The embedded link pointed to a path on a compromised Turkish website:

hxxps://www[.]zerrinperde[.]com[.]tr/Microsoftteam/invite-teams

Historical URL intelligence recovered an identical page

By the time analysis began, the original phishing page was no longer available. ZeroBEC therefore pivoted to historical URL intelligence and searched for the same page structure and campaign artifacts. URLQuery results exposed another site hosting an identical lure:

hxxps://anujyotindustries[.]com/MicrosoftTeam/invite-teams/

The page closely reproduced the visual design of the Microsoft Store, including Microsoft Teams branding, product details, screenshots, and a fake Windows taskbar. The user was told that an update was required before the secure document could be accessed.

A broken download became an investigative clue

On the recovered anujyotindustries[.]com page, clicking Update opened an installation guide and initiated a file named MicrosoftTeams_Update.exe. The downloaded object was not a valid executable. It contained the phishing page's HTML because the installApp() function pointed back to the page itself.

This branch was likely disabled, misconfigured, under development, or stripped of its payload before analysis. It still exposed the campaign's page structure, filename conventions, and JavaScript logic, which became useful pivots for locating a functional deployment elsewhere.

2. Page-title dorking exposes the live campaign

ZeroBEC used the phishing page title, "Microsoft Store - Microsoft Teams," as a search pivot. This revealed a live deployment at teamvem[.]com with the same page design, social-engineering narrative, and fake Microsoft Store workflow.

DNS analysis showed that the site was deployed through Netlify and exposed the associated platform hostname:

bluedashlimited[.]netlify[.]app

The active page retained portions of the older JavaScript but used a direct button action to download supportdev.exe from support[.]berrydev[.]xyz. The domain also hosted another copy of the same phishing page, demonstrating that the actors used interconnected sites for both presentation and payload delivery.

3. SupportDev: from fake Teams update to redundant RMM access

supportdev.exe was not a legitimate Microsoft Teams installer. It was an Inno Setup package designed to launch a hidden PowerShell command. Unpacking the installer exposed a short but operationally significant script that created two independent remote-access paths.

Hidden PowerShell and silent Level RMM enrollment

The installer started powershell.exe with ExecutionPolicy Bypass and WindowStyle Hidden. It downloaded the official Level RMM MSI from Level's infrastructure to the user's temporary directory, then invoked msiexec.exe with a quiet installation switch and the attacker-controlled enrollment parameter LEVEL_API_KEY=GxSCHE8EZwfyYN3iPQHPai8D.

Supplying the enrollment parameter during installation automatically registered the endpoint to the operators' Level RMM environment without requiring the victim to approve a connection or interact with the RMM interface. The use of the legitimate vendor installer allowed the operators to inherit the functionality and trust normally associated with an approved administrative product.

ScreenConnect as the second access channel

The same PowerShell command downloaded and executed a ScreenConnect client from sqnchzmt4lsc[.]net. At the time of analysis, that ScreenConnect endpoint was no longer operational. The Level deployment path remained functional, however, and continued to enroll test systems into the attacker-controlled RMM environment.

The parallel use of Level RMM and ScreenConnect is central to the campaign's resilience. Removal or disruption of one product does not necessarily eliminate the attacker's second remote-access channel.

Why Level RMM matters. Microsoft's March report described ScreenConnect, Tactical RMM, and MeshAgent. Operation BlueDash adds Level RMM to the observed ecosystem and shows the official Level installer being enrolled silently through a command-line API key.

4. Post-compromise reconnaissance through the RMM channel

The investigation captured commands executed after the remote-management agent was installed. These commands were not required to complete the installation. They represent follow-on assessment of the endpoint and demonstrate that the operators were actively evaluating the compromised system.

This sequence suggests a practical operator checklist: determine system state, understand encryption and firewall posture, and identify privileged local users before deciding how to continue. It also provides defenders with a behavioral detection opportunity because the commands originate through an unauthorized RMM context rather than an approved IT workflow.

5. Inside the BlueDash development environment

The domain support[.]berrydev[.]xyz did more than host the SupportDev payload. DNS resolution exposed GitHub Pages infrastructure and the repository namespace behind the custom domain. This pivot led directly to the public repository used to maintain the Teams-themed phishing page and its payload.

The repository at hxxps://github[.]com/berry4603/Bluedashltd contained the active index.html phishing page, supporting assets, a CNAME file, and supportdev.exe. GitHub displayed a 14-commit history at the time of review. The combination of source code, domain configuration, executable payload, and historical revisions makes the repository a direct record of the campaign's development rather than a passive file-hosting location.

Commit evidence predates the investigated delivery chain

Earlier commits show the fake Microsoft Store page being wired directly to an attacker-controlled ScreenConnect instance. In the captured revision, the page's Update button directed the victim to a ScreenConnect client while labeling the download microsoftupdate. This establishes a direct development link between the lure framework and the remote-access enrollment endpoint months before the later SupportDev multi-RMM version.

The same commit also retained an older installApp() function that referenced a previous Teams-themed executable path. The active link and the residual code document successive generations of the delivery logic in one source-controlled file. Similar changes appear throughout the repository history as the operators replace domains, ScreenConnect instances, payloads, and hosting providers.

Assessment of repository control. ZeroBEC found no evidence that the repository account was compromised or taken over by an unrelated actor. The continuity of changes, campaign artifacts, custom-domain management, related repositories, and wider OSINT supports intentional operation by the developer group.

6. Commit history reconstructs the campaign's evolution

Microsoft Teams branch: Bluedashltd

Zoom branch: rustovni

The repository timeline is more than a list of indicators. It reveals the operators' workflow: reuse the same visual framework, rotate custom domains and cloud services, replace RMM instances, preserve older code during revisions, and expand the number of remote-access mechanisms available after execution.

7. A parallel Zoom campaign deploys Tactical RMM

A second repository in the same development ecosystem exposed a Zoom-themed operation. The repository contained three front-end pages, a custom-domain CNAME, images, and payload releases. Its design and workflow closely mirrored the Teams branch: a meeting lure, an "out of date" message, a counterfeit Microsoft Store page, and a download presented as a legitimate software update.

JScript replaced the executable loader

The later Zoom branch downloaded ZoomInstallerSetup.js. The script attempted to relaunch itself with elevated privileges through the runas verb, downloaded the Tactical RMM agent from its official GitHub release, installed it under the Windows temporary directory, and enrolled the device into attacker-controlled infrastructure using an embedded authentication token.

The script referenced api[.]investrneent[.]com as the Tactical RMM server and included paths for both 64-bit and 32-bit installations. It then started the agent service, completing persistent remote access. The public report redacts the authentication token.

The Zoom campaign confirms that Operation BlueDash was not tied to one brand, one payload, or one RMM product. The operators could preserve the social-engineering framework while changing the workplace application, scripting language, payload host, and remote-management platform.

8. Attribution: a Nigeria-based developer group

ZeroBEC attributes Operation BlueDash to a specific group of developers operating from Nigeria with moderate-to-high confidence. The assessment is based on converging technical and OSINT evidence rather than the registration details of a single domain or the historic profile of one account.

• Continuity of repository control. The same development environment was maintained over months as phishing pages, CNAMEs, payloads, and RMM endpoints were repeatedly changed.
• Direct campaign artifacts. The repositories held the active phishing source, custom-domain configuration, malicious installers, scripts, and historical enrollment URLs used by the campaigns.
• Cross-campaign overlap. The Teams and Zoom branches shared development practices, infrastructure patterns, fake-store workflows, cloud hosting, and preference for legitimate RMM products.
• Developer-group contribution. Repository contribution patterns and wider OSINT connect the campaign development to a coordinated group rather than a single isolated upload.
• Nigeria nexus. Independent identity and infrastructure pivots map the responsible developer cluster to Nigeria.
• No takeover indicators. The observed continuity and operational behavior do not support the theory that the primary repository account was compromised and repurposed by an unrelated actor.

ZeroBEC is intentionally withholding individual developer handles and personal identity details from this publication. Those details are not necessary for defenders to understand the campaign and could distract from the higher-confidence conclusion: the same Nigeria-based developer group built, maintained, and evolved the connected phishing and RMM-delivery infrastructure.

Confidence statement. High confidence: the Teams and Zoom campaigns originate from the connected GitHub development ecosystem. Moderate-to-high confidence: the operation is attributable to the identified Nigeria-based developer group. Attribution may be refined as additional infrastructure or contributor activity emerges.

9. Why Operation BlueDash is a more robust campaign

Operation BlueDash is significant because its strength does not come from a novel malware family. It comes from operational flexibility and the deliberate abuse of trusted administrative tooling.

• Redundant access. SupportDev attempts to establish Level RMM and ScreenConnect on the same endpoint.
• Legitimate binaries. The operation retrieves official RMM installers, reducing reliance on custom malware and allowing activity to resemble normal administration.
• Rotating infrastructure. ScreenConnect instances, custom domains, compromised websites, GitHub Pages, Netlify, Dropbox, and GitHub-hosted payloads can be replaced independently.
• Reusable lure framework. The same fake Microsoft Store model supports Teams and Zoom narratives and can be adapted to other workplace brands.
• Source-controlled operations. Repository history enables rapid changes, preserves prior delivery logic, and exposes a continuous development process.
• Interactive follow-on activity. The operators use their RMM access to inspect endpoint security and privilege posture before deciding how to proceed.

These characteristics make the campaign more resilient than a single-domain, single-loader intrusion. Disrupting one URL or one RMM instance may not remove the operator's remaining access path or stop the next version of the delivery chain.

10. Detection and mitigation opportunities

Email and web controls

• Treat unsolicited "secure document," meeting, transcript, and software-update narratives as a combined risk signal, especially when the link resolves through a compromised business website.
• Inspect redirect chains and final downloaded content rather than relying only on the reputation of the first domain.
• Hunt for cloned Microsoft Store pages using titles such as "Microsoft Store - Microsoft Teams" and for pages that present an update requirement before a document or meeting can be accessed.
• Block or investigate newly observed custom domains that resolve to GitHub Pages or Netlify when they present workplace-application download pages.

Endpoint controls

• Alert on hidden PowerShell launched by an unexpected Inno Setup executable from the user download or temporary directory.
• Detect Invoke-WebRequest or equivalent transfer commands that download level.msi or ScreenConnect.ClientSetup executables, followed by msiexec or immediate execution.
• Alert on msiexec command lines containing LEVEL_API_KEY when Level RMM is not an approved enterprise tool or when the enrollment key does not match the organization's tenant.
• Monitor wscript.exe and cscript.exe launching scripts with software-installer names from Downloads or temporary directories, particularly when the script downloads an RMM agent and requests elevation.
• Inventory installed RMM products and investigate any new Level, ScreenConnect, Tactical RMM, or MeshAgent service that cannot be tied to an approved administrator or deployment system.
• Correlate RMM-originated PowerShell with discovery commands involving BitLocker, Windows Firewall, reboot status, or local administrator membership.

RMM governance

• Maintain an explicit allowlist of approved RMM products, server domains, tenant identifiers, publisher certificates, and enrollment keys.
• Use Windows Defender Application Control, AppLocker, EDR application controls, or equivalent policy to block unapproved remote-management products and installers.
• Require MFA and strong administrative controls for approved RMM platforms, and monitor creation of new agents, sites, API keys, and unattended-access sessions.
• When unauthorized RMM enrollment is found, isolate the host, remove every installed remote-access channel, rotate affected credentials, and investigate actions performed through the RMM console.

Example Microsoft Defender XDR hunting logic

// Level RMM enrollment through PowerShell and msiexec
DeviceProcessEvents
| where ProcessCommandLine has_all ("level.msi", "LEVEL_API_KEY")
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName

// Suspicious RMM downloads by PowerShell
DeviceProcessEvents
| where ProcessCommandLine has_any ("ScreenConnect.ClientSetup", "tacticalagent", "level.msi")
| where ProcessCommandLine has_any ("Invoke-WebRequest", "Start-BitsTransfer", "curl")

// JScript-based fake installer execution
DeviceProcessEvents
| where FileName in~ ("wscript.exe", "cscript.exe")
| where ProcessCommandLine has_any ("ZoomInstallerSetup.js", "TacticalAgent")

The example queries are intended as starting points. Approved RMM use varies by organization, so detections should incorporate authorized domains, tenant identifiers, installation tools, and administrative accounts to reduce false positives.

11. MITRE ATT&CK mapping

12. Indicators of compromise

The following indicators were observed in the investigated campaign and connected repositories. URLs and domains are obfuscated for safe publication. Historical infrastructure may no longer be active. Active enrollment secrets are intentionally omitted.

Domains and hosting infrastructure

Repositories and campaign-development evidence

Payload URLs

File hashes (SHA-256)

Conclusion

Operation BlueDash is not an isolated fake Teams page and not a single RMM installer. It is a continuously developed phishing and remote-access operation whose operators rotate workplace brands, compromised sites, custom domains, cloud-hosting services, payload formats, and RMM platforms while preserving the same objective: durable interactive control of victim endpoints.

The repository history provides an unusually clear view of that evolution. Earlier versions delivered ScreenConnect directly. Later revisions introduced SupportDev and Level RMM, retained ScreenConnect as a second path, and connected the infrastructure to a Zoom campaign that eventually used JScript to deploy Tactical RMM. The commands executed after enrollment show that the operators did not stop at installation; they assessed endpoint security and privilege posture through the remote-management channel.

By following the chain from the email to the active RMM environment and then back into the development repositories, ZeroBEC advanced the activity beyond the "unknown actor" framing of earlier reporting. ZeroBEC assesses that the connected campaigns were intentionally developed and operated by a specific Nigeria-based developer group.

Why ZeroBEC

ZeroBEC provides AI-native email security. Because our solution understands exactly how our customer's mailboxes, users, and tenants behave under normal conditions, we are positioned to detect abnormal patterns and prevent these multi-layered attacks.

While individual pieces of Operation BlueDash (a "secure document" narrative, a compromised business website, a fake Microsoft Store page, a signed installer, an official RMM binary) might evade static rules and domain-reputation lookups, ZeroBEC correlates sender behavior, message context, and recipient history. For Microsoft 365 organizations, this AI-native baseline is what identifies the attack before the counterfeit update ever reaches the user.