The message comes in at an ordinary hour, usually mid-afternoon. "I think I just clicked something I should not have. It asked for my password and I typed it before I realized." This is the call that rearranges the rest of your afternoon. Most people's instinct is to ask more questions, confirm it was really phishing, wait for the person to forward the email. The right move is to start moving while you are still on the call.
This is not a theoretical scenario. Over several years managing Microsoft 365 environments for distributed teams, I have been on the responding side of phishing incidents more times than I would like. Not because the teams I work with are careless. Phishing attempts have become genuinely hard to distinguish from real emails, especially when they spoof internal senders, mimic login pages for tools the team uses every day, or arrive through a compromised external address that passed all the authentication checks.
The response matters more than the click. Here is the exact sequence I follow.
The First Two Minutes
Your only job in the first two minutes is to treat this as a confirmed incident until the logs tell you otherwise. Not a "possible" incident. Not "let me check and see." You start the response sequence while you are still gathering the facts, because the attacker is not waiting for you to finish gathering them.
Open the Microsoft Entra admin center immediately. Navigate to the user account, then to sign-in logs. Filter to the last 30 minutes. You are looking for three things: a successful authentication from an IP address the user does not normally use, a device that is not on their known device list, or a sign-in originating from a country outside the user's regular locations. A clean log means you are probably early. An anomalous successful sign-in means you are already behind.
What Attackers Do First
If the attacker obtained valid credentials and bypassed MFA (credential-harvesting pages now routinely capture MFA tokens in real time by acting as a proxy to the real login page), they move quickly on two things.
The first is a mail forwarding rule. They add an external address as a forwarding target for all incoming mail, or for messages matching specific keywords like "invoice," "password," or "reset." This rule gives them persistent access to inbound mail even after you change the password. It stays active unless you find it and remove it manually. In the Exchange admin center, go to the affected user's mailbox and check mail flow rules and inbox rules. Both.
The second is an OAuth application grant. An authorized app token is independent of the user's password. Resetting the password does not revoke it. The attacker uses this as a backup foothold for data access even after you complete the standard reset procedure. In Entra, go to the user account and check "Apps with permissions to this account." Remove anything that was not explicitly authorized by the user or your IT policy.
Revoke First, Then Reset
This is the step that trips up even experienced IT administrators. The instinct is to reset the password first, as quickly as possible. The correct sequence is: revoke all active sessions first, then force the password reset and MFA re-enrollment.
The reason matters. An active session token is issued at authentication time and has its own expiry, independent of the user's password. If you reset the password before revoking sessions, an active session the attacker holds can continue to function for the remainder of its token lifetime, which can be hours. In Entra ID, go to the user account, select "Revoke sessions," confirm. Then immediately initiate the password reset and force re-enrollment of the authenticator.
The revoke step closes the window that is currently open. The reset step prevents a new one from being opened with the old credentials.
The Window That Actually Matters
The most dangerous period in any phishing incident is not the moment of the click. It is the gap between the click and the moment IT finds out.
In most of the incidents I have handled, by the time I started my investigation, the forwarding rule was already in place. The attacker had already read at least some inbox content. That window cannot be closed retroactively. What you can change is how quickly your team reports.
A blame-free, low-friction reporting culture shortens the reporting gap more reliably than almost any technical control you can add. When people believe they will be treated as someone who flagged a problem rather than someone who caused a disaster, they report within minutes. That difference in reporting time has more practical impact than the exact sophistication of the phishing attempt.
You can harden the technical surface forever and still lose days of data to a reporting gap that a single honest conversation could have closed.
Talking to the User
Keep the user briefing short, specific, and non-accusatory. Something close to: "You did exactly the right thing by telling me immediately. Here is what is happening now: I am resetting your account password and you will need to re-enroll your authenticator. I will walk you through it on this call." Then do it together, live, so you can confirm the re-enrollment completed correctly and the user is not locked out at the end of the call.
The goal of this conversation is not to determine culpability. It is to get your account back under your control as quickly as possible, with the user's cooperation.
The 48-Hour Follow-Up
Do not close this incident at the end of day one. Set a reminder and return to the sign-in logs and mailbox configuration 48 hours later. Check for new inbox rules that appeared after you cleared the originals. Review the mailbox send logs for any emails that went out in the user's name that the user did not write. Look at the sent items folder and the deleted items folder.
Also check shared drives and SharePoint sites the user had access to. If the attacker authenticated successfully, they had access to everything the user had access to. That scope matters for any breach notification decisions, and for conversations with your legal or compliance team if sensitive client or financial data was in scope.
The Longer Fix
The incident response procedure closes the immediate gap. The system changes reduce the blast radius of the next one.
Two controls make a significant difference here. Conditional access policies that block sign-ins from non-compliant or unenrolled devices prevent an attacker from authenticating from a fresh machine even with valid credentials. Legacy authentication protocol blocking closes a set of authentication pathways that bypass MFA entirely because they predate it. Both are available in Entra ID and neither requires third-party tooling.
The goal is not to prevent every phishing attempt. You will not achieve that. The goal is to make a successful credential capture as difficult as possible to convert into a lasting breach, and to make the containment procedure fast enough that the window stays small when prevention fails.
Sources
- Microsoft Entra: Sign-in log concepts and review
- Microsoft: Responding to a compromised email account in Office 365
- Microsoft Entra: Conditional Access overview
Have a question about M365 incident response or security configuration for your team? Reach me at felixmaru.com/#contact.