Skip to content
Tyler Butler edited this page Aug 24, 2021 · 17 revisions

What is PhishCatch?

PhishCatch is a privacy-respecting web browser extension and dockerized back-end infrastructure that can help prevent account takeover (ATO) of enterprise identities. PhishCatch monitors browser activity to:

  • Detect when users enter their enterprise password(s) on external websites.
  • Prevent password leaks on impersonated authentication pages.
  • Allow users to report visited pages as suspicious.
  • Empower security teams to quickly detect and respond to these attacks.

PhishCatch has the following native functionality:

  • Support for Google Chrome and Microsoft Edge. (Firefox support is planned)
  • Support for centralized management via Microsoft Group Policy (GPO) for Windows clients.
  • Support for centralized management via Jamf Pro for MacOS clients.

High-Level Functionality

PhishCatch is installed as an extension in your browser. You may choose to install it from the respective Browser Store, or compile and redistribute it yourself.

PhishCatch is designed to communicate with a listening post (LP) server broadly accessible on the Internet. This server will be used to receive PhishCatch detections and other notifications for forwarding to your security information and event management (SIEM) or other system. We've included a functional LP server for rapid deployment.

Note: PhishCatch can be deployed in standalone mode with no external connectivity. Please see the configuration settings for additional information.

PhishCatch configuration starts with specifying enterprise_domains, which are a list of domains that you implicitly trust for receiving credentials. Any domains not on the enterprise_domains list are presumed to be unauthorized and will generate password re-use and other detection events.

Here's how this functions in practice:

If the site is listed in enterprise_domains

PhishCatch is designed to capture credentials used on sites on the enterprise_domains list. These credentials are stored locally and are never transmitted off the device.

Here's how this works:

  • When credentials are entered on a site on the enterprise_domains list, PhishCatch captures the password entry, hashes it, and stores the hash locally with a per-secret salt. PhishCatch also saves the entered username associated with that domain.
  • PhishCatch additionally stores a fuzzy DOM hash of the site visited. This is a representative hash of the page's HTML code which can be used to compare similarities to HTML on other sites. This will be used in cloned site and other visual similarity detections.
  • As an additional security measure, PhishCatch displays a green checkmark on the extension icon when visiting an enterprise domain. This provides a quick a visual reference for users to consider before entering credentials.

If the site is not listed in enterprise_domains

PhishCatch will compare saved credentials captured from the enterprise_domains list against credentials submitted to any other domain.

Here's how this works:

  • Shortly after the page is loaded, the extension will hash the website DOM and check it against saved fuzzy DOM hashes. If the hashes match, the extension will trigger a warning alert that this site may be malicious. This is designed to help prevent a password leak before it occurs.
  • When text is entered into a password field, the extension hashes the field and compares it to the cached hashes. If there is a match, an alert is triggered.
  • The entire password field is hashed with each keystroke, so that external passwords that contain the enterprise passwords will be detected, even if they are not fully identical.
    • For example, say the cached enterprise password is Password1 and an external password is Password123. An alert will be not be triggered for entering Pa, Pass, or Password, but will be triggered as soon as Password1 is entered.
  • The extension also hashes the username and compares it to the cached hashes. This detects and prevents users from accidentally entering their password into username fields. As username fields are generally not hashed or otherwise protected in event logs, this helps prevent further plaintext leakage of credentials.
    • The username_regexes config option can be used as an additional guard against passwords sneaking in.

When alerts are triggered

Metadata about the reuse event is sent to the PhishCatch server as configured in by the phishcatch_server value. If phishcatch_server is not configured, the extension will not initiate any network connections.

Only metadata about the reuse event (username, external domain, referrer, timestamp, etc.) is sent to the server for logging and alerting. Hashes are only stored locally and are never sent to the PhishCatch server or any other external location.

If the PhishCatch server cannot be reached, the extension will cache the alert and attempt to retransmit them periodically. This is useful if the PhishCatch server can only be reached while on a corporate VPN, or if the route is temporarily down.

Configuration overview

The extension uses Chrome management schema to obtain deployment configuration settings. These settings should be deployed using the appropriate enterprise management mechanism for the endpoint: Group Policy for domain-joined Windows systems, Jamf Pro configuration profile for managed macOS systems, or other configuration deployment system.

Mandatory configurations:

  • enterprise_domains: The list of domains where entering a enterprise account password is expected and approved.

Configurations required for remote alerts:

  • phishcatch_server: The URL of the PhishCatch server. If this is not supplied then the extension will only display local alerts. An example of this would be https://phishcatch.example.com.
  • psk: The preshared key configured on the PhishCatch server. Pick something strong. An example of this would be thisisalongpresharedkey.

Optional configurations:

  • data_expiry: The number of days that hashed passwords and usernames are cached locally. The default setting is 90.
  • display_reuse_alerts: Display pop-up alerts on the endpoint when reuse is detected. The default setting is true.
  • enable_debug_gui: Allow debug GUI access. The debug GUI shows the current config, currently cached data (usernames, password hashes, etc.), and allows for manual config override. The default setting is true.
  • faq_link: Enables a FAQ button in the PhishCatch GUI that links to an arbitrary URL. If not present, no button will be displayed.
  • ignored_domains: Configure sites that should be ignored. Usernames and passwords entered into sites on this list will NOT be hashed, stored, compared, or generate alerts. If not present, no domains will be ignored.
  • manual_password_entry: Allows the user to manually populate password hashes in the PhishCatch GUI, in addition to capturing them from enterprise domains. The default setting is false.
  • pbkdf2_iterations: The number of PBKDF2 iterations used when hashing passwords. The more iterations used, the more difficult the hash will be to reverse, but will also require additional processing resources on the endpoint. The default setting is 100000.
  • repo_link: Enables a "Source Code" button in the PhishCatch GUI that links to an arbitrary URL. If not present, no button will be displayed.
  • url_sanitization_level: Determines the verbosity of the URLs sent in reuse alert webhooks. See url_sanitization_level configuration details for options. The default setting is host.
  • username_regexes: Define regexes that usernames must match in order to be stored.
  • username_selectors: Allows enterprises to define selectors used to detect username fields on domains listed in enterprise_domains. This is currently highly recommended for enterprises not using Azure AD.

Detailed examples for all configurations are found at Configuring the extension

Policy templates for both Windows and macOS are available at https://github.com/palantir/phishcatch/tree/main/policy-templates

A note about testing

Misconfiguration can lead to both false positives and false negatives. It is recommended that the complete detection and alerting pipeline be tested before full deployment. Please read all of the instructions including blind spots and references before implementing.