Microsoft has published a research into phishing campaigns that abused MSP360 RMM in July 2026. Attackers disguised our installer as familiar software, then used it to gain unauthorized remote access and deploy additional tools.
As the vendor, we have a responsibility to address this misuse. We have investigated abusive activity, blocked accounts involved, and strengthened account verification and monitoring. Our response builds on safeguards introduced both before and after the July campaigns.
MSPs depend on their vendors to take these steps, and they should be able to verify how those safeguards work. They also need to understand which protections remain their responsibility in customer environments.
Below, we review Microsoft’s findings and the measures we have taken, then explain what MSPs should expect from an RMM provider and how to check for unauthorized use of remote-management tools.
What Microsoft’s Research Found
In July 2026, Microsoft Defender Experts observed phishing campaigns that distributed a legitimate, digitally signed MSP360 RMM installer under deceptive filenames. Meeting invitations, document-sharing pages, software update prompts, and other familiar business workflows were used to persuade recipients to download and execute it.
Following execution and User Account Control elevation, the installer established remote-management access. Microsoft observed attackers using the RMM agent to invoke PowerShell and install ConnectWise ScreenConnect, creating a second remote-access channel. Further tools supported credential theft, information collection, and other activity on compromised devices.
Microsoft's research describes attackers abusing legitimate remote-management capabilities, rather than exploiting an identified vulnerability in MSP360 software. Addressing this kind of misuse requires vendors to control access to sensitive capabilities, monitor for abuse, and take action against the accounts involved.
Actions MSP360 Has Taken
We have investigated misuse of our products, blocked accounts associated with abuse, and strengthened account verification, monitoring, and enforcement.
We introduced mandatory business verification before new accounts can customize installer branding or perform remote-management operations in MSP360 RMM, alongside restrictions on certain capabilities in MSP360 Managed Connect and MSP360 Managed Backup. The implementation details and chronology are documented in our published response.
These vendor-side measures address access to our platform and its capabilities. MSPs also need controls for what is installed and executed in the environments they manage.
5 Practical Lessons for MSPs
We recommend using the research as a sign to review how remote-management access is approved, monitored, and investigated. The following checks translate the findings into decisions an MSP can apply during customer onboarding, routine reviews, and incident response.
Lesson 1: Keep an Ownership Record for Every RMM Deployment
Start with an inventory of approved remote-management and remote-support tools for each customer. Record more than the product name: include the responsible provider, business purpose, management account or tenant, and devices covered by the authorization.
Compare endpoint software and service inventories with your deployment records and management consoles. For example, finding an agent for a product your MSP already uses does not settle whether that particular installation is authorized. It could be associated with a different account.
Where ownership is unclear, use available configuration information, deployment records, and vendor assistance to establish it. Do not infer authorization from a familiar filename, logo, or publisher.
Lesson 2: Test and Enforce Approved-Tool Policies on Customer Devices
An approved-software list needs a technical enforcement policy behind it. Microsoft’s recommendations include restricting unapproved remote-management tools through application controls.
On Windows, evaluate rules that reflect the software each customer actually authorizes. Test new application-control policies before broad enforcement; Microsoft recommends initially using audit mode to identify applications that would be affected and to refine the policy.
Understand the boundary of those rules. AppLocker publisher conditions identify signed files using publisher and application attributes. They do not establish which remote-management account controls an installation. Allowing a product therefore does not replace verifying the ownership and purpose of its deployment.
Review MFA and access permissions for your approved management accounts as well. But keep the two risks distinct: protecting your own console accounts does not, by itself, prevent someone from introducing a separate attacker-controlled remote-management installation.
Lesson 3: Verify Unexpected Scripts and Installations
The research also goes into script execution and software deployment – capabilities that also have legitimate administrative uses. Their presence alone does not tell you whether an action was authorized.
When investigating an unexpected script or remote-access installation, check whether it matches expected work. Was there an approved deployment, support request, or scheduled task? Can the initiating administrator and management account be identified? Do the target devices and timing match that task?
For example, a planned remote-support rollout and an unexpected second remote-access agent require different responses, even when they involve the same software.
Use endpoint telemetry alongside management-console records. Activity associated with an installation outside your authorized accounts should not be assumed to appear in your own RMM console. Ask your security team or monitoring provider how unexpected remote-access installations and related activity are detected and escalated.
Do not dismiss a relevant RMM alert solely because the initiating application is a legitimate administrative tool.
Lesson 4: Check for Additional Access and Credential Exposure
When there is evidence of unauthorized remote access, investigate how far it extends and what access may remain.
The secondary ScreenConnect deployment in Microsoft’s findings is particularly important. Removing the first RMM agent would not establish that the additional access channel, other deployed tools, or consequences of credential theft had been addressed.
Follow your incident-response process to contain affected devices promptly while preserving relevant evidence. Microsoft documents device isolation and investigation-package collection as response options in Defender for Endpoint; the appropriate actions depend on the environment and available capabilities.
Build a timeline around the installation and subsequent activity. Review the accounts involved, scripts and programs executed, additional remote-access software, and evidence of access to other devices. Assess credential exposure, including accounts used to install the software, and include appropriate credential remediation in the response.
Coordinate with the software vendor so it can investigate and act against abusive accounts. However, vendor account enforcement and endpoint remediation are separate tasks. A blocked account is not evidence that every access path on an affected device has been removed.
Lesson 5. Give Staff a Procedure for Verifying Support Requests
The phishing lures in Microsoft’s research imitated familiar business activities. Give customer staff a clear procedure for handling an unexpected request to install software, approve elevation, or grant remote access.
Include that procedure in onboarding and support communications. Employees should know how to verify a request through an established service-desk channel, rather than using contact details or links supplied in the suspicious message. Microsoft also recommends verification through a known channel in its separate guidance on support impersonation.
What MSPs Should Ask Their Vendor
Endpoint controls are only one part of the response. Vendors also make decisions about who can access remote-management capabilities, how potential misuse is reviewed, and what happens when abuse is identified.
MSP360’s Code of Conduct for RMM and Remote Desktop vendors sets out our position on those responsibilities. For an MSP evaluating a software provider, the next step is to ask how those principles are implemented.
Use the following questions with any software provider, including MSP360.
| Question to ask | What a useful answer should explain |
|---|---|
| What verification is required before an account can perform remote-management actions? | How email and business verification differ, which capabilities require verification, whether trial, free, and paid accounts are covered, and how restrictions are enforced. |
| How is installer customization controlled? | Who can change installer branding, what approval or verification is required, and how subsequent branding changes are controlled. |
| How do you review potential misuse after registration? | How ongoing account reviews and abuse reports inform investigations, and how concerns are escalated. Ask about the process; proprietary detection thresholds are unnecessary. |
| What happens when an account is identified as abusive? | What suspension or blocking stops within the platform, including sign-ins and remote-management activity, and what remediation is still needed on affected devices. |
| Can someone who is not your customer report suspected abuse? | A public, monitored reporting channel, the information needed to investigate, and an urgent escalation route. Reporting should not require access to the account controlling the agent. |
| What evidence can support an investigation? | Which activity records are retained, for how long, whether they remain available after suspension or termination, and how affected organizations can request access or assistance. |
Ask vendors to distinguish controls that are deployed today from work still in development. For capabilities central to your evaluation, request documentation or a demonstration where practical.
These questions should also inform periodic reviews of an existing provider. Establish the reporting contacts before an incident, record any limitations that affect your response process, and revisit the answers when relevant capabilities change.
Business verification, monitoring, and account enforcement serve different purposes. None should be treated as proof that every installation is authorized or that every action performed through it is legitimate.
Keep Remote Access Under Review
An MSP should be able to explain why a tool is present, who controls it, and how unexpected use will be investigated. A vendor should be able to explain how it controls access to sensitive capabilities and responds when those capabilities are abused.
Use those questions in customer onboarding, access reviews, and vendor evaluations.
Suspected misuse of MSP360 software can be reported through our Trust & Safety Center, which provides a dedicated channel for reporting scams, unauthorized remote access, and other abusive activity.
