RedELK is a red team–oriented SIEM that centralizes operational and redirector traffic logs into Elasticsearch, giving authorized operators oversight and early warning when defenders probe their infrastructure.
| Tool | outflanknl/RedELK — the Red Team's SIEM for operational log aggregation and Blue Team detection |
| Category | Operational security / log aggregation and alerting platform |
| Primary Use | Collecting logs from multiple red team teamservers and redirectors into a searchable Elasticsearch/Kibana stack for historic searching and blue team detection during authorized engagements |
| Safe Use | Intended for legally authorized red team engagements, purple team exercises, and internal labs with written customer permission; also useful for defenders studying attacker-side OPSEC tradecraft |
| Telemetry Note | As a defensive observation tool it ingests redirector traffic and teamserver operational logs; from a defender's viewpoint, its presence signals a mature adversary — blue team detection queries firing back indicates your own defensive reconnaissance was observed |
RedELK, hosted at outflanknl/RedELK and tagged in its own README as "The Red Team's SIEM," occupies a niche that most security tooling ignores: operational awareness for the attacking side of an authorized engagement. With roughly 2,600 stars, a BSD-3-Clause license, and a primary codebase in Python, the project has matured into one of the reference implementations of what its authors call counter-blue-team monitoring. The core premise is simple and well articulated in the README: long-running, multi-operator red team operations generate enormous amounts of operational data, and without central aggregation, that data is scattered across individual teamservers where nobody can query it holistically.
The project defines two headline capabilities. The first is enhanced usability and overview — a central location where all relevant operational logs from multiple teamservers are collected and enriched. The README emphasizes this is valuable for historic searching within an operation, and notably for providing a read-only view on the operation, which the authors suggest can be handed to a White Team. That last detail reveals the tool's pedigree in formal, rules-of-engagement-driven exercises rather than ad hoc testing: a read-only stakeholder view only makes sense when a neutral party arbitrates an engagement.
The second capability is the one that gives RedELK its identity: spotting the Blue Team. By centrally collecting and enriching traffic logs from redirectors — the forwarding infrastructure that sits in front of teamservers — operators can run specific queries to detect that defenders are investigating their infrastructure. This is the "Who watches the Watchmen" theme the authors expanded on in their Hack In Paris 2019 and x33fcon 2019 talks, both linked directly from the README. It is essentially defensive detection logic inverted: the same log analysis a SOC performs, pointed back at the SOC's own reconnaissance activity.
Architecturally, the README's CI badges tell you nearly everything you need to know about the stack before you read a line of documentation. GitHub Actions workflows build separate Docker images for elasticsearch, kibana, logstash, jupyter, and a base image, which maps cleanly onto an ELK-stack deployment where logstash handles ingestion and enrichment pipelines, Elasticsearch stores the indexed operational data, Kibana provides dashboards and query interfaces, and Jupyter presumably supports ad hoc analytical notebooks over the collected data. The repo's topic list — elastic, elasticsearch, kibana, logstash, siem, red-teaming — confirms this is a composition of battle-tested observability components rather than a bespoke analytics engine.
That architectural choice matters for an operator evaluating the tool. Building on ELK means RedELK inherits the entire query, alerting, and visualization ecosystem operators may already know from defensive work, lowering the learning curve considerably. It also means the enrichment model is extensible in a familiar way: new log sources and new detection queries slot into logstash pipelines and Kibana saved searches rather than requiring changes to a monolithic application. The presence of a dedicated jupyter image suggests the authors expect analysts to do exploratory work beyond what canned dashboards offer, which fits the tool's long-operation orientation.
The README is candid about the scale of operations RedELK is built for: multi-scenario, multi-teamserver, multi-member, and multi-month engagements. This is not a tool for a two-day external pentest. The operational-logging side aggregates artifacts the README lists explicitly — screenshots, IOCs, and keystroke output — with the authors cheerfully noting these become "super easy ways" to review. For engagement leads, this consolidation function alone justifies deployment: reconstructing what happened across a three-month, four-operator engagement is otherwise a forensic exercise in itself.
Installation guidance in the README deliberately points to the project wiki for a manual procedure, and lists three externally maintained Ansible options: fastlorenzo/redelk-server and fastlorenzo/redelk-client, both maintained by one of RedELK's own developers, and ansible-redelk maintained by curi0usJack of TrustedSec. The existence of a maintained Ansible path by a core developer is a strong signal that deployment is taken seriously, and the server/client split reflects the architecture — a central RedELK server collecting from agent-style clients running on teamservers and redirectors.
The documentation surface goes well beyond a typical GitHub README. The authors link a three-part blog series from Outflank — covering the rationale, getting running, and achieving operational oversight — plus four conference presentations spanning BruCon 2018 through SANS Hackfest 2020. This body of material matters because the harder half of RedELK, detecting blue team activity, depends on query logic and OPSEC reasoning that cannot be summarized in a README; the talks, particularly the x33fcon material on catching Blue Team OPSEC failures, are where that tradecraft lives.
The maintainer roster is another quality signal: Marc Smeets, Mark Bergman, Lorenzo Bernardi, and Geert Smelt are all credited, with Bernardi maintaining the Ansible deployment discussed above. Active contribution invitations cover code, alarm ideas, and usability improvements — the explicit mention of "alarms" as a contribution category tells you detection content is treated as a living dataset rather than a static feature set, which is the right model for a detection platform that must keep pace with evolving defender tradecraft.
For defenders, RedELK is worth studying precisely because it documents how a disciplined adversary watches back. The core defensive lesson embedded in the tool's design is that every action a blue team takes against attacker infrastructure — probing redirectors, fingerprinting domains, repeated connections from analyst egress ranges — leaves a signature in traffic logs. The x33fcon talk linked in the README is essentially a catalog of such OPSEC failures, and purple teams can use RedELK's alarm concepts in reverse: if the red team's SIEM can detect your investigation, your investigation needs to be quieter or routed through infrastructure that does not correlate.
Within an authorized workflow, RedELK sits on the red team's own infrastructure — it ingests the operator's logs, not the target's — which keeps its use firmly within engagement-owned systems. Deployment belongs on a dedicated server the team controls, ideally deployed via the Ansible playbooks, with access to the Kibana interface segmented so operators get operational views and any White Team stakeholders get the read-only view the README describes. Treat it as engagement infrastructure to be spun up per-operation rather than a persistent service, and scope log retention to the engagement window. As a piece of engineering, RedELK is one of the clearest public demonstrations that modern red teaming is, at its core, a data problem — and that the teams solving it well are the ones borrowing directly from blue team tooling.
outflanknl/RedELK.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.