# About ## What is Check? **Check** is a browser extension that provides real-time protection against Microsoft 365 phishing attacks. Specifically designed for enterprises and managed service providers, Check uses sophisticated detection algorithms to identify and block malicious login pages before credentials can be stolen by bad actors. Check is available for **Chrome**, **Microsoft Edge**, and **Firefox** (109+ Coming Soon!). The extension integrates seamlessly with existing security workflows, offering centralized management, comprehensive logging, and optional CIPP integration for MSPs managing multiple Microsoft 365 tenants. Check is completely free and open source, can be delivered to users fully white-labeled, and is licensed under AGPL-3. You can contribute to Check at . Installing the extension immediately gives you protection against AITM attacks and takes seconds. Click the install button and you're good to go. Install for Edge **OR** Install for Chrome **OR** Firefox (Coming Soon!) ## Why was Check created? Check was created out of a need for better protection against AITM attacks. During a CyberDrain brainstorming session, CyberDrain's lead developer came up with the idea to create a Chrome extension to protect users:
This led to a hackathon in which the team crafted a proof of concept. This proof of concept led to the creation of Check by CyberDrain. CyberDrain decided to offer Check as a free-to-use community resource for everyone. ### What information does Check collect? Nothing. We're not even kidding: we don't collect any data at all. You can set up a CIPP reporting server if you'd like, but it reports directly to your own environment. CyberDrain doesn't believe in making its users a product. We don't sell or collect any information. ## How does it look? When the extension is added for a user, a new icon will appear. This icon is [brandable](/settings/branding), allowing you to customize it with your own logo and name.
When you visit a suspicious page but our certainty that it is phishing is too low, we'll show a banner to warn you. If we're sure that the page is an AITM or phishing attack, we'll block it entirely:
This too is completely [brandable](/settings/branding), and can be made to match company colours. The Contact Admin button is a mailto: link that contains the information about what page the user tried to visit, including a defanged URL. # Domain Squatting Detection Domain squatting protection helps keep you safe from fake websites that try to trick you by using look-alike domain names. Attackers create these fake domains to steal your login credentials. ## What is Domain Squatting? Domain squatting (sometimes called "typosquatting") is when attackers register website addresses that are intentionally similar to legitimate sites. For example: * `micros0ft.com` (using a zero instead of the letter O) * `microsоft.com` (using a Cyrillic "о" that looks like an English "o") * `login-microsoft.com` (adding extra words to a real domain) These fake sites often look exactly like the real Microsoft login page, but they're designed to capture your username and password. ## How Check Protects You Check automatically watches for these fake domains using four smart detection methods: ### 1. **Character Difference Detection** Spots domains where characters are changed, missing, or swapped around. **Examples Check catches:** * `microsft.com` → missing the letter "o" * `micorsoft.com` → letters swapped ("or" instead of "ro") * `microosoft.com` → extra letter added ### 2. **Look-Alike Character Detection** Finds domains using special characters that look similar to normal letters. **Examples Check catches:** * `micrоsoft.com` → uses a Cyrillic "о" that looks like an English "o" * `microsоft.com` → mixes different alphabet characters * `micro𝐬oft.com` → uses special Unicode characters ### 3. **Typing Mistake Detection** Identifies domains based on common typing errors and keyboard slip-ups. **Examples Check catches:** * `micrisoft.com` → finger slipped to a nearby key * `microssoft.com` → double-typed a letter * `microosft.com` → transposed letters ### 4. **Suspicious Word Combination Detection** Spots domains that add words before or after legitimate domains to look more official. **Examples Check catches:** * `secure-microsoft.com` * `login-microsoft-verify.com` * `microsoft-auth.com` * `official-microsoft-support.com` Common suspicious words attackers use: `login`, `secure`, `verify`, `official`, `support`, `auth`, `signin`, `portal`. ## What Domains Are Protected? Check protects **30+ popular domains** by default, including: **Microsoft Services:** * microsoft.com, microsoftonline.com, office.com, outlook.com, onedrive.com, and more **Other Popular Services:** * google.com, github.com, facebook.com, amazon.com, apple.com, paypal.com, and more **Plus: Your URL Allowlist** {% hint style="info" %} **Unified Protection:** Check uses your [URL Allowlist](/settings/detection-rules#url-allowlist-regex-or-url-with-wildcards) for double protection. Any domains you add there are automatically protected from squatting attempts too! For example, if you add `https://yourcompany.com/*` to your allowlist, Check will also protect against fake domains like `yourcompany.net` or `your-company.com`. {% endhint %} ## How It Works in Practice When you visit a website, Check automatically: 1. **Checks** whether the domain looks similar to any protected domain 2. **Analyzes** the domain using all four detection methods 3. **Warns** you if it finds a suspicious match 4. **Blocks** the page if it's clearly a phishing attempt You don't need to do anything—the protection works automatically in the background! ## Configuration {% hint style="warning" %} **For most users**: Domain squatting detection works automatically with default settings. You don't need to change anything! {% endhint %} ### Page Blocking Control Check has an **"Enable Page Blocking"** setting in the extension options that controls how suspicious pages are handled. The detection **Action** can be one of three values: `block`, `warn`, or `log`. * **Page Blocking Enabled** + **Action: "block"** = Page is completely blocked with full-page warning * **Page Blocking Enabled** + **Action: "warn"** = Warning banner shown, page remains accessible * **Action: "log"** = Detection is recorded in Activity Logs and (if configured) sent to reporting and webhooks. No banner and no block are shown to the user, regardless of the Page Blocking setting. * **Page Blocking Disabled** = Never blocks. If **Show Notifications** is enabled, a `block` or `warn` action shows a warning banner instead; a `log` action stays silent. This gives you control over whether you want aggressive blocking, visible warnings, or silent monitoring for suspicious domains. ### For Advanced Users and IT Departments Domain squatting detection is configured in your detection rules file (not in the Settings UI). This follows the same pattern as other advanced security features like Rogue Apps Detection. #### How to Configure Edit your `rules/detection-rules.json` file to customize: **Enable/Disable Detection:** ```json { "domain_squatting": { "action": "block" // Action when detected: "block", "warn", or "log" } } ``` **Set Action Type:** ```json { "domain_squatting": { "action": "block" // "block" = full page block, "warn" = banner only, "log" = silent, telemetry only } } ``` Note: Page blocking also requires "Enable Page Blocking" to be turned ON in settings. **Adjust Sensitivity:** "enabled": false } } ```` **Adjust Sensitivity** (how strict the checking is): ```json { "domain_squatting": { "deviation_threshold": 2 } } ```` * Lower numbers (1) = Very strict, catches fewer variations * Higher numbers (3-5) = More lenient, catches more variations * Default is 2 (recommended for most organizations) **Choose Detection Methods:** ```json { "domain_squatting": { "algorithms": { "levenshtein": true, "homoglyph": true, "typosquat": true, "combosquat": true } } } ``` You can turn individual detection methods on or off. We recommend keeping all four enabled for maximum protection. ## For MSPs and Enterprise IT ### Enterprise Policy Management Domain squatting detection can be managed through Group Policy (GPO) or Microsoft Intune, just like other Check settings. **What You Can Control via Policy:** * Detection sensitivity (character difference threshold) * Which detection methods are active * Additional protected domains specific to your organization **What's in the Rules File:** * Enable/disable domain squatting detection * Default protected domains list * Detection rules and patterns This separation gives you flexibility: you control the core security settings through your detection rules file while still allowing policy-based customization for different clients or departments. ### Adding Organization-Specific Domains {% hint style="info" %} **Use the URL Allowlist!** The easiest way to protect your organization's domains is to add them to the URL Allowlist in Detection Rules settings. This automatically: 1. Prevents false positives on your internal sites 2. Protects those domains from squatting attempts 3. Works without modifying detection rules files {% endhint %} **Example:** Adding `https://contoso.com/*` to your allowlist protects against fake domains like: * `cont0so.com` (zero instead of the letter "o") * `contos0.com` (zero at the end) * `login-contoso.com` (suspicious prefix) ### CIPP Reporting and Webhooks Domain squatting detections are automatically reported through your existing Check monitoring: * **Activity Logs**: View all domain squatting warnings and blocks * **CIPP Integration**: Squatting detections appear in your CIPP logbook * **Webhooks**: Configure webhooks to receive `domain_squatting_detected` events See [General Settings](/settings/general) for configuring reporting and webhooks. ## Troubleshooting ### "Check blocked a legitimate site" If Check blocks a site you trust: 1. **Add it to your URL Allowlist** in Detection Rules settings 2. The site will be both allowed and protected from squatting 3. Report the false positive to help improve Check ### "A phishing site wasn't detected" Domain squatting detection works alongside Check's other phishing protections. If a site gets through: 1. Use "Report False Negative" if you encounter a phishing site 2. Check will update rules to catch it in the future 3. Your report helps protect the entire community ### "Settings are grayed out" If you can't see or change domain squatting settings, your IT department has configured these centrally. This is normal for managed deployments—contact your IT team if you need adjustments. ## Related Documentation * [Detection Rules](/settings/detection-rules) - Configure your URL allowlist * [General Settings](/settings/general) - Set up reporting and webhooks * [Enterprise Deployment](https://github.com/CyberDrain/Check/tree/dev/docs/deployment/README.md) - Deploy Check across your organization * [Creating Detection Rules](/advanced/creating-detection-rules) - Advanced rule customization # Chrome/Edge Deployment Instructions This page will outline the various ways that you can deploy Check to your clients' environments across Chrome, Edge, and Firefox Check is available for **Chrome**, **Microsoft Edge**, and **Firefox** with deployment guides for each browser. ## Chrome/Edge Deployment {% content-ref url="/pages/sISL49xdyjkOYaJO3oi0" %} [Windows](/deployment/chrome-edge-deployment-instructions/windows) {% endcontent-ref %} {% content-ref url="/pages/3GZp4vVHilDkbt11ISuU" %} [macOS](/deployment/chrome-edge-deployment-instructions/macos) {% endcontent-ref %} # Windows This page will outline the various ways that you can deploy Check to Windows devices There are several ways to deploy Check to Windows devices. For more information about each method, see the following pages: {% content-ref url="/pages/06VN3PS8Udxi6x95BgPK" %} [Manual Deployment](/deployment/chrome-edge-deployment-instructions/windows/manual-deployment) {% endcontent-ref %} {% content-ref url="/pages/BXg1jIMezIkaKwCGaNe5" %} [Domain Deployment](/deployment/chrome-edge-deployment-instructions/windows/domain-deployment) {% endcontent-ref %} {% content-ref url="/pages/jzpd26NVzDUb13rDYTqS" %} [RMM Deployment](/deployment/chrome-edge-deployment-instructions/windows/rmm-deployment) {% endcontent-ref %} # Manual Deployment {% tabs %} {% tab title="PowerShell" %} **Modify the following script and copy it to your RMM's scripting engine or run the script directly on the endpoint to deploy Check:** {% hint style="info" %} This script is designed to deploy the extension to both Chrome and Edge. We recommend deploying it to both browsers, even if you standardize on one. This provides better protection in case someone uses the non-preferred browser. {% endhint %} 1. Review the Extension Configuration Settings and Custom Branding Settings variables and update those to your desired values. The current values in the script are the default values. Leaving any unchanged will set the defaults. 2. If you are using an RMM that can define variables in its scripting interface, you may be able to remove this section and enter the variable definitions in the RMM instead. 3. For webhook deployment, configure `$enableGenericWebhook`, `$webhookUrl`, and `$webhookEvents` in the script. Supported events are documented in [Webhook Documentation](https://github.com/CyberDrain/Check/tree/dev/docs/webhooks.md). Download the Script from GitHub {% endtab %} {% tab title="Sideload" %} Developers who wish to test their code changes can sideload the extension in their browser. 1. Fork the repository and clone your fork 2. Open `chrome://extensions` or `edge://extensions` 3. Enable **Developer mode** and choose **Load unpacked** 4. Select the repository root to load the extension. Reload the extension after making changes. {% endtab %} {% endtabs %} # Domain Deployment {% tabs %} {% tab title="Intune" %} The simplest method of Intune deployment is through a Win32 script. Follow the steps below to deploy Check with Intune. *** ### Setup Script 1. Download a copy of the Setup-Windows-Chrome-and-Edge.ps1 script from the Check repository on GitHub using the button below. Download script 2. Run the script locally on your computer to generate the following scripts: 1. Deploy-Windows-Chrome-and-Edge.ps1 2. Remove-Windows-Chrome-and-Edge.ps1 3. Detect-Windows-Chrome-and-Edge.ps1 3. The setup script will prompt you to configure Check. Follow its guidance to ensure that you enter each value accurately. These values will be used by both the deployment and detection scripts to verify that the extension is properly deployed. 4. Set the output location the script will use to generate the three new scripts. {% hint style="info" %} You can also download the three scripts directly from the Check GitHub repo and edit the configuration settings manually. {% endhint %} *** ### Adding to Intune #### Prerequisites * Microsoft Intune admin access * The [Microsoft Win32 Content Prep Tool](https://github.com/microsoft/Microsoft-Win32-Content-Prep-Tool) (`IntuneWinAppUtil.exe`) to package scripts as `.intunewin` files #### Step 1: Package the Scripts Intune Win32 apps require an `.intunewin` package. Place your three configured scripts in a folder, then run: ```powershell .\IntuneWinAppUtil.exe -c "C:\path\to\scripts\folder" -s "Deploy-Windows-Chrome-and-Edge.ps1" -o "C:\path\to\output" ``` This creates `Deploy-Windows-Chrome-and-Edge.intunewin`. #### Step 2: Create the Win32 App in Intune 1. Open the [Microsoft Intune admin center](https://intune.microsoft.com) 2. Navigate to **Apps** > **Windows** 3. Click **Add** > Select **Windows app (Win32)** > **Select** 4. Upload the `.intunewin` file created in Step 1 #### Step 3: Configure App Information | Field | Value | | ----------- | ------------------------------------------------------------------------------------------------------------ | | Name | `Check by CyberDrain - Browser Extension` | | Description | `Deploys and configures the Check by CyberDrain phishing protection extension for Chrome and Edge browsers.` | | Publisher | Your company name or `CyberDrain` | #### Step 4: Configure Program Settings | Field | Value | | ----------------------- | --------------------------------------------------------------------------------- | | Install command | `powershell.exe -ExecutionPolicy Bypass -File Deploy-Windows-Chrome-and-Edge.ps1` | | Uninstall command | `powershell.exe -ExecutionPolicy Bypass -File Remove-Windows-Chrome-and-Edge.ps1` | | Install behavior | **System** | | Device restart behavior | **No specific action** | #### Step 5: Configure Requirements | Field | Value | | ----------------------------- | ------------------------------------------------------- | | Operating system architecture | **64-bit** | | Minimum operating system | **Windows 10 1607** (or your minimum supported version) | #### Step 6: Configure Detection Rules 1. Under **Detection rules**, select **Use a custom detection script** 2. Upload `Detect-Windows-Chrome-and-Edge.ps1` 3. Set the following: | Field | Value | | ---------------------------------------------- | ------ | | Run script as 32-bit process on 64-bit clients | **No** | | Enforce script signature check | **No** | Keep **Run script as 32-bit process on 64-bit clients** set to **No** so the detection script runs in the 64-bit PowerShell/registry context on 64-bit devices. This is important because the script checks values under `HKLM:\SOFTWARE\Policies\...`; running it as 32-bit could read redirected `WOW6432Node` paths and cause detection to fail incorrectly. The detection script checks that all registry keys written by the install script exist and have the correct values. It exits with code `0` when everything matches (app detected) and code `1` when any value is missing or wrong (app not detected, triggers reinstall). #### Step 7: Assign the App 1. Under **Assignments**, click **Add group** under **Required** 2. Choose your target: * **All devices** — deploys to every Intune-managed Windows device * **All users** — deploys to devices used by any licensed user * **Select groups** — deploy to specific Azure AD / Entra ID groups 3. Click **Review + create** > **Create** ### Updating Settings When you need to change extension settings (e.g., enable page blocking or update branding): 1. Re-run the setup script with new values, or manually edit the config blocks in both `Deploy-` and `Detect-` scripts 2. Re-package with `IntuneWinAppUtil.exe` 3. In Intune, either update the existing app or delete and recreate it with the new package Because the detection script body changes when settings change, Intune will detect the app as "not installed" on endpoints and automatically redeploy with the updated configuration. ### Uninstalling To remove the extension from managed devices: * **Option A:** In Intune, change the app assignment from **Required** to **Uninstall**. Intune will run the `Remove-Windows-Chrome-and-Edge.ps1` script on targeted devices. * **Option B:** Delete the app from Intune entirely. Note that this stops management but does not actively remove the registry keys from devices that already have them. ### Troubleshooting * **Extension not appearing after deployment:** Check that the install script ran as System (not User). Verify registry keys exist under `HKLM:\SOFTWARE\Policies\Google\Chrome\ExtensionSettings\` and `HKLM:\SOFTWARE\Policies\Microsoft\Edge\ExtensionSettings\`. * **Intune keeps reinstalling the app:** The detection script values don't match what the install script wrote. Ensure both scripts have identical configuration values. * **Detection script shows as failed:** Run the detection script manually on a test device as Administrator to see which check fails (it will exit at the first mismatch). {% endtab %} {% tab title="Group Policy" %} 1. Download the following files from the Check repository on GitHub: 1. ​[Deploy-ADMX.ps1](https://github.com/CyberDrain/Check/blob/main/enterprise/Deploy-ADMX.ps1) 2. ​[Check-Extension.admx](https://github.com/CyberDrain/Check/blob/main/enterprise/admx/Check-Extension.admx)​ 3. ​[Check-Extension.adml](https://github.com/CyberDrain/Check/blob/main/enterprise/admx/en-US/Check-Extension.adml)​ 2. Run `Deploy-ADMX.ps1`. As long as you keep the other two files in the same folder, it will correctly add the available objects to Group Policy. 3. Open Group Policy and create a policy using the imported settings at `Computer Configuration → Policies → Administrative Templates → CyberDrain → Check - Microsoft 365 Phishing Protection`. ![](https://3839320335-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFtDhotz26LyzVUTgqw4L%2Fuploads%2Fri1SKiYvXM5ImKg5lxGP%2Fimage.png?alt=media\&token=96732056-4723-4528-89cb-b9f4f1ec5c5f) {% endtab %} {% tab title="CIPP Standard" %} You can use a CIPP standard to deploy Check. It works the same way as the [#intune](#intune "mention") instructions, but CIPP handles the installation and detection-script creation. For more, see our [Standards documentation](https://standards.cipp.app/standards/deploycheckchromeextension). {% endtab %} {% endtabs %} # RMM Deployment This page will outline the various ways that you can deploy Check to Windows devices Review the following options for deploying Check to Windows devices through an RMM. If you use an RMM that is not listed, see the script in [Manual Deployment](/deployment/chrome-edge-deployment-instructions/windows/manual-deployment#powershell) to automate the installation.
Action1 For Action1, you can save the script in [Manual Deployment](/deployment/chrome-edge-deployment-instructions/windows/manual-deployment#powershell) as a `.ps1` file and deploy it through a [custom package in the software repository](https://www.action1.com/documentation/add-custom-packages-to-app-store/) or the [script library](https://www.action1.com/documentation/script-library/).
Acronis RMM For Acronis RMM, you can use the script in [Manual Deployment](/deployment/chrome-edge-deployment-instructions/windows/manual-deployment#powershell) to [create a script in the Script repository](https://www.acronis.com/en-us/support/documentation/CyberProtectionService/#cyber-scripting-creating-script.html) and then run it through a [Script Plan](https://www.acronis.com/en-us/support/documentation/CyberProtectionService/#cyber-scripting-scripting-plans.html).
ConnectWise Automate 1. Go to **Automation** → **Scripts** → **Script Manager** 2. Create a new script 3. Add a PowerShell Execute Script step 4. Copy in the [Manual Deployment](/deployment/chrome-edge-deployment-instructions/windows/manual-deployment#powershell) script. 5. Save and assign the script to your targeted devices.
Datto RMM 1. Go to **Automation** → **Components** 2. Create a new Custom Component 3. Copy in the [Manual Deployment](/deployment/chrome-edge-deployment-instructions/windows/manual-deployment#powershell) script 4. Save and publish the component 5. Navigate to **Automation** → **Jobs** → **Create Job** 6. Name the job Check Browser Extension Deployment 7. Add the custom component you just created 8. Target your selected device(s) 9. Schedule the job
ImmyBot ImmyBot includes a pre-built Global Computer Task for Check browser extension deployment.\ Due to Immy's flexibility, this may look intimidating at first, but the process is straightforward and almost entirely UI-driven.\ Follow these steps to deploy Check using ImmyBot: **Step 1: Create a Deployment** 1. **Navigate to Deployments** in the left menu 2. Click **New** to create a deployment 3. **Select the Global Task**: Choose "Check by CyberDrain" from the available global tasks 4. **Configure Enforcement Type**: * **Required**: Automatically applies during maintenance sessions * **Onboarding**: Applied only during computer onboarding * **Ad Hoc**: Run only when explicitly triggered 5. **Select Targets**: * **Cross Tenant**: Apply to all computers across all tenants * **Single Tenant**: Apply to computers in a specific tenant * **Individual**: Target specific computers or users * Use filters, tags, or integration-specific targeting as needed **Step 2: Customize Parameters** 1. **Configure Task Parameters** to customize the deployment for your environment: * Set company branding options (company name, logo URL, primary color) * Configure CIPP reporting settings (server URL, tenant ID) * Adjust notification and blocking preferences * Set custom detection rules URL if needed 2. **Set Dependencies** if required (e.g., ensure Windows updates are applied first) 3. **Configure Scheduling** if using time-based deployment **Step 3: Deploy and Monitor** 1. Click **Create** to save the deployment 2. **Run a Maintenance Session** to apply the deployment: * Navigate to the target computers * Initiate a maintenance session to execute deployments 3. **Monitor Results** through ImmyBot's maintenance session logs 4. Review deployment status and address any failures **Best Practices for ImmyBot Deployment** * **Test First**: Create a test deployment targeting a small group before rolling out globally * **Use Targeting**: Leverage Immy's advanced targeting to deploy based on computer properties, user assignments, or custom criteria * **Monitor Compliance**: Set up recurring maintenance sessions to ensure Check remains installed and properly configured * **Handle Exceptions**: Create separate deployments for customers requiring different configurations For detailed information about Immy deployments, tasks, and maintenance sessions, refer to the [ImmyBot Documentation](https://docs.immy.bot).
Kaseya VSA 1. Go to **Agent Procedures** → **Installer Wizards** → **Application Deploy** 2. Upload the [Manual Deployment](/deployment/chrome-edge-deployment-instructions/windows/manual-deployment#powershell) script as a `.ps1` file 3. Choose Private or Shared Files 4. Select installer type 5. Add command-line options 6. Name the procedure Check Browser Extension Deployment 7. Save and schedule the script for deployment
ManageEngine Endpoint Central 1. Navigate to **Manage** → **Extension Repository** 2. Click **Add Extensions** and click the desired browser 3. Select the Web Store Extension Type 4. Enter the extension ID: 1. Chrome: benimdeioplgkhanklclahllklceahbe 2. Edge: knepjpocdagponkonnbggpcnhnaikajg 5. Click **Add** after each 6. Navigate to **Browsers** → **Manage** → **Groups & Computers** 7. Select the custom groups or computers you wish to distribute the extension to 8. Click **Distribute Extensions** 9. Select the extensions you just added to the repository 10. Click **Distribute** {% hint style="warning" %} ManageEngine's documentation is not clear about how to manage the extension settings through this method. It may be necessary to transition to scripted deployment. {% endhint %}
N-able N-Central 1. Go to **Configuration** → **Scheduled Tasks** → **Script/Software Repository** 2. Click **Add** → **Script** 3. Choose: 1. Script Type: **PowerShell** 2. Operating System: **Windows** 4. Upload the [Manual Deployment](/deployment/chrome-edge-deployment-instructions/windows/manual-deployment#powershell) script as a `.ps1` file or paste the script directly 5. Name the script `Check Browser Extension Deployment` 6. Save the script 7. Go to **Configuration** → **Scheduled Task** → **Add Task** 8. Choose **Run a Script** 9. Select the script you just uploaded 10. Configure the task 1. Name: **Check Browser Extension Deployment** 2. Target Devices: Choose specific devices, groups, or filters 3. Schedule: Set your desired interval. We recommend running on login or startup for the best results, but a lower frequency can also ensure deployment to all machines 4. Execution Context: **System Account** 11. Click **Save and Activate**
N-able N-Sight 1. Go to **Settings** → **Script Manager** 2. Click **New** 3. Enter `Check Browser Extension Deployment` for the name and a brief description 4. Set a timeout period for the script of 600 seconds 5. Upload the [Manual Deployment](/deployment/chrome-edge-deployment-instructions/windows/manual-deployment#powershell) script as a `.ps1` file, leaving `Script check and automated task` selected 6. Click **Save** 7. On the **All Devices** view, right-click your targeted Client or Site 8. Select **Task** → **Add** 9. Select the script you just uploaded 10. Enter a name for the task, e.g., ` Check Browser Extension Deployment` 11. Select `Once per day` for the frequency method 12. Set a **Start Date**, **Start Time**, **End Date**, and **End Time** as desired 13. Set a maximum permitted execution time, e.g., 600 seconds 14. Set `Run task as soon as possible if schedule is missed` 15. Select **Next** 16. Select the targeted devices and click **Add Task**
NinjaOne 1. Go to **Administration** → **Library** → **Automation** → **Add** → **New Script** 2. Enter: 1. Name `Check Browser Extension Deployment` 2. Description: To deploy Check by CyberDrain for Edge and Chrome 3. Categories: Select as appropriate for your environment 4. Language: PowerShell 5. Operating System: Windows 6. Architecture: All 7. Run As: System 8. Script Variables: Add as desired to customize 3. Copy the [Manual Deployment](/deployment/chrome-edge-deployment-instructions/windows/manual-deployment#powershell) script into the editor 4. Click **Save** 5. Go to **Administration** → **Policies** 6. Create a new policy or add the automation to an existing policy that targets Windows devices 7. Select **Scheduled Automation** on the left 8. Click **Add a Scheduled automation** button 9. Select the script and set the options for frequency, add variables, etc. 10. Click **Add** 11. Click **Save**
Pulseway 1. Go to **Automation** → **Scripts** 2. (Optional) Create a new **Script Category** called Browser Extensions 3. Click **Create Script** 4. Name the Script `Check Browser Extension Deployment` 5. Toggle **Enabled** under the Windows tab 6. Select **PowerShell** as the script type 7. Paste the [Manual Deployment](/deployment/chrome-edge-deployment-instructions/windows/manual-deployment#powershell) script into the editor 8. Click **Save Script** 9. Navigate to **Automation** → **Tasks** 10. Click **Create Task** 11. Name the task `Check Browser Extension Deployment` 12. Choose the PowerShell script you just added 13. Set the **Scope** to **All Systems** or create a custom scope 14. Set **Daily** for **Schedule** 15. Save the task
SuperOps.ai 1. Navigate to **Modules** → **Scripts** 2. Click **+ Script** 3. Name the script `Check Browser Extension Deployment` 4. Choose **PowerShell** as the language 5. Paste the [Manual Deployment](/deployment/chrome-edge-deployment-instructions/windows/manual-deployment#powershell) script 6. Set a timeout of 600 seconds 7. Choose to run as **System/Root User** 8. Save the script 9. SuperOps has multiple ways to deploy a scheduled action. Review its documentation to choose your preferred method.
Syncro 1. Navigate to the **Scripts** tab 2. Click **+Script** 3. Name the script `Check Browser Extension Deployment` 4. Choose **PowerShell** as the file type 5. Set **Run As** to **System** 6. Copy the [Manual Deployment](/deployment/chrome-edge-deployment-instructions/windows/manual-deployment#powershell) script into the editor 7. Click **Create Script** 8. Navigate to **Policies** 9. Click **+New Policy** 10. Name the policy `Check Browser Extension Deployment` 11. Choose the **Scripting** policy category 12. Click **+Add Entry** 13. Select the script you just created from the drop-down list 14. Select your desired frequency. We recommend running it at least daily. 15. Click **Save Policy**
# macOS We recommend deploying Check through your MDM if the goal is to install it automatically without user interaction. A custom `.mobileconfig` file can be uploaded to most MDMs if they don't have built-in profile-building functionality for Google Chrome or Microsoft Edge. Here's an example XML profile for a mobile configuration that installs Check in Microsoft Edge and Google Chrome. ``` PayloadContent ExtensionInstallForcelist benimdeioplgkhanklclahllklceahbe PayloadDisplayName Google Chrome PayloadIdentifier com.google.Chrome.23E5DDCF-1EB2-4869-9510-5E47D6640A85 PayloadType com.google.Chrome PayloadUUID 23E5DDCF-1EB2-4869-9510-5E47D6640A85 PayloadVersion 1 ExtensionInstallForcelist knepjpocdagponkonnbggpcnhnaikajg PayloadDisplayName Microsoft Edge PayloadIdentifier com.microsoft.Edge.DD4A940A-B216-4D5E-8B2C-1EF2CAFF7F38 PayloadType com.microsoft.Edge PayloadUUID DD4A940A-B216-4D5E-8B2C-1EF2CAFF7F38 PayloadVersion 1 PayloadDescription This profile installs and enforces the 'Check' browser extension from CyberDrain on Google Chrome and Microsoft Edge web browsers. PayloadDisplayName Check CyberDrain PayloadIdentifier 020D4Z7P-7F1A-4723-89CB-1826F8BAF4B5 PayloadOrganization YOUR ORG NAME PayloadScope System PayloadType Configuration PayloadUUID 020D4Z7P-7F1A-4723-89CB-1826F8BAF4B5 PayloadVersion 1 RemovalDate 2044-05-19T21:46:44Z TargetDeviceType 5 ``` You could also deploy it in Chrome from the command line by creating the appropriate JSON object in the correct location under the core `/Library` directory in macOS. Credit goes to @cezaraugusto for the script, which was slightly modified to install Check when no parameter is passed. You can also pass another Chrome extension ID after the script path to install that extension. ``` #!/bin/bash # https://developer.chrome.com/docs/extensions/mv3/external_extensions/#preferences # Credit to #cezaraugusto# from GitHub Gist for this script, slightly modified to install Check by CyberDrain if no parameter is passed # https://gist.github.com/cezaraugusto # https://gist.github.com/cezaraugusto/0101d2cb251c088f398ca0f8d4495ca0 extension=$1 if [[ -z "$extension" ]]; then extension="benimdeioplgkhanklclahllklceahbe" fi install_chrome_extension() { chrome_extensions_folder="/Library/Application Support/Google/Chrome/External Extensions" chrome_extensions_preferences_file="$chrome_extensions_folder/$extension.json" # This URL is used by Chrome to check for updates to external extensions update_services_url="https://clients2.google.com/service/update2/crx" if [[ -d "$chrome_extensions_folder" ]]; then mkdir -p "$chrome_extensions_folder" fi echo "{" > "$chrome_extensions_preferences_file" echo " \"external_update_url\": \"$update_services_url\"" >> "$chrome_extensions_preferences_file" echo "}" >> "$chrome_extensions_preferences_file" echo "Added \"$chrome_extensions_preferences_file\"" } if [ $# -ne 1 ]; then echo "Usage: $0 " exit 1 fi install_chrome_extension "$extension" # Usage: # ./install_extension.sh # Sample: adding React Dev Tools from the command line to Chrome # ./install_extension.sh fmkadmapgofadopljbjfkapdkoienihi ``` This does not install the extension until the next time Chrome is launched. The user will then be required to approve it. SCR-20260520-krbi Due to limitations like this, it is better to deploy the extension through an MDM. If you have experience deploying managed macOS browser extensions, please contribute to the [docs via GitHub](/). All macOS resources in the GitHub repo should be considered inaccurate until tested. # Removal Overview Guides for removing Check enterprise policies and managed settings Use this section to remove Check deployment configuration and managed policies from supported browsers. {% content-ref url="/pages/VlxHsdW8LBivTJKXfM8B" %} [Windows](/removal/removal/windows) {% endcontent-ref %} # Windows Windows removal guidance for Check managed browser configuration Use the pages below to remove Check enterprise settings from Windows endpoints. {% content-ref url="/pages/pCgfN5tghAdpO4CmJgpn" %} [Chrome and Edge](/removal/removal/windows/chrome-edge) {% endcontent-ref %} {% content-ref url="/pages/DuLGNNtFkYSte8mLAMmj" %} [Firefox](/removal/removal/windows/firefox) {% endcontent-ref %} # Chrome and Edge If you need to fully remove Check managed enterprise configuration from Windows endpoints, use the uninstall script instead of manually deleting registry values. This removes all extension-specific policy values created during deployment for both Chrome and Edge, including nested settings such as domain squatting, webhook, branding, and allowlist values. ## Uninstall Script 1. Run the script as Administrator on the target endpoint. 2. Use the script when testing policy changes and you want a clean baseline before redeploying. 3. After running the script, restart Chrome and Edge to ensure that their policies refresh. Download the Uninstall Script from GitHub # Firefox Firefox enterprise removal for Check is managed through the Firefox policies file. ## General Removal Steps 1. Remove Check entries from `%ProgramFiles%\\Mozilla Firefox\\distribution\\policies.json`. 2. Remove extension lock and install directives related to Check. 3. Restart Firefox to apply policy changes. For deployment and policy format details, see [Firefox Deployment](/deployment/firefox-deployment). # General This is where you control the main features of Check. ## Extension Settings ### **Enable Page Blocking** This is Check's main job—blocking dangerous websites. When this setting is enabled, which we recommend, Check will stop you from visiting fake Microsoft login pages and show you a warning instead. You may need to disable it temporarily for testing. Disabling page blocking removes most of your protection, so we recommend leaving this setting enabled. ### Enable CIPP Reporting CIPP is a system that IT professionals use to monitor security across multiple organizations. Enabling CIPP monitoring allows you to send detection information from Check directly to CIPP, allowing you to alert and report on what's happening with your endpoints. When enabled, configure the CIPP Server URL and Tenant ID/Domain below. View CIPP reporting activity in the [Activity Logs](/settings/activity-logs) section. ### **CIPP Server URL** Enter the base URL of your CIPP server for reporting Microsoft 365 logon detections. This should be the full URL to your CIPP instance (e.g., `https://your-cipp-server.com`). This field is only active when CIPP Reporting is enabled. ### **Tenant ID/Domain** Enter your tenant identifier to include with CIPP alerts for multi-tenant environments. You can use either your tenant GUID or your primary domain (e.g., `contoso.onmicrosoft.com` or the tenant GUID). This helps CIPP identify which tenant the alert belongs to when managing multiple clients. {% hint style="info" %} Currently, CIPP displays these alerts in the logbook. Future updates to CIPP are planned to provide additional functionality. Keep an eye on the CIPP release notes for more updates! You can monitor CIPP reporting status and activity in [Activity Logs](/settings/activity-logs). {% endhint %} ### **False Positive Webhook URL** This setting allows you to configure a webhook endpoint that receives false positive reports from users. When configured, a "Report False Positive" button will appear on blocked pages, allowing users to report when Check has incorrectly blocked a legitimate website. Enter the full URL to your webhook endpoint (e.g., `https://your-server.com/api/false-positive`). When a user clicks the "Report False Positive" button, Check will send a POST request with comprehensive detection data to help you review and improve your detection rules. #### Webhook Payload Structure Your webhook endpoint will receive a POST request with `Content-Type: application/json` containing the following fields: | Field | Type | Description | | ------------------ | ------ | -------------------------------------------------------------- | | `timestamp` | string | ISO 8601 timestamp when the report was submitted | | `reportType` | string | Always "false\_positive" | | `blockedUrl` | string | The defanged URL that was blocked (colons replaced with `[:]`) | | `blockReason` | string | User-facing explanation for why the page was blocked | | `userAgent` | string | Complete browser user agent string | | `browserInfo` | object | Browser environment details (see below) | | `screenResolution` | object | Display information (see below) | | `detectionDetails` | object | Complete detection data (see below) | | `extensionVersion` | string | Version of Check that generated the report | **browserInfo object:** * `platform` - Operating system (e.g., "Linux x86\_64", "Win32", "MacIntel") * `language` - Browser language setting (e.g., "en-US") * `vendor` - Browser vendor (e.g., "Google Inc.") * `cookiesEnabled` - Boolean indicating whether cookies are enabled * `onLine` - Boolean indicating network connectivity status **screenResolution object:** * `width` - Screen width in pixels * `height` - Screen height in pixels * `availWidth` - Available screen width (excluding taskbars) * `availHeight` - Available screen height (excluding taskbars) * `colorDepth` - Color depth in bits (e.g., 24) **detectionDetails object:** * `url` - Original URL (non-defanged) * `score` - Legitimacy score assigned by the detection engine * `threshold` - Threshold value that triggered the block * `reason` - Detailed technical reason for blocking * `pageTitle` - Title of the blocked page * `timestamp` - When the page was blocked * `threats` - Array of threat objects with `id`, `type`, `description`, and `severity` * `phishingIndicators` - Array of specific indicators that triggered detection * Additional fields depending on the detection method used #### Complete Payload Example ```json { "timestamp": "2025-11-05T21:30:00.000Z", "reportType": "false_positive", "blockedUrl": "https[:]//example[.]com/login", "blockReason": "This website looks like it has tried to steal your login credentials, to prevent you from logging in we've blocked access.", "userAgent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36", "browserInfo": { "platform": "Linux x86_64", "language": "en-US", "vendor": "Google Inc.", "cookiesEnabled": true, "onLine": true }, "screenResolution": { "width": 1920, "height": 1080, "availWidth": 1920, "availHeight": 1040, "colorDepth": 24 }, "detectionDetails": { "url": "https://example.com/login", "score": 42, "threshold": 50, "reason": "Multiple phishing indicators detected: score 42/50 (3 phishing indicators)", "pageTitle": "Sign In - Example Services", "timestamp": "2025-11-05T21:29:45.000Z", "userAgent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36", "threats": [ { "id": "phi_suspicious_domain", "type": "domain_analysis", "description": "Domain closely resembles microsoft.com", "severity": "high" }, { "id": "phi_fake_login_form", "type": "form_analysis", "description": "Login form mimics Microsoft 365 sign-in", "severity": "medium" } ], "phishingIndicators": [ { "id": "phi_suspicious_domain", "description": "Domain closely resembles microsoft.com", "severity": "high" }, { "id": "phi_fake_login_form", "description": "Login form mimics Microsoft 365 sign-in", "severity": "medium" }, { "id": "phi_suspicious_title", "description": "Page title suggests Microsoft login", "severity": "low" } ] }, "extensionVersion": "1.0.0" } ``` #### Webhook Requirements Your webhook endpoint should: 1. Accept POST requests with `Content-Type: application/json` 2. Respond with HTTP status codes: * `200 OK` - Report successfully received * `4xx` - Client error (user will see error message) * `5xx` - Server error (user will see error message) 3. Respond within 30 seconds to avoid timeout 4. Use HTTPS to protect sensitive detection data in transit {% hint style="info" %} **Usage Notes:** * Leave this field empty if you don't want to enable false positive reporting * The "Report False Positive" button only appears when this webhook URL is configured {% endhint %} ## User Interface ### **Show Notifications** When Check blocks a dangerous website or finds something suspicious, it can show you a small popup message to let you know what's going on. We recommend leaving this setting enabled. ### **Show Valid Page Badge** This adds a small green checkmark to real Microsoft login pages. This feature is optional. ### **Valid Page Badge Timeout** This setting controls how long the "Verified Microsoft Domain" badge stays visible on legitimate Microsoft login pages before it is automatically dismissed. * **Set to 0**: Badge stays visible until you manually dismiss it (no timeout) * **Set to 1-300 seconds**: Badge automatically disappears after the specified number of seconds * **Default**: 5 seconds This allows you to customize the badge experience based on your preferences. If you want to see the badge every time you visit a Microsoft login page, set it to 0. If you prefer it to disappear quickly, use a smaller number like 3-5 seconds. {% hint style="warning" %} #### What if Settings Are Not Visible? If some settings do not appear in your version, it means your organization's IT department has set them for you. This is normal in business environments—your IT team wants to make sure everyone has the same security settings. You will also see text indicating that the extension is being managed by policy. {% endhint %} # Detection Rules This section controls how Check recognizes and responds to phishing threats. Most users can leave these at their default settings, but here's how to manage them. ## Understanding How Detection Works Check uses a constantly updated list of rules to identify fake Microsoft login pages. Think of them like antivirus definitions—they need to be kept current to protect against new threats. ## Detection Configuration ### **Config URL** This field allows you to specify a custom URL for fetching detection rules. Leave this field empty to use the default CyberDrain rules. If your organization provides custom detection rules, enter the full HTTPS URL here (e.g., `https://your-company.com/custom-rules.json`). **For most users:** 1. Leave the "Config URL" field empty or at its default 2. Set "Update Interval" to 24 hours 3. Click "Save Settings" **For organizations with custom security rules:** 1. Enter your organization's custom rules URL (provided by IT) 2. Custom rules, including allowlists, can be created using the [Creating Detection Rules](/advanced/creating-detection-rules) guide. ### **Update Interval (hours)** Controls how often Check fetches updated detection rules. The default is 24 hours. Set the update interval based on your security requirements: * High-security environments: 6-12 hours * Standard environments: 24 hours * Limited bandwidth: 48-72 hours ### **URL Allowlist (Regex or URL with wildcards)** {% hint style="info" %} **Need to allowlist a phishing training service?** MSPs and IT departments commonly need to exclude phishing training platforms (like KnowBe4, Proofpoint, etc.) from detection. Check [Advanced → Creating Detection Rules](/advanced/creating-detection-rules#exclusions) for technical details. {% endhint %} Add URLs or patterns that should be excluded from phishing detection. This is useful for internal company sites or trusted third-party services that might trigger false positives. **Dual Protection:** Your allowlist serves two purposes: 1. **Prevents false positives**—Sites you add won't be flagged as phishing 2. **Domain squatting protection**—Domains extracted from your allowlist are automatically protected against typosquatting and look-alike attacks For example, adding `https://yourcompany.com/*` will both allow that site AND protect against fake domains like `yourcompany.net`, `your-company.com`, or `y0urcompany.com`. Learn more about [Domain Squatting Detection](/features/domain-squatting-detection). **How it works:** Your allowlist patterns **supplement rather than replace** the default CyberDrain exclusions, providing additional protection without losing baseline coverage. You can use: * **Simple URLs with wildcards:** `https://google.com/*` or `https://*.microsoft.com/*` * **Advanced regex patterns:** `^https://trusted\.example\.com/.*` **Copy-paste examples (based on existing default exclusions):** ``` https://*.google.com/* https://*.auth0.com/* https://*.amazon.com/* https://*.facebook.com/* https://training.your-company.com/* https://*.internal-domain.com/* ``` Enter one pattern per line. These patterns are added to the exclusion rules without replacing the entire ruleset from your Config URL. ### Updating Rules Manually Sometimes you need to update rules immediately: 1. **When to do this:** * You've heard about a new phishing campaign * Check isn't detecting a threat it should * Your IT department asks you to update them 2. **How to do it:** * Go to the Detection Rules section * Click "Update Rules Now" * Wait for the "Rules updated successfully" message ## Understanding the Configuration Overview The Configuration Overview section displays your current detection rules in two viewing modes: **Formatted View (default):** * **Version number** - Higher numbers are newer * **Last Updated** - Should be recent (within your update interval) * **Total Rules** - More rules generally mean better protection * **Rule Categories** - Shows a breakdown by rule type (exclusions, indicators, etc.) **Raw JSON View:** * Click "Show Raw JSON" to view the complete detection rules file * Useful for advanced users and troubleshooting * Shows the exact configuration being used by the extension **If you see problems:** * Very old "Last Updated" date → Click "Update Rules Now" * Version shows "Error loading" → Check your internet connection * No rules showing → Contact support {% hint style="warning" %} #### What if Settings Are Not Visible? If some settings do not appear in your version, it means your organization's IT department has set them for you. This is normal in business environments—your IT team wants to make sure everyone has the same security settings. You will also see text indicating that the extension is being managed by policy. {% endhint %} ## Troubleshooting Rule Updates ### **Problem: Rules won't update** 1. Check your internet connection 2. Try clicking "Update Rules Now" again 3. If using a custom rules URL, verify that the URL is correct 4. Contact your IT department if the problem persists ### **Problem: Extension seems slow after rule update** 1. Wait 5-10 minutes for the new rules to fully load 2. Restart your browser 3. If still slow, try updating rules again ## Using the Rule Playground {% hint style="warning" %} Note that the Rule Playground is in beta. Some limitations affect how it handles more complex detection filters, so results may not be identical to the extension's behavior. {% endhint %} The rule playground is your chance to prototype and test detection rules locally. ### Setting Up Candidate Rules There are two ways to build your candidate rules: 1. You can use the `Load Current` button to pull in the configured detection rules for the browser. You can test them as-is or add or edit the rules JSON until you have the candidate rules you want to test. 2. Create a fully custom candidate ruleset. This should be an array. See the format of the default detection rule set for the data structure. Once created, you have additional tools to review your JSON. * [**Validate**](#understanding-the-validation-tool) * [**Sanitize**](#understanding-the-sanitize-tool) * **Copy**: Copies the current JSON to your clipboard. This allows you to paste it into the editor of your choice or use it to create a pull request on GitHub if you are contributing back to the source code. #### Understanding the Validation Tool What it checks: 1. JSON validity * Tries to parse the text. If parsing fails, it shows “Invalid JSON: \” and stops. 2. Overall shape (must be ONE of): * An array of rule objects * An object with a rules array (parsed.rules) * A single rule object that has both id and type * If none match, it will issue “JSON does not look like rule(s) array or object with 'rules'.” 3. For each rule it inspects ONLY these fields: * id: Missing → issue “Rule missing 'id'” * type: Missing → issue “Rule \ missing 'type'” * weight: Present but not a number → issue “Rule \ weight should be number” * description: Missing → suggestion “Rule \ missing description (optional but recommended)” 4. Output: * Issues (blocking problems) listed if any * Suggestions (non‑blocking) listed if any * “No blocking validation issues found.” if zero issues * Displays results panel; does NOT change your JSON What Validate does NOT do * Does not check regex correctness * Does not verify severity/action/pattern semantics * Does not add or remove fields * Does not reformat or reorder anything * Does not merge with stored extension rules #### Understanding the Sanitize Tool What Sanitize actually “fixes” * Only whitespace, indentation, and line structure. What Sanitize does NOT change * Field names, values, types * Order of object properties beyond natural JS enumeration * Array ordering * Missing required fields (`id`, `type`, etc.) * Invalid logic or patterns * It does not validate anything beyond being parseable JSON ### Testing Your Rules Once you have your candidate rules, you can test your ruleset by providing a test URL and sample HTML from that site. You must copy the HTML because the tool will not fetch it from the live site. The URL is needed for the ruleset evaluation. Once you have the test URL and sample HTML, select `Test Rules`. To start a fresh test, select `Clear`. ### Reading the Test Results Below the `Test Rules` button, you will see the output of your candidate rule set with the test URL and sample HTML. * **Decision & Summary**: This provides a high-level overview of the test result, including the decision to allow, warn, or block. * **Threats**: This outlines the rules that identified threats in the sample HTML, along with a snippet of the HTML that triggered the detection. * **Unsupported Features**: This outlines the features that the playground was unable to check because of the complexity of those filters. * **Raw JSON**: This will allow you to view the raw output of the playground's evaluation of the sample HTML. # Activity Logs ## Controls and Configuration The Activity Logs show you everything Check has been doing to protect you. Here's how to use this information effectively. ## Debug and Developer Settings ### **Enable Debug Logging** When enabled, Check logs additional detail about page scans, rule evaluations, and internal operations. By default, Check only logs blocked pages and security events. Enable debug logging when: * Troubleshooting detection issues * Working with support to diagnose problems * Investigating false positives or missed detections **Important:** Debug logging increases storage usage and should be disabled after troubleshooting. ### **Developer Mode** Enables additional console logging visible in the browser's Developer Tools. This provides real-time information about Check's operations for advanced troubleshooting. ### **Simulate Enterprise Policy Mode (Dev Only)** This development-only feature simulates how the extension behaves when managed by enterprise policies. It is useful for administrators testing policy deployments or understanding the end-user experience under policy management. ## Log Filtering and Management ### **Event Type Filter** Filter logs by event type to focus on specific activities: * **All Events** - Shows everything Check has logged * **Security Events** - Threats detected, pages blocked, warnings issued * **URL Access** - Pages Check has analyzed (requires debug logging) * **Threats Detected** - Only shows actual threats found and blocked * **Page Scans** - Detailed scanning activity (requires debug logging) * **Debug Events** - Internal operations and detailed analysis (requires debug logging) ### **Log Actions** * **Refresh** - Reload the current logs from storage * **Clear Logs** - Permanently delete all stored logs (cannot be undone) * **Export Logs** - Download logs as a JSON file for support or analysis ## Reading Your Logs When you open the Activity Logs section, you'll see a table with recent activity. Here's what each column means: * **Timestamp** - When the event happened * **Event Type** - What kind of activity (like "Threat Blocked" or "Page Scanned") * **URL/Domain** - Which website was involved * **Threat Level** - How dangerous it was (None, Low, Medium, High, Critical) * **Action Taken** - What Check did about it * **Details** - A summary of what happened Additionally, clicking a row allows you to review detailed information about the event and the criteria used to determine the threat level. {% hint style="info" %} By default, Check only logs blocked pages. If you want to show valid login pages, check `Enable Debug Logging`. {% endhint %} ### Understanding Common Log Entries **"Page Scanned" with Threat Level "None"** * This is normal—Check scanned a page and found it safe * You'll see lots of these for legitimate websites **"Threat Blocked" with Threat Level "High"** * Check found a dangerous page and blocked it * This is Check protecting you from a real threat **"Legitimate Access" with Threat Level "None"** * Check verified this was a real Microsoft login page * You can trust this page with your credentials ### Investigating Suspicious Activity If you think something suspicious happened: 1. **Look for recent "Threat Blocked" entries** 2. **Click on the entry to expand details** 3. **Check the URL** - Does it look like a site you tried to visit? 4. **Note the time** - Does it match when you had problems? **Example Investigation:** You tried to log in to Office 365 but were blocked. The logs show: * **Timestamp:** 2024-01-15 14:30:22 * **Event Type:** Threat Blocked * **URL:** office365-login-secure.com (suspicious domain) * **Threat Level:** High * **Details:** Phishing page impersonating Microsoft login This shows that Check correctly blocked a fake Office 365 page. ### Configuring Log Detail Level **For regular users:** * Leave "Enable Debug Logging" unchecked * Leave "Enable Developer Console Logging" unchecked * Leave "Simulate Enterprise Policy Mode (Dev Only)" unchecked **For troubleshooting or working with support:** 1. Check "Enable Debug Logging" 2. Reproduce the problem 3. Export logs (see below) 4. Send logs to support (see [Common Issues](/troubleshooting/common-issues) for additional troubleshooting steps) 5. Uncheck debug logging when done (saves storage space) **For admins wanting to simulate the end-user experience:** 1. Click "Simulate Enterprise Policy Mode (Dev Only)" 2. Review behavior, investigate settings, and capture screenshots for documentation 3. Uncheck the setting when done and refresh the page to return to normal operations ### Managing Your Log Data **Refreshing Logs:** * Click "Refresh" to see the latest activity * Useful if you just experienced a security event **Clearing Old Logs:** 1. Click "Clear Logs" 2. Confirm you want to delete all log history 3. **Warning:** This permanently deletes all logs **Exporting Logs for Support:** 1. Click "Export Logs" 2. Choose where to save the file 3. The file will be named like `check-logs-2024-01-15.json` 4. Send this file to support when reporting issues ### Real-World Scenarios **Scenario 1: Checking if Check is working** 1. Go to Activity Logs 2. Look for recent "Page Scanned" entries 3. If you see recent entries, Check is working 4. If no recent entries, try visiting a Microsoft website to test **Scenario 2: Investigating a blocked page** 1. Note the time when you were blocked 2. Go to Activity Logs 3. Look for "Threat Blocked" entries around that time 4. Click the entry to see why it was blocked 5. If you think it was blocked incorrectly, contact support with the log details or check [Common Issues](/troubleshooting/common-issues) for known problems **Scenario 3: Preparing for support** 1. Enable debug logging 2. Try to reproduce the problem 3. Export logs immediately after the problem occurs 4. Disable debug logging 5. Send the exported file to support or check [Common Issues](/troubleshooting/common-issues) first # Branding The Branding section lets you customize how Check looks. This is especially useful for organizations that want consistent branding. {% hint style="info" %} **For individual users** Most individual users can skip this section unless they want to personalize the extension. {% endhint %} ## Overview All user-facing components (suspicious login banner, blocked page, extension popup, and options page) use the same branding configuration. Your custom branding will be displayed consistently across: * **Suspicious Login Banner** - Warning banner shown on potentially malicious sites * **Blocked Page** - Full-page block screen for confirmed threats * **Extension Popup** - Extension icon popup * **Options Page** - Extension settings page ## Company Information {% hint style="warning" %} **What if Settings Are Not Visible?** If some settings do not appear in your version, it means your organization's IT department has set them for you. This is normal in business environments—your IT team wants to make sure everyone has the same security settings. You will also see text indicating that the extension is being managed by policy. {% endhint %} ### Branding Properties You can customize the following properties: 1. **Company Name** - Enter your organization's name. This appears in the extension interface and blocked page messages (displayed as "Protected by \[Company Name]"). 2. **Product Name** - What you want to call the extension (like "Contoso Security" instead of "Check"). This replaces the default "Check" branding throughout the interface. 3. **Support Email** - The email address users should contact for help. This address is used by the "Contact Admin" button when phishing sites are blocked. 4. **Support URL** - URL opened by the popup **Support** link (for example, `https://support.yourcompany.com`). 5. **Privacy Policy URL** (`privacyPolicyUrl`) - URL opened by the popup **Privacy** link (for example, `https://yourcompany.com/privacy`). 6. **About URL** (`aboutUrl`) - URL opened by the popup **About** link. Leave empty to use the built-in extension About page. ## Visual Customization 1. **Primary Color** - Choose a color that matches your brand (hex format, e.g., `#FF5733`). This color is applied to buttons, headers, and other interface elements throughout the extension. 2. **Logo URL** - Link to your company logo or local path (e.g., `https://cdn.example.com/logo.png` or `images/custom-logo.png`). This replaces the default Check logo in the extension popup, options page, and blocked page warnings. ## Live Preview The branding preview shows you exactly how your customizations will appear to users. Changes are reflected immediately as you modify the settings, showing: * Your custom logo and company name in the header * How the primary color affects buttons and interface elements * The overall visual appearance users will see ## Configuration Methods ### Method 1: Manual Configuration (Options Page) **Works with:** Chrome, Edge, Firefox 1. Open the extension's Options page 2. Navigate to the "Branding" section 3. Fill in your branding information: * Company Name * Logo (upload or provide URL) * Primary Color * Support Email * Support URL * Privacy Policy URL * About URL 4. Click "Save" Your branding will be applied immediately to all components. ### Method 2: Group Policy (GPO) - Chrome & Edge For enterprise deployments using Windows Group Policy: 1. Create a new GPO or edit an existing one 2. Navigate to: `Computer Configuration > Administrative Templates > Google Chrome > Extensions` 3. Add a policy for the Check extension with the following structure: ```json { "customBranding": { "companyName": "Your Company", "logoUrl": "https://example.com/logo.png", "primaryColor": "#FF5733", "supportEmail": "security@example.com", "supportUrl": "https://support.example.com", "privacyPolicyUrl": "https://example.com/privacy", "aboutUrl": "https://example.com/about" } } ``` 4. Apply the policy to target computers 5. The extension will automatically use the enterprise branding on managed devices ### Method 3: Firefox Policies (policies.json) **Works with:** Firefox only For Firefox deployments, configure branding through the `policies.json` file: 1. Locate or create the policies file: * **Windows:** `%ProgramFiles%\Mozilla Firefox\distribution\policies.json` * **macOS:** `/Applications/Firefox.app/Contents/Resources/distribution/policies.json` * **Linux:** `/etc/firefox/policies/policies.json` 2. Add the branding configuration under `3rdparty.Extensions`: ```json { "policies": { "3rdparty": { "Extensions": { "check@cyberdrain.com": { "customBranding": { "companyName": "Your Company", "productName": "Security Extension", "supportEmail": "security@example.com", "supportUrl": "https://support.example.com", "privacyPolicyUrl": "https://example.com/privacy", "aboutUrl": "https://example.com/about", "primaryColor": "#FF5733", "logoUrl": "https://example.com/logo.png" } } } } } } ``` 3. Save the file and restart Firefox **Note:** The Firefox extension ID is `check@cyberdrain.com`. ### Method 4: Microsoft Intune - Chrome & Edge For organizations using Microsoft Intune for Chrome and Edge: 1. Create a new Configuration Profile 2. Select "Custom" configuration 3. Add the branding configuration as a JSON payload: ```json { "customBranding": { "companyName": "Your Company", "logoUrl": "https://example.com/logo.png", "primaryColor": "#FF5733", "supportEmail": "security@example.com", "supportUrl": "https://support.example.com", "privacyPolicyUrl": "https://example.com/privacy", "aboutUrl": "https://example.com/about" } } ``` 4. Assign the profile to user or device groups 5. Branding will be applied to enrolled devices ### Method 5: Chrome Enterprise Policy For Chrome Enterprise customers: 1. Access the Google Admin Console 2. Navigate to: `Devices > Chrome > Apps & Extensions` 3. Select the Check extension 4. Add the branding configuration under "Policy for extensions" 5. Save and publish the policy ### Method 6: Windows Registry (Advanced) - Chrome & Edge For direct registry configuration with Chrome/Edge: 1. Open Registry Editor 2. Navigate to: `HKLM\Software\Policies\Google\Chrome\3rdparty\extensions\[extension-id]` 3. Create a new key named `customBranding` 4. Add string values for each branding property 5. Restart the browser ## Configuration Priority When multiple configuration methods are used, they are applied in this order (highest to lowest priority): 1. **Enterprise Policy** (GPO/Intune/Chrome Enterprise/Firefox Policies) 2. **Manual Configuration** (Options page) 3. **Default Configuration** (Built-in defaults) Enterprise policies always take precedence over manual settings. ## Logo Requirements and Tips ### **Technical requirements:** * Format: PNG, JPG, or SVG * Size: 48x48 pixels recommended (maximum 128x128, recommended 200x200px or smaller for enterprise deployments) * Must be accessible via HTTPS URL ### **Design tips:** * Use a square logo for best results * Ensure it looks good on both light and dark backgrounds * Keep it simple—small logos need to be clear ### **Common logo hosting options:** * Your company website: `https://yourcompany.com/logo.png` * Cloud storage: Upload to Google Drive, Dropbox, etc., and get a public link * Image hosting: Use services like Imgur or similar ## Browser-Specific Notes ### Firefox * Uses extension ID: `check@cyberdrain.com` * Configuration is managed through the `policies.json` file * Policies file location varies by operating system ### Chrome & Edge * Configuration is available through GPO, Intune, or Chrome Enterprise Policy * Uses Windows Registry for advanced configurations * Supports standard Chrome extension policy format ## Troubleshooting Branding Issues ### **Logo not showing:** 1. Check that the URL is correct and accessible 2. Try opening the logo URL in a new browser tab 3. Make sure the URL starts with `https://` 4. Verify the image file isn't too large 5. Verify that logo URLs are publicly accessible (if using an external URL) 6. Check the image format (PNG, JPG, and SVG are supported) 7. Ensure image size is reasonable ### **Colors not applying:** 1. Make sure you clicked "Save Settings" 2. Try refreshing the page 3. Check if your organization has locked branding settings ### **Preview not updating:** 1. Try changing the color slightly and changing it back 2. Refresh the settings page 3. Clear your browser cache if problems persist ### **Branding Not Appearing** * Verify the configuration is saved correctly * Check browser console for errors * Ensure logo URLs are accessible * Restart the browser after configuration changes ### **Enterprise Policy Not Working** * Verify the policy is applied to the correct organizational unit * Check that the extension ID matches your deployment * Allow 15-30 minutes for policy propagation * Run `gpupdate /force` on Windows to force policy refresh ## Example Configurations ### **Example 1: Small Business Setup** ``` Company Name: Smith & Associates Law Product Name: Smith Security Support Email: it@smithlaw.com Primary Color: #1f4e79 (professional blue) Logo URL: https://smithlaw.com/images/logo-small.png ``` ### **Example 2: Large Corporation** ``` Company Name: Global Manufacturing Inc. Product Name: GMI Security Suite Support Email: cybersecurity@globalmfg.com Primary Color: #c41e3a (corporate red) Logo URL: https://assets.globalmfg.com/security/gmi-logo-48.png ``` ### **Example 3: Basic Branding (Chrome/Edge)** ```json { "customBranding": { "companyName": "Acme Corp", "primaryColor": "#00AA00" } } ``` ### **Example 4: Full Branding (Chrome/Edge)** ```json { "customBranding": { "companyName": "Contoso Corporation", "productName": "Contoso Defender", "logoUrl": "https://contoso.com/assets/logo.png", "primaryColor": "#0078D4", "supportEmail": "security@contoso.com", "supportUrl": "https://support.contoso.com", "privacyPolicyUrl": "https://contoso.com/privacy", "aboutUrl": "https://contoso.com/about" } } ``` ### **Example 5: Firefox Policy Example** ```json { "policies": { "3rdparty": { "Extensions": { "check@cyberdrain.com": { "customBranding": { "companyName": "Contoso Corporation", "productName": "Contoso Defender", "logoUrl": "https://contoso.com/assets/logo.png", "primaryColor": "#0078D4", "supportEmail": "security@contoso.com", "supportUrl": "https://support.contoso.com", "privacyPolicyUrl": "https://contoso.com/privacy", "aboutUrl": "https://contoso.com/about" } } } } } } ``` # About The About section provides information about your Check installation, version details, and links to important resources. ## Extension Information ### Version Details The About section displays key information about your Check installation: * **Extension Version** - The current version of the Check extension installed in your browser * **Detection Rules Version** - The version of the detection rules currently loaded (from either default or custom source) * **Last Updated** - When the detection rules were last refreshed from their source This information is useful when: * Reporting issues to support * Verifying you have the latest updates * Troubleshooting detection problems ### Product Information **About Check** Check is an advanced browser extension that provides real-time protection against Microsoft 365 phishing attacks. Designed for enterprises and managed service providers, Check uses sophisticated detection algorithms to identify and block malicious login pages before credentials can be compromised. The extension integrates seamlessly with existing security workflows, offering centralized management, comprehensive logging, and CIPP integration for MSPs managing multiple Microsoft 365 tenants. **Created by CyberDrain** CyberDrain is a leading provider of Microsoft 365 automation and security solutions for Managed Service Providers (MSPs) and enterprises worldwide. With a focus on innovation, CyberDrain delivers enterprise-grade tools that streamline Microsoft 365 management and enhance security posture through automation. ## Important Links The About section provides quick access to essential resources: ### Extension Stores * [**Chrome Web Store**](https://chromewebstore.google.com/detail/benimdeioplgkhanklclahllklceahbe) - Download, rate, and review the extension for Chrome and Chromium-based browsers * [**Microsoft Edge Add-ons**](https://microsoftedge.microsoft.com/addons/detail/check-by-cyberdrain/knepjpocdagponkonnbggpcnhnaikajg) - Download and rate the extension for Microsoft Edge * Firefox Add-Ons - Coming soon! ### Development and Support * [**GitHub Repository**](https://github.com/CyberDrain/Check) - View source code, report issues, and contribute to the project * [**CyberDrain Website**](https://cyberdrain.com) - Learn more about CyberDrain's solutions and services # Creating Detection Rules The extension uses a rule-driven architecture where all detection logic is defined in [`rules/detection-rules.json`](https://github.com/CyberDrain/Check/blob/main/rules/detection-rules.json). This file contains: * **Trusted domain patterns** - Microsoft domains that are always trusted * **Exclusion system** - Domains that should never be scanned * **Phishing indicators** - Patterns that detect malicious content (supports both regex and code-driven logic) * **Detection requirements** - Elements that identify Microsoft 365 login pages * **Blocking rules** - Conditions that immediately block pages * **Rogue app detection** - Dynamic detection of known malicious OAuth applications Each rule type has its own schema. You can create a custom rules file and host it anywhere publicly, such as in your own fork of Check's GitHub repository or an Azure Blob. By default, Check loads the CyberDrain rule set from our repository every 24 hours (configurable). Custom rules URLs must be CORS-accessible and return valid JSON matching the schema. **Important:** After updating rules via the UI or changing custom URLs, reload any open tabs for changes to take effect on those pages. The extension loads rules at startup and on the configured interval. You can contribute to our rules through . ## Rule Configuration and Updates Rules are managed by the [`DetectionRulesManager`](https://github.com/CyberDrain/Check/blob/main/scripts/modules/detection-rules-manager.js) class. Its job is to: * Load rules at extension startup * Check for updates based on the configured interval (default: 24 hours) * Cache rules locally in browser storage for offline use * Fall back to local rules ([`rules/detection-rules.json`](https://github.com/CyberDrain/Check/blob/main/rules/detection-rules.json)) if remote fetch fails **Update Process:** 1. Rules are fetched from the configured remote URL, with a fallback to the local file 2. New rules are cached locally and immediately applied 3. A message is sent to notify other extension components of the update 4. Open tabs require a reload to apply the new rules ## Exclusions {% hint style="info" %} **For simple exclusions:** Most users should use the [Settings → Detection Rules](/settings/detection-rules#url-allowlist-regex-or-url-with-wildcards) UI field, which supports both wildcards and regex patterns. This section is for advanced users creating custom rule files. {% endhint %} To exclude domains from all scanning (complete bypass), add them to the `exclusion_system.domain_patterns` array: ```json { "exclusion_system": { "domain_patterns": [ "^https://[^/]*\\.yourdomain\\.com(/.*)?$", "^https://[^/]*\\.trusted-site\\.org(/.*)?$" ] } } ``` ### Pattern Format Use regex patterns that match the full URL: * `^https://` - Must start with HTTPS * `[^/]*` - Match any subdomain * `\\.` - Escaped dot for literal dot matching * `(/.*)?$` - Optional path at the end ### Trusted Domains These domains receive immediate trusted status with valid badges: ```json "trusted_login_patterns": [ "^https://login\\.microsoftonline\\.(com|us)$", "^https://login\\.microsoft\\.com$" ] ``` ## Phishing Indicators The Check extension supports two types of phishing indicators: 1. **Regex-based indicators** - Traditional pattern matching using regular expressions 2. **Code-driven indicators** - Advanced logic-based detection using structured operations ### Regex-Based Indicators Traditional indicators use regular expressions to match patterns in page content: ```json { "id": "custom_indicator_001", "pattern": "(?:suspicious-pattern-here)", "flags": "i", "severity": "high", "description": "Description of what this detects", "action": "block", "category": "custom_category", "confidence": 0.85 } ``` ### Code-Driven Indicators Code-driven indicators allow complex detection logic without regex complexity. Set `code_driven: true` and define your logic in the `code_logic` object: ```json { "id": "phi_example_code_driven", "code_driven": true, "code_logic": { "type": "all_of", "operations": [ { "type": "substring_present", "values": ["microsoft", "office", "365"] }, { "type": "substring_present", "values": ["password", "login"] } ] }, "severity": "high", "description": "Microsoft branding with credential fields", "action": "warn", "category": "credential_harvesting", "confidence": 0.8 } ``` #### Code-Driven Logic Types **1. `substring_present`** - Check if substrings are in the page ```json { "type": "substring_present", "values": ["microsoft", "office", "365"] } ``` **2. `substring_count`** - Require minimum occurrences ```json { "type": "substring_count", "substrings": ["verify", "urgent", "suspended"], "min_count": 2 } ``` **3. `substring_proximity`** - Words must appear near each other ```json { "type": "substring_proximity", "word1": "urgent", "word2": "action", "max_distance": 500 } ``` **4. `multi_proximity`** - Check multiple word pairs ```json { "type": "multi_proximity", "pairs": [ {"words": ["verify", "account"], "max_distance": 50}, {"words": ["suspended", "365"], "max_distance": 50}, {"words": ["secure", "microsoft"], "max_distance": 50} ] } ``` **5. `all_of`** - All conditions must match ```json { "type": "all_of", "operations": [ { "type": "substring_present", "values": ["microsoft"] }, { "type": "substring_present", "values": ["password"] } ] } ``` **6. `any_of`** - At least one condition must match ```json { "type": "any_of", "operations": [ { "type": "substring_proximity", "word1": "urgent", "word2": "action", "max_distance": 500 }, { "type": "substring_proximity", "word1": "immediate", "word2": "attention", "max_distance": 500 } ] } ``` **7. `has_but_not`** - Require some keywords, prohibit others ```json { "type": "has_but_not", "required": ["microsoft", "login"], "prohibited": [ "sign in with microsoft", "sso", "oauth", "third party auth" ] } ``` **8. `pattern_count`** - Count regex pattern matches ```json { "type": "pattern_count", "patterns": ["]*action"], "flags": "i", "min_count": 1 } ``` **9. `obfuscation_check`** - Detect code obfuscation ```json { "type": "obfuscation_check", "indicators": [ "eval(atob(", "Function(atob(", "String.fromCharCode", "setInterval(eval(" ], "min_matches": 2 } ``` **10. `form_action_check`** - Validate form submission targets ```json { "type": "form_action_check", "required_domains": ["login.microsoftonline.com"] } ``` **11. `resource_from_domain`** - Verify resource origins ```json { "type": "resource_from_domain", "resource_type": "customcss", "allowed_domains": ["aadcdn.msftauthimages.net"], "invert": true } ``` **12. `substring_or_regex`** - Fast substring check with regex fallback ```json { "type": "substring_or_regex", "substrings": ["atob(", "unescape(", "eval("], "regex": "(?:var|let|const)\\s+\\w+\\s*=\\s*(?:atob|unescape)\\([^)]+\\)", "flags": "i" } ``` #### Complete Code-Driven Example Here's a real-world example from the detection rules that detects Microsoft branding combined with urgency tactics: ```json { "id": "phi_004", "code_driven": true, "code_logic": { "type": "all_of", "operations": [ { "type": "any_of", "operations": [ { "type": "substring_proximity", "word1": "urgent", "word2": "action", "max_distance": 500 }, { "type": "substring_proximity", "word1": "immediate", "word2": "attention", "max_distance": 500 }, { "type": "substring_proximity", "word1": "act", "word2": "now", "max_distance": 500 } ] }, { "type": "substring_present", "values": ["microsoft", "office", "365"] } ] }, "severity": "medium", "description": "Urgency tactics targeting Microsoft users", "action": "warn", "category": "social_engineering", "confidence": 0.65 } ``` This rule triggers when: 1. Any urgency phrase pair is detected (urgent+action, immediate+attention, or act+now) 2. AND Microsoft branding keywords are present #### When to Use Code-Driven vs Regex **Use Code-Driven When:** * You need to check multiple conditions (AND/OR logic) * Word proximity matters * You want to exclude certain contexts (allowlist patterns) * Performance is important (substring checks are faster than complex regex) * You want rules that are easier to maintain and understand **Use Regex When:** * You have a simple, single pattern to match * You need complex character matching * The pattern is already well-tested as a regex ### Pattern Properties * **id**: Unique identifier for the rule * **pattern**: Regex pattern to match against page content * **flags**: Regex flags (`i` for case-insensitive) * **severity**: `critical`, `high`, `medium`, `low` * **action**: `block`, `warn`, `monitor` * **category**: Grouping category for the rule * **confidence**: Confidence level (0.0 to 1.0) ### Severity Levels * **Critical** (25 points): Immediate blocking threats * **High** (15 points): Serious threats requiring attention * **Medium** (10 points): Moderate threats for warnings * **Low** (5 points): Minor suspicious indicators ### Context Requirements Only trigger if specific context is present: ```json { "id": "context_example", "pattern": "malicious-pattern", "context_required": ["(?:microsoft|office|365|login|password|credential)"] } ``` ### Microsoft 365 Login Page Detection Configure what elements identify a legitimate Microsoft 365 login page: ```json "m365_detection_requirements": { "primary_elements": [ { "id": "custom_primary", "type": "source_content", "pattern": "your-pattern-here", "description": "Custom primary element", "weight": 3, "category": "primary" } ], "secondary_elements": [ { "id": "custom_secondary", "type": "css_pattern", "patterns": ["css-pattern-here"], "description": "Custom secondary element", "weight": 1, "category": "secondary" } ] } ``` ### Element Types * **source\_content**: Match against page HTML source * **css\_pattern**: Match against CSS styles * **url\_pattern**: Match against the URL * **text\_content**: Match against visible text ## Rogue Apps Detection Check includes dynamic detection of known rogue OAuth applications that attempt to steal Microsoft 365 credentials. This feature: * Automatically fetches the latest list of rogue apps from the [Huntress Labs repository](https://github.com/huntresslabs/rogueapps) * Updates every 12 hours by default (configurable in the `rogue_apps_detection` section) * Warns users when they encounter known malicious OAuth applications * Caches data locally for offline protection The rogue apps detection is configured in the `rogue_apps_detection` section of the detection rules: ```json "rogue_apps_detection": { "enabled": true, "source_url": "https://raw.githubusercontent.com/huntresslabs/rogueapps/refs/heads/main/public/rogueapps.json", "cache_duration": 86400000, "update_interval": 43200000, "detection_action": "warn", "severity": "high", "auto_update": true } ``` ## Browser Console Testing Use these functions in the browser console to test your rules: ```javascript // Test detection patterns testDetectionPatterns(); // Test phishing indicators testPhishingIndicators(); // Check rules status checkRulesStatus(); // Analyze current page analyzeCurrentPage(); // Manual phishing check manualPhishingCheck(); // Re-run protection rerunProtection(); ``` **Note:** These console functions are available when the extension is loaded and debug logging is enabled. Use the browser's Developer Tools (F12) to access the console. # Common Issues
Policies not appearing in Group Policy Management Console * Verify that the ADMX/ADML files are in the correct location (see [Windows deployment docs](/deployment/chrome-edge-deployment-instructions/windows)) * Ensure that the files are not blocked (right-click > Properties > Unblock) * Refresh Group Policy Editor For complete deployment instructions, see [Domain Deployment guide](/deployment/chrome-edge-deployment-instructions/windows/domain-deployment).
Policies not applying to extension * Check that the registry values are present (see [Manual Deployment guide](/deployment/chrome-edge-deployment-instructions/windows/manual-deployment)) * Restart the browser after policy changes * Verify that the extension has the necessary permissions For troubleshooting policy deployment, consult the [Windows deployment documentation](/deployment/chrome-edge-deployment-instructions/windows).
Custom branding not working * Verify URLs are accessible via HTTPS * Check that the image format is supported (PNG, JPG, or SVG) * Ensure that color codes use a valid hexadecimal format
# Testing Check Whether you are contributing to the Check repo, developing your own detection rules, or just want to see Check in action, the easiest way is to spin up Evilginx locally on your own hardware. {% hint style="danger" %} We strongly caution against sharing phishing links because some phishing kits in circulation run potentially malicious client-side code. {% endhint %} Instructions for how to spin up Evilginx 3.0 can be found via [this blog post from Jan Bakker](https://janbakker.tech/running-evilginx-3-0-on-windows/).