Operation BlueDash Ships No Malware. It Ships ScreenConnect, and Your EDR Is Fine With That.

ZeroBEC has documented a campaign they call Operation BlueDash. The chain is short and it works.

A Teams-themed phish with a secure document lure. The victim clicks and is routed through compromised legitimate web infrastructure to a counterfeit Microsoft Store page. That page says Microsoft Teams has to be updated before the shared document can be opened. The victim updates Teams.

What installs is Level RMM or ScreenConnect. Real, signed, commercially licensed remote monitoring and management software. The attacker now has hands-on-keyboard administrative remote access to the endpoint, and every process on the box is legitimate.

There is no malware in this attack. That is not a weakness of the attack. That is the attack.

Why the hash-based defence has nothing to bite

Walk the chain and ask what each of your controls sees.

Your email gateway sees a Teams-themed message. Teams-themed messages are the highest-volume legitimate category in most inboxes.

Your web filter sees a redirect through compromised legitimate infrastructure — a real site with real history and real reputation, which is why attackers pay for compromised sites instead of registering new domains.

Your endpoint agent sees a signed installer for commercial software with a valid certificate, published by a company that sells to managed service providers. Not a suspicious binary. Not a packed loader. Not something with a bad reputation score. A product your own IT department might legitimately deploy.

And your user sees a Microsoft-branded page telling them to update Teams before opening a document — which is, and this is the uncomfortable part, exactly what a real Teams update prompt looks like. We have trained an entire workforce to click update. This campaign is not defeating security awareness training. It is using it.

So the standard defensive stack produces nothing to block. No hash worth adding to a blocklist, because the hash is a legitimate vendor's installer and blocking it would break the customers who license it. No domain worth blocking permanently, because the delivery host is a compromised legitimate site that will be cleaned up. This is what living-off-trusted-tools means when it is done properly, and it is why we keep saying the perimeter is not where the fight is any more.

The detail that turns this from clever to dangerous

Here is the part that deserves to be better known.

If the target's organization already runs ScreenConnect legitimately — which describes an enormous number of businesses that use a managed service provider, because ScreenConnect is how MSPs do support — then clicking the attacker's link can join the victim straight into a live remote session controlled by the attacker. No install step. No prompt that looks unusual. The client is already there and trusted; the attacker is simply supplying the session.

Read that again if you are an MSP customer. The remote-support tool your provider installed to help you is the delivery mechanism. The presence of the legitimate agent makes you easier to attack, not harder, because it removes the only step in the chain that might have looked odd.

That inverts the usual advice. Normally we tell people that having managed IT is a security upgrade, and usually it is. Here, the trusted tool is the soft surface, the hard perimeter held perfectly, and the bleed went straight through the trusted middle. Same shape as the AI support-bot takeovers and the OAuth integration breaches we have catalogued: the attack does not break the strong boundary, it walks in through the trusted connection that was built to bypass it.

This is a category, not an incident

BlueDash is not novel and we are not going to pretend it is. Signed RMM abuse via workplace-app lures is one of the best-documented patterns of the past two years. Microsoft's security team published on signed malware impersonating workplace apps to deploy RMM backdoors in March. Netskope has written up signed RMM tools delivered through Zoom, Meet and Teams lures. Red Canary catalogued four distinct phishing lures dropping RMM tools. Huntress has been documenting rogue ScreenConnect social engineering since 2025.

The reason to write about it again is that the volume of published research has not translated into deployed controls. Everybody has read about RMM abuse. Very few organizations have actually built the one control that stops it, which is not a detection at all.

The control that actually works

You cannot block RMM software by reputation. You can block it by policy.

Decide which RMM tools are authorized in your environment. Write the list down. Block everything else by default.

That is it. That is the whole defence, and it works against this campaign, the next one, and every variant of it, because it does not care what the lure was or which vendor got impersonated. If ScreenConnect is your MSP's tool and it is on the list, fine. If Level RMM is not something you have ever licensed, its installer should not be able to run on any endpoint you own, regardless of who signed it.

Concretely, tonight:

Inventory what RMM agents are actually installed right now. Most organizations discover at least one they did not know about — left over from a former provider, installed by a department that solved its own problem, or already dropped by somebody like this. Do this before you write the allowlist, because you need to know what you are grandfathering in.

Enforce the allowlist with application control. Windows Defender Application Control or AppLocker on Windows; whatever equivalent your EDR offers. Block-by-default on the RMM category specifically. This is a narrow, low-breakage policy compared with general allowlisting, which is why it is achievable for small teams.

Alert on relay and tenant mismatch, not on the binary. This is the detection that catches the nastiest version of the attack. If you legitimately run ScreenConnect, your agent talks to a known relay endpoint belonging to your provider's instance. An attacker-supplied session talks to a different one. A ScreenConnect client connecting to an unfamiliar relay is the signal — the process name and the signature will both look perfect. Get your provider's legitimate relay host and instance identifier, and alert on anything else.

Alert on RMM installers executing from user-writable paths. A legitimate deployment comes from your management platform, not from a Downloads folder. Same binary, completely different meaning depending on where it launched from and who launched it.

Tell your people the specific lie. Generic phishing training does not cover this. The specific lie is: a document will never require you to update Teams first. Teams updates itself, silently, through Microsoft's own channel. Any page that tells you to update Teams to open a file is an attack, one hundred percent of the time, no exceptions. That single sentence is more useful than an hour-long training module.

Ask your MSP two questions. Which relay does your ScreenConnect instance use, and can you confirm session logs for the past thirty days show no sessions you did not request? Their answer to the second question tells you a lot about the provider.

What we cannot give you, and why we are saying so

We normally close a campaign post by putting the indicators into our free feed so anyone can pull and block them. We cannot do that here yet.

ZeroBEC's research is the primary source, and their published indicators are not retrievable from where we sit — their site returns a 403 to us. The syndicated coverage carries the narrative and the tooling names but no domains, no addresses, no hashes. We are not going to invent them, and we are not going to launder somebody else's feed under our own name and call it a DugganUSA observation.

We also checked our own corpus honestly and it came up empty. We hold no attributed ScreenConnect-abuse or Level RMM indicators. That is a genuine gap in our coverage of a category we clearly should be covering, and naming it is more useful than implying otherwise. It is now on the list.

When BlueDash indicators become publicly available, they go into the feed with a campaign-specific source tag so anyone can pull, block, and audit them. Until then the allowlist above is the deliverable, and frankly it is the better one — an indicator list expires the week the infrastructure rotates, and an RMM allowlist keeps working next quarter.

We are 95 percent confident this pattern accelerates through the rest of the year, because the economics are unbeatable for the attacker: legitimate signed tooling, no development cost, no detection surface, and a lure that exploits behaviour we deliberately taught users. The remaining five percent is the chance that RMM vendors themselves start enforcing tenant-level install restrictions that break unsolicited deployment. That would be the real fix, and it belongs to them, not to us.

Credit to ZeroBEC for the research and the naming, and to Microsoft, Netskope, Red Canary and Huntress for the prior work that makes this recognizable as a category rather than a surprise.

Free IP, domain, hash, and malicious-package blocklists at analytics.dugganusa.com.

---

Her name was Renee Nicole Good.

His name was Alex Jeffery Pretti.