home / incident-response / cloud-iam-consent-phishing
OAuth Consent Phishing to Cloud Data Access
A single consent grant to a convincing app became mailbox access, cloud credentials, new persistence and an exfiltration attempt.
- Type
- Security incident
- Severity
- Critical
- Category
- Cloud identity / OAuth consent phishing / data exfiltration
- Duration
- About 30 hours from first consent to full recovery
- Times
- Relative to detection (T+0)
Summary
A staff member was sent a link to an application that asked to “review a shared document” and required sign-in with the corporate cloud account. The sign-in was real and the consent screen was genuine; the application was not. Once consented, the attacker held a delegated token that could read mail and files without ever knowing the password or defeating MFA.
From that token the attacker found mail containing cloud access details, moved into the cloud account with legitimate credentials, created a second way back in, and began staging data for exfiltration. The incident tested three things: whether identity events were logged well enough to reconstruct the path, whether containment could revoke a token rather than reset a password, and whether the organisation could keep working while the answer was determined.
My role
Incident lead and primary investigator. I owned the timeline and decisions, led the identity and cloud analysis, directed containment, and wrote the post-incident review. Supporting roles: the identity platform owner, the cloud platform owner, the endpoint and mail administrators, a communications contact for the affected business unit, and the data-protection lead for the regulatory decision.
Timeline
relative to detection- T−6d
Initial access
The victim consents to the malicious application. The grant appears in the identity audit log as a routine new app, and is not reviewed.
- T−5d
Mailbox access
The attacker reads mail through the granted token, looking for cloud credentials, security notifications and anything resembling an API key or invitation.
- T−4d
Cloud access
Using credentials recovered from mail, the attacker authenticates to the cloud environment from a new address and enumerates identity and storage permissions.
- T−3d
Persistence
A long-lived access key is created for an existing principal and the account is added to a group with broader read access. A mailbox rule is created to hide notifications.
- T−1d
Staging
Files are collected and a large export is prepared from a storage bucket the account can read.
- T+0
Detection
An alert fires on the new access key created from an unfamiliar address, and a second on an unusually large read against storage. The on-call analyst opens a critical incident.
- T+20m
Triage
Identity and cloud logs are joined by principal and source address. The pattern is clear enough, and the still-active consent grant is found, to treat this as an active intrusion rather than a single bad login.
- T+45m
Containment
The malicious application’s consent is revoked, its refresh tokens are invalidated, the new access key is deleted, the mailbox rule is removed, and the staging export is blocked. The affected account is disabled pending recovery.
- T+3h
Scoping
Every action taken by the application and by the cloud principal is listed: what was read, what was created, what was shared and what left the environment. Other users who received the same link are checked for consent.
- T+8h
Eradication
All credentials visible to the compromised account are rotated, sessions are revoked, and the cloud principal’s permissions are rebuilt from a least-privilege baseline rather than repaired in place.
- T+20h
Recovery
The affected account is re-enabled under a supervised reset, the victim is walked through what happened and re-enrolled MFA, and business access is restored in stages with heightened monitoring.
- T+30h
Recovery complete
Monitoring shows no further activity from the attacker’s infrastructure. The data-protection lead completes the exposure assessment and notification decision.
- T+5d
Review
A blameless review is held and recorded against the improvements below.
Key decisions
Treat a consent grant as a credential
The instinct is to reset the user’s password. That would have done nothing: the attacker never had the password. The effective action was to revoke the application and its tokens, which is why the incident was scoped by token first and password second.
Contain the identity, not just the endpoint
Disabling the account and revoking sessions stopped the intruder from continuing while leaving the rest of the organisation untouched. Recovery was sequenced so a critical business process was restored early under monitoring, instead of waiting for a perfect cleanup.
Rebuild permissions instead of repairing them
The cloud principal had exactly the kind of accumulated access that made the intrusion easy. Rebuilding from a documented least-privilege baseline was slower than trimming it, but it removed the same conditions that caused the incident.
Assume the mailbox was read in full
Rather than guess which messages mattered, the team assumed anything in the mailbox was exposed. That drove the credential rotation list and the data-protection assessment, and removed a class of “we think they didn’t see that” uncertainty.
Communicate in stages, with what is not yet known
Updates named the current belief, the confidence in it, and what was still being determined. That kept the business unit aligned without overstating progress or hiding uncertainty.
Actions taken
- Contain: revoke the application consent and refresh tokens; delete the attacker-created access key and group membership; remove the mailbox rule; block the staging export; disable the account.
- Scope: reconstruct the full path from consent to staging using identity and cloud audit logs, and identify everyone else who received the same link.
- Eradicate: rotate every credential the account could reach, revoke all sessions, rebuild permissions from a least-privilege baseline, and reset MFA.
- Recover: re-enable the account under supervision, restore access in stages, and monitor the environment closely for the following days.
- Communicate: factual staged updates to the business unit and leadership, and a complete exposure assessment with the data-protection lead.
- Learn: a blameless review turning every finding into a named improvement with an owner.
What detection caught, and what it missed
The events that eventually fired were identity changes: a new access key from an unfamiliar source and an outsized storage read. The consent grant at T−6d was logged but not alerted on. The gap was not a lack of data — it was a lack of a rule treating a new application consent as a security event, which is exactly the behaviour exercised in the cloud identity range. The cloud playbook from this incident now pairs a consent-aware rule with the credential and MFA rule published in the detection library.
Post-incident improvements
| Area | Change |
|---|---|
| People | Awareness material updated to cover OAuth consent screens and app-permission phishing, with a clear way to report a suspicious consent request. |
| Process | An app-consent review step, a documented identity incident runbook, and a pre-agreed credential rotation list so the answer does not have to be found mid-incident. |
| Tooling | Alert on new high-privilege application consents, on newly created long-lived keys, and on large reads by an identity that has never performed them. Reduce standing permissions so a single token is worth less. |
| Detection | Consent events treated as first-class alerts; credential and MFA changes mapped to their own rule; correlations between identity and storage activity. |
| Recovery | A tested re-enrolment path for a compromised account that does not require disabling MFA for everyone. |
Lessons
- A consent grant is a credential. If the review covers passwords and MFA but not application permissions, the biggest door is left unguarded.
- Containment has to match the mechanism. Revoke tokens and consent for a token-based intrusion; resetting a password is theatre.
- Logging that reconstructs a path beats logging that produces isolated alerts. The consent at T−6d and the key at T+0 were the same story told twice.
- Decide the credential rotation list before the incident. Under pressure, teams rotate the obvious secret and forget the five the account could also reach.
- Least privilege is the difference between one readable bucket and the whole estate. It is worth doing before it is the thing you wish you had done.
Tags
#incident-response#cloud#identity#oauth#phishing#data-exfiltration