KavachIQ/Recovery scenarios/Compromised Global Admin
Illustrative recovery scenario

Recovery scenario: compromised Global Admin in Microsoft 365.

See how identity-first recovery helps a Microsoft 365 team restore Entra controls, contain blast radius, recover critical users, and verify business recovery after a privileged identity compromise.

This page describes an illustrative scenario. It is not a customer testimonial and does not contain fabricated metrics. It is intended to help Microsoft 365 teams, IT and security leaders, and procurement reviewers understand KavachIQ in the context of a realistic privileged identity compromise.

SECTION 1 · INCIDENT SETUP

What the incident looks like in Microsoft 365

A privileged identity is compromised. The attacker works inside Microsoft Entra and Microsoft 365 to establish persistence, expand access, and weaken the controls that would normally catch them.

Privileged identity access

Attacker phishes a privileged session or abuses a valid token. MFA is weakened or bypassed.

Global Admin abuse

Global Admin is assigned to a new account or an existing account is elevated.

Conditional access modified

CA policies and sign-in frequency requirements are loosened. Break-glass paths expanded.

OAuth grants and service principals

New app consents or service principals added. Scoped permissions quietly expand.

Group and role membership

Security groups, role-assignable groups, and admin units shift. Blast radius grows.

Data access expands

Mailbox delegation, SharePoint site access, OneDrive sharing, and Teams membership start drifting.

SECTION 2 · WHY MANUAL RECOVERY IS HARD

Where teams run into trouble

Most Microsoft 365 teams can eventually recover from this scenario. What makes it painful is the first few hours.

01

Blast radius is unclear. Who is actually affected, which policies changed, and what is safe to touch first is hard to answer in real time.

02

Policy drift is invisible. Conditional access and role changes over the last 24 hours are not trivially queryable across Entra.

03

Restore order is unclear. Teams pull mailboxes and files back first because that is what leadership asks for, but the attacker still holds admin rights.

04

Identity stays compromised while data is restored. The attacker re-encrypts, re-exfiltrates, or simply waits until attention drops.

05

Triage is slow. Cross-referencing Entra audit logs, M365 audit logs, and third-party alerts takes hours or days.

SECTION 3 · HOW KAVACHIQ HANDLES RECOVERY

Six phases, applied to this incident

KavachIQ runs the same six-phase workflow on every recovery. Applied to a compromised Global Admin, this is what each phase does.

PHASE 01Protect

Baseline identity and workload state is already captured.

  • 12 Entra ID object types snapshotted: users, groups, role assignments, conditional access policies, OAuth grants, service principals, and administrative units.
  • Exchange, OneDrive, SharePoint, and Teams protected on a schedule. Snapshots are WORM-locked for the SLA retention window.
  • Per-tenant keys and audit trail are in place before any incident begins.
PHASE 02Monitor

Baselines track normal tenant behavior.

  • Change rate across identity objects and workload data is baselined per tenant.
  • Privileged role counts, conditional access policy counts, and MFA enforcement levels are tracked over time.
  • Unusual service-principal or OAuth-grant activity feeds into the anomaly model.
PHASE 03Detect

Destructive change and identity drift are flagged with evidence.

  • Global Admin count jumps. MFA enforcement drops on privileged users. Conditional access policies are modified or disabled.
  • Mass rename or mass-deletion patterns across OneDrive and SharePoint are flagged.
  • Alerts reference the specific object type, the affected users, and the time window, not just a generic anomaly score.
PHASE 04Assess

Blast radius is computed across identity and data.

  • Diff the current Entra state against the last known-good snapshot. See exactly which policies, roles, OAuth grants, and group memberships changed.
  • Map identity changes to the users, mailboxes, and sites they affect.
  • Score affected users by business criticality. Surface a recommended recovery order before action is taken.
PHASE 05Recover

Guided, identity-first restore in the safest business order.

  • Phase A: Revert privileged role assignments. Remove attacker-added Global Admins and service principals.
  • Phase B: Restore conditional access, MFA enforcement, and OAuth grants to the last known-good state.
  • Phase C: Recover critical users first, then high-priority departments, then full business data.
  • Every restore action is logged and attributable. Broken changes can be rolled forward or reverted per object.
PHASE 06Verify

Business recovery is confirmed with evidence.

  • Checksums confirm data restore integrity. Policy-active checks confirm conditional access is enforcing again.
  • Sign-in tests verify privileged and critical users can authenticate cleanly.
  • A recovery report bundles the timeline, the actions taken, the evidence, and the snapshots used.
SECTION 4 · IDENTITY-FIRST RECOVERY ORDER

Why identity comes first, and in what order

Restoring mailboxes and files before restoring identity controls is not safe. The attacker still holds Global Admin or residual privileged access.

  1. 01

    Entra controls first

    Privileged role assignments, conditional access policies, MFA enforcement, OAuth grants, service principals, administrative units, and security groups are reverted to the last known-good snapshot.

  2. 02

    Critical users next

    Executives, privileged-role holders, compliance and security owners, and finance leads are restored and verified first.

  3. 03

    High-priority departments and sites

    Directors, senior engineering, shared SharePoint sites, and legal repositories are recovered in the order their business criticality suggests.

  4. 04

    Full business data, verified end-to-end

    Remaining mailboxes, sites, Teams, and OneDrive content are restored. Checksums and sign-in tests confirm the tenant is actually back online.

SECTION 5 · OPERATIONAL OUTCOMES

What changes for the team

KavachIQ does not eliminate incidents. It changes how a Microsoft 365 team runs the recovery and how defensibly they can sign off on being back online.

Faster recovery coordination

Teams start from a computed blast radius and a pre-computed recovery plan instead of improvising under pressure.

Safer restore order

Identity controls come back before data. Attackers lose their foothold before the tenant is fully restored.

Clearer blast radius understanding

Identity and data diff-against-baseline make the actual scope of the incident visible, not assumed.

Stronger recovery confidence

Recovery is scored with evidence. Leadership and security can sign off on "we are back" with a defensible artifact.

Better evidence for review

A timestamped log of detected changes, decisions, and restores supports security, legal, and procurement review after the fact.

Talk through your Microsoft 365 recovery scenario

Walk the compromised Global Admin scenario, or your specific incident, with a KavachIQ recovery engineer. Bring the Entra, policy, and workload questions that matter for your tenant.

© 2026 KavachIQ. All rights reserved.