Attackers Map Your Network Better Than You Do: Fixing Blind Spots With Live Topology Monitoring

This week the extortion crew ShinyHunters told The Register it hacked the FBI — its words — "to protect our business." Set aside the audacity for a second: for groups like this, network reconnaissance is a business process. They enumerate subnets, fingerprint devices, and find the forgotten switch in a wiring closet, the IP camera plugged in behind a printer, the unmanaged endpoint that never got an agent. They map networks methodically — often more methodically than the teams paid to run them.

That leaves an uncomfortable question for every IT manager and MSP tech: how well do you know your network right now? Not the 2019 Visio diagram. Not the quarterly scan export sitting in someone's Excel file. The network as it exists this minute — including whatever got plugged in twenty minutes ago.

For most teams the honest answer is "not well enough," and that's a tooling problem more than a people problem.

The Problem: Your Tools Only See Fragments of the Network

Most IT environments run on a patchwork that was never designed to fit together:

• The RMM platform (ConnectWise Automate, NinjaOne, Datto RMM) only sees devices with agents. Anything without an agent — switches, access points, firewalls, printers, IP cameras, that lab NAS under someone's desk — simply does not exist to it.
• The standalone monitoring tool (PRTG, SolarWinds, Nagios, Zabbix) polls whatever a technician manually added, sometimes years ago. A switch racked last month that nobody added to the sensor list? Invisible.
• The network map lives in Visio or on a wiki page, updated whenever someone remembers. Which is to say: never.
• The helpdesk (ConnectWise PSA, Freshservice, Jira Service Management) records "Wi-Fi is slow on floor 3" with zero topology context attached.

These gaps exist because the tools were built as silos. RMM was built for endpoints. Legacy monitoring was built around a static device list, with discovery that runs nightly or quarterly at best — so "the network" is a snapshot that can be weeks stale. Nothing cross-references anything else. When a ticket says "can't reach the ERP server," the tech correlates switch, uplink, and VLAN from memory or an outdated diagram.

You know the consequences already, because you live them:

• The unknown device. A contractor's laptop or an unmanaged camera sits on a flat VLAN for eight months. Nobody notices, because discovery ran quarterly and the report went to a mailbox nobody reads.
• The half-degraded link. An edge switch loses one uplink. The network isn't down, it's "slow" — and monitoring shows everything green because the switch itself still answers ping. Three hours of triage across four tools before someone physically walks to the wiring closet.
• The mystery switch. A new switch appears on the network — legitimate (a junior tech racked it) or not. Either way, no alert fires. You find out when spanning-tree does something creative.
• The SLA report nobody trusts. You can't produce an accurate availability report when monitoring data lives in one system and ticket data lives in another.

Industry research keeps finding attacker dwell times measured in days or weeks before detection — largely because criminals spend that time mapping what defenders never inventoried. Every device you don't know about is free reconnaissance for whoever maps it first. The operational cost is just as real: inflated MTTR, "unknown cause" tickets piling up, techs burning out on blind triage, and IT managers signing SLA reports that are educated guesses.

How AlertMonitor Closes the Gap

AlertMonitor's network visibility layer is built on one premise: the map must be live, not a snapshot.

• Continuous discovery via SNMP, ARP, and active scanning. AlertMonitor continuously discovers every device on the network — switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints. Not nightly. Not quarterly. Continuously.
• A live topology map that's always current. Switch-to-switch links, uplinks, and device relationships reflect the real network state right now. When a switch goes offline, a link drops, or a new device appears, you see it on the map. No Visio involved.
• Alerts with full network context. A topology alert isn't a bare "host down" ping failure. It tells you which device, where it connects, what depends on it, and — for MSPs — which client is affected.
• One console, not five tabs. Because monitoring, RMM, helpdesk, and patch management live in the same platform, a link-down alert can auto-create a helpdesk ticket pre-filled with the device, its location, and affected links — and the tech can take remote action from the same pane.

Compare the workflows:

The old fragmented way: user reports slowness → ticket in the helpdesk → tech opens the RMM to check the endpoint → opens PRTG to check the switch → opens the Visio to figure out which switch → walks to the wiring closet. Total: 45–90 minutes of blind triage.

With AlertMonitor: the link drops → the alert fires in seconds with switch, port, and uplink context → a ticket is auto-created → the tech sees exactly which segment is degraded → remote diagnosis or a targeted dispatch. Minutes, not hours.

And the scenario the ShinyHunters story should put front of mind: a new device appears on the network. AlertMonitor raises a new-device alert immediately — the contractor's laptop or the unmanaged camera gets noticed in minutes, not months. For MSPs, per-client topology lives in one NOC dashboard, so Client #7's core switch flapping is seen in context, not buried as alert #3,412 in a generic queue.

Practical Steps You Can Take Today

Before (or alongside) deploying anything, run these checks. They take an afternoon and usually find something surprising.

Step 1: Audit your SNMP coverage. SNMP is how network monitoring sees infrastructure devices, and coverage gaps are extremely common:

# Audit SNMP service status across servers - no SNMP means invisible to network monitoring
$servers = Get-Content .\servers.txt
foreach ($server in $servers) {
    $snmp = Get-Service -ComputerName $server -Name 'SNMP' -ErrorAction SilentlyContinue
    if (-not $snmp) { Write-Output "$server`tSNMP NOT INSTALLED" }
    elseif ($snmp.Status -ne 'Running') { Write-Output "$server`tSNMP $($snmp.Status.ToUpper())" }
    else { Write-Output "$server`tSNMP RUNNING" }
}

Step 2: Baseline what's actually live on a subnet.

# Fast ping sweep of a /24 - requires PowerShell 7+ for -Parallel
1..254 | ForEach-Object -Parallel {
    $ip = "192.168.10.$_"
    if (Test-Connection -ComputerName $ip -Count 1 -Quiet) { $ip }
} -ThrottleLimit 64

On a Linux gateway or jump box, pull the live ARP table instead — it shows every device that box recently spoke to:

# Live ARP neighbors, sorted by last octet
ip neigh show | awk '$1 !~ /fe80/ {print $1"\t"$5}' | sort -t'.' -k4 -n

Step 3: Diff discovered devices against an approved baseline. Anything the comparison flags is a device you didn't expect:

# Compare live ARP entries against an approved device list - '=>' entries are unexpected
$discovered = (Get-NetNeighbor -AddressFamily IPv4 |
    Where-Object { $_.State -in 'Reachable','Stale' -and $_.IPAddress -notlike '169.254.*' }).IPAddress |
    Sort-Object -Unique
$approved = Get-Content .\approved-devices.txt
Compare-Object -ReferenceObject $approved -DifferenceObject $discovered |
    Where-Object SideIndicator -eq '=>' |
    Select-Object -ExpandProperty InputObject

Step 4: Check for silent link failures on your servers. A downed or duplex-mismatched NIC is a classic "monitoring says everything is fine" failure:

# Report any non-Up network adapters across your servers
$servers = Get-Content .\servers.txt
foreach ($s in $servers) {
    Invoke-Command -ComputerName $s -ScriptBlock {
        Get-NetAdapter | Where-Object Status -ne 'Up' |
            Select-Object Name, Status, LinkSpeed
    } | Select-Object PSComputerName, Name, Status, LinkSpeed
}

Step 5: Turn on continuous discovery in AlertMonitor. Point it at each site or VLAN, let SNMP, ARP, and active scanning build the live topology map, then enable the new-device alert and route topology alerts (link down, switch offline) into auto-created helpdesk tickets with full device context. From that moment, "what's on this network?" has exactly one answer, and it's current.

Step 6: Retire the stale diagram. After a week of live mapping, export the AlertMonitor topology and compare it with your Visio file. The diff is usually educational — and it's the last time you'll maintain two versions of the truth.

Know Your Network Better Than They Do

ShinyHunters treats reconnaissance as a business process — mapping networks is their day job. Countering that doesn't require paranoia; it requires knowing your own environment in real time, with a topology map that's never out of date and alerts that arrive with context instead of questions. You can't troubleshoot, support, or defend a network you can't see.

Related Resources

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