DEV Community

StarkMan
StarkMan

Posted on

Turning a one-off VMmanager check into a monitoring routine

#security #zoomeye #vmmanager #hosting

Turning a one-off VMmanager check into a monitoring routine

Most organisations run an exposure query once, after a breach headline, and never again. For a virtualisation control plane that pattern is weak, because the population it belongs to changes as hosting businesses deploy, migrate and retire installations. The measurement from 27 October 2026 is a snapshot, and the useful thing about it is that it can be repeated.

Build the baseline

The first run is a baseline, not a finding. Record four values: the global asset count for title="VMmanager", the count restricted to your own address ranges and domains, the count on port 443, and the number of distinct hostnames you did not previously know about.
The last value is the one that drives action. A panel on an address your inventory does not contain is either a new deployment, a shadow installation, or a reseller arrangement that nobody documented. Each of those is worth resolving before the next incident forces the question.

Set the cadence around change, not the calendar

Daily scanning of the entire internet is wasteful. A workable rhythm is: a global query at a low frequency to track the population, a scoped query against owned ranges after any infrastructure change, and an immediate scoped query after the vendor publishes a security update. The vendor channel is the trigger that matters, because a patch announcement is the point at which an unpatched panel becomes interesting.
For VMmanager specifically, ISPsystem stated on 22 October 2026 that additional updates beyond the initial set would follow. Each announcement is a scheduled reason to re-run the scoped query and compare the result with the baseline.

Alert on the signal, not the noise

A global count moving by a few dozen assets is noise. A new panel appearing inside your own ranges is a signal, and so is a panel that reappears after being closed, which usually means a restored snapshot or a configuration management system that re-applied the old state.
The other signal worth tracking is port distribution. If a panel that previously answered only on an administrative port begins answering on 443, something in the deployment changed, and the change may not have been intentional. On 27 October 2026 the global split was 1,592 assets on port 443 against 15 on 8443, which shows how heavily this platform concentrates on the shared port.

Keep the evidence

Store each run with its query, timestamp, count and the specific assets inside owned ranges. When a breach notification arrives, the stored runs answer a question that cannot be answered retroactively: was this panel reachable, and since when. That record also supports the claim that a hardening step took effect, which matters when the same team has to justify the extra firewall rule later.
The record costs almost nothing to keep. Reconstructing it after an incident costs days.

Where the routine stops

Reachability checks cannot verify patch level, audit logging or the configuration of the management plane's own authentication. Those have to come from the platform, either through an API, a configuration export or a documented build number. A monitoring routine that only scans the internet will produce a false sense of coverage, because the panels it cannot see, behind an allowlist or a VPN, are the ones that are properly managed. The scan exists to catch the ones that are not.

References

Top comments (0)