On the 24th of January, AMOSSYS and Malizen put together a Blue Team CTF, for the SupSec seminar organized by Inria. In this blog post, we explain how we, at AMOSSYS, generated the dataset used in this challenge. In addition, Malizen has published its own post about the investigation of the dataset using their platform: https://www.malizen.com/post/supsec-challenge-a-blue-team-ctf-by-malizen-and-amossys.

Context

MonkeyMoney, a startup operating in the NFT market, has positioned itself by introducing a marketplace for buying and selling NFTs. Unlike its competitors, MonkeyMoney employs a disruptive strategy by utilizing post-quantum cryptography to secure NFT tokens. Despite being part of a highly competitive industry, MonkeyMoney aims to expedite the release of its platform and has made compromises in the security of its information system. Additionally, the startup’s aggressive marketing tactics have faced opposition within the NFT community, attracting the attention of certain attacker groups.

The day of the attack

On January 19th 2023, around 3:00 pm, the information system of the startup MonkeyMoney stopped working altogether. The employees were no longer able to log on to their workstations. The cause seemed to be that the domain controller was not responding. An administrator logged in locally to the Active Directory server, and found this message on the screen:

The investigation

The participants were given the role of an analyst within the incident response team of the CERTIFLEX company, called to help on this breach. The startup MonkeyMoney was able to extract the different logs of the information system during the supposed period of the attack. These logs were provided to the participants for analysis, in order to investigate and understand the attacker’s path.

To help them in this mission, the company gave the following network topology diagram of their information system to CERTIFLEX:

Additionally, the logs were available in different forms:

• as raw syslog files,
• through Kibana (Elastic),
• through the Malizen Investigation Platform.

If you want to know more about the investigation through the Malizen Investigation Platform, visit the blog post written by Malizen: https://www.malizen.com/post/supsec-challenge-a-blue-team-ctf-by-malizen-and-amossys. In the rest of the present post, we will cover how the logs and dataset were produced at AMOSSYS.

Behind the scene

Emulating the IT system

The Cyber Range embraces an Infrastructure as Code paradigm. The topology of the network to be simulated needs to be defined in a YAML format. From this definition, the Cyber Range takes care of booting up all the required virtual machines and docker nodes, and configures the emulated networks and routes. A pool of basic virtual machine (Windows 10, Ubuntu, Debian, Windows Servers, etc.) and docker containers (e.g. for a lightweight NTP or DNS server) are available in the Cyber Range, ready to be booted and connected to the simulation.

Below is an illustration of the network definition for the SupSec challenge, and of how the network infrastructure is instantiated into a simulated network:

Emulating life

On top of the emulated IT system, the Cyber Range allows to dynamically configure the machines, simulate aging, and simulate human user actions.

Right after the setup of the emulated IT system, and before the emulation of the attack(s), a provisioning phase takes place. In particular, configuring services, creating users, registering Windows machines to the AD, deploying artifacts on the machines (such as documents, or navigation history), and other tasks can be done automatically. This is necessary to make the machines of the IT system work together, but it also participates in creating a more realistic network, making it look like it has had some activity in the past.

Also, the provisioning step is useful to actually configure the weaknesses in the services and machines of the network. The Cyber Range effortlessly allows the provisioning of such weaknesses, tailored to the considered attack scenario. For instance, for SupSec, the Log4Shell vulnerability (CVE-2021-44228) was used as initial access for the attacker. Thus, a vulnerable Tomcat server was automatically installed and configured on the target web server machine.

The last brick for the emulation of life consists in playing user actions on the desktop machines. While the provisioning occurs before the actual attack scenario, the user actions occur (most of the time) in parallel to the attacks. The catalog of user actions notably covers the opening/closing of sessions, web browsing, email writing, opening and writing documents (such as Office documents), and file system navigation. The technology involved automates these actions, based on a pre-defined actions scenario, and it does not necessitate an agent on the impacted machines. This latter point ensures that the user actions appear to come from a human actor, resulting in real traces on the systems or network.

For the SupSec challenge, one hour of various user actions were played on all five Windows clients. We can see on the following video, examples of user actions being played in diffrent machines (taken fomr VNC viewers on the Cyber Range frontend).

Emulating the Threat Actor

At the core of M&NTIS platform is the threat emulation. More exactly, the platform can run user-defined attack scenarios, comprised of as many steps as necessary (« unitary attacks« ). Each step is typically mapped to a Tactic (TA) and Technique (T) from the MITRE ATT&CK knowledge base.

For the SupSec challenge, the attack scenario (and the solution to the challenge!) consisted of the sixteen steps, listed in the graphical representation below.

The unitary attacks listed above come from M&NTIS’ catalog of unitary attacks ready to be employed. This catalog offers unitary attack ranging from initial access (phishing, log4shell, webshells, …) and credential access (web browser stored credentials, LSASS credentials, SSH keys, web cookies, etc.) to lateralization (through SFTP brute-force attacks, WinRM with credentials, watering hole, …) and impact (ransomwares, wipers, spywares, etc.).

Most importantly, the threat emulation in M&NTIS is powered by the scenario engine, which allows automated scenarios, by chaining unitary attacks which have pre- and post-conditions. Indeed, each unitary attack has requirements which must be checked before launching, and creates new attack knowledge when it exits successfully. In between is the attack itself. For instance, the unitary attack for Zerologon can only be triggered if an AD is known and reachable, and it creates as output new credentials (i.e. null password for Administrator) which are added to the current knowledge base. In turn, these credentials can then be used to fulfill the requirements of the unitary attacks realizing the NTDS dump and WinRM lateral movement.

Lastly, the threat emulation platform comes with built-in C&C infrastructure (including the C&C server itself, a phishing server, exfiltration servers). These servers can be dynamically deployed during the simulation, and are placed in the Internet part of the simulated network, to emulate the external attacker’s infrastructure.

In the end, during a typical attack scenario, once the initial access phase is done, unitary attacks can either go through the simulated C&C (actual commands and payloads are executed using beacons on the infected targets), or either be performed by standalone payloads dropped on the targets. More advanced scenarios can include more complex lateralizations (e.g. rebounds by having one beacon used as proxy for another beacon).

Collecting traces

The collection of system, application, and network traces during the attack scenario is accomplished by the M&NTIS platform:

• Network traffic: based on user-defined probes placed in the simulated networks, PCAP files can be produced. Alternatively, or simultaneously, the network traffic can be mirrored to a specific machine within the simulation. In the topology illustrated previously, for instance, the traffic of all subnetworks is mirrored to the Suricata machine.
• System logs: by provisioning (see previous sections) sysmon or syslog agents on Windows and Linux machines, the system logs can be watched and collected. On Linux, /var/log/ files are typically watched, while on Windows, it is the Event log(s).
• Application logs: in addition, still by provisioning, it is possible to collect the logs of specific applications. For instance, when an attack scenario involves a web server, it is relevant to collect the server’s logs for future analysis.

There is an important difference in the way network traces and logs are collected. On the one hand, the surveillance of network traffic is seamless and invisible in the simulation (unless traffic is mirrored). The traces are collected in PCAPs produced during the simulation, and can then be analyzed with Wireshark for instance. On the other hand, the collection of logs relies on the presence of a « supervision LAN » within the simulation: all logs are centralized in a logstash instance. From this logstash, then, logs can be collected by sending them to a rsyslog server (much like PCAPs for network traces), or alternatively, they can be sent to an ELK instance.

For the SupSec challenges, the logs collected covered all system logs, the tomcat webserver, the DNS and proxy application logs, and the Suricata alerts. And network probes were configured to ensure Suricata watched all subnetworks.

Validating the investigations

In order to validate and rank the participants’ answers in this challenge, we compared their investigations to the ground truth, described in the attack report.

The attack report: explainability of attack steps

The M&NTIS Platform generates a posteriori an attack report containing all the metadata linked to the attack steps and explaining the full attack scenario. This report details each attack step with the following fields:

• the name of the attack step and its metadata (i.e. the MITRE ATT&CK metadata, the side effects, etc.),
• its status (if the attack succeeded or failed),
• its time and duration,
• its targeted node(s) in the simulation,
• its output,
• the infrastructure used (C&C, phishing server, etc.).

M&NTIS Platform

For the creation of this challenge, we used the capabilities of the M&NTIS Platform, a full adversary emulation platform, to provide a realistic dataset for a Blue Team CTF. As described in this post, this product is able to execute real attack scenarios to replicating the attacker infrastructure and emulating TTPs on targeted systems, alongside the user activity and provisionéing capacities.

This platform was used here to create a CTF but, it has a multitude of other uses. The platform can be exploited to test security products and benchmark IDS or XDRs, to study a malware’s behavior (if a malware was detonated in the simulation), to validate secops capabilities, to train SOC/CERT teams and analysts, or to generate a bank of datasets for future research or for educational purposes.

M&NTIS Platform is the result of several years of research and development inside AMOSSYS, and has received financial support from the DGA-MI (French Government Defence procurement and technology agency) through several research grants. If you want to know more about this platform and its use cases, contact us at contact.mantis@amossys.fr.