The Server Was Fixed. Persistent Access Wasn’t.

Persistent access is one of the few compromise patterns that can survive a fully executed recovery. In August, researchers disclosed that attackers exploiting Microsoft Exchange Server had deployed a browser-based implant — internally documented as OWAReaper — that modified mailbox permissions in a way that outlasted both credential rotation and complete server rebuilds. The recovery actions worked exactly as designed. They simply never touched the layer where persistence actually lived.

That third row is the entire argument. Not “untouched” as in overlooked by a rushed team. Untouched as in structurally outside the scope of what the first two actions were ever capable of reaching — the same pattern The Architecture of Premature Closure names at the general level: a closure signal firing on execution, not on the verified state it was meant to represent. Persistent access is simply what that gap looks like when the unverified state in question is who still has a way in.

What Recovery Assumed Was Enough

The standard sequence after an incident like this one looks complete on paper — and it is worth being explicit up front that this is a data protection architecture failure, not an incident-response one, before walking through why:

Every item in that sequence executed correctly. That’s what makes this pattern dangerous instead of merely sloppy — there’s no failed step to point to afterward, no missed patch, no skipped rebuild. The sequence closes the incident from the perspective of every system it was designed to check. It just wasn’t designed to check the one system that mattered. This is the same authority-side question Incident Recovery Process raises about declaring an incident closed at all: recovery completing is not the same claim as the incident being over, and treating them as interchangeable is exactly what happened here.

Where Persistent Access Actually Lived

This is the section that matters, and it’s not about Exchange Server specifically — it’s about what “recovery” was scoped to versus what the compromise actually touched.

The implant granted the built-in “Default” identity owner-level access to affected mailboxes — a permission change written into Exchange’s own mailbox store, not into the operating system, not into an identity provider, not anywhere a credential reset or a disk re-image would ever look. Rotating a password changes what proves you’re allowed in. Re-imaging a host replaces everything the host was running. Neither action reads or resets a mailbox ACL, because neither action was built to. That’s not a bug in the remediation. It’s the remediation working exactly as scoped — against a scope that didn’t include where persistent access was actually stored.

This is worth sitting with, because the instinct is to look for what recovery did wrong. Nothing was done wrong. Credential rotation is not the failure here. Server rebuild is not the failure here. The failure is the assumption baked into declaring the incident closed once those two actions completed — the assumption that the systems recovery knows how to check are the same systems the attacker knew how to use. Those two sets overlap, but they aren’t identical, and the gap between them is exactly where persistent access sits once the “fixed” systems stop being watched.

Put differently: recovery validated that the front door was rekeyed and the house was rebuilt. Nobody checked whether the attacker had also been quietly added as a co-owner of the mailroom. The mailroom wasn’t part of the house inspection. It was never going to be found by re-inspecting the house.

That co-owner status is what makes this specific persistence mechanism worth taking seriously rather than filing as a footnote. Owner-level mailbox access lets the attacker read every message in the box, send as the compromised identity with no forwarding rule or delegation flag to trip a review, and keep that access indefinitely — because none of it depends on the credential that got rotated or the login pattern a detection rule might flag.

This is the same gap The Authorization Was Legitimate. Nobody Watched What Happened Next. names from the access-grant side rather than the recovery side: a Qantas contact-center agent’s authorization was genuinely legitimate, and the monitoring in place correctly checked identity and login pattern — it just never treated the session’s ongoing behavior as something worth watching once the grant existed. Here, the equivalent gap sits one step later in the incident lifecycle: recovery correctly checked host and credential state, and never treated the mailbox-permission layer as something worth watching once remediation was declared complete.

There’s no anomalous sign-in to catch, because the attacker was never using a sign-in. The access rides on a permission grant that predates the “compromised” account entering a suspicious-activity report. Persistent access of this kind doesn’t look like an ongoing breach from the tools recovery is watching. It looks like nothing, because the layer it lives in was never instrumented to look like anything at all.

Recovery Follows Ownership Boundaries

Here’s the generalizable version of the pattern, stripped of the Exchange specifics — because this incident is one example of persistent access, not the definition of it:

The left column is what operations teams remediate, because those are the systems they own and instrument. The right column is where sophisticated persistence increasingly lives, precisely because those layers usually sit outside standard recovery scope — owned by an application team, a platform team, or nobody in particular. Persistent access exploits exactly that ownership gap, not a technical one.

Identity Directories Have Become An Unmonitored Intelligence Source names the identical asymmetry from the opposite side of the identity plane: security programs govern writes tightly and treat reads as safe by default, so a valid session pulling an entire tenant directory in one call trips nothing, because nobody ever defined bulk reads as a category worth watching. Same shape here — mailbox-permission state sits in the same kind of blind spot reads do: not hidden, just never classified as something the existing controls were built to notice.

An attacker with any operational patience will prefer the right column every time. It’s not stealthier because it’s cleverer. It’s stealthier because it’s structurally outside the boundary recovery teams have been trained, tooled, and scoped to check — the exact scoping failure The System Recovered. Your Recovery Boundary Didn’t. documents from the dependency side: the asset comes back, the service doesn’t, because the dependency was never inside the boundary recovery was built to cover.

This is Framework #148 — Recoverability Gap — showing up in its cleanest possible form, and it’s the anchor framework for Ransomware Survival Architecture, the D4 stage of the Data Protection Learning Path. The framework’s definition is the distance between a recovery plan validated under clean-failure scenarios and a recovery architecture that actually survives adversarial compromise across identity, credential, control-plane, and application authority. This incident didn’t fail because the organization’s recovery plan was weak. It failed because the plan was validated against the wrong compromise model — one where the attacker only touches what recovery already knows how to check.

Your Cloud Isn’t Compromised. Your Vendor Is. Now What? names the same gap at vendor scale — Framework #169, Authority Persistence Boundary: a third party’s security boundary fails, and the authority it holds inside your environment keeps working unchanged, because nothing automatically revokes it when the trust behind it stops being valid. Same shape here, no vendor involved: the remediation event happened, and the mailbox-level access kept working unchanged, because nothing in either remediation action was built to check it.

The diagnostic version of this section, worth scanning on its own:

Recovery is incomplete until every layer capable of carrying persistence has been validated.

What to Check Before Declaring Closure

Two lists, deliberately kept separate, both aimed at confirming persistent access is actually gone rather than just quiet. One is specific to this incident class. The other should survive it.

The second list is the one worth keeping on a wall somewhere. The first one will be obsolete the next time the vendor and the vulnerability change.

Additional Resources

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →