How to Detect Mailbox Folder Permission Persistence After an Exchange OWA Compromise

OWA compromise runbooks usually look the same: reset the password, revoke active sessions, rebuild the device. These steps are correct as far as they go. But they stop at the endpoint. They do not reach the mail server itself.

CVE-2026-42897 (OWAReaper) gave this gap a name. The proof-of-concept exploit grants the Default user Owner permission on every mailbox folder during compromise. After it runs, any authenticated account in the organization can open that mailbox and read its contents. Rotate the password: no change. Re-image the laptop: no change. Apply the patch after exploitation: no change, because the permission grant is already sitting on the server.

This is server-side persistence. And most runbooks do not check for it.

The Permission That Survives Everything

When the OWAReaper implant runs, it executes a single operation against the compromised mailbox: it grants the Default user Owner permission on all folders. In Exchange, the Default security principal represents any authenticated user in the organization. Owner is the highest folder-level permission in Exchange's ACL model. It grants full read, write, and delete access to every folder in the mailbox, including the contents of sent items, calendar entries, and deleted items.

Standard incident response does not touch this. Password resets do not remove folder permissions. Device re-imaging does not reach server-side ACLs. Even Revoke-OWAMailboxPolicy, which terminates active OWA sessions, does not modify folder permissions. The grant persists until someone removes it explicitly.

The practical implication is blunt: if an attacker used OWAReaper against your organization, every mailbox the implant touched is readable by every authenticated user in the domain. That is the post-exploitation state you are operating in while your runbook says the incident is closed.

How to Detect the Permission Grant

The detection is direct and uses cmdlets that already exist in Exchange Server and Exchange Online.

Exchange Server

Run this against a single mailbox to check the Default user's folder permissions:

Get-MailboxFolderPermission -Identity "jsmith@contoso.com:\Calendar" | Where-Object {
    $_.User.ToString() -eq "Default" -and $_.AccessRights -contains "Owner"
}

To scan all folders in a single mailbox:

$mailbox = "jsmith@contoso.com"
$folderScope = (Get-MailboxFolderStatistics -Identity $mailbox).FolderPath
foreach ($folder in $folderScope) {
    $target = "$mailbox`:$folder"
    Get-MailboxFolderPermission -Identity $target | Where-Object {
        $_.User.ToString() -eq "Default" -and $_.AccessRights -like "*Owner*"
    }
}

Exchange Online

For Exchange Online or hybrid deployments:

Get-EXOMailboxFolderPermission -Identity "jsmith@contoso.com:\Calendar" -User "Default"

To check across multiple mailboxes using a script:

$mailboxes = Get-Mailbox -ResultSize Unlimited
foreach ($mbx in $mailboxes) {
    $perms = Get-EXOMailboxFolderPermission -Identity "$($mbx.UserPrincipalName):\Calendar" -User "Default" -ErrorAction SilentlyContinue
    if ($perms.AccessRights -like "*Owner*") {
        Write-Output "$($mbx.UserPrincipalName): Default has Owner on Calendar"
    }
}

The flag is the same in both environments: Default or Anonymous with any permission above Reviewer. In practice, an Owner grant on any folder is worth treating as a finding. Owner on the entire mailbox root or on Calendar and Inbox specifically is high severity.

Hunting Across All Mailboxes

If you suspect a broad compromise, you need to scan every mailbox in the organization. The approach is the same in both Exchange Server and Exchange Online: enumerate all mailboxes, check each one for anomalous Default permissions, and prioritize those with Owner grants.

A practical hunting script for Exchange Online:

$mailboxes = Get-EXOMailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq 'UserMailbox'}
$findings = @()
foreach ($mbx in $mailboxes) {
    try {
        $allPerms = Get-EXOMailboxFolderPermission -Identity "$($mbx.UserPrincipalName):\`*" -ErrorAction SilentlyContinue | Where-Object {
            ($_.User -eq "Default" -or $_.User -eq "Anonymous") -and $_.AccessRights -like "*Owner*"
        }
        if ($allPerms) {
            foreach ($perm in $allPerms) {
                $findings += [PSCustomObject]@{
                    Mailbox    = $mbx.UserPrincipalName
                    Folder     = $perm.FolderName
                    User       = $perm.User
                    Rights     = $perm.AccessRights -join ', '
                }
            }
        }
    } catch {
        Write-Warning "Could not check $($mbx.UserPrincipalName)"
    }
}
$findings | Format-Table -AutoSize

Save the output to a variable or CSV. Every row is a finding.

The prioritization logic is simple: Owner grants come first. Reviewer or Editor grants on sensitive folders (Calendar, Inbox, Sent Items) come second. Anything assigned to Anonymous gets flagged regardless of level, because Anonymous access should almost never appear on internal mailboxes.

What Actually Removes the Persistence

Remediation requires explicitly removing the permission grant. Nothing in the standard reset process does this.

To remove the Default permission grant from a specific folder in Exchange Server:

Remove-MailboxFolderPermission -Identity "jsmith@contoso.com:\Calendar" -User "Default" -Confirm:$true

For Exchange Online:

Remove-EXOMailboxFolderPermission -Identity "jsmith@contoso.com:\Calendar" -User "Default" -Confirm:$true

You need to run this for every affected folder. You can script it to target all folders at once, but be careful with the scope: removing Default permissions from folders that legitimately depend on it (shared calendar resources, for example) will break access for users who legitimately need it.

After removing the permission grant, also revoke active OWA sessions to prevent the attacker from re-establishing persistence:

Revoke-OWAMailboxPolicy -Identity "jsmith@contoso.com"

Or in Exchange Online:

Get-OWAMailbox -Identity "jsmith@contoso.com" | Revoke-OWAMailboxToken

Then force a re-authentication for the affected user. This step is where most runbooks stop. It is not where the response ends.

Adding Folder Permission Auditing to Your Runbook

The gap this attack exposes is structural: most incident response runbooks never check folder permissions on the mail server. Closing it requires adding a specific step to post-OWA-exploitation procedures.

The minimal addition is a post-incident check: any time OWA exploitation is confirmed or strongly suspected, enumerate Default folder permissions across all mailboxes before declaring the incident closed. The OWAReaper implant affects the mail server, not the endpoint. Your investigation is not complete until you have checked the server.

For ongoing security posture, baseline your folder permissions quarterly. Export the current state, store it, and compare new exports against the baseline. Flag any new Default grants, any elevation of existing grants, and any Anonymous grants on internal mailboxes.

The alerting signal is straightforward: Default or Anonymous receiving any folder permission above Reviewer should generate a security event. Owner or Editor grants should generate a high-severity alert.

Where DMARC Monitoring Fits (and Where It Does Not)

Be direct about the limits of this detection approach: DMARC aggregate reports will not flag this attack directly. The authentication passes legitimately. The attacker is using valid credentials. There is nothing in the DMARC report that looks like an attack.

What DMARC reports do provide is context. If you see unexpected senders appearing in your aggregate reports, unusual third-party activity against your sending domains, or volume anomalies on subdomains you do not recognize, those signals can prompt the kind of deeper investigation that finds permission anomalies. DMARC reports tell you what is sending under your domain. They are a useful early warning system, not a direct detection tool for mailbox-level persistence.

The practical value of DMARC reports here is narrower than in pure spoofing detection. When authentication passes legitimately, DMARC has nothing to flag. But unexpected sending patterns in your aggregate reports, whether that means a subdomain you did not expect to see sending mail or volume spikes from sources you cannot identify, are exactly the kind of anomalies that prompt deeper investigation. A team that routinely reviews DMARC reports is more likely to notice when something looks off across the broader email environment, including mailbox permission anomalies that DMARC cannot see directly.

Use both signals. Check the folder permissions. Read the DMARC reports. The OWAReaper gap is that most teams do one without the other.

FAQ

What accounts should I check for anomalous permissions?
Default and Anonymous. Default represents any authenticated user in the organization. Anonymous represents unauthenticated external senders. Both should almost never appear in folder permission grants on internal mailboxes. Any presence above Reviewer is worth treating as a finding.

How often should I check folder permissions?
At minimum, check after any confirmed or suspected OWA exploitation. For ongoing security posture, quarterly baselining with monthly alerts on new grants is a practical starting point.

What does "Owner" permission actually allow?
Owner is the highest folder-level permission in Exchange. It grants full read, write, and delete access to that folder and all subfolders. It does not grant access to other folders in the mailbox unless those subfolders are explicitly included.

Can legitimate folder sharing create false positives?
Yes. If your organization uses folder sharing with the Default principal for legitimate collaboration, your baseline will need to account for that. Review any Default grants flagged in a baseline against known legitimate sharing practices before escalating.

Does patching Exchange remove existing permission grants?
No. Patching fixes the vulnerability. It does not remove grants that already exist on the server. You must remove those explicitly.

Is this specific to OWAReaper or does it apply to other Exchange compromises?
The OWAReaper implant uses this technique specifically, but the underlying issue is general: any compromise that grants server-side folder permissions will survive password resets and device re-imaging. The detection and remediation steps apply broadly to any mailbox-level permission persistence.