Phishers Are Installing RMM Tools on Your Endpoints — How to Take Back Control of Remote Access

Two recent security reports, covered by Redmond Magazine, describe a shift that should make every sysadmin and MSP tech uncomfortable. Phishing campaigns are no longer just stealing passwords — they're convincing users to install legitimate remote management software like AnyDesk, TeamViewer, and ScreenConnect-class tools, handing attackers full remote control of the machine. A second wave embeds hidden instructions inside emails designed to manipulate AI email assistants into taking actions the user never requested.

Different techniques, same lesson: the trust boundaries inside your own tooling are the new battlefield. And for IT teams, the first half lands squarely on your desk — because the software attackers abuse is the same software your technicians rely on at 2 a.m.

Ask yourself the question most IT shops genuinely cannot answer in under an hour: which remote access tools are installed and running across every endpoint I manage right now? If that answer lives in five different consoles and a spreadsheet, you have a control problem — and it's already costing you in response time, audit readiness, and staff sanity.

The Problem in Depth

The attack doesn't look like an attack

There's no payload for your antivirus to flag. The user installs TeamViewer themselves after a convincing "IT support" call or a phony helpdesk email. The binary is signed, legitimate, and behaves exactly as designed — the problem is who's on the other end. From that moment, the attacker has a persistent, GUI-level session: screen, keyboard, clipboard, file transfer. No malware, no exploit, no alert from any traditional monitoring stack.

The uglier variant: an attacker compromises a technician account or an RMM console itself. Now they don't need to phish one user — they inherit administrative remote access to hundreds or thousands of endpoints at once. This is exactly why RMM platforms are prized targets, and why the tool you use to manage your fleet needs to live inside a governed, audited platform rather than as a standalone app on someone's desktop.

Fragmented tooling makes this invisible

Here's why so many teams find out weeks too late:

• Monitoring tools like PRTG, Zabbix, and Nagios don't watch software. They watch services, uptime, and bandwidth. A new remote access application installed on a workstation generates exactly zero events — not out of scope by accident, but because those tools were never built to see it.
• Remote access sprawl. TeamViewer for one thing, AnyDesk for another, ConnectWise ScreenConnect for clients, Zoho Assist for the vendor. Each has its own console, its own credential store, its own update cycle. Nobody can correlate a remote session on a client's file server with the helpdesk ticket from the same day.
• The helpdesk lives somewhere else. A user submits "my mouse moved by itself and a window closed." In a disconnected stack, that ticket sits in Zendesk or Freshdesk while the technician who could actually see what changed on that machine is working in a completely different tool.
• Patching is a separate project. When a vulnerability lands in a remote access tool itself — as it repeatedly has with ScreenConnect-class products — the fix competes in a patch queue that doesn't even know which endpoints have the tool installed.

The AI email assistant angle compounds the pattern: hidden instructions inside emails making trusted productivity tools act on the attacker's behalf, in a layer your infrastructure monitoring can't see. Trusted software, weaponized, in your blind spot — that's the common thread.

What this actually costs

• Detection time measured in weeks, not minutes. An attacker with a silent remote session doesn't trip a single sensor in a traditional stack. Most incidents surface when a user notices something odd — or when the damage is already done.
• The MSP reality: 12 tabs across 5 consoles. Answering "which clients have UltraVNC installed?" means logging into each client environment and running a manual audit. That's days of work, and the answer is stale the moment you finish.
• Compliance and accountability gaps. When an auditor — or a client — asks who accessed which machine and when, a patchwork of standalone remote tools gives you no unified answer.
• Technician burnout. Your techs context-switch between consoles, re-authenticate constantly, and copy device names between windows. Every switch adds minutes to resolution and drains the team.

How AlertMonitor Closes the Gap

AlertMonitor was built on the premise that monitoring, remote management, helpdesk, patching, and alerting belong in one platform — because the workflows that take back control of remote access are the same workflows that break down between disconnected tools.

One inventory, every endpoint, every client. Every installed application across your Windows and Linux fleet is indexed in AlertMonitor. Search "TeamViewer" or "AnyDesk" and get an answer across all managed devices in seconds — not days of per-client manual audits.

RMM that lives where your monitoring lives. Open a remote session directly from a device record, from an alert, or from a ticket. Run a script against one device or an entire device group. Push software. No tab-switching between a monitoring console and a separate remote control tool — because there's only one console.

Every action on one timeline. Script results, remote sessions, patch deployments, and automated remediations all feed back into the same monitoring data and the same device timeline. When something looks wrong on a machine, you see the full story: what got installed, what ran, who connected, what changed. That's also your audit answer — who did what, when, on which endpoint.

Patching that includes the tools you depend on. Because patch management is part of the same platform, the remote access layer gets patched on the same cycle as Windows updates and third-party applications — with compliance reported per device, per client.

The workflow difference. Old way: alert fires (or doesn't) → log into the RMM console → log into the helpdesk → manually correlate → write up findings → hope nothing else changed. AlertMonitor way: alert → device record shows install history and recent sessions → remote in → run remediation script → script output lands on the timeline → ticket documented automatically. Minutes instead of hours, with the audit trail included.

Practical Steps: Take Inventory This Week

You don't need a platform migration to get a handle on this. Start with ground truth: what remote access software actually exists in your environment.

1. Audit installed remote access applications on Windows endpoints:

# Audit installed remote-access applications on a Windows endpoint
$uninstallKeys = @(
    'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*',
    'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*',
    'HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*'
)

$remoteTools = 'anydesk|teamviewer|screenconnect|rustdesk|ammyy|ultraviewer|splashtop|logmein|gotohttp|ultravnc|tightvnc|zoho|supremo'

Get-ItemProperty -Path $uninstallKeys -ErrorAction SilentlyContinue |
    Where-Object { $_.DisplayName -match $remoteTools } |
    Select-Object PSComputerName, DisplayName, DisplayVersion, Publisher, InstallDate |
    Sort-Object DisplayName -Unique |
    Format-Table -AutoSize

In AlertMonitor, upload this to the script library and execute it against a device group — "All Workstations" or a specific client. Results appear directly on each device's timeline and become part of your permanent inventory record.

2. Check which remote-access services are actually running — an installed app matters; a running one matters more:

# List remote-access related services and their current state
$remoteSvc = 'anydesk|teamviewer|screenconnect|rustdesk|vnc|splashtop|ultraviewer|zoho'

Get-CimInstance -ClassName Win32_Service |
    Where-Object { ($_.DisplayName -match $remoteSvc) -or ($_.PathName -match $remoteSvc) } |
    Select-Object Name, DisplayName, State, StartMode, StartName |
    Format-Table -AutoSize

3. Cover your Linux fleet too:

# Audit remote-access services on a Linux endpoint
systemctl list-units --type=service --state=running \
  | grep -Ei 'rustdesk|xrdp|vncserver|teamviewer|anydesk|guacd' \
  || echo "No remote-access services running"

# Which processes are listening on common remote-desktop ports
ss -tlnp | grep -E ':(3389|5900|5901|5800)'

4. Verify patch posture on the endpoints where those tools run. An outdated remote access tool is as much a liability as an unknown one:

# Patch posture: last installed update + pending reboot state
$session  = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$last     = $searcher.QueryHistory(0, 1) | Select-Object -First 1
"Last installed update : $($last.Date)"

$pendingReboot = @(
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired',
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
) | Where-Object { Test-Path $_ }

if ($pendingReboot) { "Pending reboot        : YES" } else { "Pending reboot        : NO" }

5. Operationalize it in AlertMonitor. Schedule the inventory script as a recurring job across device groups. Newly discovered remote access applications land on the device timeline automatically, and because the helpdesk is in the same platform, an exception — an unapproved tool on a user's machine — becomes a ticket with full device context in one click. Your patch compliance reports include those endpoints automatically. No spreadsheet, no per-client manual audits, no stale answers.

The lesson from these reports isn't "stop using remote management tools" — you can't run modern IT without them. The lesson is that remote access demands the same discipline as everything else in your environment: complete visibility, centralized control, unified auditing, and a single platform your team actually lives in. That's exactly the gap a fragmented tool stack leaves open — and exactly the gap AlertMonitor exists to close.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources