RedELK is a red team's SIEM — an Elasticsearch, Logstash and Kibana based system that collects operational logs from red team teamservers and traffic logs from redirectors into one enriched central location, built for red team operators and for the white teams that need oversight of long-running engagements.

What it is

RedELK is a Python tool that lives in the Elastic/Elasticsearch, Logstash and Kibana ecosystem and turns that stack into a monitoring and observability platform aimed at offensive operators rather than defenders. It ingests two kinds of data: operational logs from multiple teamservers, and traffic logs from redirectors. Both are enriched at collection time, so a single central location holds the full operational picture instead of scattered per-server logs.

The concrete problem it solves is the loss of visibility that comes with scaled-up adversary simulation. Once an engagement spans several scenarios, several teamservers, several operators and several months, no individual operator can hold the history, and no white team member can audit it. RedELK replaces ad hoc log grepping and manual teamserver inspection with enriched, queryable history, and it additionally gives red teams a way to notice that the blue team has started investigating their infrastructure by querying collected redirector traffic.

Key capabilities

• Central collection and enrichment of operational logs from multiple teamservers, supporting historic searching across multi-scenario, multi-teamserver, multi-member and multi-month operations.
• Traffic log collection and enrichment from redirectors, with specific queries intended to detect blue team investigation of red infrastructure.
• Fast viewing of screenshots, IOCs and keystrokes output gathered from the operation.
• A read-only view of the operation suitable for a white team.
• Docker images built for the base system plus Elasticsearch, Kibana, Logstash and Jupyter, each with its own GitHub Actions build workflow.
• Kibana-based search and dashboards over the enriched indices, consistent with the project's kibana and elasticsearch topics.
• Deployment automation provided through Ansible playbooks for both server and client roles.

Who uses it and how

• Red team operators running campaigns that involve more than one teamserver, so that logs from all of them land in one searchable place.
• White teams that need a read-only view of ongoing operations without direct access to teamserver consoles.
• Long engagements measured in months, where historic searching matters more than real-time alerting.
• Infrastructure teams deploying the server and client roles through Ansible playbooks: redelk-server and redelk-client, maintained by one of RedELK's developers, or ansible-redelk, maintained by curi0usJack/TrustedSec.
• Teams that need to review all captured screenshots, IOCs and keystroke output in bulk rather than one host at a time.

Getting started

The README points to the project wiki for manual installation, and notes Ansible playbooks maintained by others for the server and client roles. Docker images for the base system, Elasticsearch, Kibana, Logstash and Jupyter are built by the project's own GitHub Actions workflows.

How it compares

No list of paid products that RedELK replaces is provided in the available facts, and no directly comparable red-team SIEM is named. It stands alone in this registry, since the Elasticsearch, Kibana and Logstash components it is built on are dependencies rather than substitutes.

When to use it — and when not to

A self-hoster must operate the full Elasticsearch, Logstash and Kibana stack, plus the Jupyter image, and must arrange log shipping from every teamserver and redirector that matters. Teams with a single teamserver, no redirectors, or no need for historic operational search get little from it, and blue-team-only organisations have no reason to run it. The main weakness visible in the facts is documentation shape: the README defers installation entirely to the wiki and to third-party Ansible playbooks, so the initial setup is not self-contained in the repository.