The Register's Dark Web Roast recently surfaced an ad circulating in criminal forums: a fake "Google Security Team" voice-phishing operation that promises victims "no script reading" — and then, in the body of its own advertisement, prints the script. That is where the industry is right now. Scammers are branding themselves, writing marketing copy, and mocking their own tradecraft in public. The pitch itself never changes: call a user, claim to be IT support or the security team, and walk them through "verifying" something — a command, a script, a remote session.
It is funny if you are not the person who has to explain to a director why someone in finance gave a stranger a remote session at 4 p.m. on a Tuesday. It is a lot less funny once you accept the real reason it works: from the end user's side, legitimate IT support and fake IT support are indistinguishable.
Your techs call from personal cell numbers. Sessions start ad hoc. Scripts run from random consoles and jump hosts. There is often no ticket, no timeline, no record a user could check. Attackers do not need to defeat your security stack — they only need to imitate a support workflow that has no defined shape. The operational fix is not a security product. It is making your own remote operations coherent, consistent, and on the record.
The Problem: Nobody Can Prove What Ran, When, or Where
Look at the tooling behind a typical mid-size IT team or MSP: monitoring in PRTG, Zabbix, or SolarWinds; remote sessions in ConnectWise Control, NinjaOne, or Datto RMM; ticketing in Freshservice, HaloPSA, or Jira Service Management; plus a freemium remote-desktop tool (TeamViewer, AnyDesk) and a jump host for RDP and SSH. Five products, five agents, five log formats, five different definitions of "done."
Here is what that fragmentation costs, in scenarios every sysadmin and MSP tech will recognize:
The unrepeatable fix. It is 2:14 a.m. A disk-pressure alert fires on the SQL server. A tech RDPs in, runs a cleanup script from their laptop, pastes a screenshot into chat, and goes back to bed. Three weeks later the same alert fires — and nobody, including that tech, can find what was run, against which path, with what exclusions. You re-diagnose from zero, and the incident runs three times longer than the original fix.
The silent partial failure. An MSP pushes a remediation script to 250 endpoints at a client site. 244 return clean output; six fail — truncated output, older PowerShell version, whatever the reason. Nobody notices, because "script ran" and "script worked" are different events and disconnected tools do not distinguish them. The six endpoints resurface later as a much louder failure, on your time, during patch week.
The audit you cannot pass. Compliance asks: "List every remote action taken on FIN-WS-114 last quarter." Between the RMM session log, the jump-host RDP records, the helpdesk, and whatever ran completely out-of-band, that is half a day of stitching spreadsheets — or an honest answer of "we can't," which is worse.
The SLA report nobody trusts. Monitoring says the alert fired at 09:12. The helpdesk ticket was opened at 09:41. The RMM shows the session at 09:52. Three timestamps, three systems, one manual reconciliation in Excel every month. When your metrics require archaeology, they stop being metrics and start being fiction.
Why does this persist? Architecture. These products were built as separate agents with bolt-on "integrations" that sync ticket records — not operational context. Script output, session metadata, and alert correlation do not cross the boundary between tools. So technician behavior fills the gap: shadow scripts, personal remote tools, screenshots pasted into chat. And end users learn, over years, that contact from IT is inherently unstructured — which is exactly the conditioning voice phishers exploit when they phone in wearing your name.
What a Coherent Remote-Operations Workflow Looks Like
This is where unified architecture stops being a slide-deck word and starts mattering at 2 a.m. In AlertMonitor, infrastructure monitoring, RMM, helpdesk, and patch management share one agent, one console, and one timeline per device — so remote work stops being a pile of disconnected events:
- Remote sessions launch from context. The tech opens the alert or the ticket, clicks the device, and starts the session. That session is recorded against the device's timeline — not floating in a separate tool with no provenance.
- Scripts run across device groups, and results feed back into monitoring data. When a remediation script executes, its output lands on the same timeline as the alerts and the ticket. Automated remediations and manual technician actions become the same class of visible, timestamped event.
- The ticket carries the evidence. "What did we do about ticket #4471?" gets answered by the timeline, not by anyone's memory.
- Users get a verifiable process. Every legitimate support interaction has a ticket ID, a named technician, and a session record. "Let me confirm your ticket number and call you back on the published helpdesk line" becomes a real control — because the record actually exists to check against.
Compare the flows. Old way: PRTG alert → switch to ConnectWise → RDP through the jump host → run PowerShell by hand → paste output into Freshservice → hope the timestamps line up in the monthly report. Four consoles, and a six-minute fix takes forty. AlertMonitor way: alert → device view → run the script on the group → output lands in the timeline → the ticket updates itself. One console, one sitting. The alert-to-resolution gap collapses, the audit trail builds itself as a side effect of doing the work, and a technician who joined last month can see exactly how the last five people handled the same alert.
Practical Steps You Can Take This Week
- Map every remote-execution path you have. One spreadsheet: tool, who can run what, where the output goes, how it ties to a ticket. Most teams find at least one path they forgot existed.
- Move your most frequent manual fix into a script engine first. Pick the one thing your techs do by hand every week and standardize it.
- Write scripts whose output is designed to be read later. Hostname, before-state, after-state, one line per finding. Output is documentation.
- Tie every manual session to a ticket. No exceptions, including yours.
- Tell your users the verification step. Legitimate IT always has a ticket ID and will call back on a published number. Consistency is what makes that teachable.
Here are three timeline-friendly scripts to standardize first. The pending-reboot audit — push this to your Windows Servers device group so patch cycles stop surprising you overnight:
# Pending-reboot audit - run via AlertMonitor against your "Windows Servers" device group
$markers = @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending',
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
)
$found = @($markers | Where-Object { Test-Path $_ })
if ($found.Count -gt 0) {
"[$($env:COMPUTERNAME)] REBOOT REQUIRED - $($found.Count) pending marker(s)"
} else {
"[$($env:COMPUTERNAME)] CLEAN - no pending reboot"
}
A critical-service watchdog whose output reads like an incident note — perfect for running across a device group, with every result visible in the same timeline as the alerts it prevents:
# Critical-service watchdog with audit-friendly output
$critical = 'wuauserv', 'WinRM', 'Spooler'
foreach ($svc in $critical) {
$s = Get-Service -Name $svc -ErrorAction SilentlyContinue
if (-not $s) { "[$($env:COMPUTERNAME)] $svc NOT INSTALLED"; continue }
if ($s.Status -ne 'Running') {
"[$($env:COMPUTERNAME)] $svc was $($s.Status) - restarting"
try {
Start-Service -Name $svc -ErrorAction Stop
"[$($env:COMPUTERNAME)] $svc now $((Get-Service $svc).Status)"
} catch {
"[$($env:COMPUTERNAME)] $svc restart FAILED: $($_.Exception.Message)"
}
} else {
"[$($env:COMPUTERNAME)] $svc Running"
}
}
And the same idea for your Linux fleet — flag any filesystem over 80% before it becomes a page:
# Flag Linux filesystems over 80% full - push to your Linux device group
df -hP | awk 'NR>1 && $5+0 >= 80 {print $6 " is " $5 " full (" $4 " free)"}'
The Takeaway
Scammers printing their own script in an advertisement is a joke about confidence. The serious version of the same idea is an IT operation confident enough to put every script run and every remote session on the record — because the platform makes that the path of least resistance. That is what a unified timeline buys you: faster fixes today, a provable history tomorrow, and a support experience your users can actually tell apart from a phone call claiming to be Google.
Related Resources
AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.