Why use the ELK Stack for Red Team Infrastructure?

As a red team operator, my priorities are to hit all my objectives and have accurate and complete documentation and screenshots as to how and when I accomplished those objectives. However, when you are working with a team, you never know what may happen to your infrastructure. If you are running containers and those containers get killed, all your logs are immediately lost. Implementing ELK allows us to address my two main concerns and account for anything that could go wrong, including accidentally killing a container with important logs on it.

Opting out of ELK Logging

By default, Terry will deploy filebeat to all nodes in a deployment and logstash to the Lighthouse node. ELK logging can be disabled with the -Ne / --no_elastic flag.

Configuration

All the deployed servers come preinstalled with filebeat. If a deployment contains a Lighthouse, the Lighthouse node will come installed with logstash.

Each of those beats will send their logs to the Lighthouse's logstash instance, which is the deployment's micro-service for shipping all logs in the deployment to the Elasticsearch instance specified in the CLI or configuration file.

Logstash Configuration

The Logstash configuration contains two main files: the runtime configuration and service configuration. Note, this is my own nomenclature, not Elastic's.

The Service Configuration

The service configuration is located at /etc/logstash/logstash.yml and the contents gets populated by the template located at templates/elastic/logstash/logstash.yml.j2.

This file contains all the base config for the Logstash service and even points the service to the Logstash runtime configuration. Generally speaking, you will not need to edit this file.

The Runtime Configuration

The runtime configuration is located at /opt/logstash/logstash.conf and the contents get populated by the template located at templates/elastic/logstash/logstash.conf.j2.

This is the file that may need tweaked based on your needs. By default, the credentials to authenticate to the Elasticsearch instance are added to this file from the ELASTIC_SERVER and ELASTIC_API_KEY environment variables, which get set by Terry at runtime from either an existing env var, CLI argument, configuration file value, or standard input.

The ELASTIC_SERVER should be the FQDN of the Elasticsearch instance OR the IP address of the instance AND port. Do not include the https://.

By default, Logstash will listen on the Nebula interface for connections from the beats installed on the other nodes in the deployment.

Filebeat Configuration

Coming soon!