A signed installer can still give attackers remote access: phishing deployed MSP360 and ScreenConnect

A fake meeting invitation, a request to open a document or a PDF software update prompt can install legitimate administration software instead of a conventional malware sample. Microsoft described campaigns in which criminals persuaded victims to run a digitally signed MSP360 Remote Monitoring and Management installer, then used it to deploy a ConnectWise ScreenConnect client silently.

The lesson matters to employees and organisations alike: a digital signature verifies where a file came from and whether it has been altered, but it does not establish that the user actually needs the software or identify who will control it. A tool designed for legitimate IT support can give an attacker persistent remote access, command execution and a way to transfer additional files.

How the attack unfolded

Microsoft Defender Experts observed the campaigns in July 2026 across organisations in multiple industries. Messages and landing pages used themes including Zoom and Google Meet calls, RSVP invitations, documents for signature, job offers, DHL deliveries and Adobe Reader updates. Downloaded files had names that made them look like business documents or installers for familiar applications.

Despite the variety of lures, they ultimately delivered the same legitimate, digitally signed MSP360 RMM installer, version 2.5.0.67. Once the user ran it and approved the privilege elevation prompt, the software installed a persistent remote management service. The RMM agent then launched PowerShell, downloaded ScreenConnect and installed it without a visible setup wizard.

The second product created a redundant access channel. The attacker could transfer and execute further tools used for activities including information collection and credential access. Microsoft did not observe exploitation of a ScreenConnect vulnerability in these campaigns. The issue was abuse of legitimate product functionality that worked as designed.

Why antivirus may not provide a simple answer

Traditional malware can sometimes be recognised by known code or behaviour. RMM software is supposed to perform actions that resemble an administrator’s work: it runs as a service, executes commands, installs software, transfers files and maintains a remote connection. The presence of such an application alone does not determine whether an attack has occurred.

An organisation therefore needs to know its approved state. If the help desk uses one tool with a defined configuration and owner, a second RMM client appearing on an accounting laptop is a strong signal. Without an inventory of approved products, the security team cannot quickly distinguish a supplier’s support session from an attacker’s access.

Legitimate cloud services made assessment harder too. The campaigns used services including Amazon S3, Cloudflare R2, Dropbox, GitLab and Supabase to host files. A familiar platform domain does not automatically make a particular download trustworthy.

What employees should do

Install meeting or document-reading software from the corporate application catalogue or a location specified by IT, not from a button in an unexpected invitation. If a file presented as a document ends in .exe or asks for administrator approval, stop and contact the help desk through a separate channel.

Do not assume that a User Account Control prompt means the company has approved the software. The operating system is asking whether you allow the program to make changes to the device; it does not confirm a business need or the sender’s intent. Report the event even if the program has already run. Early notice gives the team a chance to isolate the device and determine whether a remote access channel was established.

What organisations should do

Maintain a register of approved remote access tools: product name, owner, permitted devices, management servers, authentication method and review date. For authorised platforms, require MFA, individual technician accounts, restricted roles and session logging.

Application control can restrict unauthorised tools. Monitoring should look for a new RMM service, an installer launched from the downloads folder, unusual PowerShell execution by an administration agent and installation of a second remote access platform. Each signal needs context, but the sequence is considerably more meaningful than any event in isolation.

If a device may have been compromised, uninstalling MSP360 or ScreenConnect is not a complete incident response. The organisation needs to establish when access began, which accounts were used, what tools were downloaded, which data was reachable and whether credentials may have been stolen. Only then can trust in the device and its accounts be restored safely.

Employees can prepare through cybersecurity training based on realistic scenarios. Our guide to secure remote work develops the controls around legitimate support sessions, while the incident response plan explains what to do after a suspicious file has been run.

Source facts and Breachroad’s conclusions

Microsoft Security’s analysis describes the July 2026 campaigns, the lures, the signed MSP360 installer, the subsequent ScreenConnect deployment, the cloud services involved and the follow-on activity. Microsoft explicitly states that it did not observe exploitation of ScreenConnect vulnerabilities in these campaigns and did not attribute the activity to a named threat actor.

The approved-tools register, employee guidance, correlation of signals and scope of the incident assessment are Breachroad recommendations. The abuse of a legitimate product does not imply that its vendor participated in the attack.