Phishing Resistant Authenticators in action through Okta Fastpass

Phishing Activity Trends Summary report conducted by the Anti-Phishing Working Group highlights the following findings that you should be aware of:

  • In the third quarter of 2022, APWG observed 1,270,883 total phishing attacks, a new record and the worst quarter for phishing that APWG has ever observed.
  • Attacks against the financial sector represented 23.2% of all phishing attacks.

As Phishing attacks are continuously on the rise year after year, and your employees are the main targets of these attacks, I’m here to showcase how Okta is able to leverage Phishing Resistance Authenticators to DETECT, PREVENT and PROTECT your end-users and organisation from Phishing attempts.

Phishing resistance

Here’s a quick video demonstrating Okta’s Phishing Resistant Authenticators in Action vs EvilGinX

Okta FastPass provides strong resistance to credential phishing attacks. The Loopback server and the SSO extension methods described above have strong phishing resistance capabilities. The fallback methods, such as Universal Links (iOS), Custom URI (macOS), and App Links (Android), do not provide the same level of phishing protection. However, we can use some of these methods to launch Okta Verify and enable users to authenticate using the phishing resistance bindings such as the Loopback server. Okta’s policy configuration page guides the admin to configure the app sign-on policies with phishing resistance correctly.

The below diagram shows how Okta’s Loopback server binding helps in preventing phishing attacks involving an adversary in the middle attack using a proxy server such as evilginx.

Refer to https://www.okta.com/blog/2022/11/a-deep-dive-into-okta-fastpass/

Since Okta FastPass includes the origin header in the signed response payload, Okta can easily detect the domain mismatch throw and alert administrators and end-users, in addition to rejecting the authentication request.

Admins can use Okta Workflows to alert the end-user through a back channel such as Slack or email or to take other actions such as blocking traffic to and from the phishing site.

Combining this with device assurance policies, Okta can provide strong protection from other forms of endpoint attacks, such as malware or ransomware. Okta’s partners, such as Crowdstrike and Windows Security Center, can provide valuable signals on the presence of malware on the device, which Okta leverages to enforce strong authentication policies.

4 thoughts on “Phishing Resistant Authenticators in action through Okta Fastpass

  1. Great demo – but I have a couple of questions…

    How do you go about locking down access to apps once the phishing event has been logged?
    I can’t see anything to do with Phishing in Event Hooks… This is what I would use to pass through Syslog events to Okta Workflows. What is the work-around?
    I assume you use Workflows to add a user to a temporary “App Lock-out” Okta Group.
    Do you then add a Rule to the top of Authentication Policies, where if user is in the “App Lock-out” Okta Group > then Access is denied?
    Then from the Learning platform, I assume you would need some kind of Webhook to send details back to Okta Workflows to remove the user from the “App Lock-out” group if they successfully pass the “Phishing Refresher” training?

    1. HI Steve!

      Thanks for posting your questions.

      In order to trigger a workflow event once a phishing event has been captured by Okta, you would need to leverage Okta’s event hooks and configure a event filter – https://ibb.co/FHSCQpV

      Once you’ve configured the above, every time Okta detects the said event that matches the appropriate filter, you can trigger a workflow that will add the user to a temporary “App Lock-out” Okta Group. You’re absolutely correct that the said group will be configured to the top of Authentication Policies, where if user is in the “App Lock-out” Okta Group > then Access is denied.

      And you’re spot on again that once the user successfully pass the “Phishing Refresher” training, a incoming webhook can be trigger back to Okta to remove the user to the said group.

      I hope the response above answers your question 🙂

    1. Hi Steve! Apologies for the late reply but yes the event hook filtering is in BETA. you can request a support ticket to enable this on your Okta org if the said feature is not yet enabled on your end. Cheers

Leave a Reply