AI Malware That Picks Its Own Moves: Why Live Network Visibility Is Your First Line of Defense

The Register just reported on something that should change how every IT operations team thinks about monitoring: CLOSEDQUORUM, the first publicly documented Windows implant that uses large language models as its command-and-control brain. It does not follow a static script an analyst can memorize. It queries an AI model, evaluates what it finds on the compromised host, and autonomously selects its next post-compromise action — which systems to enumerate, which credentials to try, how to move through the environment.

Security researchers will debate detection signatures for months. But if you run infrastructure day to day — Windows Server, switches, firewalls, printers, a NOC full of client networks — there is a more uncomfortable takeaway: whatever that AI decides to do next, it has to do it on your network. It has to sweep subnets, touch switches, authenticate to servers, and move laterally across VLANs. Every one of those actions leaves a footprint in the one layer most IT teams monitor with tools that only know about devices from the last discovery scan.

If your network map is a Visio diagram from two years ago and discovery runs monthly, you are not watching your network. You are watching an old photograph of it.

What an AI-Native Implant Changes About Detection

Traditional malware is mostly deterministic. Analysts pull it apart, extract hashes, domains, and registry keys, and defenders block the list. CLOSEDQUORUM-style implants break that model: behavior is decided at runtime by a model looking at each specific victim. Two infections on two machines can act completely differently. Static indicators become unreliable, and predictable kill chains stop being predictable.

Here is the part that matters for IT operations, though: unpredictability at the host layer still produces observable structure at the network layer. The implant still has to:

• Exist somewhere physical or virtual — often an unmanaged device nobody documented: an IP camera, a smart TV in a meeting room, a test box under a desk
• Enumerate its surroundings — ARP traffic, SMB and WMI sweeps, LDAP queries
• Reach something external for command and control, no matter how the model picks the channel
• Move laterally — which means new east-west connections between devices that have never talked to each other before

None of that requires you to identify the malware. All of it requires you to actually see the network — continuously, with context, in real time.

The Problem: Your Tools Only Watch What They Already Know

Walk through the stack most teams run:

• The RMM — NinjaOne, ConnectWise, Datto — has agents on managed endpoints only. It is blind to the IP camera on VLAN 30, the secondhand switch someone installed under a desk, and the contractor laptop plugged into a conference room port.
• The monitoring tool — PRTG, SolarWinds, LibreNMS — runs sensors configured per known device. A device that was never added gets no sensor, produces no data, and fires no alert. Ever.
• The network map is a Visio file or a spreadsheet, updated when somebody remembers. Industry surveys routinely find double-digit percentages of connected enterprise devices that are unknown or unmanaged by IT.
• The helpdesk receives the fallout. When users start reporting that the file server is slow, your end users have become your detection layer.

Now replay a realistic post-compromise sequence on that stack. An implant lands on a workstation, enumerates the /24, finds a file server, moves laterally over SMB, and reaches a hypervisor. During all of that:

• Every monitored device stays up. Every sensor stays green. Every ping succeeds.
• No RMM alert fires, because from an agent perspective the machines are healthy.
• The only genuinely new observables are a handful of new ARP entries and new east-west traffic patterns — and nothing in the stack watches for either.
• If the attackers dropped a rogue device onto a spare switch port, the next discovery scan eventually flags it. That scan runs monthly or quarterly, so the flag arrives up to 90 days late.

Industry reports consistently put average breach identification near 200 days. That number is not only a security failure — it is a visibility failure. You cannot detect in minutes what your tooling only examines monthly.

For an MSP, the math is worse. Fifty clients, each with switches you have never fully inventoried, each full of IoT devices the client plugged in themselves. You support all of it when it breaks and see none of it when it changes.

The human cost shows up everywhere: technicians firefighting symptoms users report instead of root causes, IT managers unable to produce an accurate SLA report because monitoring data lives in one tool and ticket data lives in another, and 2 a.m. pages for outages a correct topology map would have localized in seconds. Burnout does not come from hard work. It comes from blind work.

How AlertMonitor Makes the Network Itself the Sensor

This is exactly the gap AlertMonitor closes: continuous network discovery and a live topology map that reflects the real state of the network right now.

Continuous discovery, not scheduled scans. AlertMonitor discovers and maps every device on the network — switches, firewalls, access points, printers, IP cameras, unmanaged endpoints — using SNMP, ARP, and active scanning, continuously. The map is always current, because discovery never stops.

Instant alerts with full network context. When a switch goes offline, when a link drops, or when a new device appears anywhere on the wire, an alert fires immediately — carrying the details that make it actionable: which switch, which port, which VLAN, what the device sits next to on the map. That is precisely the signal an AI-driven implant cannot avoid producing: it has to exist somewhere on your infrastructure.

The workflow changes completely.

Old way:

1. A rogue device sits on the network for weeks until a quarterly scan or a user complaint surfaces it
2. The tech checks the RMM — no agent, of course
3. The tech checks the monitoring tool — no sensor, of course
4. The tech Googles the MAC vendor, walks to the wiring closet, and traces the port by blinking LEDs
5. Someone updates the spreadsheet, which is stale again by morning

AlertMonitor way:

1. The device powers on and appears on the wire
2. An alert fires within moments: new device, switch X, port 14, VLAN 30
3. The tech opens the live map and sees exactly where it connects and what surrounds it
4. The alert becomes a ticket in the same platform, a remote session starts from the same console, patch state is checked in the same view — loop closed without ever switching tools

Time savings you actually feel. Rogue-device detection drops from whenever-someone-notices to minutes. Lateral-movement investigations shrink from hours of cross-referencing five consoles to minutes of reading one accurate map. Onboarding a new tech for network troubleshooting goes from weeks of tribal knowledge to a diagram that is simply correct.

For MSPs specifically: every client topology lives in one NOC view. When an unfamiliar MAC shows up at three different clients, you see the pattern across your base instead of discovering it three separate times in three separate tools.

And because monitoring, RMM, helpdesk, and patching run in one product, a network signal never dies in a dashboard — it becomes a ticket, a remote session, a patch job, and an audit trail.

Practical Steps: Close the Visibility Gap This Week

You do not need an AI-powered implant on your network to justify this work. Run it anyway.

1. Reconcile the live network against your RMM inventory. Sweep your user VLANs and compare what answers against what has an agent:

# Sweep a /24 and list every device that answers.
# Compare this output against your RMM agent list - anything
# on the wire without an agent is an unmanaged device.
$subnet = '192.168.10'
$liveDevices = foreach ($i in 1..254) {
    $ip = $subnet + '.' + $i
    if (Test-Connection -ComputerName $ip -Count 1 -Quiet) { $ip }
}
Write-Host ('Live devices found: ' + $liveDevices.Count)
$liveDevices | Out-File -FilePath 'C:\Temp\live-devices.txt'

2. Audit DHCP for clients outside your naming convention. Unknown hostnames in DHCP are usually the first administrative evidence of undocumented devices:

# List active DHCP leases whose hostnames do not match your naming standard
Get-DhcpServerv4Scope -ComputerName 'DC01' | ForEach-Object {
    Get-DhcpServerv4Lease -ScopeId $_.ScopeId -ComputerName 'DC01' -AllLeases
} | Where-Object { $_.HostName -notlike 'CORP-*' -and $_.HostName -notlike 'LT-*' } |
Select-Object IPAddress, HostName, ClientId, LeaseExpiryTime |
Format-Table -AutoSize

3. Find ghost machines in your domain inventory. Domain-joined devices that have not authenticated in months are either decommissioned boxes still cabled in, or documentation that lies:

# Export domain-joined computers with last logon to spot stale or ghost machines
Get-ADComputer -Filter * -Properties IPv4Address, LastLogonDate |
    Select-Object Name, IPv4Address, LastLogonDate |
    Sort-Object LastLogonDate -Descending |
    Export-Csv -Path 'C:\Temp\domain-inventory.csv' -NoTypeInformation

4. Snapshot ARP deltas on your Linux infrastructure. A daily diff of the ARP table is a simple new-device tripwire:

# Snapshot the ARP table and diff against the previous run
# to spot devices that appeared on the segment since yesterday
arp -a | awk '{print $2, $4}' | sort > /tmp/arp-now.txt
diff /tmp/arp-last.txt /tmp/arp-now.txt || true
cp /tmp/arp-now.txt /tmp/arp-last.txt

5. Replace the scheduled-scan mindset with continuous discovery. These scripts are one-time hygiene; the durable fix is a platform where discovery never stops. Stand up AlertMonitor, let SNMP, ARP, and active scanning build the live map, set alert policies for new devices and link-state changes, and route those alerts into the same console where your tickets and remote sessions live. From that point forward, the answer to what is on your network right now is always current — not 89 days stale.

The Bottom Line

You cannot predict what an AI-driven implant will decide to do, and you should not build your operations around trying. You can make one thing certain: nothing touches your network without your map changing and your team knowing within moments. CLOSEDQUORUM gets its advantage from improvisation. Live network visibility takes that advantage away, because whatever it improvises, it has to do it on infrastructure you are actually watching.

Related Resources

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