As reported by The Hacker News, Microsoft has documented a phishing campaign abusing a digitally signed MSP360 RMM installer as an initial access vector, subsequently deploying ConnectWise ScreenConnect to establish a redundant remote-control channel on compromised Windows endpoints. The activity, detected in July 2026, remains unattributed and underscores a persistent and growing problem: threat actors don't need malware when legitimate administrative software does the job better.

Threat Alert: As reported by The Hacker News, Microsoft has documented a phishing campaign abusing a digitally signed MSP360 RMM installer as an initial access vector, subsequently deploying ConnectWise ScreenConnect to establish a redundant remote-control channel on compromised Windows endpoints.

Why This Pattern Keeps Succeeding

The core issue isn't novel, but it bears repeating with emphasis. RMM tools — MSP360, ScreenConnect, AnyDesk, TeamViewer, NinjaRMM, Faronics Deploy — are designed to do exactly what attackers need: execute commands, transfer files, maintain persistence, and operate with SYSTEM-level privileges. They ship with valid digital signatures, appear on allow-lists by default, and generate traffic that blends into normal IT operations. When an EDR sensor sees a signed, recognized installer executing, it has little reason to raise an alarm.

What makes this campaign particularly effective is the dual-RMM architecture. By deploying MSP360 first and then using it to install ScreenConnect, the attacker gains two independent control channels. If a security team discovers and removes one tool, the other remains functional. This redundancy also means that even if one vendor revokes a certificate or pushes an update that breaks attacker workflows, the intrusion survives. The separate Faronics Deploy variant Microsoft observed confirms this is a flexible playbook, not a one-off tooling choice.

The attacker's advantage isn't technical sophistication — it's the operational camouflage that legitimate software provides within environments where IT teams themselves can't always account for every installed agent.

What Defenders Are Actually Up Against

Several design choices in this intrusion chain deserve attention because they complicate detection:

What Defenders Are Actually Up Against
Signed binaries, deceptive names: The installer carries MSP360's legitimate signature but runs under names like VIP_ECARD_INVITATION_rmm_v2.5.0.67_oid[redacted].exe or ZoomSetup_Installation_v2.5.0.67_oid[redacted].exe. Signature validation passes; filename scrutiny typically does not.
Cloud-hosted payloads: Staging on Amazon S3, Cloudflare R2, Dropbox, GitLab, and Supabase means download traffic looks like ordinary consumer or DevOps activity. Egress filtering to these domains is rarely feasible.
Living-off-the-land persistence: Windows services, registry autoruns, and firewall modifications for UDP port 48678 are all standard admin operations. Individually, none are suspicious — collectively, they form a coherent intrusion chain that most detection rules will miss.
Post-install activity uses native functionality: ScreenConnect's RunFile capability executes additional payloads without needing custom tooling, keeping the attacker's footprint minimal.

Who Is Most Exposed

Organizations that already use MSP360 or ScreenConnect for legitimate administration face the highest risk of operational blindness — a new or unexpected instance of a tool you already deploy may not trigger investigation. Small and midsize businesses without centralized IT asset management are also heavily exposed, as are environments where individual departments or contractors install RMM tools independently of IT governance.

Shield53 Recommendations

This is a detection and governance problem, not a patching problem. No vulnerability in MSP360 or ScreenConnect is being exploited — the tools are working as designed. The defensive gap is in knowing what's supposed to be there.

  • Inventory authorized RMM tools today. Maintain a living list of every approved remote management product, expected version, and expected installation scope. If it isn't on the list, investigate it.
  • Alert on RMM installer execution from non-standard paths. Detect when known RMM installers (MSP360, ScreenConnect, Faronics, AnyDesk) execute from %TEMP%, %Downloads%, or user-writable directories rather than IT-managed deployment paths.
  • Monitor for dual RMM coexistence. Two or more RMM agents running on the same endpoint — especially if one was installed recently — is a high-fidelity signal of compromise or at minimum policy violation.
  • Correlate firewall changes with RMM installation events. The MSP360 installer opens UDP 48678. Alert when inbound firewall rules are created within a short window of a new service registration.
  • Block RMM installer execution at the email/browser boundary. Application control (WDAC, AppLocker) or EDR containment rules can prevent user-context execution of RMM installers unless initiated by an administrative identity.
  • Hunt for the specific indicators. Search endpoint telemetry for service registrations of RMM.Agent.exe and RMM.Agent.Launcher.exe, especially when preceded by a UAC elevation prompt and a download from a consumer cloud storage domain.
  • Tighten email filtering for executable attachments and external links. The lures are socially conventional — meeting invites, e-cards, government notices — but the payloads are .exe files hosted on external infrastructure. Strip or quarantine executable attachments and rewrite external links for user confirmation.

The broader industry challenge is that RMM abuse will continue as long as these tools remain trusted by default within operating environments. CISA's 2023 advisory on RMM abuse flagged this exact pattern, and the problem has only expanded since. Organizations that haven't implemented allow-listing for remote management software should treat this as an urgent gap — the next campaign will use a different vendor's signed binary, and the detection logic needs to be tool-agnostic to keep pace.