Backup Trust Plane Shared With Production Domain

The backup infrastructure — console, servers, storage, administrative accounts — authenticates through the same directory as the production environment it protects. A production domain administrator is therefore, de facto, a backup administrator: able to connect to it, reduce retention, delete backup sets.

This is structural: backup is deployed as a service of the environment instead of an independent control plane. Directory integration is the default path for most solutions — unified authentication, simplified management — and the opposite decision is never even articulated. The architectural consequence is that backup shares the fate of what it protects: compromise of production identities is compromise of the backups. The last safety net hangs on the same nail as everything else.

The dominant human-operated ransomware scenario includes destroying backups before encryption — this is a planned step, not collateral damage. With a shared trust plane, an attacker who has obtained directory privileges has nothing to “compromise” on the backup side: they simply connect to it, legitimately as far as the system is concerned.

The observable sequence: deletion of backup sets, snapshots, and scheduled jobs, followed by encryption of production. The question “can we restore?” gets answered at the worst possible moment.

The stakes are binary: this single trust boundary is very often the only thing separating an incident lasting a few days (restore) from a rebuild lasting several weeks — with the payment question, which would not otherwise arise, sitting in between.

The test comes down to one question: with a production domain administrator account (or an account able to reset such an account’s password), can you open the backup console and delete a backup set? If yes, the pattern is present, regardless of how good the solution is.

Additional checks:

• is the backup server joined to the production domain?
• are the backup service accounts drawn from that same directory?
• does the backup storage expose a protocol allowing write or delete operations from the production network?
• who can reduce retention, and can this be done unilaterally, without a second approval?
• do backup administrators use their regular workstation to administer it?

Each “yes” widens the path between production privileges and backup destruction.

Separate the trust plane, not just the network:

• backup administration accounts kept outside the production directory: dedicated local accounts or a separate directory, with its own MFA;
• backup server not joined to the production domain;
• segmentation: the console is not reachable from workstations; the storage exposes only the backup write stream to production, not an administrative interface;
• delayed deletion or dual approval where the solution supports it: a deletion requested today only takes effect after several days;
• complement with an immutable copy (see MFL-010): separating the trust plane reduces the likelihood of destruction, immutability bounds its impact. Both are warranted together; either one without the other leaves a scenario open.

If production identities are compromised, treat the backup infrastructure as compromised until proven otherwise — it is the same trust plane.

In order:

• cut off destruction paths: isolate the storage administration interface, suspend exposed accounts, trigger a storage-array-side snapshot if available;
• export a copy of the backups’ current state to a location out of reach before any other action — even if partial, even if slow;
• audit what the attacker may already have done: retention reductions, recent deletions, job modifications — silent corruption over the preceding weeks is a documented scenario;
• verify the integrity and date of the remaining sets before committing to a restoration plan;
• restore to a clean environment, with rebuilt identities — not back into the suspect domain that allowed access to the backups in the first place.