When a user clicks a known phishing URL — a link that Microsoft's threat intelligence has identified as malicious — they have likely been exposed to a credential harvesting page, a malware download, or an AiTM proxy designed to capture their session token. The click itself doesn't confirm that credentials were stolen or that the account is compromised, but it represents a high-risk moment that requires immediate investigation.

Phishing remains the most common initial access vector for Microsoft 365 account compromises. Modern phishing pages can capture credentials and MFA tokens simultaneously through adversary-in-the-middle proxies, meaning that even users with MFA enabled are not fully protected once they interact with a convincing phishing page. The window between the click and potential compromise can be very short — sometimes minutes.

• Credential harvesting page captures the user’s email address and password in real time and relays them to the attacker immediately
• AiTM phishing proxy transparently proxies the authentication flow, capturing both credentials and the active session token after the user completes MFA
• With a captured session token, the attacker has full authenticated access to the user’s Microsoft 365 services without needing the password or passing MFA themselves
• Attacker acts within minutes of token capture — inbox rules established, files accessed, contacts enumerated before the user has time to report the incident
• Phishing email forwarded to the user’s entire contact list from within the trusted domain, expanding the attack to colleagues and business partners
• OAuth consent page used instead of credential harvesting — user authorises a malicious app, granting persistent access that survives a password reset
• Multiple users in the same organisation click the same URL, indicating a targeted or bulk campaign against the tenant rather than an isolated event
• Even without credential submission, visiting a malware delivery page may silently install browser credential stealers or endpoint compromise tools

There is no scenario where clicking a known phishing URL is expected or intentional for a regular user. However, some context can reduce the urgency:

• Security awareness training platforms (e.g., KnowBe4, Proofpoint Security Awareness) often run simulated phishing campaigns — clicks on these may trigger the same alerts as real phishing URLs depending on how the simulation is configured
• Security researchers or analysts who clicked a link deliberately as part of analysis (though this should be done in a sandboxed environment, not on a production account)

Before escalating to full incident response, confirm with your security awareness training provider whether a simulation was running at the time. If it was a real phishing URL, treat it as a potential compromise regardless of whether the user reports entering credentials.

• In Microsoft Defender for Office 365, review the URL click event — what was the URL, when was it clicked, and what was the verdict (phishing, malware, etc.)
• Check whether this was a simulated phishing campaign from your security awareness training platform
• Review the user's sign-in logs for any new sign-ins in the minutes and hours following the click, particularly from unfamiliar IPs or locations
• Check the user's mailbox for any new inbox rules created after the click timestamp
• Look at whether other users in the organisation received the same email and whether any also clicked the URL
• Contact the user — via phone, not email — to find out whether they entered credentials on the page they were taken to

1. Revoke all active sessions for the user immediately via Entra ID — if a token was captured, this prevents continued access even if you don't yet know for certain whether credentials were stolen
2. Reset the user's password via a secure channel (not email, which may be compromised)
3. Re-enrol or verify MFA for the account to ensure the attacker cannot use captured credentials even if sessions are re-established
4. Review the user's mailbox for inbox rules created after the click — delete any rules that weren't there before
5. Check SharePoint and OneDrive for any file access or sharing that occurred after the click timestamp
6. If the phishing email was delivered to multiple users, report the URL and sender to Microsoft Defender and consider blocking the domain at the mail gateway
7. Follow up with the user through security awareness training — this is a teachable moment, not just a remediation event

Overe Auto-Response: The Phishing URL Clicked alert can be configured in Overe to trigger automatic session revocation or account block as soon as a phishing click is detected. Review your Auto-Response settings under Org Config > Auto-Response — given the short window between click and potential token capture, automated response for this alert is strongly recommended.

Microsoft: Safe Links in Defender for Office 365

Microsoft: Defend against AiTM phishing attacks

Microsoft: Investigate malicious email delivered in Microsoft 365

After investigating a phishing URL click alert, review these related risk areas:

• Session Hijack via Unusual IP Change — if a token was captured via AiTM, watch for immediate IP changes in the user's active session
• Suspicious Inbox Rules — post-compromise inbox rule creation is one of the first actions attackers take after gaining access via phishing
• Risky Inbox Forwarding Rules — check for forwarding rules established after the click to maintain persistence
• OAuth Phishing via First-Party Microsoft Apps — some phishing pages use OAuth consent flows rather than credential harvesting; check for unexpected app consent grants
• Excessive Authentication Failures — if credentials were captured, the attacker may attempt sign-in shortly after, triggering authentication failure patterns if MFA blocks them