“Push fatigue” is a noisy form of attack that generates numerous detection opportunities.

In a “push fatigue” attack (sometimes called “MFA bombing”), an attacker already in possession of a user password triggers push notifications, often in rapid succession, to trick or frustrate the legitimate user into allowing access. The attacker gains unauthorized access to the account if the user approves the request out of habit or under the assumption of system error.

The most strategic, long-term way to counter these attacks (and many others) is to migrate users to phishing-resistant authenticators such as Okta FastPass, FIDO2 WebAuthn authenticators or Smart Cards.

The next best solution - albeit a tactical one - is to apply number challenges to push requests.

If your organization isn’t in a position to make these changes, we recommend introducing detections that identify suspicious push requests, as well as workflows for automating your response to suspicious events.

Okta Security previously published logic used by our detection engineering team to identify malicious push requests. This detection, alongside others, has been added to the content libraries of security analytics tools like Splunk.

Okta Workflows, our no-code automation tool, offers opportunities to automate responses to suspicious requests in close to real-time, using the same underlying logic.

In this post, we’ll discuss two flows that evaluate the trustworthiness of a Verify Push request according to different criteria:

1. Variations in the geolocation metadata captured by the source of the request (the Okta SignIn Widget) and the response to the request (the Okta Verify app), and

2. Multiple rejected push challenges by a user.

Workflow 1: Detect Suspicious Push Challenges

The “Detect Suspicious Push Challenges” workflow was developed for workforce customers using Okta Identity Engine.

The logic does not rely on user identification of a suspicious request. Instead, it determines whether the source of a Push Challenge (the “source event” generated by the Okta SignIn Widget) comes from a different location than the Okta Verify client that accepts or rejects the challenge (destination event):

The geolocation information (country, state, city) in each event is found in the client.geographicalContext object.

This week, a basic version of this flopack was added to Okta’s extensive Workflows template library. The templated workflow checks if the two requests described above come from the same city. If the city does not match, a message with some of the relevant metadata is prepared for security operations teams.

There are a range of other orchestrated responses available for “flogrammers” to consider, which are discussed below.

Workflow 2: Detect Repeated User Rejections

Our alternative workflow addresses the “fatigue” aspects of a push fatigue attack. Okta solution engineer Sean Hanrahan has created versions for both Okta Identity Engine and Okta Classic.

The logic works as follows:

• The flow triggers on user rejection of a push MFA prompt (see table below)

• The flow stores data on sequential rejection events in tables

• If a user rejects a Push MFA request more than a configurable number of times (default: 5) in a configurable time threshold (default: 1 hour), a range of responses can be automated (see suggestions below the table).

• The tables are purged at configurable intervals.

Orchestrated Responses

Both of these flows were designed to notify security operations analysts of suspicious activity in close to real-time. Okta Workflows comes with built-in connectors for messaging tools like Slack and Teams, email clients like Gmail and Office 365 Mail, or IT service management tools such as ServiceNow, Jira Service Desk, freshservice, PagerDuty, ZenDesk and more.

Okta Workflows also offers opportunities to orchestrate differentiated responses based on the metadata observed in the events.

In the template for Workflow 1, for example, security operations teams are notified when the location of push source and push response do not include the same city (client.geographicalContext.city). This is a good place for analysts to start evaluating the benign reasons why location information doesn’t match. After this analysis, you may also want to take different actions based on whether there is a mismatch in city, state or country data, or other network related information captured by these events.

With a little tuning, your workflow might end up something more like this:

• If the city matches, end the flow and take no action.

• If the state matches, but the events came from different cities, send a message to the SOC.

• If the events were in a different country, immediately revoke the session (using the Clear User Session action card) and notify the SOC.

The Workflow can further be extended to:

• Provide the SOC analyst a direct link/shortcut to the events of interest in the Okta Admin Console (Under Reports > System Log).

• Provide the SOC analyst a history of how many times the user successfully authenticated from a given location in recent months (using the Search System Logs action card)

• Place users into a “higher risk” group that subjects them to higher assurance requirements for access to critical applications (using the Add User to Group action card)

• Assess if the user successfully authenticated after repeated failure events (using the Search System Logs action card), and in turn:

  • Trigger a session revocation (using the Clear User Session action card) and/or

  • Reset the user’s potentially compromised password (using the Reset Password action card)

Next Steps

If you'd like to get started with Workflow 1 (“Detect Suspicious Push Challenges”):

• Import the flopack into your Workflows console.

• Follow the instructions in the readme doc provided at GitHub to configure an Event Hook that triggers the flow on Verify Push MFA events.

• Select a connector for which tool you want to use for SOC notifications.

• Start testing!

If you’re at the RSA Conference in San Francisco this week, the “Detect Suspicious Push Challenges” flow will be showcased at the Okta booth.

For access to a pre-built template for Workflow 2 (“Detect Repeated User Rejections”), please ask your Okta Customer Success Manager.

And if you’re just getting started with Workflows, we recommend this YouTube channel for lots of great tutorials.

Thanks to Harish Chakravarthy and Bryan Barrows for testing and documenting these flows.