Attackers Now Breach Networks for $25 a Target — Would You Even Notice the New Device on Yours?

Security researchers at Israeli firm Gambit recently documented something that should reset every IT team's assumptions. An attacker used open-source AI tools to hit 105 online retailers in five days and compromised 27 of them. Cost per target: about $25. The toolkit was off the shelf — Strix for vulnerability discovery, Cairn for autonomous end-to-end exploitation, and Hermes to orchestrate the campaign. The haul: 600,000 active credit card records from just two businesses, card skimmer scripts planted at five more, and footholds in an unknown number of major companies.

Read that as an operations story, not just a security story. To compromise those 27 networks, the attacker had to move through them. Enumerate hosts. Map subnets. Find a path from the internet-facing layer to the payment systems. Plant skimmer scripts and persistence. Every one of those steps left a footprint on the network — new hosts appearing, new traffic between devices that had never spoken, new services listening where none had been.

Now the uncomfortable question. On the day that attacker scanned one of those networks, how long would it have taken the IT team to notice a device they didn't recognize? If your honest answer involves "the quarterly scan," "the audit," or "when a user complains," you have the same gap those 27 companies had — and it now costs an attacker $25 to find it.

The Problem: You Can't Spot "New" If You Don't Know "Normal"

Every network alert that matters is based on one principle: something changed against a baseline. A device appears. A device disappears. A link drops. A host starts talking to a subnet it never touches. All of that detection is only as good as the baseline — and for most IT teams, the baseline is fiction.

• Your RMM only sees managed endpoints. Ninja, ConnectWise, Datto — the agent covers machines where someone installed it. It knows nothing about the printer in accounts payable, the eight IP cameras on the warehouse VLAN, the conference-room mini-PC nobody onboarded, or the switch in the IDF closet that hasn't been touched since the fit-out.
• Standalone monitoring waits for you to add devices. PRTG, SolarWinds, Zabbix — someone creates sensors by hand. Anything that arrived after the initial setup never got a sensor. If nobody knows it exists, nobody monitors it: no visibility leads to no monitoring leads back to no visibility.
• Diagrams and spreadsheets rot fast. The Visio file is from 2019. The device spreadsheet is from the last audit, with MAC addresses typed by hand and half of them wrong. Nobody trusts these artifacts, so nobody uses them — and nobody replaces them either.
• The raw data exists everywhere except where you can use it. DHCP leases live on the server. MAC tables live on each switch. ARP caches live on every router and workstation. Correlating that into "every device on this network right now" is a human-with-a-spreadsheet job, so it happens at audit time instead of every day.

What This Costs in the Real World

• Dwell time is measured in months. IBM's annual breach research consistently puts mean time to identify a breach around 200 days. The Gambit campaign ran five days against 105 targets before researchers even saw it. Your detection window is the whole game.
• The rogue-device scenario. A contractor plugs a consumer router into a conference room drop for "better Wi-Fi." It NATs traffic around your firewall for eight months, until a pentest finds it. Nothing was watching for new devices on that VLAN, so nothing noticed.
• Lateral movement with no tripwire. Phishing lands on one workstation. The attacker scans the subnet, finds the file server, keeps going. Detection depends entirely on someone recognizing "not normal" — but without a live inventory and topology, "normal" was never defined.
• MSP onboarding drags for weeks. New client, three sites, a couple of /24s each. Discovery becomes a project: port scans, switch MAC table dumps, a spreadsheet nobody maintains. The first QBR reveals devices nobody can name, and the client quietly loses confidence.
• Audit and compliance pain. PCI scope conversations start with "list every device that can reach the cardholder network." If the answer takes two weeks of archaeology, the audit takes two weeks.

And this isn't only a security problem. When a branch switch dies at 8:50 on a Monday, do you know within minutes — or when the third user tickets "the internet is down"? Every blind spot in your inventory is also a support blind spot, and it shows up in your MTTR and your ticket volume long before it shows up in an incident report.

How AlertMonitor Closes the Visibility Gap

AlertMonitor treats network discovery as a continuous state, not a quarterly project.

• Continuous, multi-method discovery. AlertMonitor sweeps your networks using SNMP, ARP, and active scanning — ongoing, not quarterly. Switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints are discovered and added automatically. The consumer router in the conference room shows up in the first sweep cycle, not eight months later.
• A live topology map. The map reflects the network's real state right now: devices, links, dependencies. When a switch goes offline, when a link drops, when a new device appears — an alert fires instantly, with network context attached: which switch, which port, which VLAN. Technicians stop guessing and start acting.
• Alerts that mean something. Because the baseline is live, "new device detected" is a meaningful alert rather than noise. In a fragmented stack, that alert doesn't exist at all.
• The full loop in one platform. The discovery alert auto-creates a ticket in the integrated helpdesk. The technician reviews the context, opens a remote session, verifies or isolates the device — without switching tools. Monitoring coverage and patch status for the affected segment are visible in the same console.

Before and After: An Unknown Device on VLAN 20

For MSPs, discovery templates and alert policies roll out across every client from the NOC dashboard. Onboarding discovery drops from weeks of manual sweeps to hours — the collector maps the environment while you configure alert routing. Every client gets the same live-map standard, which turns "what devices do you even have?" from an archaeology project into a screen share.

The time savings are ones you actually feel: unknown-device triage goes from days of spreadsheet diffing to one alert with full context. Audit prep goes from two weeks of gathering to an export of the live inventory. And the 2 a.m. question — "is it the switch or the uplink?" — gets answered by the map before you've finished logging in.

Practical Steps: Establish Your Network Baseline Today

Before you can detect "new," you need "known." Here's how to start today, with tools you already have.

Step 1: Sweep the Subnet and Record Live Hosts

# Ping-sweep a /24 and save responsive hosts (PowerShell 7+)
$results = 1..254 | ForEach-Object -Parallel {
    $ip = "192.168.10.$_"
    if (Test-Connection -ComputerName $ip -Count 1 -Quiet) { $ip }
} -ThrottleLimit 64

"Responsive hosts found: $($results.Count)" $results | Sort-Object { [version]$_ } | Out-File "C:\IT\live-hosts.txt"

Step 2: Flag Everything You Can't Immediately Identify

# Compare live hosts against your approved inventory
# approved-devices.csv columns: IPAddress, MAC, Owner, Purpose
$approved = Import-Csv "C:\IT\approved-devices.csv"
$live     = Get-Content "C:\IT\live-hosts.txt" | Where-Object { $_ -match '^\d+\.' }

$review = $live | Where-Object { $_ -notin $approved.IPAddress }

if ($review) {
    "Devices that need review before you can trust this baseline:"
    $review
    $review | Out-File "C:\IT\needs-review.txt"
} else {
    "All live hosts match the approved inventory."
}

That "needs review" list is the one that matters. Every device on it is either an asset that fell out of your inventory — or exactly the kind of quiet foothold a $25 attack depends on.

Step 3: Capture MAC Addresses for Identification

# Build an IP-to-MAC inventory from the local ARP cache
arp -a | Select-String 'dynamic' | ForEach-Object {
    $p = ($_ -replace '\s+', ' ').Trim() -split ' '
    [PSCustomObject]@{ IP = $p[0]; MAC = $p[1] }
} | Export-Csv "C:\IT\arp-inventory.csv" -NoTypeInformation

From a Linux jump host, nmap gives you the same picture plus MAC vendors:

# Sweep the VLAN and capture IPs with MAC addresses
sudo nmap -sn 192.168.10.0/24 | grep -E "Nmap scan report|MAC Address" | tee /it/vlan10-sweep.txt

Step 4: Stop Doing This Manually

Be honest about the limitation of the scripts above: they're a snapshot. They tell you what's live right now. They tell you nothing tomorrow at 3 a.m. when a new MAC appears on VLAN 20, and they can't tell you which switch port it's plugged into. That's exactly the gap AlertMonitor's continuous discovery fills:

1. Deploy the AlertMonitor collector and scope your subnets and SNMP credentials.
2. Continuous discovery sweeps — SNMP, ARP, and active scanning — populate the live topology map automatically.
3. Review the initial inventory once with your team. After that, anything new is signal, not noise.
4. Enable the "new device detected" alert policy and route it to your helpdesk queue. Each alert arrives with switch, port, and VLAN context.
5. For MSPs: apply the same discovery template and alert policy across every client site from one dashboard.

After that, "what's on this network right now?" is a live map instead of a spreadsheet that was wrong the day you finished it. And when an AI-driven attack starts mapping your environment for $25, it lands on a network where every move it makes trips an alert — with your team holding the only accurate map.

Related Resources

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