<figure><img src="image_1.png" /></figure>

HAL
open science

# Get out of DEDALE with RESCOUSSE: a New Dataset and Testbed for Evaluating the Detection of APT attacks among Network and System Logs

Maxime Lanvin, Frédéric Majorczyk

<figure><img src="image_2.png" /></figure>

## To cite this version:

Maxime Lanvin, Frédéric Majorczyk. Get out of DEDALE with RESCOUSSE: a New Dataset and Testbed for Evaluating the Detection of APT attacks among Network and System Logs. ANUBIS 2025 - Assessment with New methodologies, Unified Benchmarks, and environments, of Intrusion detection and response Systems, Sep 2025, Toulouse, France. pp.1-21. hal-05329482

HAL Id: hal-05329482

https://hal.science/hal-05329482v1

Submitted on 27 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_3.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Get out of DEDALE with RESCOUSSE: a New
Dataset and Testbed for Evaluating the Detection
of APT attacks among Network and System Logs

Maxime Lanvin¹[0009-0001-0368-2153] and Frédéric Majorczyk²[0009-0008-9558-397X]

¹ CentraleSupélec, Univ. Rennes, IRISA, Rennes, France
maxime.lanvin@centralesupelec.fr

² DGA-MI, Univ. Rennes, IRISA, Rennes, France
frederic.majorczyk@intradef.gouv.fr

**Abstract.** High-quality data is required to design and evaluate Intrusion Detection Systems (IDSes). However, the currently publicly available datasets are often considered unrealistic and unrepresentative of advanced attacks. Moreover, many errors were recently identified in some network intrusion detection datasets. Even well-known and widely used datasets such as CICIDS2017 have recently been criticized for their poor quality. Another issue with those datasets is that they tend to become quickly outdated. In this work, we propose and share a new testbed named RESCOUSSE and a new dataset named DEDALE. RESCOUSSE can be used to generate new datasets; it is based on an existing testbed that we improved deeply. In particular, we fix the errors and biases we identified in the currently available datasets. DEDALE is a new dataset generated with RESCOUSSE. The dataset lasts one month: the first two weeks contain only benign activities, a discrete APT attack is spread over eight days from the third week, and the remaining six days are free of attacks and can be used to evaluate the false positive rate. The dataset contains both network and system logs, which allows the design and evaluation of Host and Network IDSes, as well as correlation techniques. We label both the system and network logs and check that no obvious biases exist in the network logs. Since RESCOUSSE is open source, it allows other researchers to replicate DEDALE and correct some errors that they may find if needed.

**Keywords:** Intrusion detection · APT attacks · Dataset · Testbed

# 1 Introduction

In cybersecurity, Intrusion Detection Systems (IDS) are tools that monitor network and/or host activity to detect attacks as soon as possible. High-quality datasets are required to design and evaluate these tools. In particular, the benign activity, the attack steps, and the dataset labeling should be correctly implemented and documented to ensure a precise evaluation of an IDS. Moreover,
to evaluate anomaly-based IDSes, datasets must contain a fairly long period of
time containing benign activity so that these IDSes can learn normal behavior.

Unfortunately, the currently available datasets are of poor quality for both
the evaluation and the design of the IDSes. In particular, previous work [17,25,28]
found many defects in commonly used network intrusion detection datasets such
as CICIDS2017 [37] or CSE-CIC-IDS2018 [1]. The identified errors are mainly
related to the labeling and the execution of attacks. Other work [17, 25, 35] also
found errors in CICFlowMeter, the flow description extraction tool used in many
datasets. In addition to these errors, [16,20,24] highlighted the presence of biases
in the data that make detection obvious.

Beyond the errors that may exist, most datasets contain unrelated unitary
attacks. The attack types are rather noisy, such as brute force or Denial-of-
Service (DoS) attacks, and can be identified using simple counters: no complex
models are required for the detection as shown in [16]. On the contrary, very
few datasets [2, 21, 30, 31] contain Advanced Persistent Threat (APT) attacks.
Even among those datasets, the APT attack is sometimes unrealistic: the attack
steps may not follow the logic of an APT, or the duration of the dataset and the
spread of the attack steps are unrepresentative of APT attacks. This last issue
is difficult to overcome as providing host and network data representing months
of activity is quite impossible.

Another issue with current datasets is that most are static and cannot be
regenerated when errors are identified. Moreover, the tools used to create the
datasets are often closed source or only partially open source, which prevents the
improvement of the datasets: researchers are forced to create their own testbed,
which is time-consuming. The closed-source datasets also prevent users from
knowing the exact attack tools configuration, which hinders the logs analysis
a posteriori. Fortunately, new open-source testbeds like SOCBED [39] or Ky-
oushi [23] were proposed to overcome these difficulties.

Given the aforementioned errors and limitations of the existing datasets,
we thus propose a new testbed RESCOUSSE (REvised Self-Contained Open
source Utility for Simulated Security Experiments) Compared to SOCBED,
RESCOUSSSE includes a larger Information Technology (IT) system with more
servers and services that improve realism and variety. It also avoids all the bi-
ases that exist in the original testbed. Using this new testbed, we produce a new
dataset DEDALE (Dataset for Evaluating Detection of APT among Logs and
Events), which lasts one month: the first two weeks contain only benign activ-
ity, then from the third week, eight days contains an APT attack and the six
remaining days contains only benign activity. The first two weeks can be used
as a benign training set for anomaly-based IDSes. The last six days can be used
to measure the false positive rate (FPR). To our knowledge, DEDALE is one of
the longest APT datasets containing both network and system logs. The attack
proportion is really low since no noisy attack steps are performed. To generate
the benign activity, we develop a new tool called AURA (Automated UseR Ac-
tivity) that implements host and network activities and uses more services than
previous tools. The contributions of the paper can be summarized as follows:
- RESCOUSSE: a new open source testbed based on SOCBED, in which we fix a maximum of the errors existing in previous datasets.

- AURA: a new tool to generate benign activity in the IT system.

- DEDALE: a new labeled APT dataset (with network and system logs) lasting four weeks, with a suitable training set and an APT spread over eight days.

- An analysis of the biases existing in the network data and an evaluation of the detection performance of a signature-based NIDS on the new dataset.

The remainder of the article is organized as follows. Section 2 presents some related works on intrusion detection datasets and the associated generation tools. Then, in Section 3, we present the enhancements we bring to an existing testbed to obtain RESCOUSSE and, notably, how we fix all the biases existing in the previous datasets. Section 4 details the attack scenario we implement in DEDALE. In Section 5, we highlight the experimental setup used to generate the dataset, including the post-processing steps, and we propose some analysis of the obtained data. Finally, Section 6 concludes the article.

# 2 Related Works

## 2.1 Datasets Generation Tools/Testbeds

Several methodologies have been used in the past to generate intrusion detection datasets. The first method is to collect real activity in an organization's IT system. Due to privacy constraints, it is often impossible for academics to obtain such a dataset. Moreover, labeling the dataset is hard or even impossible since nobody knows whether attacks happened during the capture and, if so, when and what kind of attacks occurred. To overcome these limitations, many datasets have been generated using a controlled testbed. Some of them were generated using testbeds like the IXIA tool, custom IT systems, or cyber ranges. However, these are rather expensive, closed-source, and/or proposed by private companies. On the contrary, other testbeds, such as Kyoushi [23] and SOCBED [39], have recently been proposed in open source by the research community. They allow the experiments to be rerun as needed and are available for all researchers. However, the main limitation of the use of testbeds is the difficulty of generating benign activity as diverse as real-world activity.

It is worth mentioning that other methods have been proposed, like the generation of artificial traffic with machine learning techniques [32], or like malicious traffic injection in a benign network capture as ID2T [15] tool proceeds. However, no commonly used datasets were generated with this kind of method, and it is difficult to evaluate the quality of the resulting activity.

We believe that the use of testbeds is a good trade-off between the representativeness of the IT system and the controllability of both benign and malicious activities, which allows the labeling of the dataset. We strongly believe that open-source testbeds are key tools that can allow other researchers to reproduce and improve datasets in the future by modifying the IT system architecture, the benign activity, or the APT scenario. The following section presents datasets generated with such testbeds and their limitations.
## 2.2 Existing Datasets

Many datasets were proposed over the past [14, 34], and most of them have limitations, as shown by Flood et al. [18]. The oldest datasets (DARPA98 [27], UNSW-UNB15 [29]) are outdated, and the activity no longer represents today's characteristics. Other datasets [13, 36] lack benign activities as they are obtained from Capture The Flag or pentest games and are not adapted to evaluate IDSes. Many datasets (CICIDS2017 [37], CUPID [26], UWF Zeek Data22 [12]) do not include APT attacks and contain very noisy attacks such as port scan, brute force, and DoS attacks. Moreover, they tend to have a very high attack ratio.

On the opposite, several datasets (DAPT2020 [30], AIT-LDSv2 [21], Darpa OpTC [2], Unraveled [31]) include an APT-like scenario. However, we found some issues in these datasets. The IT system in DAPT2020 [30] is very small and unrepresentative of real ones, most of the attacks are very noisy, leading to a high attack ratio in the data, and the different attack steps are repeated multiple times, which do not represent a consistent APT scenario. For AIT-LDSv2, the IT system is much more realistic but the attack scenarios often last less than two hours, which does not respect the temporality of the APT attack type. Moreover, the network data is not labeled. Darpa OpTC is an interesting dataset since it contains three APT scenarios in a very large IT system with ten days of benign activity. Nevertheless, the generation of benign activity is not documented. The APT scenarios are only described textually and no precise labeling is provided. Finally, we observe undocumented significant drops in the number of network communications during the ten days of benign activity. Unraveled is the closest work to our: there are two weeks of benign activity, an APT scenario spread over more than one week and a specific effort has been made for the benign activity. However, defensive actions, such as malicious IP blocking, are implemented during the scenario. This is particularly problematic for evaluating anomaly-based IDSes as they may leverage the artifacts generated by the defensive actions to detect the intrusions. Moreover, it is surprising that IDSes are evaluated on data containing defensive actions that should derived from the detection. Finally, Unraveled is not fully reproducible: the APT attack is generated by pentesters, and only the benign activity scripts are provided.

## 2.3 Datasets Generation Good Practices

Several works proposed recommendations for dataset creation. In [18], the authors warn creators about the presence of biases in datasets. They point out the predominance of datasets that include only disconnected attacks. They also recommend including normal usage of the services used by the attacker so that the attacker is not the unique user, which makes the detection obvious. Landauer et al. [22] encourage the creation of datasets that specifically allow the evaluation of detectors that leverage sequential patterns in the data. For this purpose, APT attacks are particularly relevant since they include a sequential logic between the attack steps. To avoid the presence of obvious biases, the authors of [16] advise dataset creators to assess the performance of the simple One
Rule (OneR) model on network features. A OneR model makes a single condition to separate the attack from the normal traffic. If performance is too high, then the associated network features are biased.

Throughout this work, we strive to respect these recommendations. We decide to create our dataset using an open-source testbed. We started from SOCBED since it requires fewer resources to run than Kyoushi and offers almost the same functionalities. Thus, in the next section, we detail how we improve the SOCBED testbed to propose RESCOUSSE. In particular, we detail how we avoid the biases and other limitations mentioned before.

# 3 RESCOUSSE: an Enhanced Testbed

The section is organized to explain first the modifications we propose to SOCBED to reach a more realistic and unbiased testbed. We explain how we change the network architecture and add new services to the IT system. Then, we detail AURA, the benign user activity tool we implement. Finally, we justify how we fix the biases in the testbed. The whole testbed<fnref n="3" /> and the benign user activity<fnref n="4" /> codes are open source and are thus available.

## 3.1 Network Architecture Improvements

<figure><img src="image_4.png" /><figcaption>Fig. 1: Final network architecture in RESCOUSSE.</figcaption></figure>

The original testbed architecture [39] includes a relatively small IT system, and the attacker is the only client machine outside. Therefore, we add external

<footnote n="3">³ https://gitlab.inria.fr/mlanvin/rescousse</footnote>

<footnote n="4">⁴ https://gitlab.inria.fr/mlanvin/aura</footnote>
Windows and Linux clients who can browse the company's websites and send emails to internal company clients. This fulfills the need for background activities that use the IT services as recommended by Flood et al. [18]. We also add remote company workers. For that, we add a VPN server in the DMZ and company clients in the external zone. The remote clients can thus connect to internal services via the VPN server. The number of Windows and Linux external clients and remote company clients is customizable, which follows the initial philosophy of SOCBED. We add an external network zone for all these new external and remote clients to separate them from the company router. We thus add another router, called "External Router" to the network architecture.

To achieve a better realism of the IT system, we decide to separate the internal server zone from the clients, as done in many company networks. Since the ipfire routers used in SOCBED only have three network interfaces, we add another router, called "Company Router 2" to split the internal zone. The final network architecture with all these changes is shown in Figure 1.

## 3.2 New IT System Services and Monitoring Enhancements

As presented in the previous section, we add several remote company clients. We add a VPN server to the DMZ to allow them to access the company's internal services. The required certificates are put on each remote company client at the beginning of the simulation to allow them to connect to the VPN server. We also add another web server to the DMZ network zone. This web server runs a WordPress website which offers new attack possibilities and also brings more traffic diversity in addition to the existing DMZ server, which runs a Damn Vulnerable Web Application (DVWA).

In the original testbed, only system data is logged using an Elasticsearch Logstash Kibana (ELK) stack, which prevents the evaluation of NIDSes. To by-pass this limitation, we set up several network captures inside the IT system, which correspond to different levels of security monitoring. A cheap and basic solution that can be set up in companies is to only record the traffic on the "Company Router 1" which is the network's entry point. This high-level viewpoint misses the internal traffic between the clients and the servers but is easy to set up and does not require expensive storage capacity. A security team might also capture the traffic in other locations of the network. Therefore, we also record the network traffic in the three different zones of the company network, namely the internal servers and clients zones, as well as the DMZ. It thus requires more storage and would only be affordable by bigger companies. Providing the two levels of network captures can help researchers evaluate NIDSes in two realistic situations and analyze which actions of the attacker could be detected depending on the network capture points.

## 3.3 AURA: Automated UseR Activity

Benign activity is a crucial part of an intrusion detection dataset to evaluate IDSes. Indeed, it should hide enough of the attacker's actions so that they are
not too visible and allow the evaluation of the false positives. Moreover, it is necessary to train some anomaly-based IDSes. The benign activity should be diversified, realistic, and easily configurable to create different user profiles. In most testbeds [31,33,37], benign activity is generated by scripts launching different actions. We analyze the previous user activity scripts and summarize their features in Table 1. We develop a new tool called AURA as the previous ones do not fulfill all the requirements. The user activity script of SOCBED includes diverse actions but is not well documented, and the configuration settings are deeply nested, preventing the user behavior from being easily configured. The script used in Kyoushi and the one of the Unraveled dataset lack some functionalities, such as filing activities and working hours, as seen in Table 1. Ghost [3] is an interesting tool that runs user activity on hosts. Its drawback is the need for a server that controls the different clients, which could be hidden in a dedicated network zone but requires effort to set up. From our viewpoint, the user behavior script [6] used for CIDDS001 [33] is the most interesting. It includes a lot of user actions, such as ssh commands, and considers the periodicity of human workers, but it lacks VPN activities and is quite old.

In our new tool, we keep a maximum of the identified features in Table 1, except usbing actions, which correspond to actions where external drives are plugged into the company machines. We also choose to have customizable settings per profile type in the company, as several existing scripts do.

<table><caption>Table 1: Summary of the features included in the different existing user behavior scripts. “Filing” includes the actions related to the files on a system (read, modify, copy, move, delete). W stands for Windows and L for Linux.</caption><thead><tr><th>Dataset / Tool</th><th>Mailing</th><th>Web-browsing</th><th>Filing</th><th>Usb-ing</th><th>SSH</th><th>Printing</th><th>Use office hours</th><th>VPN</th><th>OS</th></tr></thead><tbody><tr><td>SOCBED</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✗</td><td>✗</td><td>✗</td><td>✗</td><td>W</td></tr><tr><td>Kyoushi</td><td>✓</td><td>✓</td><td>✗</td><td>✗</td><td>✓</td><td>✗</td><td>✗</td><td>✗</td><td>L</td></tr><tr><td>Unraveled</td><td>✓</td><td>✓</td><td>✗</td><td>✗</td><td>✓</td><td>✗</td><td>✗</td><td>✗</td><td>W & L</td></tr><tr><td>CIDDS001</td><td>✓</td><td>✓</td><td>✓</td><td>✗</td><td>✓</td><td>✓</td><td>✓</td><td>✗</td><td>W & L</td></tr><tr><td>Ghost</td><td>✓</td><td>✓</td><td>✓</td><td>✗</td><td>✓</td><td>✗</td><td>✗</td><td>✗</td><td>W & L</td></tr><tr><td>AURA</td><td>✓</td><td>✓</td><td>✓</td><td>✗</td><td>✓</td><td>✗</td><td>✓</td><td>✓</td><td>W & L</td></tr></tbody></table>

**User behavior script implementation** Our implementation is divided in two parts: the scheduler and the action manager. The scheduler creates the timeline of the actions, and the action manager starts the different scheduled actions at due time. It is worth mentioning that we build different profiles. *internal-developper*, *internal-manager*, *internal-office* are three different profiles among the internal company clients. *admin* is the profile that we set up for the first internal company client, which we consider as the IT administrator. *remote* represents the remote company clients that belong to the company but are outside.
*external* corresponds to all other machines, unrelated to the company and located in the “External” zone. The user behavior script we implement considers these user profiles to adapt the settings of each component.

**Scheduler** The scheduler plans the timeline of all the events. One event is a 3-tuples consisting of (a starting date, an action type, a duration). The following action types are available: *mailing*, *browsing*, *filing*, *ssh*, *system*, and *vpn*. To choose the timestamp of the beginning of an event, we draw a waiting time in an exponential distribution, which is commonly used to model the waiting time until an event occurs. Then, the action type is chosen based on two parameters. First, the set of actions depends on the user profile described previously. For instance, the *admin* is the unique profile to use ssh commands over the network, and only *remote* employees use VPN. Then, the choice of the next action is also conditioned by the transition matrix of the profile that defines the probability of choosing one action after another. The coefficients of the matrix are currently identical. However, in future work, we could set more specific transition probabilities between actions that could be learned from real users to enhance the realism. A last kind of event is added at the end of the working hours, which is a shutdown of the machine.

Once the timeline of the events is generated as a CSV file, all the actions are planned. Then, the action manager launches the actions when the scheduled time is reached. The advantage of generating such a timeline is the possibility of rerunning the same actions later, just shifting the starting dates and keeping the intervals between actions. The reproducibility of the benign activity is limited by some parameters chosen randomly at runtime and the variable network circumstances external to the testbed.

*Action manager* The action manager is responsible for starting the different action types at due time. A dedicated process is created for each action, which brings some robustness since if a subprocess crashes, it will not crash the main user behavior script.

## 3.4 Fixing Biases and Shortcuts

In previous datasets, the background activity does not hide the attacker's actions, and the attacker is often the unique user of IT services. With AURA, we ensure many protocols are used, including ssh and smb. Besides, adding external benign clients outside the company helps hide the attacker since they also send emails to the internal company clients and even add attachments. Thus, the phishing email with a malicious attachment is better hidden in the attack scenario. The legitimate use of the network services follows the advice of [18] to make detection harder by avoiding biases.

We also identify an additional bias linked to the attacker position in the network architecture. Indeed, in previous work [37, 39], the attacker is located at one-router hop from the victim IT system. Thus, its network traffic has very distinguishable characteristics: for example, the latency of the attacker network
flows is much smaller than the rest of the Internet traffic. To overcome this bias, we configure the external router cleverly which gives the illusion that the attacker is as far as the other web servers used in the normal traffic. We add a given delay to the packets passing through the external router and also decrement their TTL with a static value. For the delay, we measure the ping round-trip time between an internal company client and the attacker or other different websites at the beginning of each simulation. We obtain ping round-trip time distributions per website as shown in Figure 2. Then, we choose the delay that shifts the average of the attacker distribution to the average of the average of the website distributions. Regarding the TTL, we systematically decrement the TTL of the packet by 12 so that the attacker TTL values fall inside the distributions of the other legitimate websites. The next section presents the attack scenario and how we fix possible biases.

<figure><img src="image_5.png" /><figcaption>Fig. 2: Ping round-trip time distributions comparison between an internal company client and the attacker or other websites.</figcaption></figure>

# 4 Attack Scenario Design

## 4.1 APT Description

The attack scenario is inspired by APT attacks, which are sophisticated, stealthy, and persistent. Thus, multiple steps are performed to achieve the final objective. These steps are notably described by the MITRE ATT&CK matrix [38]. All the attack steps are scripted and are executed in parallel with the benign activity.

We propose the following scenario where the objective of the attacker is to exfiltrate data from the internal server. An employee receives an email from the attacker with an attached file, which is an office document containing a malicious macro. This macro downloads an https meterpreter reverse shell from the attacker server, which the attacker uses as a dropper to download a malware on the victim client. The malware connects to a Command-and-Control (C2)
server, retrieves commands to execute, and executes them on the infected ma-
chine. In particular, the first commands sent by the C2 enforce the malware's
persistence using registry keys to survive reboots of the machine. Then, the at-
tacker performs a lateral movement to move from the initial infected client to the
administrator client machine using the PrintNightmare exploit. When it reaches
the domain administrator machine, the attacker also installs the malware to com-
municate with the C2, and again, persistence is enforced. The final objective of
the attacker is the exfiltration of data from the internal server, which contains
the domain credentials of the users and internal documents from the company.
Therefore, the attacker connects in ssh to the server using the domain adminis-
trator ssh key and retrieves the data on the administrator machine. Finally, the
malware sends the exfiltrated data to the C2 server in a stealthy manner. An
illustration of the attack scenario can be found on the website<fnref n="5" />.

The scenario includes the following tactics of the MITRE ATT&CK framework: initial access, execution, persistence, command and control, discovery, lateral movement, collection, and exfiltration. Using custom malware and the PrintNightmare exploit that are leveraged in this scenario represents the sophisticated aspect of the APT attack. The whole attack scenario is conducted over eight days. We have scattered the stages of the APT to the maximum by letting one day free from malicious actions between each attack step. Ideally, we would like to imitate long-lasting attacks by running the experiment for several months or years and diluting the attack steps as much as possible. To keep the size of the logs reasonable enough to share the data with other researchers, we limit the duration to one month for the whole dataset. We describe some key points of the attack steps in the next paragraphs.

*Malicious macro* The email received by client 2 contains a doc file attachment with a malicious macro. The macro runs a PowerShell script to first download an https meterpreter reverse shell (http://172.19.1.1/Bank-of-Nuthington.exe) from the attacker server using the Invoke-WebRequest method. It downloads the file to a stealthy location, namely in the “APPDATA” folder. Then, it starts the downloaded malicious file in a new process using Start-Process. The process path (C:\appdata\scvhost\scvhost.exe) is thus stealthy and looks similar to the legitimate svchost windows service.

*Malware design* The https meterpreter reverse shell acts as a dropper since its main goal is downloading the communication malware. It is generated using metasploit [7]. The reverse shell first attempts to connect to another IP address controlled by the attacker: 172.19.2.1 on port 443. When the attacker opens the reverse connection, the malware is uploaded to the client. After the upload, to be stealthier, the process of the https reverse shell is terminated to avoid noisy beaconing. Then, the malware connects to the C2 server on a third IP address controlled by the attacker, namely 172.19.0.2. The first command sent to the malware is to set the persistence on the infected machine to resist to reboot.

<footnote n="5">⁵ https://dedale.inria.fr</footnote>
The malware is written in Python and compiled using pyinstaller [9]. It has
several functionalities: it retrieves commands, downloads and uploads files from
or to the C2 server, and sends the results of the executed commands to the C2
server. The C2 commands retrieval is stealthy enough since it makes a GET
request on a web page on the attacker C2 server on port 443, which contains
the attacker instructions. When the malware sends data to the C2 server, it also
uses the attacker's web server by performing a POST request to the web page
with the content to be sent, which imitates clients' classic browsing behavior.

*PrintNightmare exploit - CVE-2021-1675* This exploit allows one to move from one Windows client to another by leveraging a vulnerability in the printer driver, allowing remote code execution. When adding a printer to another client, an attacker can provide a custom DLL that is executed. The attacker uses it to compromise another internal client from the initial victim.

We used an existing implementation [4] of the exploit. In this code, an smb server is started on the attacker's side and contains the malicious DLL file. To reproduce the living of the land behavior of attackers, we decided to avoid using an smb server on the attacker and instead use the existing smb share inside the company network. This also increases the stealth of the attack since no network connection is outgoing from the internal network during this step. Thus, the attacker places the malicious DLL file (renamed as *presentation.pdf*) on the company smb share, which is then used in the exploit as the DLL location. In our scenario, the malicious DLL is an https reverse shell that is used in the same way as for the initial client compromise.

*Exfiltration* Since the attacker reaches the domain administrator's machine using the PrintNightmare exploit, he/she can access the internal company servers using the preregistered ssh keys that the administrator set up. The attacker runs ssh commands to dump the user domain credentials and the domain groups, performs a scp command to retrieve a valuable file located on the internal server, and then exfiltrates the data to the C2 server.

## 4.2 Biases and Shortcuts

This section explains how we eliminate errors related to the attack scenario. As a reminder, the limitations were the attack realism, the attack variety, the user agent artifact, and the obvious port detection.

We do our best to build a relevant attack scenario inspired by real APT groups. Based on the Mandiant ressources on APT groups [11], APT28 used spear phishing with malicious attachments. The attachment has a malicious macro, and then it downloads multiple malicious payloads as our macro does with the https reverse shell used as a dropper. APT25, APT35, and APT39 are also known to use spear phishing as an attack vector. The PrintNightmare exploit is an advanced attack representing the kind of zero-day attacks that advanced attackers can use. By analyzing the attack scenario through the prism
of the MITRE ATT&CK matrix, we also ensure that the steps regarding the kill chain are well organized.

The multiple steps of the APT attack provide a variety of attack types: phishing, beaconing, malware, persistence, CVE exploitation, and data exfiltration. All attack steps are rather stealthy and cannot be detected by their traffic volumetry (except for the exfiltration). We thus avoid the brute force pattern that is recurrent for almost all the attacks of the CICIDS2017 dataset, which affects the variety and representativeness of the behaviors of the attacks. Other datasets might have more diverse attack types for the initial compromise tactic but usually do not have any other tactics. In addition, like in APT attacks, the different attack stages depend on each other.

We take care of the volumetry of the attacks. We configure precisely the timings used in the https meterpreter reverse shell. The reverse shell attempts to connect to the attacker once per minute and retries it only 15 times. The malware connects to its C2 server only once per day to stay stealthy.

Unlike the CICIDS2017 dataset, the user agent does not unveil attacks. We set the user agent to a Windows machine using Firefox for the https meterpreter reverse shell and for the malware that both perform web requests. This ensures that attacks will not be detected too easily based on such obvious out-of-distribution features. In the same way as the user agent, we make sure to use common destination ports for the attack implementations. Thus, the https meterpreter reverse shell, and the malware use port 443, which is very common for the https traffic. This helps to make the attacks look as similar as possible to the normal activity.

# 5 DEDALE

DEDALE is the dataset we generate and can be downloaded at https://dedale.inria.fr. To generate the dataset, we instantiate the IT system and launch the background activities and the attack scenario. This section describes the experimental settings and our labeling process to provide the ground truth.

## 5.1 Experimental Setup

The experiment is conducted for one month. There are no attacks during the first two weeks. Compared to other datasets that provide a relatively small period of benign activity or no period at all, DEDALE contains a significant period of such activity. Anomaly-based NIDSes can thus use it to learn the normal behavior of the IT system. After these two weeks, the attacks are conducted for eight days, beginning in the third week. The details of the attack steps and the timeline are presented in Table 2. We choose to space out the different attack steps by one or two days each time to mimick as possible the length of an APT attack while keeping the dataset manageable.

For DEDALE, we instantiate 30 internal company clients, 5 external company clients, 5 external Windows clients, and 5 external Linux clients. The machine
<table><caption>Table 2: Planning of the attacks in DEDALE dataset. Beaconing actions are not detailed but exist between the attack steps</caption><thead><tr><th>Date</th><th>Event</th></tr></thead><tbody><tr><td>23/12/24 - 05/01/25</td><td>normal</td></tr><tr><td>06/01/25</td><td><b>10:00</b> email infection of client 2, the malware starts</td></tr><tr><td>08/01/25</td><td><b>15:00</b> lateral movement to client 1 via PrintNightmare, the malware starts on client 1</td></tr><tr><td>10/01/25</td><td><b>11:00</b> collection of data on the samba server (DC)</td></tr><tr><td>11/01/25</td><td><b>11:00</b> exfiltration of the collected data</td></tr><tr><td>12/01/25 - 13/01/25</td><td><b>11:40</b> extinction of the malware and last beaconing</td></tr><tr><td>14/01/25 - 19/01/25</td><td>normal</td></tr></tbody></table>

used has an AMD EPYC 7413 (Zen 3) CPU with 96 cores and 512 GB of RAM. In practice, around 300 GB of RAM is needed for the 55 VMs.

The collected logs include the network capture in the different zones and on the "Company Router 1" as PCAP files, the system logs (of both company clients and servers) as json export of the Elastic database, and the logs regarding the simulation and the attacks conducted. In particular, we collect all the exfiltrated data on the attacker side and the timestamps of the execution of the C2 commands. This allows us to check that the attack steps were correctly executed. We also collect the benign user behavior logs from the company and external clients. They contain all the actions performed by AURA. The normal behavior logs are also interesting for understanding a posteriori what happened in the network traffic or in the system logs. The dataset contains, in total, around 7.6 TB of raw network captures and 65 GB of compressed system logs. In addition, we keep the VM's disks for a forensic usage and provide the DFIR ORC artefacts.

## 5.2 Post-processing and Labeling Process

Post-processing prepares the data to be used notably by cutting them in a relevant manner. In addition, various network features can be extracted with different tools, such as Zeek [8] (or CICFlowMeter, as in previous datasets). Intrusion detection systems can then use these extracted features as input. We provide one network capture per day and per network zone for ease of use. Thus, we merge the files that belong to the same day and recut properly the network captures that straddle two days. The cut of network captures must be carefully done to avoid breaking TCP connections, as we can observe in the CICIDS2017 dataset, for instance. For this task, we designed a script called pyCapCutter<fnref n="6" />.

Therefore, we include all the TCP traffic initiated during the day for the daily network captures. It means that the daily network captures can have packets that arrive beyond the end of the associated day, but these packets belong to connections started on the day we consider. We then apply Zeek on these PCAP files to generate logs for the different identified protocols. To provide the network

<footnote n="6">⁶ https://gitlab.inria.fr/mlanvin/pycapcutter</footnote>
labels, we avoid using CICFlowMeter since the implementation is not robust and
the research community already found many bugs in it [17, 25, 35].

After this first step, we need to label the data. We develop different scripts<sup>7</sup>
to label the network traffic and the system logs. On the network side, the labels
are provided at the flow level, not the packet level. We used three classes of
labels: 0 for benign flows, 1 for attack flows, and 2 for attack-related flows,
which are not inherently malicious. The labeling is provided on the *conn.log* log
files generated by Zeek. These log files describe the network flows. Then, we label
all the network flows using a Python script that we also share on GitLab. The
Python script uses the timestamps, IP addresses, and sometimes port values to
precisely identify the malicious network flows. It allows the automatic labeling
of the network flows. The user only needs to set the timestamps of the different
attack steps manually. These timestamps are available in the attacker or the user
behavior logs, where each executed action has its corresponding timestamps. In
addition to the class of the flow, we also provide the tactic and technique numbers
as defined in the MITRE ATT&CK matrix [38]. A description comment is also
provided for each malicious flow. The labeling of the system logs is based on the
known malicious processes and their sub-processes. For system logs, the labeling
process is greatly facilitated by the fact that we know exactly what are the
different attack steps and when they occur. We also developed the malware so
we know which processes are launched and when. We also distinguish the logs
into three classes: benign logs (logs related to benign activity), malicious logs
(logs clearly linked to a malicious action) and malicious-related logs (logs that
are consequences or dependent on how the attack step works).

In the network data, the proportion of attack flows in the green zone is
0.0004%. This represents very few flows, confirming the APT attack's stealth-
iness property. Table 3 gives the detailed number of flows per attack step and
per network zone.

5.3 Dataset Quality

In [16], the authors evaluated the complexity of several datasets by using oneR
models on each feature. A oneR model corresponds to a decision tree with a depth
of 1 on a single feature. We evaluate such oneR models on the 90 network features
extracted by CICFlowMeter on DEDALE and on CICIDS2017 for a baseline. For
DEDALE, we consider the class 2 of labels as benign. We train and test the oneR
models on the whole dataset so that we obtain the best possible classification
performance. We measured the F1-score, the recall, and the precision for all
the oneR classifiers on each network feature. The detailed metrics are presented
in Appendix A. In DEDALE, we observe that only two network features are
biased and unveil 1.4% of the attack flows. The two biased network features
(Fwd Bytes/Bulk Avg and Fwd Packet/Bulk Avg) are related to the amount
of emitted data, which makes sense since the scenario includes an exfiltration
step. Thus the biases are legitimate. In the CICIDS2017 dataset, we identify

7 https://gitlab.inria.fr/mlanvin/dedale_labeling
34 network features that provide high performance for the CICIDS2017 dataset which can be explained by the lack of variation in the benign data or the biases introduced in the attack data. For instance, several temporal network features like the *Flow Bytes/s* provide relatively high detection performance, which can be linked to the attacker's network position issue fixed in RESCOUSSE, as presented in Section 3.4. These oneR models' performance measurements confirm the proper functioning of the mechanisms we enforced in RESCOUSSE and in the attack scenario to avoid biases that may constitute detection shortcuts. Other statistical models, which take combination of features as inputs for example, can be used to look for other biases in the data but this first analysis shows there is no obvious detection shortcut for an attack scenario designed to be stealthy.

**Evaluation of a signature-based NIDS**
Two Suricata NIDSes run on the company routers using the Emerging Threat Open rules [10] (ET Open). We evaluate the performance of such signature-based NIDSes on the DEDALE dataset considering again the class 2 of labels as benign. Part of the flows are analyzed by both Suricata. There can thus be multiple alerts for a single flow because of this configuration and we do not perform any aggregation on the alerts. Both Suricata raise 130, 430 alerts with only two of them being true positives (related to the same flow) and missing 144 network flows linked to the malicious activity. The false positive rate is around 0.22%, corresponding to around 4,300 per day. We deactivate only some signatures that raised many alerts related to the monitoring but do not optimize further the signatures. A high number of alerts are low priority alerts linked to connections to some specific top-level domains and the corresponding signatures should certainly be deactivated in a real set-up. The two malicious flows identified belong to the Ingress Tool Transfer (T1105) attack step. These results show that a signature-based NIDS with a default rule-set has much difficult in detecting the network flows related to the attack. This corroborates the stealthiness of the attack we designed.

<table><caption>Table 3: Number of network flows per attack step and per network zone. The parenthesis indicates the number of flows belonging to class 2. "router1" includes all its interface captures.</caption><thead><tr><th rowspan="2">Attack step</th><th colspan="4">Network zones</th></tr><tr><th>green internal</th><th>orange dmz</th><th>orange servers</th><th>router1</th></tr></thead><tbody><tr><td>Benign</td><td>16,274,341</td><td>839,052</td><td>17,191,110</td><td>24,025,799</td></tr><tr><td>Initial access</td><td>1</td><td>2</td><td>0</td><td>4</td></tr><tr><td>Command &amp; control</td><td>58 (+22)</td><td>0</td><td>0</td><td>58 (+20)</td></tr><tr><td>Discovery</td><td>1</td><td>0</td><td>1</td><td>0</td></tr><tr><td>Lateral movement</td><td>4</td><td>0</td><td>3</td><td>0</td></tr><tr><td>Collection</td><td>5</td><td>0</td><td>5</td><td>0</td></tr><tr><td>Exfiltration</td><td>2</td><td>0</td><td>0</td><td>2</td></tr></tbody></table>
***Evaluation of dataset properties*** Goldschmidt and Chudá [19] published a thorough survey on network intrusion datasets in 2025. In the survey, they define a 10-step pipeline to create network datasets and detail 11 different properties they should have. As the survey was published very recently, we were not able to follow the pipeline and DEDALE may lack some properties. A detailed analysis is provided in Appendix B. To sum up, we think that we followed 9 of the 10 steps of the pipeline and that DEDALE completely fulfill 7 properties of the 11 defined. 3 of the properties are partially fulfilled and 1 is lacking.

## 6 Conclusion

In this work, we described RESCOUSSE, the new testbed we propose, and how we enhanced an existing testbed to increase the realism and the size of the IT system and avoid the biases we identified in previous datasets. Thanks to RESCOUSSE, we generated a dataset, called DEDALE, which contains raw network captures, Zeek, CICFlowMeter and system logs. To the best of our knowledge, DEDALE has no identified detection biases that are irrelevant with the attack types. However, it is likely that in the future, errors or biases will be found. Fortunately, using an open-source platform to generate the dataset, we allow other researchers to fix them and regenerate a fixed dataset. With the timelines regarding the benign activity and the scripted attack steps, we did our best to maximize the reproducibility even if it cannot be rigorously ensured due to web servers' response timings and network speed non-determinism, for instance. This possibility did not exist for past datasets such as CICIDS2017 for example. Sharing the whole code used to generate the testbed and the attacks provides all the necessary information to understand and verify the attack tools settings, the network configuration, the firewall settings, and any other settings. Again, this is not the case for the previous datasets.

The dataset analysis we proposed using the oneR models highlighted no strong bias in the network flow features extracted by CICFlowMeter. Further analysis could be done to verify the existence of biases with other network features or using combination of features. Other analyses could also be made regarding the diversity of the data. In the analysis, we measured the performance of the signature-based NIDS Suricata on the DEDALE dataset. The poor detection results obtained with the ET Open rules illustrate the difficulty of detecting APT attacks. Further research should be conducted on APT attack detection.

As a future work, we would like to improve the IT system by adding new services. The automated user activity can also be improved by adding more interactions between internal clients and refining the different user profiles. In the external zone, we could try adding a routing system like the MI-LXC [5] with various associated subdomains to enhance the realism. RESCOUSSE is flexible: other attack types or steps can be implemented. It is possible to perform different reconnaissance steps, noisier attacks or implement other APT scenarios. We plan to provide more datasets to the community with different levels of stealthiness in the future.
**Acknowledgement** Through the work on the RESCOUSSE platform, several students helped to improve the IT system and the attack scenario in SOCBED. Lucien Audebert and Ayman Houna contributed to developing services, including the VPN server of the IT system and establishing a new attack stage for the email infection, respectively. They also helped to expand the IT system by adding the company router 2. Maxime Vernhet set up an initial version of the PrintNightmare attack and started the development of the C2 communication malware.

Experiments presented in this paper were carried out using the Grid'5000 testbed, supported by a scientific interest group hosted by Inria and including CNRS, RENATER and several Universities as well as other organizations (see https://www.grid5000.fr).

This work has been partly realised thanks to a doctoral grant from CREACH LABS (https://www.creachlabs.fr/).

**Disclosure of Interest** The authors have no competing interests to declare that are relevant to the content of this article

## A Performances of the oneR Models and Characteristics of Datasets

Table 4 and Table 5 present the performance of oneR models on the CICIDS2017 dataset and the DEDALE dataset respectively. The top-5 biased network features with their associated classification metrics are provided. Only two network features are biased in DEDALE. Their associated recalls are very low and do not unveil many of the attack flows. On the opposite the biased network features in the CICIDS2017 dataset unveil a lot the attack flows as shown by the associated recalls.

<table><caption>Table 4: Performance of the oneR models on the network features provided by CICFlowMeter on the CICIDS2017 dataset.</caption><thead><tr><td>Feature</td><td>F1-score</td><td>Recall</td><td>Precision</td><td>Threshold</td></tr></thead><tbody><tr><td>RST Flag Count</td><td>0.8224</td><td>0.901</td><td>0.7565</td><td>0.5</td></tr><tr><td>Fwd Packet Length Max</td><td>0.7264</td><td>0.6535</td><td>0.8177</td><td>21.5</td></tr><tr><td>Total Length of Fwd Packet</td><td>0.7259</td><td>0.6523</td><td>0.8183</td><td>28.5</td></tr><tr><td>Fwd Segment Size Avg</td><td>0.7226</td><td>0.6487</td><td>0.8154</td><td>3.3342</td></tr><tr><td>Fwd Packet Length Mean</td><td>0.7226</td><td>0.6487</td><td>0.8154</td><td>3.3342</td></tr></tbody></table>
<table><caption>Table 5: Performance of the oneR models on the network features provided by CICFlowMeter on the highest biased network zone (green) capture of the DEDALE dataset.</caption><thead><tr><td>Feature</td><td>F1-score</td><td>Recall</td><td>Precision</td><td>Threshold</td></tr></thead><tbody><tr><td>Fwd Bytes/Bulk Avg</td><td>0.0278</td><td>0.0141</td><td>1.0</td><td>6084116</td></tr><tr><td>Fwd Packet/Bulk Avg</td><td>0.0278</td><td>0.0141</td><td>1.0</td><td>4204</td></tr></tbody></table>

Table 6 contains a summary of the main characteristics of the different datasets of the literature. In particular, the table highlights the attack ratio in the logs and the limitations we identify. The attack ratio is the proportion of network logs that are related to the attack scenario.

## B Evaluation of DEDALE Properties

Goldschmidt and Chudá [19] published a thorough survey on network intrusion datasets in 2025. In the survey, they define a 10-step pipeline to create network datasets and detail 11 different properties they should have. In this paragraph, we analyse the creation of RESCOUSSE and DEDALE regarding this pipeline and these properties. As a reminder, the survey was published very recently and was not available at the beginning of our work. The *data validation* step of the pipeline is the only step we do not completely fulfill. We checked that the whole APT attack succeeded and verified the absence of obvious detection shortcuts with OneR models. However, we do not investigate packet losses or malformations, for example. About the properties, we think that *Correctness*, *Extensibility* and *Realism* may not be entirely fulfilled and that *Diversity* is not fulfilled. For *Correctness*, as just said, we did not check for packet losses. For *Extensibility*, we use RESCOUSSE to generate DEDALE so it is possible to change some features of the IT system easily, such as the number of internal or external clients. Other features may need much more work to be implemented. For *Realism*, we did our best to simulate the most comprehensive normal activity, but it is surely not as random and complete as in a real environment. Moreover, the IT architecture misses some features, such as a true routing system and the possibility of masking the IP addresses of external clients and attackers. Finally, for *Diversity*, we only implemented one APT attack with no variation in the procedures and techniques, even though RESCOUSSE is designed to allow diversity. We think that mixing different APT attacks in the same dataset will clearly impact the *Realism* of the dataset.
<table><caption>Table 6: Network intrusion detection datasets summary</caption><thead><tr><th>Dataset name</th><th>Year</th><th>Duration</th><th>Log type</th><th>Attack ratio</th><th>Labeled</th><th>#Hosts</th><th>Limitations</th></tr></thead><tbody><tr><td>DARPA98 [27]</td><td>1998</td><td>9 weeks of logs: 7 train + 2 test</td><td>Netw., Syst.</td><td>0.0065 %</td><td>Yes on flows</td><td>1,000</td><td>old and biased TTL</td></tr><tr><td>UNSW-UNB15 [29]</td><td>2015</td><td>31h</td><td>Netw.</td><td>14.5 %</td><td>Yes on flows</td><td>45</td><td>short period, no attack free period</td></tr><tr><td>CIDDS-001&2 [33]</td><td>2017</td><td>4 weeks</td><td>Netw.</td><td>5.29 %</td><td>Partially on flows</td><td>25</td><td>labeling of external traffic</td></tr><tr><td>CICIDS2017 [37]</td><td>2017</td><td>5 days</td><td>Netw.</td><td>30 %</td><td>Yes on flows</td><td>15</td><td>labeling, attack quality, multiple biases</td></tr><tr><td>CSE-CICIDS-2018 [1]</td><td>2018</td><td>10 days</td><td>Netw.</td><td>4.5 %</td><td>Yes on flows</td><td>450</td><td>labeling, attack quality</td></tr><tr><td>DARPA OpTC [2]</td><td>2019</td><td>2 weeks</td><td>Netw., Syst.</td><td>0.007 %</td><td>Txt description (some PIDs)</td><td>500</td><td>inaccurate labeling</td></tr><tr><td>DAPT2020 [30]</td><td>2020</td><td>5 days</td><td>Netw., Syst.</td><td>36 %</td><td>Yes on flows</td><td>4</td><td>small infrastructure, unclear exfiltration</td></tr><tr><td>CUPIID [26]</td><td>2022</td><td>Unclear</td><td>Netw.</td><td>39 %</td><td>Yes on flows</td><td>25</td><td>noisy attacks (high attack ratio)</td></tr><tr><td>UWF ZeekData22 [12]</td><td>2022</td><td>16 weeks</td><td>Netw.</td><td>50 %</td><td>Yes on flows</td><td>6</td><td>data of pentest exercise (approx. labeling) and attack ratio</td></tr><tr><td>AIT-LDSv2 [21]</td><td>2022</td><td>4-6 days</td><td>Netw., Syst.</td><td>0.3% - 90% depends on log types</td><td>Yes on application logs</td><td>20</td><td>short period of attack (1 day), unlabelled network logs</td></tr><tr><td>Unraveled [31]</td><td>2023</td><td>6 weeks</td><td>Netw., Syst.</td><td>1.41 %</td><td>Yes on flows</td><td>30</td><td>include defense actions</td></tr></tbody></table>
References

1. CSE-CIC-IDS2018. https://www.unb.ca/cic/datasets/ids-2018.html

2. DARPA OpTC. https://github.com/FiveDirections/OpTC-data

3. https://github.com/cmu-sei/ghosts

4. https://github.com/cube0x0/cve-2021-1675

5. https://github.com/flesueur/mi-lxc

6. https://github.com/markusring/cidds/tree/master/scripts/automation/packages

7. https://github.com/rapid7/metasploit-framework

8. https://github.com/zeek/zeek

9. https://pypi.org/project/pyinstaller/

10. https://rules.emergingthreats.net/

11. https://www.mandiant.com/resources/insights/apt-groups

12. Bagui, S.S., Mink, D., Bagui, S.C., Ghosh, T., Plenkers, R., McElroy, T., Dulaney, S., Shabanali, S.: Introducing UWF-ZeekData22: A comprehensive network traffic dataset based on the MITRE ATT&CK framework. Data 8(1) (2023)

13. Berady, A., Jaume, M., Triem Tong, V.V., Guette, G.: PWNJUTSU: A dataset and a semantics-driven approach to retrace attack campaigns. IEEE Transactions on Network and Service Management 19(4), 5252–5264 (2022)

14. Bönninghausen, P., Uetz, R., Henze, M.: Introducing a comprehensive, continuous, and collaborative survey of intrusion detection datasets. In: the 17th Cyber Security Experimentation and Test Workshop. p. 34–40. CSET ’24 (2024)

15. Cordero, C.G., Vasilomanolakis, E., Milanov, N., Koch, C., Hausheer, D., Mühlhäuser, M.: ID2T: A DIY dataset creation toolkit for intrusion detection systems. In: IEEE Conference on Communications and Network Security (CNS). pp. 739–740 (2015)

16. D’hooge, L., Verkerken, M., Wauters, T., De Turck, F., Volckaert, B.: Castles built on sand: Observations from classifying academic cybersecurity datasets with minimalist methods. In: the 8th International Conference on Internet of Things, Big Data and Security - IoTBDS. pp. 61–72 (2023)

17. Engelen, G., Rimmer, V., Joosen, W.: Troubleshooting an intrusion detection dataset: the CICIDS2017 case study. In: IEEE Security and Privacy Workshops (SPW). pp. 7–12 (2021)

18. Flood, R., Engelen, G., Aspinall, D., Desmet, L.: Bad design smells in benchmark NIDS datasets. In: 2024 IEEE 9th European Symposium on Security and Privacy (EuroS&P). pp. 658–675 (2024)

19. Goldschmidt, P., Chudá, D.: Network intrusion datasets: a survey, limitations, and recommendations. Computers & Security p. 104510 (2025)

20. Jacobs, A.S., Beltiukov, R., Willinger, W., Ferreira, R.A., Gupta, A., Granville, L.Z.: AI/ML for network security: The emperor has no clothes. In: the 2022 ACM SIGSAC Conference on Computer and Communications Security. pp. 1537–1551 (2022)

21. Landauer, M., Skopik, F., Frank, M., Hotwagner, W., Wurzenberger, M., Rauber, A.: Maintainable log datasets for evaluation of intrusion detection systems. IEEE Transactions on Dependable and Secure Computing 20(4), 3466–3482 (2023)

22. Landauer, M., Skopik, F., Wurzenberger, M.: A critical review of common log data sets used for evaluation of sequence-based anomaly detection techniques 1(FSE) (2024)

23. Landauer, M., Skopik, F., Wurzenberger, M., Hotwagner, W., Rauber, A.: Have it your way: Generating customized log datasets with a model-driven simulation testbed. IEEE Transactions on Reliability 70(1), 402–415 (2021)
24. Lanvin, M., Gimenez, P.F., Han, Y., Majorczyk, F., Mé, L., Totel, E.: Towards understanding alerts raised by unsupervised network intrusion detection systems. In: the 26th International Symposium on Research in Attacks, Intrusions and Defenses. p. 135–150 (2023)

25. Lanvin, M., Gimenez, P.F., Han, Y., Majorczyk, F., Mé, L., Totel, É.: Errors in the CICIDS2017 dataset and the significant differences in detection performances it makes. In: Risks and Security of Internet and Systems. pp. 18–33 (2023)

26. Lawrence, H., Ezeobi, U., Tauil, O., Nosal, J., Redwood, O., Zhuang, Y., Bloom, G.: CUPID: A labeled dataset with pentesting for evaluation of network intrusion detection. Journal of Systems Architecture **129**, 102621 (2022)

27. Lippmann, R., Fried, D.J., Graf, I., Haines, J.W., Kendall, K.R., McClung, D., Weber, D.J., Webster, S.E., Wyschogrod, D., Cunningham, R.K., Zissman, M.A.: Evaluating intrusion detection systems: the 1998 darpa off-line intrusion detection evaluation. DARPA Information Survivability Conference and Exposition (DISCEX’00) **2**, 12–26 (2000)

28. Liu, L., Engelen, G., Lynar, T., Essam, D., Joosen, W.: Error prevalence in NIDS datasets: A case study on CIC-IDS-2017 and CSE-CIC-IDS-2018. In: 2022 IEEE Conference on Communications and Network Security (CNS) (2022)

29. Moustafa, N., Slay, J.: UNSW-NB15: a comprehensive data set for network intrusion detection systems. In: 2015 military communications and information systems conference (MilCIS). pp. 1–6 (2015)

30. Myneni, S., Chowdhary, A., Sabur, A., Sengupta, S., Agrawal, G., Huang, D., Kang, M.: DAPT 2020 - constructing a benchmark dataset for advanced persistent threats. In: International workshop on deployable machine learning for security defense. pp. 138–163 (2020)

31. Myneni, S., Jha, K., Sabur, A., Agrawal, G., Deng, Y., Chowdhary, A., Huang, D.: Unraveled — a semi-synthetic dataset for advanced persistent threats. Computer Networks **227**, 109688 (2023)

32. Ring, M., Schlör, D., Landes, D., Hotho, A.: Flow-based network traffic generation using generative adversarial networks. Computers & Security **82**, 156–172 (2019)

33. Ring, M., Wunderlich, S., Grüdl, D., Landes, D., Hotho, A.: Flow-based benchmark data sets for intrusion detection. In: the 16th European Conference on Cyber Warfare and Security (ECCWS). pp. 361–369 (2017)

34. Ring, M., Wunderlich, S., Scheuring, D., Landes, D., Hotho, A.: A survey of network-based intrusion detection data sets. Computers & Security **86**, 147–167 (2019)

35. Rosay, A., Cheval, E., Carlier, F., Leroux, P.: Network intrusion detection: A comprehensive analysis of CIC-IDS2017. In: 8th international conference on information systems security and privacy (2022)

36. Sangster, B., O’connor, T., Cook, T., Fanelli, R., Dean, E., Morrell, C., Conti, G.J.: Toward instrumenting network warfare competitions to generate labeled datasets. In: the 2nd Cyber Security Experimentation and Test Workshop (2009)

37. Sharafaldin, I., Lashkari, A.H., Ghorbani, A.A.: Toward generating a new intrusion detection dataset and intrusion traffic characterization. In: the 4th International Conference on Information Systems Security and Privacy. pp. 108 – 116 (2018)

38. The MITRE Corporation: MITRE ATT&CK, https://attack.mitre.org/

39. Uetz, R., Hemminghaus, C., Hackländer, L., Schlipper, P., Henze, M.: Reproducible and adaptable log data generation for sound cybersecurity experiments. In: the 37th Annual Computer Security Applications Conference. p. 690–705 (2021)