Phishing URL Clicked

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.

The immediate risk after a phishing URL click depends on what the page does. Credential harvesting pages capture the user's email address and password and relay them to the attacker in real time. AiTM phishing proxies go further — they sit between the user and the real Microsoft login page, transparently proxying the authentication and capturing both the credentials and the session token at the same time.

If the attacker captures the session token, they have authenticated access to the user's Microsoft 365 account without needing the password or MFA, and they typically act within minutes: reading emails, establishing inbox rules for persistence, accessing SharePoint files, or using the account to send further phishing emails to the user's contacts.

If the user only submitted credentials (no token capture), the attacker will attempt to sign in, which may trigger MFA — but if MFA is weak (e.g., SMS or phone call), it can be defeated through social engineering or SIM swap.

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