> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# Attackers Abuse MSP360 to Deploy ScreenConnect in Dual-RMM Phishing Attacks
- URL: https://f4n6.co.uk/security-feed/attackers-abuse-msp360-to-deploy-screenconnect-in-dual-rmm-phishing-attacks/
- Published: 2026-09-30T22:08:44.000Z
- Updated: 2026-09-30T22:08:44.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

Microsoft Threat Intelligence observed phishing campaigns in July 2026 that delivered a legitimate, digitally signed MSP360 RMM installer (v2.5.0.67) under deceptive filenames, then used the resulting remote-management foothold to download and silently install a ConnectWise ScreenConnect client, giving the operator two independent remote-access channels on each compromised endpoint. The activity is not attributed to any named threat actor or group, and no CVE is involved: the actors abused legitimately signed remote administration software rather than exploiting a vulnerability. For EMEA financial services the exposure is concentrated in endpoint and identity controls, because a signed RMM agent that installs with user-approved UAC elevation and registers its own Windows services and autorun entries looks like sanctioned IT tooling to most detection stacks. The same Microsoft reporting notes a parallel July 2026 set of attacks that substituted Faronics Deploy Agent for MSP360 and again installed ScreenConnect, which indicates the delivery method is reusable across RMM products rather than tied to one installer.

## 2\. Regulatory framing

| Article            | Trigger (the fact in this item)                                                                                                                                                                                                                                                     | Practical impact                                                                                                                                                               |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| DORA Art. 17       | A user-approved, signed RMM agent established persistent remote access on affected devices and was used for credential-access operations, so the incident management process has to cover an intrusion that presents as sanctioned administration rather than as malware execution. | Detection and response runbooks must treat unapproved RMM service creation and autorun registration as an incident class, with defined escalation and evidence capture.        |
| DORA Art. 18       | The intrusion chain ran through a third-party remote administration product (MSP360, then ConnectWise ScreenConnect) and the source does not state whether any client data was accessed, so classification has to be made on incomplete impact information.                         | Classification decisions need a documented basis for the "unknown impact" case, including how the firm determines whether the second RMM channel was used for data access.     |
| NIS2 Art. 21(2)(d) | Payloads were staged on legitimate cloud services (Amazon S3, Cloudflare R2, Dropbox, GitLab, Supabase) and on compromised websites, which is a supply chain and third-party service exposure rather than a defect in the firm's own estate.                                        | Supply chain security measures must cover the risk that trusted SaaS and code-hosting providers are used to host the installer, not only the risk that a supplier is breached. |

No other article in the reference is directly engaged by the facts as reported.

## 3\. Technical analysis & attack chain

The chain below is confirmed by Microsoft Threat Intelligence reporting on campaigns observed in July 2026\. Microsoft did not observe exploitation of ScreenConnect itself, and no vulnerability is named anywhere in the source material.

1. Phishing email delivers a lure. Observed themes include meeting invitations, PDF-themed documents, software update prompts, and other social-engineering content. Emails direct the user to actor-controlled landing pages impersonating document-sharing portals, invitation workflows, Adobe Reader download pages, Zoom installation pages, and business collaboration platforms.
2. User is redirected to a download. Payloads are hosted on attacker-controlled domains, on websites assessed to be compromised, and on legitimate cloud services: Amazon S3, Cloudflare R2, Dropbox, GitLab, and Supabase. This lets the actor rotate delivery infrastructure while distributing the same installer under different lure themes and filenames.
3. The downloaded file is the MSP360 RMM installer, version 2.5.0.67, digitally signed and legitimate. Filenames are crafted to resemble business content. Analysis of samples showed that files appearing different to the victim often contained the same MSP360 installer package. Observed filenames: - `VIP_ECARD_INVITATION_rmm_v2.5.0.67_oid[redacted].exe` \- `ZoomSetup_Installation_v2.5.0.67_ oid[redacted].exe` \- `PDF Reader & Editor the Adobe Acrobatte_rmm_v2.5.0.67_ oid[redacted].exe` \- `RSVP_INVITATION_E_CARD_rmm_v2.5.0.67_ oid[redacted].exe` \- `SSA.GOV_STATEMENT_rmm_v2.5.0.67_ oid[redacted].exe`
4. Execution and elevation. The installer drops multiple DLLs and relaunches itself by invoking the Windows User Account Control elevation workflow, so it runs in a privileged context after the user approves the prompt.
5. Persistence. The installer enumerates installed .NET runtimes, registers two Windows services (`RMM.Agent.exe` and `RMM.Agent.Launcher.exe`), and creates registry-based autorun entries so MSP360 launches automatically at user sign-in.
6. Firewall modification. The installer modifies the Windows Firewall configuration to allow inbound UDP traffic to MSP360 (`RMM.Agent.exe`) on port 48678.
7. Second RMM channel. The MSP360 agent is used to invoke PowerShell, which downloads and silently installs a ConnectWise ScreenConnect client. This creates a redundant remote-access channel independent of MSP360.
8. Post-compromise activity. Through the RMM channels the operator transfers and executes additional tooling, runs payloads via ScreenConnect's native RunFile functionality, and conducts information collection and credential-access operations.

The design intent is redundancy and blending. Two RMM agents on one host mean that removing either one leaves the operator a working channel, and both agents generate traffic and service activity consistent with normal managed-IT operations.

A parallel campaign observed by Microsoft in the same month used Faronics Deploy Agent in place of MSP360, then downloaded and installed ScreenConnect by the same method. That is a single-vendor observation and is reported here as Microsoft's finding, not as independently corroborated.

Attribution is unconfirmed. Microsoft did not attribute the activity to any known threat actor or group, and no MITRE ATT&CK group profile is available for this item. Treat any actor name attached to this campaign elsewhere as unverified.

## 4\. Mitigation & containment

P1 (within 24 hours)

- Hunt for the two MSP360 services by name on all endpoints: `RMM.Agent.exe` and `RMM.Agent.Launcher.exe`. Any host where these exist without a change ticket is a suspected compromise; isolate it before remediation.
- Hunt for the firewall rule permitting inbound UDP to `RMM.Agent.exe` on port 48678\. Remove the rule and treat its presence as evidence the installer completed step 6 of the chain.
- Hunt for registry-based autorun entries that launch MSP360 at user sign-in, and for a ConnectWise ScreenConnect client installed in the same window as an MSP360 install. The pair is the signature of this campaign.
- Block execution of the five observed installer filenames if your tooling supports filename-based blocking, but do not rely on it: the actor rotates filenames and lure themes, and the underlying binary is a signed legitimate installer.
- If MSP360 or ScreenConnect is not an approved tool in your estate, block both at the application-control layer and alert on install attempts rather than only on successful installs.

P2 (within 72 hours)

- Restrict UAC elevation for standard users. The chain depends on the user approving an elevation prompt for a signed installer; removing standing local admin rights breaks step 4.
- Restrict or monitor outbound access to the cloud services used for staging (Amazon S3, Cloudflare R2, Dropbox, GitLab, Supabase) where the business does not require them, and alert on executable downloads from those services.
- Review firewall egress policy for inbound-listening RMM agents. An endpoint that opens a UDP listener for remote management should be an alertable event, not a baseline.
- Where MSP360 or ScreenConnect is legitimately deployed, inventory the expected install base and alert on any new install outside a change window.

P3 (within 7 days)

- Add the detection content in §6 to EDR and SIEM, and tune it against your approved RMM inventory to reduce noise.
- Review credential-access exposure on any host where the chain completed. The source states credential-access operations occurred but does not name the tools or the credentials targeted; scope the review from your own telemetry.
- Confirm that incident classification and reporting decisions under DORA Art. 18 and Art. 19 can be made when the impact of the second RMM channel is unknown at the time of detection.

## 5\. Indicators of compromise

| type     | value                                                                         | confidence | source                        |
| -------- | ----------------------------------------------------------------------------- | ---------- | ----------------------------- |
| sha256   | 108ef7e628d7a20bd6241a5b57149e27a6061f467123eb64061975559f8f73dc              | high       | Microsoft Threat Intelligence |
| sha1     | f34330d4c6e0aa978dc3af40360c14b31ad51127                                      | high       | Microsoft Threat Intelligence |
| filename | VIP\_ECARD\_INVITATION\_rmm\_v2.5.0.67\_oid\[redacted\].exe                   | high       | Microsoft Threat Intelligence |
| filename | ZoomSetup\_Installation\_v2.5.0.67\_ oid\[redacted\].exe                      | high       | Microsoft Threat Intelligence |
| filename | PDF Reader & Editor the Adobe Acrobatte\_rmm\_v2.5.0.67\_ oid\[redacted\].exe | high       | Microsoft Threat Intelligence |
| filename | RSVP\_INVITATION\_E\_CARD\_rmm\_v2.5.0.67\_ oid\[redacted\].exe               | high       | Microsoft Threat Intelligence |
| filename | SSA.GOV\_STATEMENT\_rmm\_v2.5.0.67\_ oid\[redacted\].exe                      | high       | Microsoft Threat Intelligence |
| service  | RMM.Agent.exe                                                                 | high       | Microsoft Threat Intelligence |
| service  | RMM.Agent.Launcher.exe                                                        | high       | Microsoft Threat Intelligence |
| port     | 48678/udp (inbound to RMM.Agent.exe)                                          | high       | Microsoft Threat Intelligence |

The two hashes are published by Microsoft as the MSP360 RMM installer package. The installer is legitimate signed software, so these hashes identify the file the actor distributed, not a malicious binary. Do not add them to a blanket blocklist without first confirming whether MSP360 is approved in your estate.

No network indicators (domains, IPs, URLs) are present in the source material. Microsoft names the cloud services used for staging but publishes no specific hostnames or addresses.

```iocs
sha256  108ef7e628d7a20bd6241a5b57149e27a6061f467123eb64061975559f8f73dc
sha1  f34330d4c6e0aa978dc3af40360c14b31ad51127
filename  VIP_ECARD_INVITATION_rmm_v2.5.0.67_oid[redacted].exe
filename  ZoomSetup_Installation_v2.5.0.67_ oid[redacted].exe
filename  PDF Reader & Editor the Adobe Acrobatte_rmm_v2.5.0.67_ oid[redacted].exe
filename  RSVP_INVITATION_E_CARD_rmm_v2.5.0.67_ oid[redacted].exe
filename  SSA.GOV_STATEMENT_rmm_v2.5.0.67_ oid[redacted].exe
service  RMM.Agent.exe
service  RMM.Agent.Launcher.exe
port  48678/udp

```

### Behavioural indicators

| behaviour                                                                                                         | where to observe                                  | confidence                           |
| ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- | ------------------------------------ |
| Signed MSP360 installer executed from a user download directory under a business-document filename                | EDR process creation, file creation               | high                                 |
| UAC elevation prompt approved immediately before MSP360 service creation                                          | Windows Security event log, EDR                   | high                                 |
| Two services registered in the same process tree: RMM.Agent.exe and RMM.Agent.Launcher.exe                        | Windows service creation events                   | high                                 |
| Registry autorun entry created to launch MSP360 at user sign-in                                                   | Registry monitoring                               | high                                 |
| Windows Firewall rule added permitting inbound UDP to RMM.Agent.exe on 48678                                      | Firewall configuration change events              | high                                 |
| PowerShell spawned by the MSP360 agent process, followed by download and silent install of a ScreenConnect client | EDR process tree, PowerShell script block logging | high                                 |
| Payloads executed through ScreenConnect's RunFile functionality                                                   | ScreenConnect client logs, EDR                    | medium (single-sourced to Microsoft) |
| Installer downloaded from Amazon S3, Cloudflare R2, Dropbox, GitLab, or Supabase                                  | Web proxy, DNS, egress logs                       | medium (single-sourced to Microsoft) |

## 6\. Detection

The YARA rule below targets the installer filenames and the service names Microsoft published. The filenames are the strongest artefact available; the service names are generic enough that they should be paired with the filename condition rather than used alone.

```yara
rule RMM_MSP360_Phishing_Installer_Names
{
    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 MSP360 RMM installer files distributed under deceptive business-document filenames in the July 2026 dual-RMM phishing campaigns."
        confidence = "medium"
    strings:
        $fn1 = "VIP_ECARD_INVITATION_rmm_v2.5.0.67" ascii wide nocase
        $fn2 = "ZoomSetup_Installation_v2.5.0.67" ascii wide nocase
        $fn3 = "PDF Reader & Editor the Adobe Acrobatte_rmm_v2.5.0.67" ascii wide nocase
        $fn4 = "RSVP_INVITATION_E_CARD_rmm_v2.5.0.67" ascii wide nocase
        $fn5 = "SSA.GOV_STATEMENT_rmm_v2.5.0.67" ascii wide nocase
        $svc1 = "RMM.Agent.Launcher.exe" ascii wide
        $svc2 = "RMM.Agent.exe" ascii wide
    condition:
        uint16(0) == 0x5a4d and (any of ($fn*) or all of ($svc*))
}

```

The Sigma rule below covers the behavioural chain: a signed installer running from a user download path, followed by service creation and a firewall rule for the MSP360 agent.

```yaml
title: MSP360 RMM Installer Execution with Service and Firewall Persistence
id: 7c1f4a92-3b6e-4d21-9a58-0e2d5f8c1b47
status: experimental
description: Detects execution of the MSP360 RMM installer from a user download path followed by creation of the RMM.Agent services and an inbound UDP firewall rule on port 48678, consistent with the July 2026 dual-RMM phishing campaigns.
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
logsource:
    product: windows
    category: process_creation
detection:
    selection_image:
        Image|endswith:

            - '\VIP_ECARD_INVITATION_rmm_v2.5.0.67_oid*.exe'
            - '\ZoomSetup_Installation_v2.5.0.67_ oid*.exe'
            - '\PDF Reader & Editor the Adobe Acrobatte_rmm_v2.5.0.67_ oid*.exe'
            - '\RSVP_INVITATION_E_CARD_rmm_v2.5.0.67_ oid*.exe'
            - '\SSA.GOV_STATEMENT_rmm_v2.5.0.67_ oid*.exe'
    selection_service:
        Image|endswith:

            - '\RMM.Agent.exe'
            - '\RMM.Agent.Launcher.exe'
    condition: selection_image or selection_service
fields:

    - Image
    - CommandLine
    - ParentImage
    - User
falsepositives:

    - Legitimate MSP360 RMM deployment where the product is approved and installed by IT outside a change window
level: high

```

A second Sigma rule for the firewall change is warranted because the port is specific to this chain.

```yaml
title: Windows Firewall Rule Allowing Inbound UDP to MSP360 RMM Agent on Port 48678
id: 2a8d6f31-9c47-4e05-b1d2-6f3a7c9e4b18
status: experimental
description: Detects creation of a Windows Firewall rule permitting inbound UDP traffic to RMM.Agent.exe on port 48678, as observed in the July 2026 MSP360 dual-RMM phishing campaigns.
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
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4946
        RuleName|contains: 'RMM.Agent'
    condition: selection
fields:

    - RuleName
    - RuleId
    - ProcessName
falsepositives:

    - Approved MSP360 RMM deployment
level: medium

```

## 7\. Sources

- Microsoft Threat Intelligence, "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
- The Hacker News, "Attackers Abuse MSP360 to Deploy ScreenConnect in Dual-RMM Phishing Attacks", https://thehackernews.com/2026/09/attackers-abuse-msp360-to-deploy.html, 2026-09-30
- 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 (related RMM-abuse campaign, different initial access vector)
- Huntress, "Rogue RMM Abuse: How Attackers Exploit Remote Access Tools", https://www.huntress.com/blog/rogue-rmm-abuse-phishing-persistent-access (related context)
- Huntress, "Bank of America Phishing Email Delivers ScreenConnect Malware", https://www.huntress.com/blog/bank-spam-rmm (related context)
- 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 (related context)

## 8\. Adverse Trace position

Adverse Trace assesses this as a high-confidence technique report with unconfirmed attribution. The technical chain is well documented by Microsoft and corroborated in outline by the secondary reporting, but no actor is named, no CVE is involved, and no network indicators were published, so the practical value is in the behavioural detections in §6 rather than in blocklists. The risk to EMEA financial services clients is not the MSP360 installer itself, which is signed and legitimate, but the second RMM channel: an operator holding two independent remote-access paths on an endpoint can survive the removal of either one, and both paths generate activity that resembles sanctioned IT operations. Firms that have not inventoried their approved RMM tooling cannot distinguish this intrusion from a routine deployment, and that gap is the one to close first. We will monitor for any attribution or additional indicators from Microsoft and from the ConnectWise and MSP360 vendors, and we will update this advisory if network indicators or a named actor emerge. Clients who find either MSP360 service or a ScreenConnect client installed outside a change window should treat the host as compromised and contact us before remediating, because the credential-access stage described by Microsoft is not fully characterised in the public reporting.

---

[Read the original source →](https://thehackernews.com/2026/09/attackers-abuse-msp360-to-deploy.html?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*