Thursday, November 5, 2026

InfraGuard for C2 redirector management and red team infrastructure defense

InfraGuard for C2 redirector management and red team infrastructure defense

InfraGuard is a Python-based C2 redirection proxy and infrastructure manager that validates inbound traffic against malleable profiles, deflecting scanners into decoys during authorized red team engagements.

ToolWhispergate/InfraGuard — red team infrastructure tracker and C2 redirector proxy, positioned as a modern alternative to RedWarden
CategoryRed team infrastructure management / C2 traffic filtering proxy
Primary UseFronting a C2 teamserver during authorized engagements, validating inbound requests against malleable C2 profiles while redirecting scanners, bots, and blue team probes to decoy sites
Safe UseFor use exclusively by authorized red team operators running sanctioned engagements, purple-team training labs, and defensive researchers studying redirector tradecraft; the included purple-team mirror and SIEM integrations exist precisely to keep blue teams informed during cooperative exercises
Telemetry NoteIronically for an OPSEC tool, InfraGuard is heavily instrumented: it exposes a Prometheus /metrics endpoint, OpenTelemetry OTLP traces, structlog JSON logs, SQLite tracking of every request, and config-history audit commits — so defenders auditing a shared environment will find a rich, persistent record of all proxy activity

InfraGuard, published at Whispergate/InfraGuard under a BSD-2-Clause license with 331 stars, is a Python-based command-and-control redirection proxy and infrastructure manager that the README explicitly frames as a modern alternative to mgeeky's RedWarden. Its core architectural position is straightforward: it sits between the internet and your C2 teamserver, validating every inbound request against the operator's malleable C2 profile and blocking or diverting anything that does not conform. Scanners, bots, and blue team probes get redirected to a decoy site while legitimate beacon traffic passes through untouched. This is a classic redirector pattern, but the breadth of what InfraGuard layers on top of that pattern — filtering, intelligence, rotation, observability — is what makes it notable.

The proxying layer is more ambitious than a typical nginx front. InfraGuard supports multi-domain proxying, where each proxied domain carries independent C2 profiles, upstreams, and rules, and it runs multi-protocol listeners concurrently: HTTP/HTTPS, HTTP/3 over QUIC, WebSocket, gRPC, DNS, MQTT, and TCP tunnels, all sharing IP intelligence and event tracking. A per-upstream circuit breaker with closed, open, and half-open states protects against dead backends — when upstreams are unreachable, traffic falls through to the domain's configured drop action rather than hanging. Protocol failover and failback, ranked by priority, round out a resilience model clearly designed for long engagements where infrastructure degradation is expected.

Profile support is one of the strongest signals in the README. InfraGuard parses and enforces profiles from Cobalt Strike, Mythic, Brute Ratel C4, Sliver, Havoc, Nighthawk, and PoshC2 as redirector rules, covering effectively the entire commercial and open-source C2 market. Profiles are hot-swappable at runtime from the dashboard without a proxy restart, and a generation wizard can create new profiles from scratch for all eight supported types or import existing ones with automatic type detection and validation. An optional Ollama integration adds a local AI chat panel in the dashboard for profile creation help and OPSEC advice — a sensible choice for a tool whose users are paranoid about cloud telemetry, since local inference keeps prompts off third-party infrastructure.

The filtering engine is scoring-based rather than binary: ten filters — JA3, IP, bot, header, DNS, geo, profile, replay, enumeration, and sandbox — each contribute a score between 0.0 and 1.0, and a configurable threshold decides block versus allow. The individual filters read like a catalog of scanner tradecraft. JA3 TLS fingerprint filtering blocks Masscan, ZGrab2, Shodan, curl, Python requests, and Nmap at the handshake layer before any HTTP data is exchanged, with an optional allowlist mode that enforces the exact beacon JA3. Sandbox and headless browser detection accumulates scores across HTTP signals such as HeadlessChrome user agents, missing Accept-Language headers, Chrome without sec-ch-ua, and non-browser Accept ordering. Path enumeration detection tracks unique URIs per IP in a sliding window to catch dirbuster, ffuf, and gobuster before they map URI space, while DNS subdomain enumeration detection counts NXDOMAIN responses per client IP and auto-blocks on threshold breach. Replay protection rejects duplicate requests by content hash, with hashes persisted to SQLite so the protection survives restarts.

What happens to rejected traffic is itself configurable through drop actions: redirect, TCP reset, proxy to a decoy site, or tarpit — a slow-drip response designed to waste scanner time. The intelligence layer feeds the filters with built-in CIDR blocklists covering 19 security vendor ranges including Shodan, Censys, and Rapid7, plus GeoIP filtering and reverse DNS keyword matching. Auto-updating threat intel feeds pull from abuse.ch, Emerging Threats, Spamhaus DROP, and Binary Defense with configurable refresh intervals and disk caching. Whitelisted CIDRs are automatically enriched with ASN, organization, and country data at startup using the GeoLite2 databases, which Docker deployment handles automatically.

The burn-detection features are where InfraGuard differentiates most from older redirectors. It monitors Certificate Transparency logs via crt.sh, checks domain reputation against URLhaus, OpenPhish, and Google Safe Browsing, and flags cross-domain analyst detection when a single IP touches multiple operator domains. A continuous burn confidence score from 0 to 100 combines six weighted signals — JA3 diversity, volume spikes, new ASNs, CT log exposure, reputation hits, and failed auth attempts — and issues recommended actions: monitor, rotate, or immediate burn. Canary token injection drops tracking pixels, honeypot links, and honeypot forms into decoy pages, each firing a canary_hit event on dedicated /_ig/px, /_ig/hp, and /_ig/hf callback endpoints, so operators know precisely when someone starts investigating their decoys. Passive DNS monitoring via CIRCL PDNS watches for external resolution of operator domains, catching new records and NXDOMAIN spikes.

Payload delivery is treated as a first-class subsystem rather than an afterthought. Content delivery routes can serve payloads and decoys from PwnDrop, the Mythic file store, local filesystem, or HTTP proxy backends, with conditional delivery that serves real content to validated targets and decoys to scanners. The mythic_file backend proxies Mythic's /direct/download/{uuid} endpoint at clean URLs. One-time payload tokens are issued automatically when a beacon is dynamically whitelisted, with atomic single-use enforcement in SQLite to prevent URL replay by analysts or sandboxes, configurable TTL, and max-use counts. Per-route sliding-window rate limiting and delivery guards — beacon IP keying, user-agent allowlists, required and forbidden headers — add further environment checks, and failed checks return the domain drop action rather than a suspicious raw 403.

Resilience features extend to infrastructure lifecycle. One-click blue-green Terraform rotation across five cloud providers includes pre-flight checks, rollback, and age-encrypted state, and rotation can be scheduled on fixed intervals, burn triggers, request-count thresholds, or staggered rolling. An auto-rotation watchdog polls the burn score and certificate expiry, auto-rotating when thresholds trip or certificates near expiry, with a cost-capped alert-only fallback. A dead man's switch halts C2 forwarding if the operator misses a heartbeat check-in, and optional domain fronting routes traffic through CDNs via SNI/Host header splitting with CDN header stripping and SSRF protection. A shared Redis state backend lets horizontally scaled replicas share replay cache, whitelists, and rate limits.

The operator experience is unusually polished. A real-time SPA dashboard streams live requests over WebSocket with domain stats, top blocked IPs, and inline block/whitelist actions; a Textual-based TUI offers a terminal alternative. A Command Post aggregates multiple InfraGuard nodes into one view, with a MapLibre fleet map plotting proxies and blocked source IPs at geolocated coordinates. A plugin marketplace ships 29 built-in plugins — SIEM forwarding to Elasticsearch, Wazuh, and Syslog, alerting to Discord, Slack, PagerDuty, and two-way Telegram ops chat with /status, /sessions, /kill, and /ack commands, plus detection plugins like YARA over request bodies, GreyNoise lookups, JA4 enrichment, and an ML bot classifier built on logistic regression over JA4, user-agent, and timing features. Every plugin toggle persists to config.yaml as a config-history audit commit, no restart required.

From a defensive perspective, InfraGuard is worth studying even if you never run it, because it documents exactly what sophisticated redirectors can observe and counter. The purple-team mirror — which duplicates allowed events to a blue-team collector for engagement scoring — signals that the tool anticipates cooperative use, not just adversarial. Deployment is Docker-first with a Dockerfile and docker-compose including optional Let's Encrypt, GeoIP download, PwnDrop, and Ollama services; a Kubernetes Helm chart under deploy/helm/infraguard/ ships the proxy, dashboard, Redis StatefulSet, and an HPA that scales on the infraguard_active_beacons Prometheus gauge. Configuration supports age and SOPS encryption, .env interpolation with ${VAR} syntax, and a CLI diff validator running 20+ security and TLS checks — a level of configuration hygiene that reflects genuine operational maturity rather than a weekend project.

Official project repository for Whispergate/InfraGuard.
Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Share articleFacebookXLinkedIn

Continue exploring

Browse all articles →

0 comentários:

Post a Comment

Note: Only a member of this blog may post a comment.