Ransomware Recovery Must Start With Email, Identity and OAuth

A ransomware recovery is not safe simply because servers are rebuilt and files are back. If an attacker still holds a mailbox session, refresh token, OAuth grant or forwarding rule, they may still have a route into the organisation. The first recovery task is therefore to regain clean administration, preserve evidence and contain identity-based access before restoring mail, files and wider business services.

Email and identity are no longer services to switch back on after the storage work. They are the operating fabric of recovery. Password resets arrive by email. Suppliers trust it. Finance teams approve through it. Staff coordinate through it. A stolen password is serious; a stolen session cookie, refresh token or consented application can survive the familiar password-reset reflex and leave a seemingly recovered environment exposed.

The harder question is not merely, “Can we restore the data?” It is: can we regain clean administrative control, remove persistence, restore trustworthy communications and show that returned access is legitimate? Backups remain essential, but they do not revoke an application’s authority to read a mailbox.

Why email, sessions and OAuth grants sit at the centre of recovery

Email is an organisation’s trust channel. A compromised mailbox can expose reset links, impersonate executives, create forwarding rules, alter contacts and hide activity by moving messages into obscure folders. The problem is not just what sits in the mailbox; it is what the mailbox allows an attacker to do next.

Microsoft’s current compromised-mailbox guidance calls out suspicious inbox rules, external forwarding, missing mail and unusual signatures as signs of compromise. Its remediation sequence includes revoking active sessions, reviewing registered multifactor authentication (MFA) methods, checking application consent and removing inappropriate administrative roles. Microsoft’s compromised email account response guidance is most useful as an operational checklist, not as proof that a password change completes the job. (learn.microsoft.com)

OAuth is the delegated-authorisation mechanism behind many “Sign in with Microsoft” and “Sign in with Google” connections. It lets an application act on a user’s behalf without handling that user’s password. That is sensible engineering. It also creates a separate route into mail, files and calendars when a connected application is malicious, compromised or simply over-privileged.

During an incident, token labels matter less than their behaviour. A refresh token can obtain further access tokens. A browser session may be controlled by the application rather than the identity provider. A tenant-wide application permission can outlive the individual user who originally consented to it. In Microsoft Entra, the identity service cannot directly revoke a session token issued by an application. It can stop new token issuance and revoke refresh tokens, but app-side sessions need app-side controls or must expire. Microsoft’s emergency access revocation guidance makes that boundary explicit. (learn.microsoft.com)

None of this is an argument against OAuth. It is an argument against treating the OAuth inventory as a procurement spreadsheet updated once a year. In recovery, it belongs in the persistence search.

The good, better and best recovery choices

There is no prize for ordering a full identity rebuild after every phished mailbox. There is also no safety in restoring every account because the CEO needs email back. The appropriate level of recovery depends on what is known, who was compromised and whether the organisation can still trust its administrative plane.

Good: a disciplined account-centred response

For a credible single-account incident, begin by suspending or disabling the user to stop new access. Preserve relevant audit evidence before making broad configuration changes. From a clean administrative session, reset the password, revoke active sessions, remove unfamiliar MFA devices or methods, revoke user-associated application consent where appropriate, and inspect mailbox delegation, forwarding, inbox rules and sent mail.

Google Workspace states that suspending a compromised user resets sign-in cookies and OAuth tokens. It then advises administrators to investigate audit logs, revoke OAuth 2.0 tokens, remove app passwords and inspect Gmail settings such as forwarding and filters before restoring access. Google’s compromised-account checklist gets the sequence right: containment and investigation come before restoration. (support.google.com)

That does not mean Google automatically removes every token risk, or that Microsoft does not offer equivalent controls. The products expose different controls and connected applications behave differently. The practical rule remains the same: identify every relevant access path and record which action invalidates it.

Better: treat the tenant as potentially altered

Once privileged accounts, shared mailboxes, finance users or broad phishing activity are involved, recovery is no longer about one user. Review changes from before the suspected initial access through to containment across the cloud tenant: administrator roles, authentication registrations, conditional-access policies, federation and single sign-on settings, mail transport rules, external forwarding, new enterprise applications, application credentials and consent events.

This is where OAuth recovery becomes forensic work rather than account hygiene. An attacker with an administrator account can consent to a legitimate-looking application, grant it broad access or create credentials for an application identity. Microsoft documents both consent phishing and attacker-created application persistence as response scenarios. Its guidance recommends reviewing application ownership, consent settings, permissions and audit events. A compromised user account may be the initial mechanism, not the persistence mechanism. Microsoft’s compromised and malicious applications investigation playbook sets out that wider review. (learn.microsoft.com)

For Microsoft 365, review both delegated and application permissions. Delegated permission lets an app act in a user’s context; application permission can let it act without a signed-in user, raising the stakes for services such as Exchange Online and SharePoint. Permissions can be reviewed and revoked from Enterprise Applications or through Microsoft Graph, but removal still requires a decision: should the application be disabled, removed, reconfigured or placed behind tighter assignment and consent controls? Microsoft’s application permission review guidance covers those mechanics. (learn.microsoft.com)

For Google Workspace, restrict third-party app access rather than relying on users to make perfect judgements from consent screens. Google lets administrators control app access by service and use a restricted model for untrusted applications; moving a service to restricted can stop previously installed untrusted apps and revoke their tokens. That can also break legitimate document management, customer relationship management (CRM), mail archiving and automation tools at exactly the wrong moment. Maintain an approved-app register before an incident. Google Workspace app access controls explains the options and their effect on existing tokens. (support.google.com)

Best: recover identity from a position you can still trust

The strongest approach is not primarily about buying another security product. It is about removing dependencies from the first hour of recovery. If the normal administrator account relies on the same mailbox, phone, federated identity provider, endpoint fleet and mobile authenticator ecosystem that may have been compromised, it is not an emergency account. It is a spare account with the same failure modes.

Microsoft recommends at least two cloud-only emergency access accounts, permanently assigned the Global Administrator role, kept separate from normal users and federated identity dependencies. It recommends phishing-resistant authentication such as FIDO2 passkeys or certificate-based authentication, stored separately, alerting on every use and regular validation. These accounts need careful governance because they are exceptionally powerful. The alternative is discovering, in the middle of an incident, that every route to administration depends on the incident. Microsoft’s emergency access account guidance sets out those recommendations. (learn.microsoft.com)

The same principle applies to Google Workspace and other SaaS providers, even where the exact break-glass pattern differs. Maintain more than one appropriately protected super-admin route, document domain-ownership and provider-support recovery procedures, and ensure the people authorised to use those routes do not depend on a compromised corporate mailbox. Google notes that self-service recovery may not apply where an organisation uses third-party single sign-on or Password Sync. An identity-provider outage or compromise belongs in the plan, not in the post-incident review. Google Workspace account recovery guidance explains that limitation. (support.google.com)

Recover email as a service, not merely a data set

Mailbox recovery has two jobs. The first is data integrity: restore deleted or altered messages, folders, mailbox permissions and, where required, retention or archive content. The second is communications integrity: establish that users can send and receive without an attacker silently forwarding mail, impersonating them, using delegated access or exploiting a connected app.

Opening Outlook or Gmail and seeing old mail is not recovery validation. Test inbound and outbound delivery from a clean external account; inspect forwarding and transport rules; check delegate access and shared-mailbox permissions; verify signatures and auto-replies; review recently created contacts; and confirm that recovery addresses and authentication methods are legitimate. For finance and senior management, validate payment-change processes separately. Email is often the route by which technical access becomes financial loss.

If an archive, backup or SaaS-protection platform can rapidly restore a mailbox, use it where the evidence supports it. Do not let a speedy data restore force a premature sign-in. A backup is not yet a disaster-recovery strategy because recoverability includes clean access, workable processes and trustworthy control planes — not merely retained copies of data.

Immutable backup design still matters here, particularly for directory exports, mail backups and recovery documentation. It is supporting infrastructure, not an identity clean-up mechanism. The choice between a dedicated hardened repository and a software appliance affects the trustworthiness and operability of retained recovery data; it does not tell you whether an OAuth grant is still live. Dedicated hardened repositories and the Veeam Software Appliance address a different control problem.

Build a runbook that distinguishes revoke, rebuild, restore and verify

The most useful ransomware recovery plan for email and OAuth resilience is a short runbook with named owners, access prerequisites and evidence outputs. It should not be a 70-page policy that nobody can execute at 02:00.

1. Declare the identity scope. Identify affected users, privileged users, mailboxes, endpoints, applications, service accounts and SaaS services. Record the working theory and its confidence level; do not present a partial investigation as certainty.
2. Use clean administration. Start from a known-good workstation and emergency account. Preserve logs and configuration exports before making destructive changes where that is safe to do.
3. Contain access. Disable or suspend suspected users, revoke sessions and refresh tokens, remove suspect authentication methods, rotate exposed secrets and disable suspect applications. Record the expected revocation delay for each service.
4. Find persistence. Review OAuth grants, enterprise apps, service principals, app registrations, credentials, privileged roles, forwarding rules, delegates, transport rules and federation changes. Include app-native sessions that the identity provider cannot directly terminate.
5. Restore in waves. Bring back a small group first, beginning with recovery and communications staff. Re-enable integrations only after checking their publisher, requested scope, credentials, owners and operational need.
6. Verify clean operation. Test real mail flow, access control, application behaviour and audit visibility. Search for renewed suspicious sign-ins, new consent events, forwarding changes and token-related alerts after users return.

For other SaaS platforms, obtain the same answers from every supplier: can an administrator revoke user sessions; can the product revoke application programming interface (API) tokens and connected-app grants; are service accounts and API keys separately discoverable; how long can app-issued sessions survive; and what audit trail remains if the primary identity provider is compromised? “We support SSO” answers none of those questions.

Test recovery time, clean access and data integrity separately

Most recovery exercises are too forgiving. They prove that IT can sign into an admin portal on a normal weekday using normal accounts. That tests convenience, not resilience.

A worthwhile exercise removes one ordinary dependency at a time. Assume the primary global administrator is unavailable. Assume the administrator’s authenticator device is unavailable. Assume the main identity provider is unreachable. Assume a user has consented to a hostile mail-reading app. Assume a shared mailbox has an external forwarding rule. Then measure not only how quickly the team restores access, but whether it can show that the old access is gone.

Google Workspace customers with the relevant editions can use the security investigation tool to examine user, administrator, Gmail, device and OAuth activity. Microsoft customers should ensure the audit and sign-in data needed for an investigation is retained and available to the responders who will actually use it. Logging that is disabled, too short-lived, inaccessible during an incident or never reviewed is not a recovery asset. Google’s list of Security Investigation Tool data sources shows the range of evidence that may be available, subject to edition and privileges. (support.google.com)

The sensible default: staged recovery, not theatrical rebuilds

There is a temptation to turn every identity incident into a grand “zero trust” rebuild. That is no more useful than treating every token alert as a password-reset ticket. The disciplined middle ground is staged recovery: assume more risk where evidence points to privilege, mail access or application persistence; restrict the blast radius; and return services according to verified controls rather than executive impatience.

Ransomware is still about availability, extortion and data theft. Recovery now succeeds or fails on identity decisions made before the encryption event and in the uncomfortable hours afterwards. If attackers can still authenticate, read email or act through an OAuth-connected application, the estate has not been recovered. It has only been restarted.