Executive Summary

Microsoft published analysis on September 29, 2026 of phishing campaigns from July 2026 that deliver legitimate remote monitoring and management software as the payload. The initial agent is MSP360 RMM v2.5.0.67, distributed through masqueraded installers; ConnectWise ScreenConnect follows as a second, independent access channel. Microsoft has not attributed the activity to a named actor and tracks it as unattributed.

Separately, ANY.RUN research covered by The Hacker News on September 3 maps a broader RMM phishing operation spanning 46 countries, with around 45% of observed activity associated with the United States and 601 total cases identified. The infrastructure numbers are the most operationally useful part of that research: 425 kit URLs across 240 hosts, 94% of which were observed for only a single day.

The structural point is in the title. Two RMM agents on one host is not a configuration error and not redundancy for the operator's convenience. It is defence in depth against your incident response. Removing the agent you found does not end the intrusion, and that is the design.

AttackAttack Overview

RMM abuse inverts the normal detection problem. There is no malware to identify. MSP360 and ScreenConnect are real commercial products, properly signed, doing precisely what their documentation says they do: providing remote access and management. Every behavioural heuristic that fires on a remote access tool fires correctly, and every one of them is also true of the legitimate deployment running in some other organisation right now.

That makes this an allow-list problem rather than a detection problem, and allow-list problems are organisationally harder. Identifying a malicious binary requires a signature. Identifying an unauthorized RMM agent requires knowing which RMM agents are authorized — which, in most enterprises, nobody has written down.

The delivery side is conventional phishing with good production values. Microsoft observed actor-controlled landing pages impersonating document portals, Adobe Reader, Zoom and collaboration platforms, with redirection into payload hosting. Lure themes include workplace meeting requests, Zoom and Google Meet prompts, Adobe Acrobat updates, RSVP invitations, job offers and DHL package delivery. ANY.RUN's regional view adds Canada Revenue Agency tax forms, shipping and UPS material, US Social Security Administration themes and invoices — the campaign was initially read as Canadian-focused because of the CRA lures before the wider scope became clear.

AttackOperator Workflow

The victim lands on a page impersonating something ordinary and downloads what appears to be an installer or document viewer. Microsoft's observed filenames are worth reading closely because they leak the campaign's own tooling conventions:

`VIP_ECARD_INVITATION_rmm_v2.5.0.67_oid[redacted].exe`

`ZoomSetup_Installation_v2.5.0.67_oid[redacted].exe`

The pattern is lure theme, then the literal product version, then an `oid` parameter that is almost certainly a per-deployment organisation identifier tying the installed agent back to the operator's tenant. The lure prefix rotates; `rmm_v2.5.0.67` and the `oid` structure do not. That makes the filename convention itself a hunting string, which is a rare gift in a campaign that otherwise rotates infrastructure daily.

Execution installs genuine MSP360 RMM. The user sees an installer behave like an installer. Nothing is injected, nothing is packed, nothing triggers a heuristic for obfuscation, because there is no obfuscation — the file is what it says it is.

Persistence is then provided by the product itself. The installation registers Windows services for `RMM.Agent.exe` and `RMM.Agent.Launcher.exe`, creates registry autorun entries for the MSP360 UI components, and adds an inbound Windows Firewall allow rule for UDP traffic on port 48678. Each of these is legitimate installer behaviour. An operator gets a service-backed, autorun-persisted, firewall-permitted remote access channel without writing a line of persistence code.

With remote access established, ScreenConnect is deployed as a second channel, adding its own Windows services with configuration parameters pointing at actor infrastructure. Microsoft also observed `FaronicsDeployAgent.exe` used the same way in related activity, which suggests the pattern generalises across RMM products rather than depending on MSP360 specifically.

AttackInfrastructure & Tradecraft

Payload staging ran across Amazon S3, Cloudflare R2, Dropbox, GitLab and Supabase in Microsoft's reporting, with ANY.RUN adding Vercel, GitHub Pages, Netlify, DigitalOcean Spaces and GoFile. This is the same serverless and trusted-cloud staging pattern visible in the EvilTokens infrastructure and in this quarter's ClickFix delivery — three unrelated campaign families converging on the same hosting strategy because it defeats the same control.

The ANY.RUN infrastructure statistics quantify why delivery-side blocking fails here. With 425 kit URLs across 240 hosts and 94% observed for a single day only, any control that depends on knowing a URL is bad before a user visits it is operating on a one-day window at best. Reputation systems, blocklists and threat-intel feeds all have latency longer than the lifespan of the average host in this campaign.

The known indicators are narrow but worth deploying, with the caveat that they will age quickly. Microsoft published the MSP360 installer hash `108ef7e628d7a20bd6241a5b57149e27a6061f467123eb64061975559f8f73dc` and ScreenConnect C2 domains `adswre[.]cfd`, `trews[.]cfd` and `swedcorry[.]stefneyv[.]com`. Defender flags the installer as `SupportScam:Win32/RogueMSP.MU!MTB` and surfaces the behaviour through "Suspicious usage of remote management software" and "Uncommon remote access software."

Note what the Defender detection names imply. Both are phrased around the tool being unexpected rather than malicious — "suspicious usage," "uncommon." Even the vendor detection is fundamentally an allow-list judgement.

DetectionDetection Opportunities

Start with the hash, deploy it today, and do not rely on it tomorrow.

let MSP360RMM = "108ef7e628d7a20bd6241a5b57149e27a6061f467123eb64061975559f8f73dc";
DeviceFileEvents
| where Timestamp >= ago(30d)
| where SHA256 =~ MSP360RMM
| project Timestamp, DeviceName, FileName, FolderPath,
          InitiatingProcessFileName, InitiatingProcessAccountName

The filename convention is more durable than the hash because it reflects the operator's build process rather than a single compiled artifact.

DeviceFileEvents
| where Timestamp > ago(30d)
| where FileName endswith ".exe"
| where FileName matches regex @"(?i)_rmm_v\d+\.\d+\.\d+\.\d+_oid"
      or (FileName has "_oid" and FileName has_any ("rmm", "Setup_Installation"))
| project Timestamp, DeviceName, FileName, FolderPath, SHA256,
          InitiatingProcessFileName

The strongest and longest-lived rule is the allow-list rule. Enumerate RMM agent processes and service names across the estate and alert on anything outside the approved set. This requires you to define the approved set, which is the real work.

let ApprovedRMM = dynamic(["YourApprovedTool.exe"]);
let RMMBinaries = dynamic([
    "RMM.Agent.exe", "RMM.Agent.Launcher.exe", "ScreenConnect.ClientService.exe",
    "ScreenConnect.WindowsClient.exe", "FaronicsDeployAgent.exe",
    "AnyDesk.exe", "TeamViewer.exe", "atera_agent.exe", "SplashtopStreamer.exe",
    "ltsvc.exe", "Syncro.Service.exe", "aemagent.exe"
]);
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ (RMMBinaries)
| where FileName !in~ (ApprovedRMM)
| summarize FirstSeen = min(Timestamp), LastSeen = max(Timestamp),
            Tools = make_set(FileName), ExecCount = count()
    by DeviceName
| extend ToolCount = array_length(Tools)
| order by ToolCount desc, FirstSeen desc

That final `ToolCount` column is the dual-RMM detection. A host running two unapproved RMM products is a far stronger signal than a host running one, because the second agent has no innocent explanation — nobody accidentally installs two competing remote management suites.

The persistence artifacts give a complementary angle that catches the install even if the process rule has a gap. The firewall rule for UDP 48678 is unusually specific.

DeviceEvents
| where Timestamp > ago(30d)
| where ActionType == "FirewallRuleAdded"
| where AdditionalFields has "48678" or AdditionalFields has_any ("MSP360", "RMM.Agent")
| project Timestamp, DeviceName, ActionType, AdditionalFields,
          InitiatingProcessFileName, InitiatingProcessAccountName

ValidationValidation Workflow

Validate in an authorized lab host enrolled in your test tenant, with no production credentials and a rollback snapshot.

The allow-list rule is the one to prove first, and it is also the one most likely to be wrong in a way nobody notices. Install an RMM product that is not on your approved list — any legitimate trial agent will do — and confirm the rule fires with the correct `DeviceName` and tool name. Then install your genuinely approved agent and confirm it does not fire. If you do not have a documented approved list, that failed test is the finding, and it is more valuable than the rule.

Next, validate the dual-agent escalation. With the first unapproved agent still installed, add a second, and confirm `ToolCount` increments and the host rises to the top of the ordering. The whole point of the rule is that it ranks dual-agent hosts above single-agent hosts, and that ordering is worth seeing work before you depend on it in an incident.

Validate the persistence rules independently, because they catch different moments. During the agent install, confirm the firewall rule event records and that `AdditionalFields` actually contains the port or product string your query matches — field contents vary by sensor version, and a query matching a string that is not there fails silently.

Finally, run a retrospective sweep rather than a live test for the filename regex: search thirty days of historical `DeviceFileEvents` for the `_oid` pattern across the real estate. If it returns results, you have an incident rather than a validation exercise, which is the correct outcome to discover during validation.

GapsEvasion & Gaps

The hash has a shelf life measured in days. It identifies one build of one installer in a campaign that rotates hosting every twenty-four hours. Deploy it, but do not let it anchor the strategy.

The filename regex is more durable but still brittle, because it keys on the operator's current naming habit. A one-line change to their build script removes it. It is a hunting string, not a control.

The allow-list rule has the opposite profile — it is durable in principle and fragile in practice, because it depends entirely on the quality of the approved list and on the completeness of the RMM binary inventory. The list above is not exhaustive; there are dozens of RMM products, and an operator who selects one you did not enumerate is invisible to the rule. Worse, if your own IT or an MSP partner legitimately uses one of the products on the list, you will either allow-list it — creating an exception an operator can hide inside — or drown in false positives. Organisations with multiple MSP relationships have genuinely hard problems here.

The dual-agent signal has a timing gap. It works when both agents are present simultaneously. An operator who installs the second agent only after the first is discovered and removed never produces a host with two concurrent agents, and the detection never fires. Retaining historical process telemetry long enough to see sequential agents on the same host is the mitigation, and it is a data-retention decision rather than a detection one.

None of these rules address the user decision. The victim downloaded and ran a signed installer from a page that looked like Zoom. No endpoint control fires on that, and the one-day lifespan of the hosting means no reputation control reliably fires on it either.

Defensive Recommendations

Write down which RMM products are authorized, and for which teams. This is the highest-leverage action available and it is not a security engineering task — it is an inventory task that unlocks every detection above. Without it, the allow-list rule cannot be written and the vendor's own "uncommon remote access software" detection has no definition of common to work from.

Deploy application control. Microsoft's recommendation is explicit: use Application Control or AppLocker to block unapproved IT management tools. This converts the problem from detection to prevention, and it is the only control that stops the install rather than reporting it. For most organisations the RMM category is an unusually good candidate for allow-listing, because the legitimate set is small, stable, and known.

Enforce multi-factor authentication on the RMM systems you do approve, so that a compromised operator console does not become a distribution channel of its own.

Enable cloud-delivered protection in Defender Antivirus and switch on attack surface reduction rules, including advanced protection against ransomware — the staging infrastructure rotates too quickly for signature-only protection to keep pace.

On response, assume the agent you found is not the only one. The dual-RMM design means that removing MSP360 and closing the incident leaves ScreenConnect running under its own service with its own C2. Sweep the host for every RMM product in your inventory list, not just the one that alerted, and check the firewall rules and autorun entries the first install created even after the binary is gone. The campaign's entire persistence model is built on the expectation that responders will find one agent and stop looking.