# splunk/attack_data is a library of attack logs you can replay into a SIEM

> splunk/attack_data collects curated datasets from real attack simulations, each with a YML file that maps log files to sourcetypes, so a detection engineer can develop and test rules without rebuilding an attack range. The logs are stored in Git LFS and the full pull is more than nine gigabytes, which shapes how you use it.

**splunk/attack_data** — A repository of curated datasets from various attacks

- Repository: https://github.com/splunk/attack_data
- Stars: 834 · Forks: 152
- Language: Python
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/splunk-attack-data

## Detections need data, and data needs a range

The stated purpose of this repository is to make detection work possible without the usual obstacles, and the three bullets in the README say it plainly. It exists so you can easily develop detections without having to build an environment from scratch or simulate an attack, to test detections, specifically Splunk Security Content, and to replay datasets into streaming pipelines for validating your detections in your production SIEM. That third use is the interesting one. In a real deployment, a detection rule is written, deployed, and then quietly sits there until a rule change breaks it or a data source changes shape. A corpus of known attack logs lets you replay the same technique into a live pipeline and confirm that the rule still fires, which turns detection engineering from a hopeful exercise into something you can repeat. The users are detection engineers and Splunk administrators, and the datasets come from a mix of manual attacks and automated simulations.

## Git LFS is the transport, and the volume is the constraint

Everything in this repository is stored in Git LFS, and the README leads with the two setup commands. On a Mac you install git-lfs with Homebrew:

```bash
brew install git-lfs
```

and then configure it so that a clone does not drag every log file down:

```bash
git lfs install --skip-smudge
```

The --skip-smudge flag matters because without it the clone attempts to fetch all of the LFS objects immediately, and the repository is large. The clone itself is:

```bash
git clone https://github.com/splunk/attack_data
```

After that you choose what to fetch. Pulling everything is possible but the README warns that it is more than nine gigabytes of data:

```bash
# This pulls one data set directory
git lfs pull --include=datasets/attack_techniques/T1003.001/atomic_red_team/

# Or pull just one log like this
git lfs pull --include=datasets/attack_techniques/T1003.001/atomic_red_team/windows-sysmon.log
```

That per directory and per file selection is the practical pattern. A detection engineer working on one MITRE technique pulls one technique directory, and a developer who only needs one log pulls one file, so the nine gigabyte figure is a ceiling rather than a floor.

## Each dataset is a YML file that maps logs to sourcetypes

The anatomy section shows what a dataset actually is, and it is a YML document rather than a pile of logs. The example carries an author, an id, a date, a description that names the individual atomic tests that were executed, an environment, a directory, a mitre_technique list, and a datasets block. Each entry in that block names the log, gives its path, and states the sourcetype and the source that the data should be loaded as, for example a crowdstrike_falcon log mapped to sourcetype crowdstrike:events:sensor, and a 4688_windows-security log mapped to XmlWinEventLog with source XmlWinEventLog:Security, alongside a windows-sysmon log mapped to XmlWinEventLog with source XmlWinEventLog:Microsoft-Windows-Sysmon/Operational. That mapping is the reason the metadata exists. When you replay a dataset, the sourcetype tells the SIEM how to parse the events, and without it a Windows event log is just a file of XML that no rule will match.

## Replaying a dataset into Splunk

Most datasets are raw log files, and the README gives two ways to ingest them. The scripted route needs a clone, a virtual environment and the Python dependencies, and the commands are given in full:

```bash
git clone git@github.com:splunk/attack_data.git
cd attack_data
pip install virtualenv
virtualenv venv
source venv/bin/activate
pip install -r bin/requirements.txt
```

Then you download the dataset and run the replay script against the technique directory, for example python bin/replay.py datasets/attack_techniques/T1003.001. The manual route uses the Splunk Enterprise interface. You add data through Files and Directories and select the dataset, set the sourcetype as specified in the YML file, and then explore your data. The installation notes at the top of the README add one constraint that is easy to miss, since these steps are intended to be run on your actual Splunk host or server and not remotely. That is about the path the Splunk instance can see, and it is the kind of detail that turns a ten minute task into an afternoon if the data lands on the wrong filesystem.

## Environments record where the data came from

Alongside the datasets there is an environments/ directory, and the README explains what it is for. Environments are a description of where the dataset was collected, and at the moment there are no specific restrictions, although there is a simple template a user can start from. The most common environment for most datasets is attack_range, since that is the tool that was used to generate attack data sets automatically. Recording provenance in this way is what makes the corpus usable for reasoning. A log captured in a lab range, a log captured during a live red team engagement and a log captured in a production incident are not interchangeable, and a dataset that does not say which one it is leaves the consumer guessing. The attack_range environment is also where the automation story continues, since the same tool both produces the data and the repository documents how it was produced.

## Contributing a dataset, and the service that generates them

The contribute section is a four step procedure. You generate a dataset, then under the corresponding MITRE Technique ID folder you create a folder named after the tool the dataset comes from, for example atomic_red_Team, and you open a pull request containing the YML file for that tool along with the dataset uploaded into the same folder. A complete example is pointed at in the T1003.002 directory. The easiest way to produce a dataset is to launch your simulations in the attack_range, or to attack the machines manually and then dump the data using the dump function that the attack_range project provides. The repository also automates this, since it takes advantage of automation to generate datasets using the attack_range, with the details in the attack_data_service sub-project folder. So there are two routes in: generate data yourself and submit it with metadata, or let the service generate it. The authors listed are Patrick Bareiß and Jose Hernandez, and the licence is Apache 2.0 with Copyright 2025 Splunk Inc.

## TOTAL-REPLAY and what this repository is not

The repository also points at TOTAL-REPLAY, a lightweight tool that helps you make the most of Splunk Security Content metadata such as detection names and analytic stories by replaying relevant test event logs or attack data from either the Attack Data or Attack Range projects, with the details in its own readme. The important boundary is that this repository is data, not detection content. The detections themselves live in the splunk/security-content repository, and the attack data exists to exercise them. That division also explains the operational character of the whole project. There are no GitHub releases, so versions are not the unit of consumption; the last push to the repository was on 2026-10-19 and it is not archived, so the corpus grows continuously. Any pipeline that replays these files should treat the dataset as a moving target and pin the technique directory it needs at the moment of testing rather than assuming a stable release.

## Conclusion

splunk/attack_data suits a detection engineer who needs realistic attack telemetry to develop and test Splunk Security Content rules, and who can afford the disk and the setup time of a Git LFS checkout. It is a poor fit for a team that wants a lightweight sample, since the whole dataset set is more than nine gigabytes and the per technique pull needs Git LFS paths, and it is not a detection content repository in its own right. Verify first that the technique you care about is covered under datasets/attack_techniques, pull only that directory with git lfs pull --include rather than everything, and remember the instructions are meant to be run on the Splunk host rather than remotely.

## FAQ

### How do I install and use splunk/attack_data?

Install git-lfs, run git lfs install --skip-smudge so the clone does not fetch every log, clone https://github.com/splunk/attack_data, then pull the datasets you need with git lfs pull --include pointing at a technique directory or a single log file. The steps are intended to be run on your actual Splunk host or server.

### How do I replay an attack dataset into Splunk?

Either run python bin/replay.py datasets/attack_techniques/T1003.001 after installing the Python dependencies from bin/requirements.txt in a virtual environment, or add the data through the Splunk Enterprise interface with Files and Directories and set the sourcetype specified in the YML file.

### What does the YML file in each dataset do?

It records the author, id, date, description, environment, MITRE technique and a list of logs with their paths, sourcetypes and sources. The sourcetype mapping is what tells Splunk how to parse the log so a detection can match it.

### How large is the full dataset download?

The README warns that pulling all data gives more than nine gigabytes. You can pull a single technique directory or even a single log file with the --include option of git lfs pull.

### How do I contribute a dataset?

Generate the dataset, create a folder named after the tool under the corresponding MITRE Technique ID folder, and open a pull request with the YML file for that tool and the dataset uploaded into the same folder. The simplest way to generate data is to run simulations in attack_range and dump the logs.

## Sources

- [Issues](https://github.com/splunk/attack_data/issues)
- [License: Apache-2.0](https://github.com/splunk/attack_data/blob/master/LICENSE)
- [README](https://github.com/splunk/attack_data/blob/master/README.md)
- [splunk/attack_data on GitHub](https://github.com/splunk/attack_data)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/splunk-attack-data