Palo Alto SecOps Professional study materials
Palo Alto SecOps Professional study resources

Saturday Token Theft: MFA Approved, No Endpoint Evidence

Palo Alto SecOps Professional · Put your knowledge to work in context.

All case studies

Saturday Token Theft: MFA Approved, No Endpoint Evidence

Saturday, 02:10. An identity alert fires: a finance controller signed in from an ASN geolocated in Country X, 40 minutes after a sign-in from the corporate office. Fourteen minutes later, an OAuth application named 'MailSync Pro' was granted delegated Mail.Read and Mail.Send. Since then, an inbox rule named 'RSS Feeds' has moved 11 messages containing 'invoice' to the Archive folder, and three external recipients received a reply-chain email containing a shortened link. The tenant allows user consent for low-risk scopes. The controller is reachable by phone and says she approved an MFA prompt because 'the sign-in page looked normal'. Her laptop is compliant, EDR shows no malicious process, and there is no evidence of credential dumping. The platform holds 1,900 open incidents and the on-call analyst is alone until 07:00.

1. Classify the most likely attack pattern and describe, in order, what you would check to size the blast radius.

Read the worked answer

Most likely adversary-in-the-middle phishing that stole a session token, not credential theft. The evidence chain is coherent: the user approved MFA on a convincing proxy page, a new-ASN sign-in followed 40 minutes later, OAuth consent was granted minutes after that, an inbox rule was created, and there is no endpoint telemetry at all. The attacker never needed the laptop, so EDR cleanliness is not reassuring.

Blast-radius checks, in order:

  1. OAuth grant scope: search all consent grants for the same application ID and publisher across the tenant. Every mailbox with the grant is potentially readable.
  2. Sign-in logs: all sign-ins for the user and for the application, including refresh-token redemption, and whether other users authenticated to the same app.
  3. Mailbox audit: rule creation, send-as and delegate additions, and sent items containing the lure.
  4. Email gateway and proxy: find other recipients of the shortened link. The campaign may have hit 30 people and this is only the first report.
  5. Conditional access: whether the new ASN would be blocked today. If not, that is a gap to raise, not just a detail.

Do not declare scope closed until the application consent search returns clean.

2. Give the containment sequence for the next 60 minutes and justify each step, including what you would deliberately not do.

Read the worked answer
  1. Preserve first, minutes matter: export sign-in logs, mailbox audit records, the inbox rule properties, OAuth grant details, and message headers. Deleting the rule before capturing it destroys your best evidence of intent.
  2. Revoke sessions and refresh tokens for the user, then force a password reset. A password reset alone leaves the stolen token valid; this ordering is the whole point.
  3. Revoke the OAuth grant and disable the application. Go tenant-wide only after checking whether any team uses it legitimately.
  4. Remove the inbox rule and search for hidden ones, including Archive, RSS, and names starting with a dot.
  5. Block the shortened URL and hosting domain at email and web proxy, and purge delivered copies from other mailboxes.
  6. Notify the three external recipients and their security contacts; they may now be targets of follow-on mail.
  7. Re-register MFA only if you suspect the method itself was enrolled by the attacker. Doing it reflexively adds friction without closing the token path.

Deliberately do not isolate the laptop: there is no endpoint evidence, isolation costs the user a working day, and it signals a conclusion the data does not support. Do not downgrade the incident to a medium identity alert; this is a confirmed account takeover.

3. It is 02:30, you are alone, and 1,900 incidents are open. What do you escalate, what do you defer, and how do you hand off at 07:00?

Read the worked answer

Escalate because the actions needed exceed analyst rights and the risk is active. Wake the identity administrator to revoke sessions and the OAuth grant, and notify the IR lead so the incident is owned above the queue. Open a single major-incident record with a timeline and link every related alert to it rather than working them separately.

Defer the 1,900 open incidents. They are overwhelmingly low-severity and none becomes materially worse in four hours; the account takeover is actively exfiltrating mail. State this trade-off explicitly in the incident record, because an auditor will ask why the backlog was untouched.

Do the highest-value containment you can do alone: block the URL, purge the message if your role allows, and preserve evidence. Document what you could not do because of permissions so it does not look like an oversight.

Hand off at 07:00 with a written summary: what happened, what is contained, what is outstanding, who owns each outstanding action, and the criteria for closing. Do not hand off verbally only; the next shift needs the timeline, not a story.