In short: attackers are installing two remote access tools for redundancy, so any request for remote access to your server or computer should be verified through a second channel before you agree.
Table of Contents
An email arrives that looks like a meeting invitation, or a PDF reader update, or a Zoom setup file. Someone clicks it expecting exactly what the filename promises. What actually installs is a real, legitimately signed remote monitoring and management tool, the same category of software IT teams use every day to support client computers, except this install didn’t come from anyone’s IT team.
That’s the attack chain The Hacker News reported, citing Microsoft’s own security research team, in a campaign abusing MSP360, a legitimate RMM platform. The installer drops the real MSP360 agent, elevates itself through a UAC prompt, registers as a Windows service, and then uses that initial access to quietly deploy a second remote access tool, ScreenConnect, through PowerShell. The report calls this “dual-RMM”: two separate remote administration channels on the same compromised machine, deliberately redundant, so that losing one doesn’t cost the attacker their access.
Why Redundant Remote Access Is the Actual Innovation Here
The technically interesting part of this campaign isn’t the phishing email itself; disguised installers are not new. It’s the decision to install two unrelated remote access tools rather than one. Microsoft’s analysis is direct about the reasoning: the combination “provided the threat actor with redundant remote administration channels and enabled the transfer, execution, and management of additional tooling.” If a victim’s antivirus flags MSP360 and removes it, ScreenConnect is already sitting there as a second, independent way back in. If IT notices ScreenConnect and shuts it down, MSP360 is still running.
This is a meaningfully harder problem for a defender than the usual “we found malware and removed it” story, because removing the thing you found doesn’t actually end the incident. For a small business without a dedicated security team watching for exactly this pattern, that’s the detail most likely to get missed: cleaning up the obvious infection while a second, quieter one keeps running.
Legitimate Software Is the Whole Point of the Trick
Both MSP360 and ScreenConnect are real, digitally signed, widely used products. Plenty of actual IT support companies use one or both to service client machines remotely every day, which is exactly why this attack works. A security tool or an alert IT administrator looking for “malware” on a network won’t flag a signed, legitimate RMM installer the way they’d flag an obvious trojan, because in a huge number of environments, that same software is supposed to be there.
Small businesses are disproportionately exposed to this specific trick for a structural reason, not a technical one: fewer of them have a dedicated, in-house security team monitoring for unauthorized software installs, and more of them already have some kind of outside IT support relationship that occasionally does install remote access tools legitimately. That familiarity is the cover. An employee who’s used to “the IT guy” occasionally installing something to fix a problem has less reason to pause and question a new remote access prompt than someone who’s never seen one before.
Why This Isn’t a “Just Train Employees to Spot Phishing” Problem
The realistic failure here isn’t an employee being careless. It’s that a correctly suspicious employee has no reliable, in-the-moment way to tell a real IT support request from a convincing fake one, because both can look and feel identical: a plausible email, a familiar-sounding software name, an installer that runs without obvious red flags, and in many cases a real digital signature on the file itself. “Be more careful” doesn’t solve a problem where careful people are still fooled, because the thing they’d need to catch isn’t a spelling mistake or a sketchy-looking link; it’s the absence of a channel to actually confirm the request is real.
A Verification Process That Actually Works for a Small Business
What a small business without a security team can realistically do is build one specific habit: before anyone installs or allows a remote access tool, verify the request through a channel that’s separate from however the request arrived. If an email claims to be from your IT provider, don’t click through it to “confirm”; call the IT provider’s known phone number or message them on a previously established channel and ask directly whether they just sent something. If the answer is no, you’ve just stopped the entire attack chain before it started, regardless of how convincing the email or file looked.
This same principle extends to any unsolicited contact claiming IT, hosting, or technical support needs remote access right now to fix something urgent. A real support interaction you didn’t initiate, with urgency built in as pressure, is a pattern worth treating with suspicion by default, not trust. Any hosting provider or IT vendor that occasionally needs legitimate remote access to a server should be someone you can verify through account documentation or a support ticket history, not someone whose only proof is an email that showed up unprompted.
It’s also worth periodically checking what remote access software is actually installed across your business’s computers and server accounts, rather than assuming you’d notice a new one appearing. A quick audit of installed programs and running services, even an informal one done once a quarter, catches a dual-RMM style compromise that’s sitting quietly in the background exactly the way this campaign is designed to.
What to Do If Something Already Got Installed
If a remote access tool you don’t recognize turns up during that kind of check, the dual-RMM pattern documented here means finding one doesn’t mean the job’s done. Change credentials for anything that tool could have touched (server access, hosting control panel, any stored passwords in a browser on that machine) and specifically look for a second remote access tool before declaring the incident closed, since Microsoft’s own research is explicit that attackers using this technique plan for exactly that outcome. Removing the first thing you find and assuming you’re finished is how the backup channel survives a cleanup.
For any business running its own server or VPS where this kind of persistent access would be especially damaging, this is also a good prompt to confirm who currently has legitimate remote or administrative access to that server, and whether every one of those entries is still something you’d approve today.
The Underlying Lesson
The published reporting offers no specific detection signature for this campaign, which is itself useful information: there isn’t a simple technical fix here, like a single setting to toggle or a pattern to block. What protects against this attack is a verification habit, not a piece of software. The moment anyone, inside your business or pretending to be someone who should have access to it, asks to remotely access a system, the question that matters isn’t whether the request looks professional. It’s whether you can confirm it through a channel the attacker doesn’t also control.
Related reading: Cloudflare Finally Fixed Certificate Transparency Alert Fatigue and The Hidden Security Risk in Your AI Chatbot’s MCP Server.