Okta phishing detection with FastPass origin check

okta

Classification:

attack

Tactic:

TA0001-initial-access

Technique:

T1566-phishing

Cette page n'est pas encore disponible en français, sa traduction est en cours.
Si vous avez des questions ou des retours sur notre projet de traduction actuel, n'hésitez pas à nous contacter.

Goal

Detect when Okta raises a phishing detection with FastPass origin check.

Strategy

This rule monitors Okta for when a phishing detection with FastPass origin check has been raised. Okta provides a platform detection for when a user enrolled in FastPass fails to authenticate via a real-time adversary in the middle (AiTM) phishing proxy.

Triage and response

  1. Extract the IP address {{@network.client.ip}} and context provided by Okta in @debugContext.debugData.risk. The user email will always populate as system@okta.com and further log events are required to determine the user account targeted.

  2. Review the risk analysis provided in @debugContext.debugData.risk. This field may include:

  • The application that was attempted to be accessed
  • Okta’s risk severity rating
  • Mismatched request origin detail

If the authentication attempt was to the Okta dashboard directly, the application name will populate as okta_enduser. A mismatched request origin can provide insight on AiTM infrastructure if captured by Okta and provided in this log field.

  1. Determine what user account was associated with the failed FastPass attempt by reviewing surrounding Okta logs for evidence of related login attempts, such as:
  • user.session.start
  • policy.evaluate_sign_on
  • user.authentication_via_mfa
  • user.authentication.verify

The IP address, device hash, or user agent can be helpful fields for further context on the identity triggering the login events.

  1. Investigate if the authentication attempts, from this IP address or user, follows typical behaviors within your environment.

  2. If the behavior appears malicious and authentication occurred successfully following the failed FastPass attempt, clear related user sessions and reset user passwords.

  3. Begin your organization’s security incident response process and investigate further for any account takeover and lateral movement behavior.

Changelog

  • 4 August 2025 - Updated rule query to group by usr.email.
  • 16 January 2026 - Updated documentation to include additional context.