Evilginx#

InfraGuard supports two Evilginx operating modes: with a phishlet file (path-aware filtering) and without (full passthrough with campaign token gating).

Config#

domains:
  login.example.com:
    upstream: "${EVILGINX_UPSTREAM}"    # e.g. https://127.0.0.1:4443
    profile_type: "evilginx"
    # profile_path: "/config/wordpress.yaml"   # optional phishlet

    campaign_token:
      enabled: true
      token_param: "t"
      tokens:
        - "${CAMPAIGN_TOKEN_Q1}"
      score_on_missing: 0.9

    drop_action:
      type: "proxy"
      target: "https://login.microsoftonline.com"    # mirror the real site

See config/examples/phishing-evilginx.yaml.

Mode 1: Without Phishlet#

All paths are forwarded to Evilginx. Use allowed_paths to restrict if lure paths are known:

allowed_paths:
  - "/wp-login.php"
  - "~^/[a-z]{8}$"    # 8-char alpha lure path

Mode 2: With Phishlet File#

Set profile_path to a phishlet YAML. InfraGuard parses login_urls and auth_urls fields to extract valid path patterns. Requests to non-phishlet paths score high.

Drop Action: proxy#

Unlike redirect (which sends a 302), proxy type silently fetches the target URL and returns its content. Analysts visiting the login URL see a real Microsoft login page — not a redirect that tips them off.

Pipeline Settings#

pipeline:
  enable_replay_filter: false        # OAuth flows are multi-step
  enable_sandbox_filter: true        # blocks Safe Links, Defender ATP sandbox
  block_score_threshold: 0.65

enable_replay_filter: false is required — Evilginx proxies multiple requests per session, and replay detection would break the OAuth flow after the first request.