RedELK: A Red Team SIEM Built on the Elastic Stack

The operational gap RedELK fills for red teams

A long engagement produces logs in places that do not talk to each other. Each teamserver keeps its own history, each redirector keeps its own traffic records, and the operator's view of the operation is whatever is still open in a terminal. RedELK addresses that by creating a central location where operational logs from multiple teamservers are collected and enriched, and a second central location where traffic logs from redirectors are collected and enriched. The README frames the first as an overview problem and the second as a detection problem: the same stack that lets an operator search historic activity is also what lets them notice that the Blue Team is investigating their infrastructure. The intended audience is narrow. The README describes multi-scenario, multi-teamserver, multi-member and multi-month operations as the case where the tool pays off, and mentions a read-only view for a White Team. A single operator running one teamserver for a week gets little from it.

How the Elastic Stack is wired together

The repository layout makes the architecture legible without reading the source. There are separate top-level directories for elkserver, c2servers and redirs, which matches the two log sources in the README: command and control servers on one side, redirectors on the other. The elkserver directory is the central deployment, and the CI badges in the README name five container images built from the repository: a base image, elasticsearch, kibana, logstash and jupyter. That is a conventional Elastic pipeline. Logstash receives and enriches events, Elasticsearch stores and indexes them, Kibana provides the search and dashboard layer, and Jupyter is available for analysis that does not fit a Kibana query. The enrichment step is what turns raw teamserver output into something searchable across servers, and it is also where the project's assumptions live: the field mappings and log formats are tied to the tools the project expects to receive logs from. The README does not document the enrichment rules themselves; it points to the wiki.

Installing RedELK from the wiki and the first search

The README's installation section does not contain steps. It says to check the wiki for the manual installation manual, and then lists three Ansible playbooks maintained outside the repository: a RedELK server playbook and a RedELK client playbook, both attributed to one of RedELK's developers, and ansible-redelk, attributed to curi0usJack/TrustedSec. Those are the supported paths the README names, so start there rather than inventing a container workflow. The repository also carries an initial-setup.sh script at the top level and an example-data-and-configs directory, which is where you should look for the shape of the configuration before you write your own.

git clone https://github.com/outflanknl/RedELK.git
cd RedELK
cat VERSION

Cloning the repository and reading VERSION tells you which line of the project you are on. The README does not state what the file contains, so treat it as the authoritative marker for your checkout rather than a release announcement.

ls example-data-and-configs
ls elkserver

Listing those two directories shows the example configuration and the server-side deployment layout. Use the example configs as the starting point for your own, because the README gives no schema of its own.

Once the stack is up, the first real use is a search across collected teamserver logs in Kibana, followed by the redirector traffic search that the README describes as the way to detect Blue Team investigation of your infrastructure. The README does not publish the specific queries; it says specific queries make that detection possible and leaves the query text to the wiki. Budget time for that step, because it is the part of the workflow the README does not hand you.

Where RedELK is the wrong tool

RedELK assumes you are willing to run and defend an Elastic Stack. That is a large amount of infrastructure for a red team, and it is itself a target: a central store of operational logs is exactly the thing an engagement's OPSEC plan has to account for. The project is also opinionated about inputs. The collection side is built around teamservers and redirectors, and the README describes enrichment in terms of the logs those components produce, so a team using a toolchain outside that model will spend its effort writing parsers rather than searching. The release history is the sharpest limitation. The most recent tagged release is v2.0.0-beta.6 from 2022-02-20, preceded by v2.0.0-beta.5 and v2.0.0-beta.4. There is no stable 2.0 tag in the release list, and the README's own installation pointer goes to the wiki rather than to a packaged release. The repository's last push was on 2026-09-23, so work is happening, but the tag you would pin to is years old and still labelled beta. If your process requires a supported, versioned release, this is not it.

RedELK against a general-purpose SIEM

The obvious alternative is a general SIEM you already run, with the teamserver and redirector logs shipped into it as another data source. The difference is in what the enrichment is built for. A general SIEM gives you a query language, retention controls and an existing on-call process, but its content is written for defenders looking at enterprise telemetry, and its detections assume the organisation is the victim. RedELK inverts that: the README's second goal is spotting the Blue Team, so the queries and alarms are aimed at the adversary's own infrastructure rather than at the estate. The practical consequence is that you can reach the same raw data either way, but only one of the two ships with the analyst workflow for a red team operation already in mind. If your team already has a SIEM with spare ingest and an analyst who enjoys writing parsers, the case for a second stack weakens considerably. If not, RedELK is the shorter path to a searchable operation history.

Maintenance, upgrades and the licence

Upgrade cost depends on which line you run. The tagged releases stop at v2.0.0-beta.6 from 2022-02-20, while the repository's last push was on 2026-09-23, which means the code and the release tags have drifted apart. The develop branch is the one the CI badges for elasticsearch, jupyter, kibana and logstash reference, so anyone tracking fixes is tracking a branch rather than a release. That is a real operational decision, not a footnote: pinning the beta tag gives you a reproducible version with no recent fixes, and following develop gives you recent fixes with no version to pin. Three Ansible playbooks are maintained outside the repository, two by a project developer and one by a third party, so their state is not governed by the project's own release cycle. On licensing, the repository is BSD-3-Clause, which permits commercial and closed-source use and requires that the copyright notice and licence text be retained; the README does not discuss trademark or redistribution terms, and the Elastic components RedELK deploys carry their own licences, which you should check separately. None of this is legal advice.

Editorial conclusion

Adopt RedELK if you run multi-teamserver, multi-month red team operations and already accept the cost of running an Elastic Stack for your own logs. Do not adopt it if you need a supported release with a stable tag, or if you cannot dedicate a host to Elasticsearch, Logstash and Kibana. Before committing, read the wiki install manual end to end and decide whether you are willing to run the 2.0 beta line, because the newest tagged release, v2.0.0-beta.6, dates from 2022-02-20 and the repository's own installation section points only at the wiki.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. outflanknl/RedELK on GitHub
4. README
5. Releases