Fake Remote Support Tools: How Businesses Can Stop RMM Phishing

Remote-support software is essential to modern business.

It allows an authorized IT provider to troubleshoot a computer, install updates, monitor system health, deploy security tools, and resolve problems without traveling to every location.

Those same capabilities are valuable to an attacker.

On September 29, 2026, Microsoft Security Research described phishing campaigns that disguised legitimate remote monitoring and management software as meeting invitations, PDF documents, software updates, electronic cards, job offers, signature requests, and package-delivery notices.

When a victim downloaded the file and approved the Windows elevation prompt, the legitimate remote-management agent was installed. The attacker then used it to install a second legitimate remote-access product, giving the attacker redundant, persistent access to the computer.

Microsoft observed the remote channels being used for information collection, credential-access activity, and the transfer and execution of additional tools.

The important lesson is not that all remote-support software is dangerous.

It is that a digitally signed, well-known application can still be dangerous when it is installed from the wrong source, connected to an attacker-controlled account, or used outside an approved support process.

For Southwest Florida small and midsize businesses, the immediate question is:

Can your organization identify every authorized remote-management tool, its owner, the devices where it is installed, and the process employees should use to verify a real support request?

If the answer is no, an attacker may be able to look like ordinary IT support.

What is RMM software?

Remote monitoring and management, commonly called RMM, is software used by internal IT teams and managed service providers to administer computers and servers.

Depending on the product and permissions, an RMM platform may be able to:

• View device health and security status
• Install software and updates
• Run commands or scripts
• Transfer files
• Start a remote-control session
• Restart a computer or service
• Collect inventory and diagnostic information
• Work in the background without the employee present
• Maintain persistent access through a Windows service

These are legitimate administrative capabilities. They are also why an unauthorized RMM installation must be treated seriously.

A thief who steals a screwdriver has a tool. A thief who obtains an RMM agent may have an administrative pathway into the business.

What Microsoft observed

Microsoft Defender Experts observed the campaigns in July 2026 across multiple industries.

The phishing lures directed users to attacker-controlled or compromised pages that imitated familiar business workflows. Payloads were also distributed through legitimate cloud-hosting services, which can make a link appear less suspicious than a download from an obviously unknown server.

The downloaded files used names that appeared to be:

• Zoom or Google Meet installers
• Adobe Acrobat or PDF updates
• Meeting and RSVP invitations
• E-cards
• Job-offer documents
• Document-review or signature requests
• DHL or other delivery notices
• Government or tax-related statements

Behind those names was a legitimate, digitally signed MSP360 RMM installer.

After the user approved the User Account Control prompt, the installer created persistent services, added startup entries, and changed the Windows Firewall configuration. The new RMM service then launched PowerShell, downloaded a ConnectWise ScreenConnect client, and installed it silently.

Microsoft explicitly said it did not observe exploitation of ScreenConnect itself in this campaign. The attackers abused legitimately obtained administration software. Microsoft also observed similar activity using another legitimate deployment product as the first remote-management channel.

This distinction matters. A business should not assume that the presence of a named product proves malicious activity. It should determine whether that particular instance, tenant, installer, configuration, and support relationship were authorized.

Why this technique can bypass ordinary suspicion

Employees are often trained to watch for obvious malware. This attack is harder to explain because much of the software may be authentic.

Several signals can create false confidence:

• The file may be digitally signed.
• The product may belong to a known technology company.
• The download may come through a legitimate cloud platform.
• The software may appear in Windows as an installed program.
• The remote session may resemble normal IT support.
• Security tools may need behavioral and organizational context to distinguish approved use from attacker-controlled use.

A valid digital signature generally helps confirm who signed a file and whether it was altered after signing. It does not prove that the recipient requested the software, that the installer belongs to the company’s IT provider, or that the remote-management account controlling it is trustworthy.

Who is affected?

Any organization using Windows computers and remote support should pay attention, especially businesses where employees can download programs or approve elevation prompts.

The risk is particularly relevant to:

• Medical and dental offices
• Insurance and financial-services agencies
• Property-management companies
• Law firms
• Construction and professional-services firms
• Restaurants, retailers, and franchise locations
• Nonprofits
• Local-government offices
• Businesses with remote or traveling employees
• Organizations using several IT vendors
• Companies without centralized software inventory or endpoint monitoring

Multi-location businesses face an additional challenge. A store manager may receive support from a franchisor, point-of-sale company, internet provider, camera vendor, payment processor, website vendor, and local IT provider. If employees do not know which tools and support procedures are legitimate, attackers gain room to impersonate one of them.

A practical response plan

1. Create an approved remote-support inventory

Document every product authorized to provide unattended or attended access.

For each tool, record:

• Product and agent name
• Software publisher
• Business owner of the relationship
• IT provider or vendor using it
• Devices and servers where it is allowed
• Whether access is attended or unattended
• Tenant, instance, or organization identifier when available
• Installation method
• Service and process names
• Expected network destinations
• Administrative roles
• Multifactor-authentication status
• Logging and retention settings
• Contract end date and removal procedure
• Emergency contact and escalation path

The product name alone is insufficient. Two installations of the same legitimate product can be controlled by different organizations.

2. Remove duplicate, abandoned, and unexplained tools

Businesses often accumulate remote-access software after vendor changes, temporary projects, equipment installations, and emergency support sessions.

An old tool may still provide unattended access even though no one remembers why it is installed.

Compare endpoint inventory against the approved list. Investigate and then remove software that is:

• Unapproved
• No longer required
• Associated with a former provider or employee
• Installed on more devices than necessary
• Connected to an unknown management account
• Missing an accountable business owner

Do not delete a suspicious agent before preserving relevant evidence and determining whether an active incident exists.

3. Restrict software installation

Most employees should not need local-administrator rights for routine work.

Use standard user accounts where practical. Establish a controlled process for installing business software. Consider application-control policies that allow approved publishers, files, paths, or managed installers while blocking or auditing unapproved administration tools.

Application allowlisting requires planning. A rushed policy can interrupt legitimate support, line-of-business software, point-of-sale operations, accessibility tools, or emergency work. Begin with inventory and audit mode, test with representative users, and define an exception process before broad enforcement.

4. Secure approved RMM platforms

For authorized remote-management systems:

• Require multifactor authentication for administrators
• Prefer phishing-resistant authentication where supported
• Use separate named administrator accounts
• Apply least privilege and role-based access
• Restrict access by location, device, or trusted network where feasible
• Review technician and vendor accounts regularly
• Disable dormant accounts promptly
• Protect API keys and automation credentials
• Enable tamper protection where supported
• Log interactive sessions, script execution, file transfer, and policy changes
• Alert on new administrators, new agents, disabled protections, and mass actions
• Review vendor security advisories and install updates promptly

The MSP or vendor should be able to show evidence of these controls, not only state that the product is secure.

5. Give employees a verification process

Employees should know:

• Which company provides IT support
• How that provider normally contacts them
• Which remote-support application is approved
• Whether support staff will ever ask them to install software
• How to independently call the help desk using a saved number
• That an unexpected Windows administrator prompt should be denied and reported
• That meeting, PDF, browser, or security updates should come from approved channels
• That a caller’s knowledge of an employee’s name, vendor, device, or open ticket does not prove identity

An employee should never verify a support request using the telephone number or link supplied in the suspicious message itself.

6. Monitor for unusual remote-management behavior

Security monitoring should look for more than one filename or hash.

Useful signals include:

• A new RMM agent appearing on a device
• An installer launched from Downloads, email attachments, or temporary folders
• Remote software not present in the approved inventory
• A remote agent spawning PowerShell or command shells unexpectedly
• Silent installation of a second remote-access tool
• Creation of new services, startup entries, or firewall rules
• Remote file-transfer activity outside support windows
• RMM sessions involving finance, executive, or administrative devices
• Credential-recovery utilities launched through a remote session
• Security controls being disabled
• A single support account accessing an unusual number of customers or devices

Behavioral evidence and business context are both necessary. A remote session at 2:00 a.m. may be legitimate maintenance—or a serious incident.

7. Prepare a containment and continuity procedure

If an unauthorized RMM tool is discovered, the organization may need to isolate the device, disable accounts, preserve evidence, block the management infrastructure, remove persistence, rotate credentials, and rebuild the system.

But containment can interrupt operations.

Before an incident, decide how the business would continue if a device operating a point-of-sale system, medical workflow, building-control function, dispatch process, or accounting operation had to be isolated.

The plan should define:

• Who can authorize device isolation
• Who contacts the employee and manager
• How evidence will be preserved
• Which accounts and credentials may be exposed
• Whether other devices received the same software
• How alternate work will continue
• When cyber insurance and legal counsel are notified
• What conditions must be met before reconnection
• Whether the device will be cleaned, rebuilt, or replaced

Simply uninstalling the visible remote tool may not be enough. Microsoft observed attackers establishing a second remote-access channel and delivering additional utilities.

8. Test the process

Conduct a tabletop exercise using a realistic scenario:

An employee receives a Zoom meeting invitation, downloads an installer, approves the Windows prompt, and then notices the mouse moving by itself.

Test whether the employee knows whom to call, whether the help desk can identify the device quickly, whether endpoint isolation works, whether logs show the installation and subsequent activity, and whether the employee can continue critical work safely.

What to do if an employee installed a suspicious support tool

Treat it as a potential security incident.

Recommended immediate actions, performed by qualified personnel, include:

1. Disconnect or isolate the affected device through an approved process.
2. Tell the employee not to continue interacting with the caller or attacker.
3. Preserve the message, link, downloaded file, browser history, timestamps, and security alerts.
4. Identify the RMM tenant or remote destination controlling the installation.
5. Check for secondary remote-access tools, new services, startup entries, firewall changes, scheduled tasks, scripts, and transferred files.
6. Review accounts and credentials used on the computer after the suspicious installation.
7. Search the organization for the same message, file, installer, service, network destination, and behavior.
8. Coordinate credential rotation from a trusted device.
9. Determine whether data was accessed, collected, staged, or transferred.
10. Decide whether the affected computer can be trusted or requires a clean rebuild.

Do not assume the incident is resolved because the first program was removed or antivirus quarantined one file.

How AI can help

AI-assisted security and IT tools can help a qualified team:

• Compare installed software with an approved RMM inventory
• Normalize variations in product and process names
• Summarize endpoint, email, identity, and firewall events
• Identify remote-tool installations that preceded PowerShell activity
• Correlate a phishing message with affected devices
• Highlight new services, firewall rules, and persistence mechanisms
• Detect unusual support times or technician behavior
• Cluster similar lures sent to multiple employees
• Build an incident timeline
• Summarize scripts and commands for analyst review
• Draft employee notifications and management updates
• Prioritize systems by business impact

AI can accelerate investigation, especially when a small IT team must review many devices and logs.

It should not be allowed to make unsupported conclusions. The presence of a legitimate RMM product does not prove compromise, and the absence of one known file hash does not prove safety.

Sensitive logs, credentials, customer information, medical information, legal documents, API keys, and incident evidence should only be processed through approved systems with appropriate data protection and retention controls.

Where human judgment is required

Qualified people must determine:

• Whether the installation was authorized
• Which vendor or tenant controls it
• Whether observed commands were legitimate support work
• Whether a device should be isolated immediately
• Whether critical operations require an alternate procedure
• Which evidence must be preserved
• Which credentials need rotation
• Whether lateral movement or data access occurred
• Whether a clean rebuild is required
• Whether an insurer, attorney, regulator, customer, or law-enforcement agency should be notified
• When the device can safely return to service

Automation can detect and contain quickly. Management must define the operational and risk boundaries in advance.

Questions to ask your IT provider

1. Which remote monitoring and support tools are authorized in our environment?
2. Can you show an inventory of every enrolled device?
3. How do you identify an agent connected to another company’s RMM tenant?
4. Are technicians required to use MFA and named accounts?
5. Which privileged actions require approval?
6. Are remote sessions, scripts, file transfers, and configuration changes logged?
7. How long are those logs retained?
8. What alerts are generated when a new remote tool is installed?
9. Can ordinary users install remote-management software or approve elevation prompts?
10. How are former technician and vendor accounts removed?
11. How do you restrict unattended access to critical systems?
12. What is the process for verifying a support call or unexpected remote session?
13. When did you last test isolation, investigation, and restoration?
14. How would we continue operating if a critical device had to be contained?

How Managed Intelligence Advisors can help

Managed Intelligence Advisors helps Southwest Florida organizations use remote support safely while preserving the speed and efficiency their operations require.

We can help:

• Inventory approved and unapproved remote-access software
• Map agents to the responsible provider, tenant, contract, and business owner
• Review administrator roles and multifactor authentication
• Evaluate local-administrator rights and installation controls
• Assess Microsoft Defender, EDR, RMM, SIEM, SOC, and MDR coverage
• Build application-control policies with staged testing
• Review logging, alerting, and retention
• Investigate suspicious remote-management activity
• Coordinate providers during an incident
• Design employee verification and help-desk procedures
• Test device isolation and restoration
• Create business-continuity procedures for critical devices
• Review vendor offboarding and agent removal
• Use AI-assisted analysis with qualified human validation
• Give leadership a clear explanation of authorized access, gaps, and remaining risk

The goal is not to eliminate remote support.

It is to ensure that every remote pathway is known, authorized, protected, monitored, and removable—and that employees can distinguish their real IT provider from an attacker using a familiar tool.

Suggested call to action: Request a Remote Support, RMM, and Endpoint Security Readiness Review from Managed Intelligence Advisors.