Creating Detection Rules
The extension uses a rule-driven architecture where all detection logic is defined in 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 apps detection - Dynamic detection of known malicious OAuth applications
Each of these rules has their own schema. You can create a custom rules file and host it anywhere publicly (e.g. your own fork of Check's GitHub repo, as an Azure Blob file, etc.). 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.
Contributions to our rules can be done via https://github.com/CyberDrain/Check/blob/main/rules/detection-rules.json
Rule Configuration and Updates
Rules are managed by the DetectionRulesManager class. It's 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) if remote fetch fails
Update Process:
Rules are fetched from the configured URL (remote or fallback to local)
New rules are cached locally and immediately applied
A message is sent to notify other extension components of the update
Open tabs require reload to apply the new rules
Exclusions
To exclude domains from all scanning (complete bypass), add them to the exclusion_system.domain_patterns array:
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 get immediate trusted status with valid badges:
Phishing Indicators
The Check extension supports two types of phishing indicators:
Regex-based indicators - Traditional pattern matching using regular expressions
Code-driven indicators - Advanced logic-based detection using structured operations
Regex-Based Indicators
Traditional indicators use regular expressions to match patterns in page content:
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:
Code-Driven Logic Types
1. substring_present - Check if substrings are in the page
2. substring_count - Require minimum occurrences
3. substring_proximity - Words must appear near each other
4. multi_proximity - Check multiple word pairs
5. all_of - All conditions must match
6. any_of - At least one condition must match
7. has_but_not - Require some keywords, prohibit others
8. pattern_count - Count regex pattern matches
9. obfuscation_check - Detect code obfuscation
10. form_action_check - Validate form submission targets
11. resource_from_domain - Verify resource origins
12. substring_or_regex - Fast substring check with regex fallback
Complete Code-Driven Example
Here's a real-world example from the detection rules that detects Microsoft branding combined with urgency tactics:
This rule triggers when:
Any urgency phrase pair is detected (urgent+action, immediate+attention, or act+now)
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)
Rules 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 regex
Pattern Properties
id: Unique identifier for the rule
pattern: Regex pattern to match against page content
flags: Regex flags (
ifor case-insensitive)severity:
critical,high,medium,lowaction:
block,warn,monitorcategory: 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:
Microsoft 365 Login Page Detection
Configure what elements identify a legitimate Microsoft 365 login page:
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
Updates every 12 hours by default (configurable in
rogue_apps_detectionsection)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:
Browser Console Testing
Use these functions in the browser console to test your rules:
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.
Last updated