Open_Threat_Research Community

The Mordor project provides pre-recorded security events generated by simulated adversarial techniques in the form of JavaScript Object Notation (JSON) files for easy consumption. The pre-recorded data is categorized by platforms, adversary groups, tactics and techniques defined by the Mitre ATT&CK Framework. The pre-recorded data represents not only specific known malicious events but additional context/events that occur around it. This is done on purpose so that you can test creative correlations across diverse data sources, enhancing your detection strategy and potentially reducing the number of false positives in your own environment.

The name Mordor comes from the awesome book/film series “The Lord of the Rings”, and it was a place where the evil forces of Sauron lived. This repository is where data generated by known “malicious” adversarial activity lives, hence the name of the project.


  • Provide free portable datasets to expedite the development of analytics.

  • Facilitate adversarial techniques simulation and output consumption.

  • Allow security analysts to test their skills with real known bad data.

  • Improve the validation stage of data analytics in a more efficient way.

  • Enable data scientists to have semi-labeled data for initial research.

  • Contribute to the ATT&CK framework Data Sourcess section.

Why Mordor?

Let’s say, it is Monday and you want to start your week by learning about a new adversarial technique and build detections around it. What is the first thing that you do besides reading about the technique? If you do not have a strategy in place, you might end up asking yourself some of the following questions:

  • Do I test the technique right away? If so, how do I prepare for the test? Do I build my own test or use someone else’s? Do I even need to use a command and control framework (i.e Empire, Caldera)? How do I even use a command and control framework? How many technique variants do I test?

  • Do I do it in production? Am I even authorized to execute random tests in production? Do I do it in a lab environment? What do I need in a lab? Do I have the right event log auditing enabled?

  • How do I collect the data generated? Do I filter anything from the event logs to reduce the noise? Do I collect logs from one endpoint only? How do I share the data collected with other team members?

Do you notice that most of the questions are more related to how to produce the data rather than how to start understanding and analyzing the data to build a detection 🏹? You might be going through this without noticing.

What if you could jump straight to the analysis of the data and avoid all the hassle of preparing and setting up everything to simulate an adversarial technique. The main goal of the project is to store and share pre-recorded datasets that you can download and replay right away.

What Do I Get With Each Mordor Dataset?

  • You get the potential relevant events and the extra context produced by other security events that get created during the time window of the log collection.

  • This is valuable if you want to explore other ways to enrich your data analytic and use extra context from events from different data sources.

  • For example, you also get events of the command and control communication from the endpoint which can then be mapped to the specific adversarial technique you are analyzing.

  • In addition, depending on the type of dataset you use, you get more context.

Mordor hosts several datasets and can be split in two categories, small and large datasets.

Small Datasets

  • They are categorized by following the Mitre ATT&CK Framework structure (Platform, Tactic, Technique).

  • They are also organized considering the concept of sub-techniques to provide variations of specific techniques.

  • They represent events that get generated throughout the lifecycle of the specific technique being tested.

  • They lack of context from other techniques that happen in other tactic categories. For example, if mordor data gives you credential dumping sub-techniques, you only get that and not the potential privilege escalation activity that might have been necessary to be able to dump credentials in the first place.

  • Think about them as the results of atomic testing.

Large Datasets

  • They are categorized by known APT groups or custom combination of techniques produced in the mordor lab environments

  • They represent events that get generated throughout the whole attack lifecycle (Initial accesss, discovery, privilege escalation, etc)

  • They have a lot of context to identify relationships across several data sources produced by the execution of several adversarial techniques in one mordor file.

  • They are inspired by the ATT&CK evaluation emulation playbooks