Microsoft's threat researchers recently detailed a hands-on intrusion campaign that should make every help desk lead, sysadmin, and MSP owner stop scrolling: attackers impersonate IT support staff in Microsoft Teams, talk an employee into granting remote control, then use PowerShell to install a malicious MSI. The payload is a Node.js backdoor with reconnaissance, screen capture, and WinRM lateral movement built in — and it pivots toward domain controllers and certificate authorities.
Here's the uncomfortable part: the first five minutes of that attack are indistinguishable from how support works at a lot of organizations. A "technician" cold-contacts a user, mentions a vague error, asks to remote in, opens PowerShell. If your team supports users through a patchwork of Quick Assist, TeamViewer, AnyDesk, ScreenConnect, and "just hop on Teams and share your screen" — with sessions that never touch your ticketing system — then attackers aren't outsmarting your security stack. They're exploiting the fact that your legitimate support process has no recognizable, teachable pattern.
This isn't a pitch for another security product. It's a case for fixing the operational chaos that made the scam work in the first place — and a unified RMM is how you fix it.
The Attack Chain, From a Sysadmin's Perspective
- Impersonation. The attacker registers a Teams identity that looks like your internal IT department.
- Social engineering. The user is persuaded to start a screen share and grant remote control "so we can fix the error we're seeing."
- Payload delivery. PowerShell downloads and installs a malicious MSI on the endpoint.
- Backdoor activation. A Node.js-based implant wakes up: system reconnaissance, screen capture, persistence.
- Lateral movement. WinRM — the same protocol your own remote management depends on — carries the attacker toward domain controllers and certificate authorities.
Steps 3 through 5 are post-exploitation that your EDR and security team are supposed to fight. Steps 1 and 2 are an IT operations problem, and they're ours to fix.
Why Existing Tooling Leaves the Door Open
Run an honest audit of how remote support works at most mid-size IT shops and MSPs:
Remote sessions happen outside the ticket. You have ScreenConnect or Ninja for remote control, a separate helpdesk for tickets, and a standalone monitoring tool for alerts. The tech remotes in from the RMM console; the ticket says "fixed printer." There's no link, no session log tied to the request, and no way to prove who did what, when.
Scripts live in personal toolboxes. Every senior tech has a OneDrive folder full of PowerShell scripts. When one runs, the output goes to the tech's console — not to the ticket, not to the monitoring platform. When someone later asks "who ran PowerShell on FIN-WS-042 on the 14th?", the honest answer involves three consoles and a shrug.
Monitoring can't see RMM actions. Your monitoring platform has no record that an MSI was pushed or a script executed via the RMM. So when a legitimate software push and a malicious MSI land on the same endpoint in the same week, neither your timeline nor your ticket history can quickly establish which was which.
Users have no baseline to judge against. At a typical 500-person company, employees have experienced support through at least three different remote tools. Nobody ever taught them what legitimate support looks like, because there was no single pattern to teach. The Teams scam works precisely because "IT will cold-contact you and ask to take control of your machine" is, unfortunately, plausible at most organizations.
The operational cost is real even before anyone gets breached. MSP techs juggle five-plus tabs per client and lose four to six minutes per interaction to tab-switching, re-authentication, and copy-pasting script output back into tickets. Across 15–20 sessions a day, that's nearly two technician-hours burned daily. And when an auditor or a cyber-insurance questionnaire asks whether all remote access is centrally logged, the honest answer is "mostly, across a few different systems."
How AlertMonitor Closes the Gap
AlertMonitor's approach is blunt: remote management doesn't sit beside your monitoring and helpdesk — it lives inside the same platform, on the same timeline.
Sessions are born from the ticket, not from a separate console. The technician opens the device or ticket in AlertMonitor and launches the remote session from there. Session start, duration, and technician identity land on the same timeline as the alerts, script runs, and patch events for that endpoint. No orphaned sessions, no "who remoted into that box?" mysteries.
Scripts come from a governed library, not a tech's OneDrive. In AlertMonitor you save, version, and scope scripts to device groups, then execute them across an entire fleet from the same console you monitor from. Output feeds straight back into monitoring data and the ticket. A PowerShell run becomes a first-class event with a full paper trail — exactly the record you'll want when someone asks what executed where, and when.
One support pattern users can actually be taught. When all support flows through one platform, the message to end users becomes simple and true: "IT will only ever remote in through a session referenced in your ticket. We will never cold-call you on Teams and ask you to install anything." That's a sentence a user can remember — and the most practical counter to support-impersonation scams you can deploy this quarter.
The workflow difference is measurable. Old way: alert in the monitoring tool (tab 1), ticket in the helpdesk (tab 2), remote session in ScreenConnect (tab 3), script from a personal folder, results pasted back by hand. New way: the alert correlates to a ticket, the session opens from that ticket, the script runs from the library, output attaches automatically, and the fix is verified against the live monitor. That's minutes saved on every remote interaction — plus a complete audit trail created as a byproduct of working normally, not as a separate compliance project.
Practical Steps You Can Take This Week
1. Inventory every remote-access tool installed across your fleet. You can't standardize on one supported tool if you don't know what's out there. In AlertMonitor, target a device group and the results land in your monitoring data automatically:
$remoteTools = @('TeamViewer','AnyDesk','ScreenConnect','ConnectWise','RustDesk','GoToAssist','Chrome Remote Desktop')
$paths = @(
'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
Get-ItemProperty $paths -ErrorAction SilentlyContinue |
Where-Object {
$dn = $_.DisplayName
($remoteTools | Where-Object { $dn -like "*$_*" }).Count -gt 0
} |
Select-Object @{n='Computer';e={$env:COMPUTERNAME}}, DisplayName, DisplayVersion, Publisher |
Sort-Object DisplayName
Expect surprises: an abandoned AnyDesk on an executive's laptop, a vendor's ScreenConnect nobody documented. Every one of those is an unmanaged remote door.
2. Verify WinRM reachability before fleet-wide script runs. WinRM is the transport for most Windows remote management — your own scripts and patch pushes depend on it, so keep a live picture of which endpoints respond:
$targets = Get-Content C:\Scripts\servers.txt
$results = foreach ($t in $targets) {
$r = Test-WSMan -ComputerName $t -ErrorAction SilentlyContinue
[PSCustomObject]@{
Server = $t
WinRM = $(if ($r) { 'Reachable' } else { 'No response' })
}
}
$results | Export-Csv C:\Scripts\winrm-status.csv -NoTypeInformation
$results | Format-Table -AutoSize
3. Make service verification part of session closure. "Fixed" should mean "verified," not "I clicked it and it seemed okay." Save this as a library script and run it before closing any ticket:
$services = @('Spooler','wuauserv','WinRM','Dhcp','Dnscache')
Get-Service -Name $services |
Select-Object Name, Status, StartType |
Format-Table -AutoSize
In AlertMonitor, the output attaches to the ticket and the endpoint's timeline automatically — the verification evidence lives where the request lived.
4. Publish one support pattern and repeat it everywhere. Onboarding docs, ticket signatures, user training: support only comes via a ticket with a visible session; IT will never ask you to install software from a cold call; nobody legitimate needs your MFA code. One tool, one pattern, one message.
5. Review the unified timeline weekly. Filter for remote sessions and script executions per device. Anything without a matching ticket gets one. In AlertMonitor that's a single filtered view; in a fragmented stack it's an afternoon of exporting CSVs from three consoles and hoping the timestamps line up.
Boring, Uniform, Logged — and Faster
The Teams support scam succeeded because legitimate remote support was chaos that anyone could imitate. The fix isn't another agent or another dashboard — it's making remote support boring: one platform, one session pattern, every script and session logged against a ticket and an endpoint. That's what an integrated RMM gives you. And the side effect your CFO will appreciate: the same unification that closes the impersonation gap also cuts minutes off every support interaction and turns audit prep from a week into an afternoon.
Related Resources
AlertMonitor RMM & Remote Management
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.