Incident Response
MSP360 and ScreenConnect Phishing: RMM Response Checklist
Investigate phishing that abuses MSP360 and ScreenConnect: verify remote access ownership, contain unauthorized sessions, and check for additional access.
Updated 2026-10-05 · 3 min read
Authorization
Verify the management account
Match each installation to an approved owner, management destination, and deployment record.
Scope
Check every access channel
Investigate additional remote access software on the same device.
Closure
Document remaining uncertainty
Record investigation coverage and unresolved evidence gaps before closing the incident.
Useful CyberPrism references
Microsoft: Phishing Abuses RMM Tools
September 29, 2026 research with campaign details and hunting queries.
CISA Remote Access Security Guide
Durable guidance on detecting and defending against remote access software abuse.
CyberPrism RIPD Framework
Connect threat context with defensive priorities.
Threat Actors
Explore threat actor context while keeping confirmed attribution separate from suspicion.
How should teams respond to RMM phishing?
Verify who authorized the remote monitoring and management (RMM) installation and which management account controls it. For confirmed unauthorized access, contain the device through your incident-response process, preserve evidence, and investigate other access channels before restoring service.
As of October 5, 2026, a fresh investigation lead is Microsoft's September 29 report: phishing campaigns observed in July deployed legitimate MSP360 software, then installed ScreenConnect to establish redundant access. Microsoft reported software abuse without observed exploitation of ScreenConnect itself. [Microsoft research](https://www.microsoft.com/en-us/security/blog/2026/09/29/phishing-abuses-rmm-tools-persistent-access/).
Verify ownership beyond the product name
Suggested triage record: device, user, installation time, installer source, management destination, responsible IT provider, and approving ticket. Ask the service owner to verify the specific deployment against their records.
A familiar product name alone cannot establish authorization. CISA's remote access guide explains how attackers co-opt tools also used by legitimate administrators. [CISA guidance](https://www.cisa.gov/resources-tools/resources/guide-securing-remote-access-software).
Look for the second remote access channel
Microsoft observed MSP360 launching PowerShell to download and install ScreenConnect. Its report includes hunting queries for agent presence, process activity, network connections, and follow-on execution. [Hunting guidance](https://www.microsoft.com/en-us/security/blog/2026/09/29/phishing-abuses-rmm-tools-persistent-access/).
Use those leads to build a device timeline: initial download, installation, remote session, subsequent software, and affected accounts. Expand the search to devices sharing suspicious destinations or installer delivery paths; record the dates your telemetry actually covers.
Contain access and preserve the investigation
Suggested response sequence: isolate confirmed compromised endpoints using approved controls, preserve available endpoint and remote-session logs, and disable unauthorized access. Coordinate disruptive actions with the incident lead and service owner.
Assess which credentials or sessions may have been exposed and assign recovery actions to their owners. Give each action a completion check, such as confirmation that a revoked session can no longer authenticate.
Give leadership a clear closure decision
Report affected devices, unauthorized access paths, containment status, identity recovery, and remaining investigation gaps. Assign an owner and next review time to each unresolved item.
Keep software removal and investigation closure as separate decisions. A useful closure record states what access was removed, what evidence was reviewed, what recovery was verified, and what remains unknown.
FAQ
Does finding MSP360 or ScreenConnect prove compromise?
No. Both have legitimate administrative uses. Check authorization, management ownership, installation history, and surrounding activity before deciding whether a deployment is malicious. [CISA remote access guide](https://www.cisa.gov/resources-tools/resources/guide-securing-remote-access-software).
Which threat actor is behind this RMM phishing campaign?
Microsoft's September 29, 2026 report describes the activity as unattributed. Keep actor attribution unresolved unless additional evidence supports it. [Microsoft attribution assessment](https://www.microsoft.com/en-us/security/blog/2026/09/29/phishing-abuses-rmm-tools-persistent-access/).
Try CyberPrism
Track CVEs, threat actors, breaches, ransomware activity, and vendor exposure from a mobile-first cybersecurity app.