Burn Detection & OPSEC Intelligence#

InfraGuard continuously monitors for signals that your redirector’s domain or IP has been identified (“burned”) by blue team defenders or security vendors. When burn is detected, alerts fire through the plugin pipeline (Discord, Slack, SIEM) and an optional cooldown pauses C2 traffic.

Components#

The burn detection system has three independent monitors that feed into a central BurnDetector:

Monitor	Source	What It Detects
BurnDetector	Request patterns	Vendor IP spikes, multi-ASN probing, cross-domain analyst recon
CTMonitor	crt.sh API	New certificate issuances for your domains in Certificate Transparency logs
DomainReputationMonitor	URLhaus, OpenPhish, Google Safe Browsing	Domain listings on public threat intelligence feeds

Configuration#

burn_detection:
  enabled: true
  check_interval_seconds: 60

  # Vendor IP spike detection
  vendor_spike_threshold: 10       # blocked vendor requests per window
  vendor_spike_window_seconds: 300 # 5-minute sliding window

  # Multi-ASN probe detection
  multi_asn_probe_threshold: 3     # unique security ASNs probing per window
  multi_asn_window_seconds: 600    # 10-minute window

  # Cross-domain analyst detection
  analyst_domain_threshold: 3      # IPs accessing N+ domains = suspected analyst
  analyst_lookback_hours: 24

  # Automatic response
  cooldown_on_burn: false          # pause C2 traffic when burned
  cooldown_duration_seconds: 300   # 5-minute cooldown

ct_monitor:
  enabled: true
  interval_hours: 6                # how often to poll crt.sh
  domains:                         # domains to monitor (auto-populated from config)
    - "cdn.example.com"
    - "static.example.com"

reputation_monitor:
  enabled: true
  interval_hours: 4
  check_urlhaus: true              # abuse.ch malware host database
  check_openphish: true            # active phishing URL feed
  check_google_safebrowsing: false # requires API key
  google_safebrowsing_api_key: "${GSB_API_KEY}"

Burn Indicators#

Each detection fires a BurnIndicator with a type and severity:

Type	Severity	Trigger
`vendor_spike`	critical	N+ blocked requests from known security vendor IPs within the configured window
`multi_asn_probe`	critical	N+ unique security-related ASNs probing the redirector within the window
`cross_domain_analyst`	warning	Single IP accessing 3+ different domains (analyst recon pattern)
`ct_domain_exposure`	critical	New TLS certificates issued for a monitored domain appear in CT logs
`domain_listed`	critical	Domain found in URLhaus, OpenPhish, or Google Safe Browsing

How It Works#

Vendor Spike Detection#

The BurnDetector maintains a sliding window of blocked requests from IPs in known security vendor CIDR ranges (Shodan, Censys, Rapid7, CrowdStrike, etc.). When the count exceeds the threshold within the window, a vendor_spike indicator fires.

Multi-ASN Probe Detection#

Tracks unique ASN numbers from blocked probes. When 3+ different security-related ASNs probe the redirector within 10 minutes, it indicates coordinated scanning - a strong burn signal.

Cross-Domain Analyst Detection#

Queries the tracking database for IPs that successfully accessed multiple domains. A single IP touching 3+ domains within 24 hours suggests an analyst methodically mapping the infrastructure, not a beacon checking in to its one assigned domain.

Certificate Transparency Monitoring#

Polls crt.sh every 6 hours for new certificate issuances matching your domains. A new cert appearing in CT logs means someone (possibly a threat intel platform) queried CT for the domain - advance warning before active scanning begins. The first poll establishes a baseline; subsequent polls alert only on new issuances.

Domain Reputation Monitoring#

Checks your domains against public threat feeds every 4 hours:

URLhaus (abuse.ch): POST to their API to check if the domain is listed as a malware host
OpenPhish: Downloads the active phishing URL feed and searches for your domains
Google Safe Browsing (optional): Uses the Lookup API v4 to check for MALWARE, SOCIAL_ENGINEERING, and UNWANTED_SOFTWARE listings

Cooldown Mode#

When cooldown_on_burn: true, the redirector enters a cooldown period after a burn detection:

C2 traffic is paused (requests that would normally be allowed are dropped)
The cooldown duration is configurable (default 300 seconds)
The operator can reset the cooldown via the API

This gives the operator time to assess the situation and rotate infrastructure if needed.

API Endpoints#

# Get current burn detection status
curl -H "Authorization: Bearer $TOKEN" https://ig:8080/api/burn/status

# Clear burn indicators (acknowledge and reset)
curl -X POST -H "Authorization: Bearer $TOKEN" https://ig:8080/api/burn/clear

Alert Integration#

Burn indicators are dispatched as synthetic RequestEvent objects through the normal plugin pipeline. Any configured plugin (Discord, Slack, Wazuh, generic webhook) receives burn alerts automatically:

method: "BURN_INDICATOR"
uri: "/_burn_detect"
filter_result: "burn_alert"
filter_reason: "10 blocked vendor requests in 300s window"

For CT monitor alerts:

method: "CT_MONITOR"
uri: "/_ct_alert"
filter_result: "burn_alert"
filter_reason: "Domain 'cdn.example.com' found in CT logs: 2 new cert(s)"