Phishing Abuses RMM Tools for Persistent Access

1. Executive summary

Between July and September 2026 Microsoft Defender Experts observed phishing campaigns that delivered a legitimate, digitally signed MSP360 RMM v2.5.0.67 installer under deceptive filenames, then used the installed agent to pull down a ConnectWise ScreenConnect client as a second remote access channel. The activity targeted organisations across multiple industries and Microsoft has not attributed it to a named actor. No CVE is involved: the actors abused signed, legitimate remote monitoring and management software, so signature-based controls and patch cycles do not apply. For EMEA financial services the exposure is operational rather than vulnerability-driven, because the same RMM capability that lets an administrator push software and run commands lets an intruder do it while blending into normal IT traffic. The verified reference data for this item is empty, so no CVSS score, severity rating or CISA KEV state is asserted here.

2. Regulatory framing

No other article in the regulatory reference is directly engaged by the facts in this item.

3. Technical analysis & attack chain

Microsoft tracked this as unattributed activity. No named threat actor is associated with it, and the verified reference data contains no MITRE ATT&CK profile for any actor in this item, so any attribution beyond "unattributed" is unconfirmed. The account below is drawn from a single vendor, Microsoft, with corroborating context from Huntress reporting on rogue RMM abuse; treat the specific file paths, service names and hashes as single-sourced until independently reproduced.

Confirmed chain, in the order Microsoft observed it:

1. Phishing email delivers a lure. Observed themes include workplace meeting requests, Zoom and Google Meet installation prompts, Adobe Acrobat and PDF reader updates, RSVP invitations and e-cards, job offer documents, document review and signature requests, and DHL and package-delivery content. Emails point to actor-controlled landing pages impersonating document-sharing portals, invitation workflows, Adobe Reader download pages, Zoom installation pages and business collaboration platforms.
2. Redirect to payload hosting. Victims are sent to download locations on attacker-controlled infrastructure and on legitimate cloud services: Amazon S3, Cloudflare R2, Dropbox, GitLab and Supabase. Microsoft notes the actor rotated delivery infrastructure quickly while serving the same installer under different lure themes and filenames. Observed filenames include VIP_ECARD_INVITATION_rmm_v2.5.0.67_oid[redacted].exe, ZoomSetup_Installation_v2.5.0.67_ oid[redacted].exe, and PDF Reader & Editor the Adobe Acrobatte_rmm_v2.5.0.67_ oid[redacted].exe. Analysis of the samples showed many of the differently named files contained the same MSP360 RMM installer package.
3. User executes the installer from the Downloads directory. The binary is a legitimate, digitally signed MSP360 RMM v2.5.0.67 installer. Microsoft reports the observed sample was signed with a certificate that has since been revoked. The installer drops System.dll, nsExec.dll and UAC.dll before relaunching itself through an elevation workflow generated by the installer framework.
4. UAC elevation. In successful installations the process continues with elevated privileges. Where elevation is denied or aborted, the installation terminates before MSP360 components are deployed and no persistence, services or remote management functionality appear. This is the single most useful control point in the chain: a denied UAC prompt stops the intrusion.
5. MSP360 installation and persistence. The installer writes status messages through eventcreate.exe under the event source MSP360 RMM Agent installer, with the messages "Begin installation" and "End installation. MSP360 de Success." It drops plugins and binaries into C:\Program Files\RMM Agent\, enumerates installed .NET runtimes with dotnet --list-runtimes, and registers two Windows services: RMM.Agent.exe and RMM.Agent.Launcher.exe. Microsoft observed events showing existing MSP360 services being stopped and new ones installed. Registry-based autorun entries are created for the MSP360 user interface components so the tray applications launch at sign-in.
6. Firewall modification. The installer creates an inbound allow rule for the MSP360 agent permitting inbound UDP to C:\Program Files\RMM Agent\RMM.Agent.exe on port 48678.
7. Second-stage download. The newly installed RMM.Agent.exe service launches PowerShell. That PowerShell process modifies the execution policy for the current session and runs Invoke-WebRequest to download an MSI named ClientSetup.msi from actor-controlled infrastructure.
8. Silent ScreenConnect install. The MSI is installed through msiexec.exe with the /qn switch, so no user interaction is shown. This deploys a ConnectWise ScreenConnect client including ScreenConnect.ClientService.exe, ScreenConnect.WindowsClient.exe and supporting components, plus Windows service registrations, application uninstall entries and authentication-related registry modifications. Microsoft states it did not observe exploitation of ScreenConnect itself; the actors used legitimately obtained remote administration software.
9. ScreenConnect command and control. The ScreenConnect client service launches with configuration parameters referencing actor-controlled infrastructure and establishes outbound communications, then spawns ScreenConnect.WindowsClient.exe. This gives a remote access channel independent of MSP360.
10. Post-compromise tooling. The actor transfers and stages executables in user Documents and Temp directories and executes them through ScreenConnect's built-in RunFile functionality, which transfers and runs files on managed endpoints. Several filenames were chosen to resemble legitimate Windows, Microsoft Defender, Phone Link and security-related components. Microsoft describes the tools as commonly associated with credential access, information collection, execution of additional payloads, and reducing defender visibility. The specific filenames were not reproduced in the source text supplied to us, so we do not list them.

Separate July activity used FaronicsDeployAgent.exe, a legitimate deployment and remote access application, in the same way: as the initial remote management platform, then to download and install ScreenConnect. Microsoft presents this as evidence that the ScreenConnect deployment is not limited to MSP360-based intrusions.

Microsoft's Defender coverage for the chain maps as follows: initial access is covered by SupportScam:Win32/RogueMSP.MU!MTB; execution by "Suspicious usage of remote management software" and "Uncommon remote access software"; persistence by "Anomaly detected in ASEP registry" and "Suspicious file registered as a service"; credential access by "Possible theft of passwords and other sensitive web browser information".

Confidence caveats. The chain above rests on one vendor report. The hashes, the port 48678 firewall rule, the service names and the eventcreate.exe event source strings are single-sourced. Huntress has separately documented rogue RMM abuse and ScreenConnect persistence in phishing campaigns, which corroborates the general pattern but not these specific artefacts. Verify before enforcing blocks on the hashes, since the MSP360 installer and agent binaries are legitimate signed software that may exist in your estate for approved reasons.

4. Mitigation & containment

P1, within 24 hours:

• Hunt for the MSP360 installer hash 108ef7e628d7a20bd6241a5b57149e27a6061f467123eb64061975559f8f73dc across endpoint telemetry for the last 30 days. Microsoft's own query is DeviceFileEvents | where Timestamp >= ago(30d) | where SHA256 =~ "108ef7e628d7a20bd6241a5b57149e27a6061f467123eb64061975559f8f73dc".
• Hunt for the second stage: a PowerShell process whose parent is RMM.Agent.exe that runs msiexec.exe with a .msi path under \Temp\. Microsoft's query is DeviceProcessEvents | where Timestamp >= ago(30d) | where (InitiatingProcessVersionInfoCompanyName == "MSP360" and ProcessCommandLine == "\"powershell.exe\"") or (InitiatingProcessCommandLine == "\"powershell.exe\"" and ProcessCommandLine has_all ("msiexec.exe","\\Temp\\",".msi") and InitiatingProcessParentFileName == "RMM.Agent.exe").
• Hunt for ScreenConnect processes (ScreenConnect.ClientService.exe, ScreenConnect.WindowsClient.exe, ScreenConnect.Client.exe) making outbound connections, and for ScreenConnect.WindowsClient.exe spawning children with RunFile and paths under \Documents\ or \Temp\.
• If MSP360 RMM is not an approved product in your estate, treat any host running C:\Program Files\RMM Agent\RMM.Agent.exe as compromised. Isolate it, capture volatile data, and remove the two services RMM.Agent.exe and RMM.Agent.Launcher.exe plus the registry autorun entries for the MSP360 tray components.
• Block the inbound UDP rule the installer created: inbound UDP to C:\Program Files\RMM Agent\RMM.Agent.exe on port 48678. Remove it on any host where MSP360 is not authorised.
• Block the ScreenConnect client service from reaching actor infrastructure. The domains Microsoft lists as contacted by ScreenConnect clients in observed malicious sessions are in §5; block them at egress and at any DNS filtering layer.
• If ScreenConnect is not an approved remote support tool, block ClientSetup.msi installation and the ScreenConnect client executables by application control rather than by hash alone, since the client is legitimate software.

P2, within 72 hours:

• Inventory every RMM product present on managed endpoints and reconcile it against an approved list. Microsoft's own framing is that the mitigations in its post help organisations identify and restrict unapproved RMM use; that inventory is the control that would have caught this chain at step 5.
• Restrict who can approve UAC elevation on endpoints that handle payment, trading or customer data. The chain fails at step 4 when elevation is denied, so tightening the elevation path is a direct control on this intrusion rather than a general hardening measure.
• Review egress policy for the cloud services used as payload hosts: Amazon S3, Cloudflare R2, Dropbox, GitLab and Supabase. Blanket blocking is usually impractical, but unsanctioned instances of these services should not be reachable from user endpoints that have no business reason to use them.
• Enable the Defender coverage Microsoft names for this chain if you run Microsoft Defender XDR: cloud-delivered protection, EDR in block mode, and attack surface reduction rules.

P3, within 7 days:

• Add the §6 detection rules to your EDR or SIEM and tune them against your own RMM baseline before enabling alerting at high severity.
• Where MSP360 RMM is legitimately deployed, baseline which accounts and hosts normally use it, so that a new install on a finance workstation is an anomaly rather than noise.
• Confirm that your incident management process can classify a legitimate-tool intrusion as an ICT-related incident. The DORA Art. 17 process has to work when the tooling is signed software, not only when a CVE is involved.

5. Indicators of compromise

Note on hash labelling: the source presents the MSP360 installer and agent values as SHA256 and SHA1. The 40-character value f34330d4c6e0aa978dc3af40360c14b31ad51127 is labelled sha1 here by length, consistent with the source. All other values are 64 hex characters and are labelled sha256.

The MSP360 installer and agent hashes are legitimate signed software. Do not block them outright without first confirming whether MSP360 RMM is authorised in your estate; a block on legitimate software will break approved remote management.

sha256  108ef7e628d7a20bd6241a5b57149e27a6061f467123eb64061975559f8f73dc
sha1  f34330d4c6e0aa978dc3af40360c14b31ad51127
sha256  f094b8263471c7b76dbed03d420736449920368fa0eca2ed6b1aea2645138d97
sha256  857c2f283de799faa74b56e862c0a9f96e67aa1b4fa4a9e46395098365b99de3
sha256  6a89de024ca62536de6f5fc10e49896bb1ac330ca39dce30203afdcc45ae237e
sha256  4188c6588f3dcda881c3f2d12df580051179a999f040b799af506edeb3211a26
domain  adswre[.]cfd
domain  trews[.]cfd
domain  swedcorry[.]stefneyv[.]com
domain  ojsuyw[.]niyari[.]org
domain  bunstar[.]harej[.]si
domain  adsaw[.]cfd
domain  sdfghj[.]rd-team[.]ru
sha256  ceb3f7fe9a618ff29a21b126383c23900fad58d6ae2b5552d7e306e4b6acf4b0
sha256  02f2ce03a2650f17bfe6e8744eebbf58522016cbdb92af8f2217b5dd4a1ad550
sha256  499d07894f730fb685ee3cbfc1a933e0da93750c1ed25a49b2eb9c32adef156a
sha256  d49cc01641c3045bf3119f9d71e7ffd29bfce32ca4b27cc96340716ed4d41cdc
sha256  67c979dc13961b09f24f85a801e4c918420adca6117c92efbeeeaa68a6344f55
sha256  6cc665057c4a4fe42a309afd3a7fa96cf1af126e9c6e08e56df5105e05378bcc
sha256  dd434f3ffcafeda538d43226665115ba136ad0fdb43dad8536e1368ca9a17b64
sha256  40f8e774e1e7a484b78c7ae4336bc47aa9cab20dc8e1e67d89838e807975f9b1
sha256  3ff5e49fd2f2bd0758467763c44d69e781b7460af84a6e3966e2621bc5bf7096
sha256  374c4934b14a1151ea68847c8627c3f1c0b878f4e673bda3f15e4388dfde0187
sha256  bc8b1b0c80512ba0e8ffccfee5b507df16a3355db1143c3ba81ef42dac1baa6c
sha256  c2c004a56de2a99f5b06ceb58d8a4b371fb60fd66ff5936786fe8d8037ead208
sha256  5bf8cf29ac6803e7269b045dea48003af7cfe48bedfc081b57ff9e86cb08971b
sha256  19035c8e2520fb70b3e2ec5338c14311b88a26cc1fb8304a01494260b6b55af1
sha256  d232d82e410de12702a67c58acf927304ee42f3e6d81a9d71eca99f9052126db
sha256  d3cb7ded277b49be06e6a1860f7c7e913e252802e9d32453a185e24797bf53ef
sha256  e31e5da7c58a7e8f89f9629f095edd7d741a1fb0b85fcb39f3818dbd9497b1e3
sha256  1a534d04bf30894d20764e91f7e94e0a73f060f0abacc9feeedba427995c83a8
sha256  77fb0e75f4396cb57bbbd28f6dc5310369a87abec9e2acc457aa99a0063ed27a
sha256  fc96a04c615847f0fb1391f04d9d1aac7f78ddfb7d459168df0a4172b98354e2
sha256  06ad69b9bebad3cc75b594cc5bb1ca0035ea22bb8a683002ca051d948566426b
sha256  a93c946c237b981189d2668d938a9d4d1d9681757e48dae8d9d65ed25b5da657
sha256  529543b4fe6a4c21d28be56dbf92fcac91d8df808d8518b4275c973fa547ad63
sha256  ccea4e1acc51ac43ba9da76ada00e7e308cc33d9c5c264dff82d1be83e957b88
sha256  a03c84ae9e569c04fdd271277f508bba5a299d53c3c0efe0819338d178fe1c5b

Behavioural indicators

The sources describe observable behaviour but the atomic indicators above do not cover the installation mechanics. These behaviours are where to look for the intrusion in your own telemetry.

6. Detection

The sources give usable artefacts for a YARA rule: the installer's dropped component filenames, the event source string, the installation directory, the firewall port, and the second-stage MSI name. The rule below targets the MSP360 installer and its dropped components. It will also match legitimate MSP360 installations, so scope it to hosts where MSP360 is not authorised, or use it for triage rather than blocking.

rule RMM_MSP360_Masqueraded_Installer_AT_2026_09_30
{
    meta:
        author = "Adverse Trace"
        date = "2026-09-30"
        reference = "https://www.microsoft.com/en-us/security/blog/2026/09/29/phishing-abuses-rmm-tools-persistent-access/"
        description = "Detects the masqueraded MSP360 RMM v2.5.0.67 installer and its dropped components observed in phishing campaigns delivering ScreenConnect as a second remote access channel. Will also match legitimate MSP360 installations."
        tlp = "AMBER"

    strings:
        $s1 = "MSP360 RMM Agent installer" ascii wide
        $s2 = "Begin installation" ascii wide
        $s3 = "End installation. MSP360 de Success." ascii wide
        $s4 = "RMM.Agent.Launcher.exe" ascii wide
        $s5 = "RMM.Agent.exe" ascii wide
        $s6 = "ClientSetup.msi" ascii wide
        $s7 = "\\Program Files\\RMM Agent\\" ascii wide
        $s8 = "nsExec.dll" ascii wide
        $s9 = "UAC.dll" ascii wide

    condition:
        uint16(0) == 0x5A4D and 4 of them
}

The Sigma rule below covers the process and service behaviour. It is written for Sysmon process creation and service installation telemetry; map the field names to your own schema before deployment.

title: MSP360 RMM Abuse Leading to ScreenConnect Installation
id: 8f2c1a44-7b3e-4d19-9c05-at20260930
status: experimental
description: Detects the RMM.Agent.exe process chain that downloads and silently installs a ConnectWise ScreenConnect client, as observed in phishing campaigns abusing MSP360 RMM.
references:

    - https://www.microsoft.com/en-us/security/blog/2026/09/29/phishing-abuses-rmm-tools-persistent-access/
author: Adverse Trace
date: 2026-09-30
tags:

    - attack.persistence
    - attack.command_and_control
    - attack.t1219
logsource:
    product: windows
    category: process_creation
detection:
    selection_powershell_parent:
        ParentImage|endswith: '\RMM.Agent.exe'
        Image|endswith: '\powershell.exe'
    selection_msiexec:
        Image|endswith: '\msiexec.exe'
        CommandLine|contains|all:

            - '/qn'
            - '.msi'
        ParentImage|endswith: '\powershell.exe'
    selection_screenconnect_runfile:
        ParentImage|endswith: '\ScreenConnect.WindowsClient.exe'
        CommandLine|contains: 'RunFile'
    condition: selection_powershell_parent or selection_msiexec or selection_screenconnect_runfile
falsepositives:

    - Legitimate MSP360 RMM deployments performing authorised software installation
    - Legitimate ConnectWise ScreenConnect remote support sessions using RunFile
level: medium

Both rules will fire on legitimate remote management activity. Baseline your authorised RMM and remote support usage before enabling them at high severity.

7. Sources

• Microsoft Security Blog, "Phishing Abuses RMM Tools for Persistent Access", https://www.microsoft.com/en-us/security/blog/2026/09/29/phishing-abuses-rmm-tools-persistent-access/, 2026-09-29.
• Huntress, "Rogue RMM Abuse: How Attackers Exploit Remote Access Tools", https://www.huntress.com/blog/rogue-rmm-abuse-phishing-persistent-access.
• Huntress, "Phishing Attacks Serve Browser-in-the-Browser Pages, Rogue RMM Persistence", https://www.huntress.com/blog/phishing-bitb-rmm-attacks.
• Microsoft Threat Intelligence, "Impersonating IT support: how threat actors turn a remote session into enterprise-wide access", https://www.microsoft.com/en-us/security/blog/2026/09/02/impersonating-it-support-threat-actors-turn-remote-session-into-enterprise-wide-access/, 2026-09-02.
• Microsoft Threat Intelligence, "From poisoned search results to GPU mining: A cryptojacking campaign abusing ScreenConnect and Microsoft .NET utilities", https://www.microsoft.com/en-us/security/blog/2026/05/26/poisoned-search-results-gpu-mining-cryptojacking-campaign-abusing-screenconnect-microsoft-net-utilities/, 2026-05-26.
• Dark Reading, "Smoke#Screen RMM Takeover Gambit Exposes Threat Actor Playbook", https://www.darkreading.com/cyberattacks-data-breaches/latest-rmm-fueled-phishing-attack-exposes-threat-actor-playbook.
• Huntress, "Bank of America Phishing Email Delivers ScreenConnect Malware", https://www.huntress.com/blog/bank-spam-rmm.

8. Adverse Trace position

Adverse Trace assesses this as a moderate-severity, high-likelihood intrusion pattern for EMEA financial services, with the caveat that no CVSS score, severity rating or CISA KEV state is available in the verified reference data for this item, so the assessment rests on the operational characteristics of the chain rather than a scored vulnerability. The chain has no exploitable software flaw to patch: it succeeds when a user approves a UAC prompt for a signed installer, which means the controls that matter are RMM inventory, elevation approval and egress monitoring, not patch cycles. The activity is unattributed and single-sourced to Microsoft for the specific artefacts; the general pattern of rogue RMM and ScreenConnect persistence is corroborated by Huntress reporting, but the hashes, port 48678 firewall rule and service names should be verified against your own telemetry before you enforce blocks, particularly because the MSP360 binaries are legitimate signed software. We will monitor for further vendor reporting that names an actor or adds indicators, and we will reissue this advisory if attribution or the indicator set changes. Clients who want help reconciling their RMM inventory against an approved list, or who need the §6 rules mapped to a non-Microsoft telemetry schema, should contact their Adverse Trace handler.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.