What happened
Microsoft observed the campaign in July 2026. Phishing lures included meeting invitations, Zoom and Google Meet themes, RSVP requests, PDFs, Adobe content and software-update prompts. Microsoft observed a legitimate, digitally signed MSP360 RMM v2.5.0.67 installer distributed under deceptive filenames. Microsoft published SHA-256 108ef7e628d7a20bd6241a5b57149e27a6061f467123eb64061975559f8f73dc for the MSP360 RMM agent installer. Victims had to execute the installer and complete a User Account Control elevation step for the full deployment to succeed.
Successful installations created RMM.Agent.exe and RMM.Agent.Launcher.exe services under C:\Program Files\RMM Agent. The MSP360 installation created an inbound UDP firewall rule for RMM.Agent.exe on port 48678. Microsoft says the MSP360 agent invoked PowerShell to download and silently install a ConnectWise ScreenConnect client, establishing a second remote-access channel. The operator then used ScreenConnect to transfer and execute additional tooling supporting credential access, information collection and other post-compromise activity.
Microsoft published its technical findings on September 29, 2026. The company explicitly said it did not observe exploitation of ScreenConnect itself; the campaign abused legitimately obtained remote-administration software. Microsoft also published Defender hunting queries covering the MSP360 hash, PowerShell spawned by RMM.Agent.exe, ScreenConnect network connections and payloads launched through ScreenConnect processes. The cited sources did not publish a confirmed victim count or actor identity. Attribution posture: Microsoft did not name a threat actor or establish a specific criminal, ransomware or state-sponsored operator.
Why this matters now
This campaign uses legitimate, digitally signed administration software rather than relying solely on conspicuous malware. That allows attacker activity to resemble normal support operations and creates a difficult question for SOC teams: whether an observed process is approved tooling, shadow IT or an adversary-controlled tenant. Deploying two RMM products gives the operator redundant access if one channel is discovered or removed.
The lures mirror ordinary enterprise workflows, including meeting invitations, PDF documents and software updates. Successful installation requires user execution and elevation, but the resulting services, autorun entries, PowerShell activity and firewall changes create durable signals that can be detected if security teams maintain a baseline of authorised remote-management software.
The newly published hash, paths, service names and hunting queries make the campaign actionable today. The strategic decision is broader than blocking one file: security leaders need a governed RMM inventory, application-control policy, tenant-aware network monitoring and a time-bound process for approving exceptions used by internal IT and external support providers.
The decision for security leaders
Mandate a tenant-aware RMM governance model. Product-name approval is insufficient because an attacker can deploy a legitimate client connected to an unauthorised management tenant. The authoritative inventory should record product, publisher, tenant, installer source, service owner, managed assets and expiry date.
Direct endpoint and SOC teams to detect behavioural combinations rather than treating signed binaries as trusted. High-value combinations include a user-launched installer from Downloads, UAC elevation, new RMM services, PowerShell retrieving an MSI, ScreenConnect installation and subsequent credential-access tooling.
Require exceptions for external support providers to be explicit and time-bound. Contracts and onboarding processes should specify approved tools, tenant identifiers, authentication controls, logging access, permitted hours and immediate revocation procedures.
Evidence of closure
- The RMM inventory maps every installed client and tenant to an approved owner.
- Hunt results document disposition for the published hash, services, paths and firewall rule.
- Application-control policy blocks unapproved RMM installers without disrupting authorised support tooling.
- Confirmed affected endpoints show both remote-access channels removed and exposed credentials reset.
The Security.io assessment
The direct Microsoft telemetry supports the installation chain, persistence mechanisms and published hash with high confidence. It does not support claims that ScreenConnect or MSP360 vulnerabilities were exploited. Blocking the products indiscriminately may disrupt legitimate administration while failing to address other RMM tools that can provide the same capability.
The cited sources did not publish a confirmed victim count or actor identity. The campaign was observed earlier, but the September 29 disclosure supplies hunt-ready evidence that changes today’s operational posture. Organisations can now test for the known installer and persistence chain while using the event to close broader RMM inventory gaps.
Attribution posture: Microsoft did not name a threat actor or establish a specific criminal, ransomware or state-sponsored operator. Escalation should depend on evidence of unauthorised remote access, credential activity and follow-on tooling rather than assumptions about the operator’s ultimate objective.
Questions for the morning meeting
- Does the organisation maintain a complete allow-list of authorised RMM products, tenants, installers and service owners?
- Can endpoint controls distinguish approved ScreenConnect or MSP360 use from newly installed, attacker-controlled instances?
- Are service-desk and IT administrators alerted when remote-management services or inbound firewall rules appear unexpectedly?