How does Push detect and prevent phishing attacks?

You can use Push to detect when an end-user has entered their SSO password on a login page that does not belong to the SSO provider, including suspected phishing sites.

Based on your configured settings, Push can then either report the SSO password reuse to administrators without notifying the end-user, warn the end-user they are reusing the SSO password on a potentially malicious site, or block the end-user from logging in altogether.

This capability is powered by the Push browser agent. You can configure the SSO password protection feature on the Controls page of the Push admin console. By default, this feature is in Monitor mode.

To use this feature, you must ensure your employees’ browsers are enrolled in Push by installing the Push browser extension and assigning them a license in the platform.

You can also use Push to:

• Detect when employees visit sites using phishing tools like EvilNoVNC and Evilginx, using Phishing tool detection. Learn more about phishing tool detection.

• Block malicious websites using URL blocking. You can manually add URLs to a blocklist, or programmatically manage URL blocking using the Push REST API. Learn more about URL blocking.

When observing logins, the Push browser extension generates a salted partial hash of the user’s password, known as a fingerprint. This fingerprint is then stored locally to allow Push to perform password comparisons. Learn more about how the extension securely observes passwords in this help article.

To detect possible phishing attempts or any SSO password reuse, the extension compares the observed password fingerprint to known fingerprints for identity provider passwords that already exist in local storage. This means that the extension must have observed the end-user logging into their IdP account at least once.

Push can detect the following identity providers:

• Okta

• Microsoft 365

• Google Workspace

• JumpCloud

• Duo

• Ping Identity

If an employee has entered a known SSO password on a webpage that does not belong to the SSO provider, Push will enforce the SSO password protection settings set by an administrator.

Note: The browser agent will ignore flagging any scenarios in which the login page is in the company domain(s), is on the ignore list under Settings > Advanced, or is in a private IP address space, including localhost.

You can ignore SSO password reuse on known work apps by using the Ignore work apps setting for this feature. Push recognizes the apps on our Supported SaaS page as known work apps. The Ignore work apps setting is enabled by default.

If the feature is in Monitor mode, employees will not be notified that a potential phishing event (or SSO password reuse) was detected and they will not be blocked from submitting their password. The Push platform will emit a webhook event that administrators can ingest into a SIEM or other monitoring tool.

In Warn mode, employees who enter their SSO password on a webpage that does not belong to the SSO provider will see a custom warning message. They must click the acknowledgement button to proceed if they are sure the site is trusted.

If the feature is in Block mode, employees who enter their SSO password on a webpage that does not belong to the SSO provider will be quickly redirected to a Push-hosted page with your custom block message, such as:

The event will also be recorded via a webhook.

The custom message field for the block page supports link and email syntax using markdown, but no other formatting.

Example markdown:

• [Push Security](https://pushsecurity.com)

• [Steph](mailto:steph@ctrlaltsecure.com)

The Push platform provides a webhook event SSO_PASSWORD_USED that administrators can listen for in their SIEM or other monitoring tool.

These events are not currently displayed in the Push admin console.

Read more in our developer documentation.

Push recommends using this feature in Monitor mode for a few weeks before you enable Warn or Block mode. This will allow you to find any sites in your environment that cause false positives, such as sites that are configured to legitimately use SSO credentials for authentication.

Monitor for webhook events during this testing period, and then add any sites that generate false positives to the Ignore specific domains list.

Once you have tested the feature and updated the ignore list, then you can enable Warn or Block mode.