A curated community wiki that documents how professional red teams design, segregate, and defend their engagement infrastructure, written for authorized operations and defensive research alike.
| Tool | bluscreenofjeff/Red-Team-Infrastructure-Wiki — a community-maintained wiki of red team infrastructure design and hardening resources |
| Category | Knowledge base / tradecraft reference (BSD-3-Clause, ~4.5k stars) |
| Primary Use | Planning functionally-segregated, redirector-fronted engagement infrastructure for Cobalt Strike and Empire operations in authorized assessments |
| Safe Use | Reference material for authorized red team engagements, purple-team training, and defensive teams studying attacker infrastructure patterns; it contains no executable code |
| Telemetry Note | The wiki itself is passive documentation; defenders gain value from it as a map of the redirector, domain-reputation, and categorization techniques that blue teams should monitor (socat listeners, mod_rewrite rules, expired-domain registrations) |
Red-Team-Infrastructure-Wiki, maintained under bluscreenofjeff, is not a tool in the executable sense but a structured knowledge repository, and that distinction matters for how you consume it. At roughly 4,500 stars and released under a BSD-3-Clause license, it has become one of the canonical reference points for professionals who design and operate engagement infrastructure. The wiki originated as a companion to the BSides NoVa 2017 talk "Doomscreen Preppers: Fortifying Your Red Team Infrastructure" by Steve Borosh (@424f424f) and Jeff Dimmock (@bluscreenofjeff), and it remains open to community contributions via pull requests, which explains how it has stayed current across shifts in tradecraft.
The core architectural thesis of the wiki is functional segregation. For engagements expected to withstand active incident response over weeks, months, or years, the authors argue that each asset should be separated by function — phishing SMTP, phishing payload hosting, long-term C2, and short-term C2. The reasoning is purely operational economics: when one campaign asset gets detected, a properly segregated design means the operator replaces only the burned component rather than rebuilding an entire team server. Because every social engineering campaign typically needs its own fresh set of assets, the wiki treats per-campaign infrastructure provisioning as the baseline assumption rather than an exception.
The second pillar is the redirector pattern. Every back-end asset — a team server, in the Cobalt Strike idiom — should sit behind an intermediary host so that there is always a hop between the target environment and the real infrastructure. The wiki's stated payoff is again resilience: when a redirector burns, standing up a replacement is fast, and there is no need to migrate sessions or reattach unburned back-end systems. It catalogs the common redirector types (SMTP, payloads, web traffic, and C2 over HTTP(S) or DNS) and notes that redirectors can live on VPS instances, dedicated servers, or even PaaS applications, which is a detail defenders should internalize when reasoning about where hostile egress endpoints actually reside.
The redirector implementation section is where the wiki earns its reputation for density. It walks through sendmail and postfix for SMTP redirection — including stripping previous server headers and configuring a catch-all address — and covers socat, iptables, and ssh-based techniques for DNS and HTTP(S) forwarding. A dedicated subsection compares socat versus Apache mod_rewrite for HTTP redirection, and further entries cover C2 redirection with HTTPS and payload hosting. Notably, this material doubles as a detection curriculum: every technique documented here maps to observable artifacts such as listener processes, rewrite rules, and forwarding chains that a defender can hunt for.
A substantial domain-selection section addresses the reputation problem that dominates modern egress filtering. The wiki is candid that choosing a domain that will pass a target's controls is not an exact science, and that OSINT is critical to estimating which categorization services matter. It describes using expireddomains.net to acquire aged, previously-registered domains, and points to helper tools like CatMyFish, DomainHunter, and AIRMASTER that automate expired-domain searches against categorization databases such as BlueCoat. DomainHunter additionally checks IBM X-Force and Cisco Talos categorization, Archive.org history, and prior malware or phishing association. For defenders, this section is essentially a field guide to how hostile domains are sourced and groomed before an engagement begins.
The wiki also curates an extensive list of categorization and blacklist-checking resources — McAfee SiteLookup, FortiGuard, BlueCoat SiteReview, Checkpoint, Palo Alto URL filtering, TrendMicro, Brightcloud, Websense/Forcepoint, SenderBase, and MXToolBox blacklists. From a purely defensive standpoint, this list is useful in the other direction: it tells blue teams exactly which reputation surfaces an adversary will probe before committing to a domain, and it reinforces the wiki's own cited observation (via Dominic Chell's "categorisation is not a security boundary") that category checks are heuristic, not a control boundary.
Later sections broaden from mail and web plumbing into C2 traffic modification for both Cobalt Strike and Empire, third-party C2 channels including domain fronting and PaaS-based redirectors, and dedicated chapters on obscuring and securing infrastructure. There is also an automation section that references contemporary work such as Rasta Mouse's Terraform-based deployment writeups, reflecting the industry shift toward treating engagement infrastructure as disposable, versioned code rather than hand-built servers. The "General Tips" and contributor acknowledgments round out a document that reads more like a living field manual than a static blog post.
What the README reveals about the project's architecture is, in the end, its editorial model: it is a curation layer over a decade of community writing — Raphael Mudge's distributed operations posts, Black Hills information security walkthroughs, and numerous practitioner blogs — organized into a coherent design methodology. There is no install, no binary, and no configuration format; the value is entirely in the taxonomy of decisions (segregation, redirection, reputation, automation) and the linked primary sources behind each one. That makes it equally valuable to a junior operator building their first lab and to a detection engineer studying how adversary infrastructure is typically layered.
For authorized use, the wiki fits naturally into engagement scoping, purple-team exercises, and internal training programs, and its phishing-setup sections — which describe mail-server builds around iRedMail, RoundCube, and proper DKIM/DMARC records — are best read as documentation of what a competent adversary's mail stack looks like, informing both authorized simulation planning and email-security tuning. As with any tradecraft reference of this breadth, professionals should treat it as educational material for systems and engagements they are explicitly authorized to operate, and as an intelligence source for the defensive side of the house.
The honest caveats are age and drift: the document is anchored in a 2017 talk, and some linked services (BlueCoat categorization flows, specific tool repos) have changed or vanished since. The fundamentals it teaches — segregation by function, redirector indirection, domain reputation management, disposable automation — have aged well precisely because they are architectural principles rather than version-specific tricks. For anyone who builds or defends engagement infrastructure, Red-Team-Infrastructure-Wiki remains a high-signal starting point and a durable map of the terrain on both sides of the operation.
bluscreenofjeff/Red-Team-Infrastructure-Wiki.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.