In May, a master key for LiteLLM — the open-source gateway that connects applications to large language models — ended up exposed in a public repository. It was never revoked. In October, an attacker picked it up, used it to access LiteLLM's Agent Platform, and stole a GitHub token with organization-owner privileges. With that token, they published a credential-stealing release of LiteLLM 1.107.0 through PyPI and container registries.
No exotic exploit. No zero-day. The key just existed, unwatched, for five months, in a place no one's tooling looked.
If you run infrastructure for a living, you already know how this happens, because you live a version of it every week — except your version has more blinky lights. It's the printer the facilities team put on the server VLAN. It's the IP cameras installed in 2022 that no monitoring platform has ever polled. It's the hypervisor under a desk in the lab. It's the unmanaged switch daisy-chained off a wall port in a conference room, feeding who-knows-what.
The LiteLLM incident is an inventory failure wearing a supply chain costume. And inventory failures are exactly where network visibility breaks down.
The Problem: Your Tools Only See What They Were Told to See
Most IT stacks have three blind spots stacked on top of each other:
Your RMM only sees agents. NinjaOne, ConnectWise RMM, Datto — pick one — can manage anything that will run an agent. It cannot see the printer, the IP camera, the UPS network card, the smart TV in the boardroom, or the contractor laptop that touched the guest Wi-Fi once. On a typical corporate network, agented endpoints are 40–60% of the actual device count. The rest is dark.
Your monitoring platform polls a hand-built list. PRTG, Zabbix, SolarWinds — someone added 40 devices in 2022 and the list has been drifting out of date ever since. If a switch was never manually added, its failure shows up as... nothing. If a device was decommissioned, you still get green checks for it.
Your documentation is a fossil. The Visio diagram was accurate the day it was exported. Since then: two office moves, a new wing, three cameras, and a switch someone swapped at 5pm on a Friday without updating anything.
Why does this persist? Because these tools are siloed by architecture. The RMM was built around agents, monitoring around SNMP polls of a static list, and documentation around one person's best intentions. Nobody correlates "the DHCP server issued a lease to a MAC I've never seen" with "that MAC just showed up on switch port 14" with "port 14 is on the unmanaged switch in Conference Room B." Every tool holds one fragment. The complete picture only exists if a human assembles it under pressure.
And the human assembles it under pressure when things break:
- The IP conflict that ruins an afternoon. Someone plugs in a device with a hard-coded static IP — the same one as your ERP app server. The app server drops off the network. Monitoring reports "server down," you can't RDP in (network, not OS), so you drive to the office, trace cables, and two hours later find a $60 device that exists in no inventory, on no map.
- The bandwidth mystery. VoIP calls degrade every afternoon. The cause turns out to be a camera on the default VLAN pushing footage to a vendor cloud. Finding it means packet captures at multiple points, because no tool can tell you what is on which port.
- The MSP onboarding surprise. The client says "about 120 machines." Your RMM onboarding confirms 118 agents. The first real discovery pass finds 340 devices: six subnets, three chains of unmanaged switches, forty printers, a camera system sitting on the server VLAN, and a second DHCP server someone stood up in 2021. That last one is a very fun afternoon.
The business impact compounds. MTTR inflates because a huge slice of every incident is spent answering "what is this, where is it, and what does it affect" before anyone fixes anything. Ticket volume climbs because unknown devices generate vague complaints ("the Wi-Fi is slow") from a dozen users instead of one actionable alert. Auditors ask for a complete asset inventory and you hand over a spreadsheet you don't trust. And techs burn out on 2am pages caused by things that were never monitored because nobody knew they existed.
That's the LiteLLM lesson in IT-ops terms: the attacker wasn't brilliant. The asset was simply invisible to every process the team trusted.
How AlertMonitor Puts Every Device on the Map — Continuously
AlertMonitor approaches this from the opposite direction: instead of monitoring only what you told it about, it discovers what is actually there.
Continuous discovery across every device class. Using SNMP, ARP, and active scanning, AlertMonitor finds switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints — including everything that can't or shouldn't run an agent. Not a nightly scan you check on Mondays. Continuous. The moment a new device appears on any segment, an alert fires with full context: IP, MAC, vendor (from OUI), the switch it hangs off, the port, the VLAN. The LiteLLM gap — an asset that existed for five months without anyone noticing — closes to seconds.
A live topology map that reflects reality. When a switch goes offline, a link drops, or a new device appears, the map updates and the alert carries the network context with it. A core switch failure shows you exactly which downstream devices and users are impacted before you stand up — triage in seconds instead of traceroute archaeology. Nobody is maintaining a Visio file, because the map is generated from the network itself.
The fragmented workflow collapses into one. The old way: user reports slowness → check the RMM (agent devices only) → check the monitoring tool (was that switch ever added?) → SSH into switches to read MAC tables → physically trace a cable → resolve a ticket in a separate helpdesk → update nothing. In AlertMonitor: the new-device or link-down alert fires with switch/port/VLAN context, an incident is created in the integrated helpdesk with that context attached, the technician sees the affected segment on the live map, and if the culprit turns out to be a managed endpoint, a remote session is one click away — same console, same device record. Monitoring history, patch state, open tickets, and topology all hang off one record, which also means SLA reporting finally adds up without CSV surgery between systems.
For MSPs: every client, one NOC view. Discovery and topology run per client but roll up into a single dashboard. New-client onboarding starts with a real scan instead of a questionnaire, so the 118-agents-versus-340-devices surprise surfaces in the first hour, not the first incident.
The practical difference: the "what is this and where is it" phase of an incident — routinely 30–60 minutes of SSH, traceroute, and cable tracing — becomes reading one alert. And unknown devices stop being a quarterly surprise and become a notification you handle in seconds.
What You Can Do Today (Before the Platform Does It for You)
Even if you're not ready to change tooling, get a baseline this week. These are the same techniques continuous discovery automates.
1. Measure the agent gap. Run a sweep of each VLAN and compare the live count against your RMM's agent count. PowerShell 7+:
$subnet = "192.168.1" # repeat per VLAN
$live = 1..254 | ForEach-Object -Parallel {
$ip = "$using:subnet.$_"
if (Test-Connection -ComputerName $ip -Count 1 -Quiet) {
try { $name = ([System.Net.Dns]::GetHostEntry($ip)).HostName }
catch { $name = "unresolved" }
[PSCustomObject]@{ IP = $ip; Hostname = $name; Seen = (Get-Date) }
}
} -ThrottleLimit 64
$live | Sort-Object IP | Export-Csv "C:\IT\discovered_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation
"Live devices found: $($live.Count)"
If your RMM shows 120 agents and this finds 300 devices, you now have the number for the slide nobody wanted to make.
2. Baseline your ARP tables and diff them daily. Every router and server already holds a neighbor table. Snapshot it once after a known-good audit, then let a scheduled task surface anything new.
# One-time: capture a known-good baseline
Get-NetNeighbor -State Reachable,Stale |
Where-Object { $_.IPAddress -notlike "169.254.*" -and
$_.IPAddress -notlike "224.*" -and
$_.IPAddress -notlike "239.*" } |
Select-Object IPAddress, LinkLayerAddress |
Export-Csv "C:\IT\arp-baseline.csv" -NoTypeInformation
# Scheduled daily: flag neighbors that are not in the baseline
$known = (Import-Csv "C:\IT\arp-baseline.csv").LinkLayerAddress
$current = Get-NetNeighbor -State Reachable,Stale |
Where-Object { $_.IPAddress -notlike "169.254.*" -and
$_.IPAddress -notlike "224.*" -and
$_.IPAddress -notlike "239.*" }
$newDevices = $current | Where-Object { $known -notcontains $_.LinkLayerAddress }
if ($newDevices) {
$newDevices | Format-Table IPAddress, LinkLayerAddress -AutoSize
$newDevices | Export-Csv "C:\IT\new-devices_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation
}
On a Linux gateway, the same idea:
# Snapshot the neighbor table (IPv4 only, skip link-local)
ip neigh show | awk '$4 == "lladdr" && $1 !~ /^fe80/ {print $1, $5}' | sort > /var/lib/itops/arp-now.txt
# Log entries that were not in last night's baseline
comm -13 /var/lib/itops/arp-baseline.txt /var/lib/itops/arp-now.txt >> /var/lib/itops/new-devices.log
# Rotate the baseline for tomorrow
cp /var/lib/itops/arp-now.txt /var/lib/itops/arp-baseline.txt
Schedule it:
# crontab -e (root) — refresh nightly at 02:00
0 2 * * * /usr/local/bin/arp-snapshot.sh >> /var/log/arp-snapshot.log 2>&1
Be honest with yourself about that cron entry: who owns it, who reads the log, and what happens when the box gets rebuilt? Scripts drift. That is the point where a platform starts earning its keep.
3. Walk the closets. Unmanaged switches daisy-chained off a wall port are where invisible devices breed. Every one you find should become a managed, monitored switch — or at minimum a documented port on the map.
4. Make the new-device alert land where people work. A CSV you must remember to open is not visibility. Route device-appearance and link-state alerts into your ticketing flow so a human is accountable within minutes, not whenever someone gets curious.
And when you're ready to stop hand-rolling it: AlertMonitor runs this discovery continuously via SNMP, ARP, and active scanning, keeps the topology map live, and raises new-device and link-down alerts with full switch/port/VLAN context directly into the same platform where your helpdesk and remote sessions live.
The Question Worth Asking
The LiteLLM postmortem boils down to this: the asset existed, it was knowable, and no system anyone actually watched was watching it. Most networks contain dozens of assets in exactly that class.
Ask yourself the question your next incident will ask anyway: if a device joined your network ten minutes ago, how long until you'd know? With continuous discovery and a live topology map, the honest answer is "already." With a quarterly scan and a Visio file, the honest answer is "when a user calls."
Related Resources
AlertMonitor Network Monitoring & Visibility AlertMonitor Platform Overview Book a Demo Network Monitoring & Visibility Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.