Fake Job Interviews Just Backdoored 30,000 Devices — Can You See What's Running on Yours?

This week's reporting on the WaterPlum campaign reads like a threat-intel story: North Korean operators posing as recruiters, dangling fake coding tests in front of jobseekers, backdooring an estimated 30,000 devices, and draining more than 7,000 crypto wallets from the access they harvested.

If you sit in an IT operations chair, read it differently. Those 30,000 machines had software on them that nobody approved, and nobody noticed — because nobody was looking. No agent checking in. No inventory. No remote session anyone could open to ask a machine a simple question: what changed here in the last 48 hours?

Every environment has devices in that category. The contractor's laptop that touches the file server once a week. The new hire's machine that's "almost done" being provisioned. The workstation whose agent got removed during a cleanup project in 2023 and never came back. Your monitoring covers the servers beautifully. The rest of the fleet runs on trust.

That's the real lesson of this story for IT managers, sysadmins, and MSP techs: preventing the attack is someone else's job, but closing the blind spot is yours. And most teams can't close it because their tooling is as fragmented as the fleet it's supposed to manage.

The Problem: Half Your Fleet Runs on Trust

Ask three sysadmins in the same company how many endpoints are actively managed and you'll get three different numbers. That's not a people problem — it's an architecture problem, and it looks like this:

• Standalone monitoring (PRTG, SolarWinds, Zabbix) is deep on servers, switches, and SNMP counters but shallow on Windows workstations. Worse, per-node licensing quietly teaches teams that only "important" machines deserve an agent.
• A separate RMM (ConnectWise Automate, NinjaOne, Kaseya VSA) has excellent remote control and scripting — as a second login, second agent, and second database. Anything it wasn't deployed to simply doesn't exist.
• A standalone helpdesk (Freshservice, Zendesk, ConnectWise Manage) knows a ticket says "laptop is slow" but has no idea what the monitoring platform saw on that laptop in the same hour.
• Patching (WSUS, SCCM, Intune) produces its own compliance reports in its own console, disconnected from what's actually happening on the device.

Each tool is individually defensible. Together, they guarantee that answering basic fleet questions takes days instead of seconds.

Scenario 1 — the fleet question. Your security lead reads the WaterPlum story and asks something perfectly reasonable: "What version of that developer tool do we have installed, and on which machines?" In a fragmented stack, the honest answer is "give me two days to remote into machines and eyeball Add/Remove Programs." With software inventory built into the same platform as monitoring, it's a search box and 30 seconds.

Scenario 2 — the 2 a.m. page. An alert fires at 2:14 a.m.: disk pressure on a file server. The on-call tech opens the monitoring console, confirms it, then switches to the RMM tab to run the cleanup script — and finds the agent on that box is offline. Now it's TeamViewer, manual cleanup, and handwritten notes in the helpdesk afterward. Alert-to-resolution: 90 minutes for a task that takes four when the tools talk to each other.

Scenario 3 — the MSP Tuesday. Twelve tabs across five tools to support one client, times 30 clients. Onboarding a new client means deploying two or three agents per endpoint before anyone can even see the machines. Every patch cycle means triaging compliance reports in one console while remote sessions queue up in another.

The cumulative cost shows up everywhere: MTTR measured in hours instead of minutes, ticket volume inflated by machines nobody proactively checked, SLA reports that can't be reconciled because monitoring says 12-minute response while the helpdesk says two hours (both are "right" — they're measuring different clocks), and techs burning out on swivel-chair work that automation should have absorbed years ago.

How AlertMonitor Closes the Gap

AlertMonitor was built on a simple bet: the fastest way to resolve an incident is to make sure the tool that saw the problem can also fix it. Concretely:

• One agent, one console. Monitoring, RMM, helpdesk, patch management, and network topology run on the same platform and the same device record. Workstations get the same first-class coverage as servers — and if a device stops checking in, it shows up as missing, not forgotten.
• Software inventory is monitoring data. Every check-in collects installed applications and versions. Searching the fleet for a specific application, version, or publisher takes seconds — no RDP safari required.
• Run scripts across device groups. Write a PowerShell or Bash script once, target a device group, and execute fleet-wide. Every result lands on each device's timeline, right next to its alerts and tickets — so automated remediations and a technician's manual actions are visible in one audit trail.
• Remote sessions from the same screen. Click a device or an alert, open the session. No tab-switching, no separate credential store, no "which tool owns this machine" archaeology.
• Patching lives in the same pane. Compliance by device group, pending-reboot states, scheduled pushes — and when a patch fails, the resulting alert and the fix script share one timeline.

The old workflow: alert in the monitoring tab → switch to the RMM tab → agent's offline → fall back to TeamViewer → fix by hand → retype everything into the helpdesk → hope the monthly report reconciles. The AlertMonitor workflow: alert fires → device page shows the timeline → run the remediation script or open a session → output is logged automatically → ticket is updated → patch state reflects the change. Ninety minutes becomes single-digit minutes, and fleet-wide questions that used to take two days take thirty seconds.

Practical Steps You Can Take This Week

1. Get honest about agent coverage. Count your actual endpoints — including contractor laptops, new hires, and anything on VPN — against machines reporting into any management platform. Every gap is a device whose software you can't see. In AlertMonitor, devices that stop checking in surface automatically; make closing that list a weekly habit.

2. Baseline installed software across the fleet. Whether it runs inside AlertMonitor's script engine or on a single box for now, know what's installed. This is the inventory question the WaterPlum story makes painfully relevant — and it's pure IT hygiene:

# Enumerate installed applications from the registry (32 and 64-bit)
$paths = @(
    'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*',
    'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
Get-ItemProperty $paths -ErrorAction SilentlyContinue |
    Where-Object { $_.DisplayName } |
    Select-Object DisplayName, DisplayVersion, Publisher, InstallDate |
    Sort-Object DisplayName |
    Format-Table -AutoSize

In AlertMonitor, you'd save this as a script, target your Engineering Workstations group, and every machine's answer lands on its timeline — searchable later without touching a single device.

3. Check patch reality, not patch reports. A machine can report "patched" and still be one reboot away from unprotected. Pending-reboot state is the ground truth:

# List which servers are sitting on a pending reboot after patching
$servers = Get-Content .\servers.txt
foreach ($server in $servers) {
    $rebootPending = Invoke-Command -ComputerName $server -ScriptBlock {
        (Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending') -or
        (Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired')
    }
    [PSCustomObject]@{
        Server        = $server
        RebootPending = $rebootPending
    }
}

4. Do the same on Linux endpoints. Recently installed packages tell you what changed on a box — useful during any "what happened here" review, not just security ones:

# Debian/Ubuntu: last 20 package installations or upgrades
grep " install " /var/log/dpkg.log* | tail -20

# RHEL/CentOS/Rocky: most recently installed packages
rpm -qa --last | head -20

5. Turn one-off scripts into scheduled automation. Any script you've run twice manually should be a scheduled check that feeds the monitoring timeline — and flags failing devices as alerts or tickets. That's the difference between inventory you did once and inventory you actually have.

The WaterPlum story ends with 7,000 emptied wallets. The boring operational version of the same story happens every week in environments where nobody could answer "what's installed on that machine?" without booking an hour of remote sessions. Close the coverage gap, put inventory and scripting in the same console as your alerts, and the next awkward fleet question takes thirty seconds instead of two days.

Related Resources

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