Rules Engine Guide

The Rules Engine is the heart of Have I Been Squatted’s threat detection system. It allows you to create sophisticated detection patterns that identify potentially malicious domain permutations based on various indicators and heuristics.

Understanding Rules

Rules are detection patterns that define what constitutes suspicious domain activity. Each rule combines multiple conditions and assigns threat likelihood scores across different categories to help you identify potential threats automatically.

What Rules Detect

Rules can identify suspicious domains based on:

• Infrastructure indicators: Hosting providers, geographic locations, ASN patterns
• DNS patterns: Suspicious nameservers, MX records, resolution behavior
• Registration data: Creation dates, registrar patterns, WHOIS information
• Technology fingerprints: Web technologies, certificates, hosting stacks
• Behavioral patterns: Traffic patterns, content analysis, domain relationships

Rule Classification System

Severity Levels

Level	Description	Use Case
critical	Highest severity, immediate attention required	Active threats, confirmed malicious activity
high	High severity, requires timely investigation	Likely threats, suspicious patterns
medium	Medium severity, investigate as appropriate	Potentially suspicious activity
low	Low severity, potentially interesting event	Unusual but not necessarily harmful
informational	Informational event, no action needed	Baseline activity, monitoring

Rule Status

Status	Description	Reliability
stable	Well-tested and reliable rule	Production-ready
test	Rule under testing, might produce false positives	Use with caution
experimental	Rule in early development, likely unstable	Development only
deprecated	Rule no longer recommended for use	Disable or replace
unsupported	Rule is not maintained or supported	Avoid usage

Tip

Rules with stable status and high or critical levels are production-ready and suitable for automated alerting.

Threat Scoring System

Each rule assigns likelihood scores (0-100%) across three threat categories to help prioritize responses:

Scoring Categories

• Malware: Likelihood the domain hosts or distributes malware
• Phishing: Likelihood the domain is used for credential theft
• Impersonation: Likelihood the domain impersonates a legitimate brand

Note

Scoring helps prioritize alerts and automate response workflows. Higher scores indicate greater confidence in the threat assessment.

Creating Custom Rules

Getting Started

Navigate to Monitoring → Rules in your dashboard and click Create Rule to open the rule builder. The creation process is divided into three simple steps:

Step 1: Basic Information

In the first step, provide the fundamental details for your rule:

• Title: A clear, descriptive name for your rule
• Description: Detailed explanation of what the rule detects
• Tags: Categorization labels for organization and filtering
• Level: Choose the appropriate severity level based on the threat
• Status: Set the maturity level (start with test for new rules)

Tip

Use descriptive titles that make it easy to understand what the rule detects at a glance. Good examples: “Domains hosted on suspicious ASN”, “Recently registered domains with suspicious technology stack”.

Step 2: Detection Logic

This is where you define the conditions that will trigger your rule. The visual detection builder allows you to:

Common Detection Patterns

Infrastructure-Based Detection

• ASN numbers associated with malicious hosting (ips.asn.number)
• Geographic locations with high threat activity (ips.country.iso_code)
• Suspicious hosting providers or data centers (ips.asn.organization)

Technology-Based Detection

• Specific web technology combinations (technologies)
• Certificate authorities or SSL configurations (origin_x509.issuer_dn)
• Content delivery networks and hosting stacks (http_banner)

Registration-Based Detection

• Recently registered domains (registration_metadata.registration_date)
• Suspicious registrars or registration patterns (registration_metadata.registrar)
• WHOIS data anomalies and patterns (whois, rdap)

DNS-Based Detection

• Nameserver patterns indicating malicious hosting (dns_ns)
• MX record configurations (dns_mx)
• DNS resolution behavior and patterns (dns_a, dns_aaaa)

Classification-Based Detection

• Machine learning confidence scores (classification.phishing, classification.legitimate)
• Domain similarity metrics (levenshtein_distance)
• Domain age and temporal patterns (created_on)

Building Conditions

Use the visual builder to create detection logic by:

1. Adding Selections: Define groups of conditions that check specific fields
2. Setting Values: Specify what values to match against
3. Combining Logic: Use AND/OR operators to combine multiple conditions

Step 3: Threat Scoring

In the final step, configure the threat likelihood scores for each category:

• Malware Score (0-100%): How likely is this domain to host malware?
• Phishing Score (0-100%): How likely is this domain used for phishing?
• Impersonation Score (0-100%): How likely is this domain impersonating a brand?

Scoring Guidelines

• 80-100%: High confidence threat indicators
• 60-79%: Moderate confidence, requires investigation
• 40-59%: Low to moderate suspicion
• 20-39%: Minimal threat likelihood
• 0-19%: Very low or informational only

Caution

Start with conservative scores and adjust based on real-world performance. It’s better to under-score initially and increase based on validation.

Managing Existing Rules

Global vs User Rules

• Global Rules: Provided by our security team, cannot be modified or disabled
• User Rules: Custom rules you create, fully editable and manageable

Rule Actions

• Enable/Disable: Control whether user rules are active in your monitoring
• Edit: Modify user-created rules to improve performance or reduce false positives
• Delete: Remove user-created rules that are no longer needed
• View Details: See rule logic, scoring, and recent alerts

Best Practices

Rule Design Principles

1. Start Simple: Begin with basic conditions and add complexity gradually
2. Test Thoroughly: Use sample data to validate rule behavior before deployment
3. Document Clearly: Provide detailed descriptions explaining the rule’s purpose
4. Tag Consistently: Use standardized tags for better organization

Avoiding False Positives

1. Be Specific: Use precise conditions rather than broad pattern matching
2. Add Exclusions: Account for legitimate use cases that might trigger the rule
3. Monitor Performance: Regularly review alerts to identify false positive patterns
4. Iterate and Improve: Refine rules based on real-world feedback

Common Use Cases

Infrastructure Monitoring

Suspicious Hosting Providers

# Flag domains on known malicious ASNs
ips.asn.number in [16509, 13335] AND
classification.phishing > 0.5

Geographic Anomalies

# Detect domains hosted outside expected regions
ips.country.iso_code not in ["US", "CA", "GB"] AND
levenshtein_distance < 5

Behavioral Detection

Registration Patterns

# Recently registered suspicious domains
registration_metadata.registration_date > "2024-01-01" AND
registration_metadata.registrar contains "suspicious"

Technology Fingerprinting

# Flag domains using suspicious tech stacks
technologies contains "PhishingKit" OR
http_banner contains "nginx/0.8.5"

Rule Categories & Tagging

Recommended Tag Structure

Use consistent tagging for better organization:

• Category Tags: infrastructure, behavioral, technology, registration
• Threat Type: phishing, malware, impersonation, spam
• Confidence: high-confidence, medium-confidence, low-confidence
• MITRE ATT&CK: attack.initial_access, attack.t1566 (where applicable)

Tip

When you add tags starting with attack., we automatically link them to the corresponding MITRE ATT&CK technique or tactic pages for easy reference.

Standard Categories

• hibs.infrastructure - Infrastructure-based detection
• hibs.phishing - Phishing-specific patterns
• hibs.malware - Malware-related indicators
• hibs.campaign - Campaign-specific detection
• hibs.experimental - Experimental/testing rules

Troubleshooting

Common Issues

Rule Not Triggering

• Verify rule is enabled and has appropriate status
• Check that field names match available data
• Review condition logic for errors
• Test with known positive samples

Too Many False Positives

• Refine selection criteria to be more specific
• Add exclusion conditions for legitimate cases
• Lower severity level or adjust scoring
• Review and update rule description/tags

Signal Reference

For detailed information about all available signals and fields that can be used in rule conditions, see our comprehensive Signals Reference.

Getting Help

For comprehensive rule creation assistance:

• Field Reference: Check our Signals Reference for all available fields
• Examples: Review the rule patterns and examples throughout this guide
• Support: Contact our security team at hello@haveibeensquatted.com for advanced rule optimization

Tip

Start with simple rules and gradually add complexity. Test thoroughly with sample data before deploying to production monitoring.