The Payroll Phish and the Unapproved MFA Prompt

Containment is ordered by what an attacker can still do, not by what is easiest.

1. Revoke sessions and reset the password first. Credentials were typed into a real-looking page, so assume they are in someone else's hands. Revoking active sessions matters as much as the reset - if the attacker already has a token, changing the password alone can leave them signed in.
2. Check and reset MFA registration. The unapproved push prompt is the critical detail: a prompt with no login attempt by the user means someone else had the password and was trying to satisfy MFA. Review registered methods and remove anything unfamiliar before anything else consumes your time.
3. Then remove the account from Payroll-Admins, or at minimum verify no new members or permissions were added to the group. If the attacker had access, the group is a target in itself, not just a door.
4. Retract the phish - you are at 75 minutes against a 30-minute retraction window, so this is already lost. Do not lead with it. Instead, search for other recipients and warn them.
5. Verify mailbox rules and forwarding. Attackers commonly add a hidden forward or inbox rule so they keep receiving mail after the password is reset.

Order matters because steps 1 and 2 close the open door; the rest is cleanup that is worthless while the door is open.

Preserve, in a location the user cannot alter: the original phishing message with full headers, the URL she visited, the exact times of the click, the credential entry, and the MFA prompt, and any mailbox forwarding rules or inbox rules created after 11:40. Export the sign-in log for the account around that window and check for unfamiliar locations, devices, or successful authentications. Record what she told you, in her words, with a timestamp.

Avoid:

• Do not wipe or reimage her machine before capturing evidence. There is no EDR to reconstruct anything afterward; the local browser history and any downloaded file may be the only record of what the page did.
• Do not delete the phishing email from her mailbox as a "cleanup" step before it is exported - you lose the headers.
• Do not question her in a way that assigns blame. A user who feels accused stops volunteering detail, and the detail is what tells you whether credentials were merely entered or actually used.
• Do not assume the incident is contained because she did not approve the prompt. An unapproved push can mean she refused, or that the attacker gave up and will retry.

Keep a written timeline from the start; reconstructing it two days later is where investigations fail.

It is a confirmed credential compromise and a suspected intrusion, which is not the same as a confirmed data breach. The distinction decides the notification clock.

What is established: credentials were entered on an attacker-controlled page, and an MFA prompt arrived that the user did not initiate. That second fact is strong evidence the password was already in use by someone else. What is not established: whether the attacker authenticated successfully, and whether any payroll data left the system.

The 24-hour clock starts at confirmation of a breach, so the immediate priority is turning "suspected" into "confirmed or excluded" with evidence - sign-in logs, group membership changes, mailbox rule changes, file access on the payroll drive. Document the time you began that check, because if data access is later found, the clock is measured from when you could reasonably have known.

Escalate to the privacy officer now, before the answer is complete. Notification rules are usually written so that a suspected incident with access to regulated personal data is reported internally regardless of the final determination. Waiting for certainty to protect against a false alarm is the wrong trade: a false alarm costs a conversation, and a late notification of a real payroll data exposure is a regulatory and contractual failure.