Green Checkmarks, Stolen Card Data: Closing the Network Visibility Gap That Keeps You Last to Know

A UK reseller of Shelly smart home devices recently confirmed that malware on its website was stealing customer payment data — and the detail that should unsettle every IT manager is who found out first. A customer spotted fraudulent charges on their card hours before the company sent any notification. The business wasn't the first to know about the compromise of its own infrastructure. Its customers were.

If you run infrastructure for a living, resist the urge to file this under "their problem." This is what happens when a monitoring stack can only answer one question: is the thing up? The checkout page loaded. TLS was valid. The uptime dashboard was green. And a few kilobytes of injected script were quietly skimming card numbers the entire time.

You know this failure mode. It's the same one that pages you at 2 a.m. because a disk filled up and the alert threshold was set against a baseline from two hardware refreshes ago. It's the same one that lets an end user — or a customer's bank — become your detection layer. The question isn't whether your tools show green. The question is whether anything is watching for change.

The Problem in Depth: "Is It Up?" Is the Wrong Question

Digital skimming — the Magecart-style attack class that hit British Airways and Ticketmaster — is practically engineered to defeat uptime monitoring. A small script is injected into a payment page and captures card data as the customer types it. From a monitoring perspective, it is nearly invisible:

• The page returns HTTP 200 all day long, so your Pingdom, UptimeRobot, or StatusCake check stays green.
• The injected code adds a few KB to page weight — a fraction-of-a-percent change that trips no threshold.
• No service restarts, no CPU spike, no disk growth. The RMM agent on the web server is watching health, not content or behavior.

Meanwhile, the typical mid-size IT stack stacks four blind spots on top of each other:

1. Uptime checks validate that a page responds — not what the page actually does.
2. RMM platforms (NinjaOne, ConnectWise RMM, Datto) monitor endpoint and server health via agents: CPU, disk, services, patch state. They don't ask "did a new file appear in the web root?" or "why is this process talking to an unfamiliar external IP at 3 a.m.?"
3. Poll-based network monitors (PRTG, SolarWinds, LibreNMS) only know the devices someone manually added. They poll a switch every five minutes and never ask whether the switch's ARP table just grew by a device nobody has ever inventoried. A forgotten vendor appliance or a compromised host is invisible because there is simply nothing configured to poll.
4. Documentation is a Visio diagram or a spreadsheet last touched in 2022. When something goes wrong, the first thirty minutes of the incident are spent on network archaeology: what is even supposed to be on this segment?

Then there's the ownership gap. The web host assumes the agency handles the site. The agency assumes the host handles the server. Internal IT assumes "the website isn't our thing." In the UK reseller case, the compromise lived on the site long enough that fraud started before the company notified anyone. That's not a failure of one tool — it's what siloed architecture produces: every tool green, system compromised.

What this actually costs, in terms any practitioner recognizes:

• Dwell time. IBM's Cost of a Data Breach research has placed average time to identify and contain a breach north of 200 days for years. Even at the optimistic end, you're measuring detection in weeks while a change-aware platform measures it in minutes.
• Compliance exposure. Since March 2025, PCI DSS v4.0 requirements 6.4.3 and 11.6.1 are enforceable: you must inventory and authorize the scripts on payment pages and detect changes to them. "Our uptime monitor didn't notice" is not a control — it's an admission.
• Helpdesk blast radius. A wave of "why was I double charged?" tickets, each opened by a customer, each starting with zero context. The incident timeline gets reconstructed from chargeback dates and angry emails, and your SLA reporting for the quarter is fiction because the real incident never had a ticket.
• Morale. Nothing burns out a tech faster than being the last to know, repeatedly, about systems nobody was actually watching.

For an MSP, multiply all of it by every client with a payment-adjacent system, each monitored with a different hodgepodge — and your NOC becomes a team of archaeologists working across five tabs per incident.

How AlertMonitor Closes the Gap

The common thread in every one of those blind spots: nobody was watching for change with context. That is exactly what AlertMonitor's network visibility layer is built for.

Continuous discovery, not quarterly scans. AlertMonitor continuously discovers every device on the network — switches, firewalls, access points, printers, IP cameras, unmanaged endpoints — using SNMP, ARP, and active scanning. Your inventory becomes a live query, not a spreadsheet that was accurate the day it was exported. If a device exists on a segment, it's in the platform, without anyone having to remember to add it.

The live topology map is the source of truth. The map is generated from what the network actually reports, so it reflects the real state of the network right now — not the state captured in a Visio file three years ago. When a switch goes offline, a link drops, or a new device appears, an alert fires instantly with full network context: what it is, which switch and port it hangs off, what changed.

"New" is always an event. The fundamental question in a scenario like the reseller's is: did something appear or change that nobody expected? With AlertMonitor, a new MAC on a port, an unexpected endpoint on a segment, or an unfamiliar node sitting next to your DMZ is an alert with context — not a surprise discovered during a quarterly review, and never a discovery made for you by an angry customer.

One timeline across monitoring, RMM, and helpdesk. Because AlertMonitor combines infrastructure monitoring, RMM, and helpdesk in a single platform, fraud-complaint tickets and network alerts land in the same system, on the same timeline. Your SLA reporting stops being guesswork because both halves of the incident — what the customer experienced and what the infrastructure did — live in one database.

The workflow difference, concretely:

• Old way: Customer calls about a fraudulent charge → ticket in the helpdesk → tech guesses which server → SSH in and start grepping logs → digs out a stale network diagram → emails the web agency → waits. Detection: days or weeks, reported by customers. Response: hours of blind archaeology.
• AlertMonitor way: An unexpected change fires an alert with network context → the tech clicks the node on the live topology map and sees exactly where it sits and what it connects to → creates the linked incident ticket in the same platform → isolates the host, pushes remediation through integrated patching, documents everything in one place. Detection: minutes. Response: informed minutes instead of blind hours.

Practical Steps You Can Take Today

You don't need an incident to start closing visibility gaps. Run these checks this week — first as one-off baselines, then as scheduled checks that alert on deviation.

1. See what's actually live on your segments right now. Pull the neighbor tables and compare them against your inventory. Everything you can't put a name and an owner to is a finding.

# List live neighbors on the local segment
Get-NetNeighbor -State Reachable, Stale |
    Select-Object IPAddress, LinkLayerAddress, InterfaceAlias |
    Sort-Object IPAddress

# The local ARP table on a Linux box
ip neigh

2. Baseline what listens on your servers. Know your normal so you can recognize abnormal. Run this on your web servers monthly and diff the output.

# Every listening port and the process that owns it
Get-NetTCPConnection -State Listen |
    Select-Object LocalAddress, LocalPort, OwningProcess,
        @{n='ProcessName';e={(Get-Process -Id $_.OwningProcess).ProcessName}} |
    Sort-Object LocalPort | Format-Table -AutoSize

# Listening sockets with owning processes on Linux
sudo ss -tulpn

3. Track change in your web roots. This isn't about building security rules — it's basic change awareness. A file nobody deployed should be a question someone asks in minutes, not weeks.

# Files changed in the last 24 hours under the web root
Get-ChildItem C:\inetpub\wwwroot -Recurse -File |
    Where-Object { $_.LastWriteTime -gt (Get-Date).AddHours(-24) } |
    Select-Object FullName, LastWriteTime, Length |
    Sort-Object LastWriteTime -Descending

# Same check on a Linux web server
find /var/www -type f -mtime -1 -printf '%T+ %p\n' | sort -r | head -25

4. Stop running these by hand. A script you run once during an incident is archaeology; a scheduled check that alerts on deviation is monitoring. In AlertMonitor, you schedule discovery and checks, define what normal looks like per site, and the platform alerts on deviation — a new MAC on a port, an unexpected node, a switch or link change — routing the alert to the helpdesk queue with full context attached.

5. Retire the stale map. Archive the Visio file and make the live topology the single source of truth for planning, incident response, and audits. The test: can a new tech answer "what's on this segment and who owns it?" in thirty seconds from the map? If yes, you've closed the gap that let the UK reseller's customers find out first.

The Shelly reseller will recover. The checkout will get scrubbed, the notification will go out, PCI will have its conversation with somebody. What won't fix itself is the structural gap that let customers detect the compromise before the company did. That gap only closes when watching for change becomes continuous, contextual, and automatic — not a quarterly scan, not a green uptime check, and definitely not a customer's bank statement.

Related Resources

AlertMonitor Network Monitoring & Visibility AlertMonitor Platform Overview Book a Demo Network Monitoring & Visibility Resources