A user reports they clicked a link in a suspicious email and typed their password into the page. What is your FIRST action?
Short answer
Assume the password is already compromised: force a reset AND invalidate the account's active sessions and tokens, because a reset alone won't evict an attacker who already holds a live session or refresh token. Then hunt for anomalous logins, MFA prompts, mailbox rules and OAuth grants from the exposure window. Deleting the email or telling the user to change it "next time" leaves the account wide open. An antivirus scan addresses malware on the endpoint, not stolen credentials in the cloud.
When a user admits they typed their password into a phishing page, treat the credential as already in attacker hands. The question tests whether you understand that modern account takeover is rarely stopped by a password change alone — and that speed of containment matters more than tidying up the inbox.
Why a reset plus session kill is the answer
A password reset closes one door, but attackers who phished credentials often immediately authenticate and obtain a session cookie or OAuth refresh token. Those tokens survive a password change. So you must do both: reset the password and revoke active sessions/tokens (sign-out-everywhere, token revocation, force re-auth). Only then do you hunt — review sign-in logs for impossible travel or new IPs, check for newly created inbox forwarding rules, OAuth app consents, and rogue MFA enrollments added during the attacker's window.
Why the other options are dangerous
- Delete the email and move on — this addresses the lure, not the breach. The credential is already gone; the inbox cleanup does nothing for the attacker's access.
- "Change it next time you log in" — every hour of delay is dwell time. The attacker can change recovery settings, exfiltrate mail, or pivot before the user's next login.
- Run a full AV scan and wait — antivirus hunts malware on the laptop. This incident is stolen cloud credentials, not necessarily a malware infection. Waiting on a scan burns the critical containment window while the account stays exploitable.
What the interviewer is probing
They want to see that you separate endpoint compromise from identity compromise and reach for the right control. The strong candidate names the dual action (reset and session/token invalidation), then pivots to scoping: what did the attacker touch, and did they establish persistence via MFA or mailbox rules? That judgment — containing identity first, investigating second — is the core of credential-phishing response.
Likely follow-ups
- An attacker enrolled their own MFA device during the session. How would your reset workflow catch that?
- What logs would you pull to scope what the attacker did with the stolen credentials?
- How do session tokens and OAuth refresh tokens change your containment beyond a password reset?