The Admin Who Could Do Everything
A 500-user organization has 6 super admins. Investigation after a phishing incident shows one super admin's account was compromised for about 36 hours before anyone noticed. During that window the attacker created a new admin account, granted it super admin, and added an OAuth app that requested broad Gmail and Drive scopes. The security team wants to reduce blast radius, enforce stronger sign-in, and catch this pattern faster - without locking out the IT staff who genuinely need admin rights. Budget is limited; you can't buy every premium add-on.
1. Evaluate the current super admin posture and propose a least-privilege admin model, including how many super admins you'd keep and why.
Read the worked answer
Current posture is the core problem: 6 super admins, each a single point of total compromise. A super admin can create admins, change security settings, and grant OAuth - exactly what the attacker did. The 36-hour dwell time shows there's no detection either.
Least-privilege model:
- Reduce super admins to the minimum - typically 2-3, enough for redundancy without a wide blast radius. These are break-glass/strategic accounts, not daily-use accounts.
- Use delegated/custom admin roles for everyday IT work: a Help Desk role for password resets and user management, a User Management Admin, a Groups Admin, etc. Most IT staff need specific privileges, not super admin. Grant the narrowest predefined or custom role that does the job.
- Separate admin identity from daily identity: admins should use dedicated admin accounts (not their everyday mailbox) so a phished personal session doesn't equal admin compromise.
- Break-glass accounts: the 2-3 super admins should be reserved, with strong controls, for emergencies; routine work uses delegated roles.
Why this matters: the attacker's ability to create a super admin and add a broad-scope OAuth app depends on holding super admin. Shrinking that population and using scoped roles means a compromised help-desk account can reset a password - not mint a new super admin.
2. The attacker added an OAuth app with broad Gmail/Drive scopes. Explain how you'd detect and limit this, and what sign-in hardening you'd prioritize given the budget constraint.
Read the worked answer
Limiting OAuth abuse:
- Restrict app access / API controls: configure the domain so users can't grant access to unverified or untrusted third-party apps, and require admin approval for apps requesting sensitive scopes (Gmail, Drive). This is the highest-leverage control - a broad-scope app can't be authorized without review.
- Review and revoke existing third-party grants; the attacker's app must be revoked immediately and its tokens invalidated.
- Audit OAuth token grants and app authorizations in the security/audit logs to see what the app accessed.
Detection:
- Alert on admin-role changes (new super admin created) - this is the pattern to catch in minutes, not 36 hours.
- Alert on OAuth app authorization with sensitive scopes.
- Alert on new admin account creation and on sign-ins from new locations/devices for admin accounts.
Sign-in hardening (prioritized, low-cost first):
- Enforce 2-Step Verification / strong MFA for all admins first, then all users. This alone likely defeats the phishing compromise. Phishing-resistant methods (security keys) for the super admins.
- Context-aware access / login challenges for suspicious sign-ins.
- Password policy and session controls.
Given limited budget, prioritize: MFA everywhere (especially admins) → OAuth app restrictions → admin-change alerting. These are configuration, not add-on purchases.
3. Describe how you'd respond to the active incident and what you'd change so a 36-hour dwell time becomes minutes, naming the specific signals you'd alert on.
Read the worked answer
Incident response (order):
- Contain: suspend/reset the compromised super admin, revoke its sessions, and force re-auth.
- Remove attacker persistence: delete the rogue super admin account, revoke the OAuth app and its tokens, and check for any other new admins, recovery-email/phone changes, or forwarding rules.
- Scope the damage: review audit logs for what the attacker accessed/changed during the 36 hours - Gmail/Drive access via the OAuth app, any data shared externally, any settings changed.
- Eradicate and recover: undo unauthorized changes, restore settings, notify per policy if data was accessed.
- Lessons learned: feed into the controls below.
Signals to alert on (so dwell time drops to minutes):
- New super admin granted or admin role changed.
- New admin account created or admin account created outside normal provisioning.
- OAuth app authorized with Gmail/Drive/sensitive scopes, especially unverified apps.
- Sign-in from new geography/device for admin accounts; impossible-travel or risky sign-in.
- MFA disabled/changed or recovery info changed on an admin account.
- Bulk email forwarding rule created or mass Drive sharing.
Why this works: the attacker's actions (create admin, grant super admin, add OAuth app) are all discrete, alertable events. Alerting on admin and OAuth changes turns a 36-hour blind spot into a near-real-time signal. Combine with MFA to prevent the initial compromise and OAuth restrictions to block the persistence step.