DEV Community: Gary Austin

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

Gary Austin — Wed, 19 Aug 2026 14:07:00 +0000

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:

Does the console share an identity system with your domain? Shared identity means one takeover becomes two.
Is MFA enforced on the console itself — not just on the technician's email account?
Can any technician open remote control on any endpoint at any hour, or is that scoped and scheduled?
Does the management server have unrestricted outbound access? A server that can tunnel anywhere can beacon anywhere.
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.

Your Backups Are a Hypothesis: The 45-Minute Restore Test

Gary Austin — Sun, 16 Aug 2026 09:15:00 +0000

The green checkmark problem

Every MSP dashboard has one: the backup column, green for months. Green feels like safety. But a green job proves exactly one thing — the job ran. It does not prove the data comes back, how long that takes, whether the increment you'll need survived the retention policy, or whether anyone alive can find the decryption key at 2 AM.

Two weeks ago this series argued that an incident response plan that's never been exercised is a hypothesis. Backups are the same species of hypothesis, with quieter failure modes:

Rotated credentials. The backup service account changed; jobs kept "succeeding" against a subset of targets.
Corrupt increments. The chain is only as good as its weakest link, and nothing verifies links like a restore.
Retention surprises. The copy you need is from 9 days ago; retention keeps 7.
Key-inside-the-vault. The decryption key or console password is documented… inside a system that's now encrypted.
Scope drift. The new file share, the new VM, the migrated mailbox — added to production, never added to the job.

Every one of these is invisible on a green dashboard, and every one of them is found in one of two moments: a scheduled drill on a Tuesday afternoon, or the worst hour of your year.

The drill

THE 45-MINUTE RESTORE TEST  (roles: an operator + a scribe. That's the team.)

0:00  Pick the target BEFORE you feel ready: one production system that
      would hurt Monday morning — file server, finance share, the PSA/RMM
      database. Not the easy one. The one that matters.

0:05  Restore last night's copy to an ISOLATED target: a spare VM, an empty
      VLAN, a cloud sandbox. NEVER over production. No internet egress
      required — isolation is the point.

0:35  Verify like a USER, not an admin: open three files, run one report,
      log in with a real non-admin account. "It boots" is not "it works."

0:40  Write four numbers: minutes to restore · GB restored · items verified
      · today's date. The scribe signs the page.

That signed page is the deliverable. Everything else — the war stories, the "huh, interesting" moments, the ticket you'll open about the service account — is bonus.

The one rule

Borrowed from the tabletop drill and repointed: every claim gets a number and a date.

"Restores work fine" is a mood. "47 minutes, 212 GB, three files opened and readable, August 11, signed by the scribe" is evidence — the kind cyber-insurance applications and enterprise security questionnaires are explicitly asking for when they say tested recovery and documented RTO. You're not doing extra work to satisfy the questionnaire; the drill's natural output is the answer.

The math you can finally do

Recovery time estimates usually divide a known number by a guess:

Real downtime ≈ (data that must come back) ÷ (restore throughput)

Every team knows the first number. Almost nobody has measured the second — and the difference between an assumed and a measured throughput is the difference between promising "a few hours" and delivering a long weekend. After one timed drill, your RTO conversations use a measurement. Guessing is over.

The trap: your backups are the first target

Ransomware crews have told reporters for years that backup infrastructure is their first stop — delete or encrypt the recovery path, then detonate. Recent KEV traffic makes the architectural point for them: Veeam's advisory for CVE-2026-44963 describes a critical RCE on domain-joined backup servers, reachable by any authenticated domain user. One stolen domain account, and the vault is another room on the sinking ship.

So alongside the restore drill, three architecture questions worth an hour:

Credential separation. Does the backup console share credentials (or auth domain) with production? It shouldn't.
An undeletable copy. Does at least one copy live where a domain admin cannot delete it — immutable object storage or genuinely offline?
Console-loss drill. If the console died tonight, who could still reach a copy, and by what path?

The commonly used rule of thumb is 3-2-1-1-0: three copies, two media, one offsite, one offline or immutable, zero errors on verification. The last digit is the one everyone skips — and it's the only one that involves actually restoring. Treat it as a starting point to adapt, not a certification to claim.

When the test fails

A restore test that fails is a successful test — it located a real gap for the price of 45 minutes. Run the tabletop rule on it: the gap gets an owner and a date, and the failed log page stays in the file next to the eventual passing one. The paper trail from red to green is itself evidence of a functioning program. The only failed test is the one never run.

Make it a rhythm

One drill is a data point; a rhythm is a program. Rotate targets quarterly — file server this quarter, the PSA database next, a full VM the one after. Fifteen minutes of scheduling covers a year: four calendar invites, each with an operator, a scribe, and a target named in advance. Booked beats intended.

Local-first GRC: why I'm building a compliance workbench that doesn't phone home

Gary Austin — Tue, 28 Jul 2026 09:27:58 +0000

I'm Gary — The Security Gator. I build a GRC command deck for vCISOs, MSPs, and consultants who are tired of renting access to their own compliance data.

The premise is simple: most compliance platforms are SaaS. Your control assessments, your risk scores, your client evidence — all of it lives on someone else's servers, behind a subscription that never ends. Stop paying, lose access.

The bet: own it, don't rent it

AxiomLens is a NIST CSF 2.0 workbench that runs entirely on your machine — SQLite under the hood, a local GUI on top, one-time license. After activation it's strictly offline.

	CaaS / SaaS	AxiomLens
Your data lives	On their servers	In a SQLite file you own
Access model	Log in to their cloud, every session	Activate once, then fully offline
Cost shape	Subscription, forever	One-time license
When you stop paying	Locked out	Nothing happens — it's yours

$ axiomlens status --json
{
  "controls_total": 106,
  "in_scope": 100,
  "coverage": "computed locally"
}

Coverage math, scored risk, board-ready reports, client hand-off docs — computed on your machine, owned outright. It supports compliance documentation and audit preparation; it's not a substitute for legal, compliance, or audit advice — and I'm careful to never claim otherwise. That honesty is part of the pitch.

What I'll write about here

The build, in public: SQLite schema decisions for framework crosswalks, packaging Python into a single exe with Nuitka, deterministic report generation instead of LLM roulette, and the general weirdness of shipping desktop software in a SaaS world.

The free stuff — field guides, a governance tool, starter kits — lives on the Gatorbyte Free Shelf.

Everything else: thesecuritygator.com · Bayou Bytes newsletter