They Didn't Break In. They Logged In: The Two-Hour Management-Plane Review

One console in your stack can reach every machine you manage. This month an attacker demonstrated exactly what that means — without deploying a single piece of malware. Here's the two-hour review that turns that lesson into a signed record.

The intrusion with no malware in it

The most instructive incident reporting of the month describes an attack with no phishing email, no dropper, no encrypted payload. An authentication bypass in a widely deployed remote monitoring and management (RMM) platform gave the attacker administrative access to the management console — and from that point they never needed an exploit again. They used the product's own remote-control feature, the same one technicians use every day, to reach managed endpoints and leave persistence behind. In at least one confirmed case, the session ran under a default support account that ships with the product.

Read that chain again from your tooling's point of view. The endpoint agent saw a legitimate remote-support session. The firewall saw a signed, widely used tunneling utility connecting to a well-known service. The audit log saw a support account supporting. Every control was working correctly. They were answering questions nobody had asked.

Why the management plane is a different asset class

Compromise an endpoint and an attacker owns an endpoint. Compromise the management plane and they own every endpoint it manages — and if you're an MSP, that's not one company, that's your entire book, through one console that lives on the internet because it has to.

A workstation is a room. Your RMM is the master key cabinet. That asymmetry is why the console deserves harder questions than any other server you run — questions that outrank every feature comparison on the next renewal call:

1. Does the console share an identity system with your domain? Shared identity means one takeover becomes two.
2. Is MFA enforced on the console itself — not just on the technician's email account?
3. Can any technician open remote control on any endpoint at any hour, or is that scoped and scheduled?
4. Does the management server have unrestricted outbound access? A server that can tunnel anywhere can beacon anywhere.
5. Is there one session record an administrator of that same server cannot quietly edit? If the intruder is admin on the console, the console's log belongs to them too.

Patched is not fixed

Here's the detail worth tattooing on the inside of the ticket queue: the flaw being actively exploited exists because the patch for an earlier vulnerability was incomplete. The first fix shipped; the underlying path stayed open; a second CVE was issued for the same way in — and the second one is what attackers are using. A population of teams did everything right, applied the update, closed the ticket, and remained exposed.

So verify patches the way you'd verify a restore:

• Check the version on the host itself. The console reporting on itself is a claim; the host is the fact.
• Check every instance, not the one you remember.
• Where the vendor documents the closed path, re-test the path rather than trusting the version string.
• Re-read the advisory a week later. Incomplete fixes are usually discovered after the first patching wave, not before.

Then write it down: version confirmed, instances checked, date, who, what test. "We're patched" is a mood. That log is an artifact — the same artifact cyber-insurance applications and client security questionnaires keep asking for.

The four tells (context, not tooling)

What actually separates an attacker from a technician when the tool, the account, and the feature are all legitimate? Context. Four kinds of it:

1. HOUR    — a support session at 3 AM on a Sunday
2. SOURCE  — a consumer-VPN exit node, not your office or corporate VPN
3. IDENTITY— a default account name nobody on your team actually uses
4. SHAPE   — connect → enumerate → disconnect
             (reconnaissance looks nothing like support)

None of these are alerts in most shops today. All four are answerable this week, from logs you already collect.

Hunt backwards, then write it down

Because this class of flaw tends to be exploited before it's catalogued, forward-looking controls are half the job. The other half is a 90-day retro-hunt: pull remote-session history and read it against the four tells; look for tunneling utilities registered as services on machines with no business running them; look for executables in user document folders wearing system file names; search for persistence no ticket explains. You're not looking for a hit — you're building the ability to say you looked, and what you found. A clean hunt, dated and signed, is still a deliverable.

The whole thing, packaged free

The Management Plane Kit (Gatorbyte #009) bundles the review: the five-question hardening checklist, the patch verification log template, the four tells as a starting detection list, and the 90-day retro-hunt worksheet — free, in Notion, duplicate and run: thesecuritygator.com.

Two hours. Five questions. One signed page either way it lands. Because a control you can't evidence is a control you're only assuming you have.

---

This is an exercise and review format, not managed security services — and not legal, compliance, or audit advice. Vendor advisories change; verify version guidance against the current advisory before acting. If you find evidence of compromise, follow your incident-response plan.