SOC/CERT analyst training in live labs

This guide shows how to run a training session for a SOC or CERT team with M&NTIS Platform. A trainer launches a lab and shares it with the team. The analysts investigate a live attack in a SIEM, and at the end the trainer reveals what the attacker actually did.

Allow about 30 minutes before the lab is ready, then the length of your exercise.

On the free trial

Everything in this guide works on a free trial, on the scenarios marked FREE, with labs of 2 to 6 hours. Options that the trial does not include, such as unlimited duration, delays between attack steps or pauses, are shown disabled in the interface with a tooltip explaining why. For the shortest path to a first lab, see the free trial quick start.

What M&NTIS Platform brings to SOC/CERT training

Each time you launch a scenario, M&NTIS Platform:

deploys a real, simulated enterprise information system (workstations, servers, Active Directory, network segments, firewalls). These are real virtual machines, not a mock-up;
can simulate legitimate user activity on that system (web browsing, document editing, logins) so that the logs contain both normal and malicious events, as in production;
plays a full attack scenario step by step (a kill chain made of MITRE ATT&CK techniques) against that system;
deploys a security monitoring chain (log agents, EDR, network probe, SIEM) that records everything that happens.

Each launch is called a lab. In a training session:

SOC analysts (L1 to L3) triage the alerts raised by the SIEM, write queries and pivot on indicators of compromise;
CERT/DFIR responders reconstruct the timeline, inspect the compromised machines and work out the scope of the intrusion;
the whole team works in the same live environment at the same time, and no one needs an M&NTIS account except the trainer who launched the lab;
in the debrief, the trainer reveals the attacker's real steps and the indicators they left, and the team checks its hypotheses against them.

See the Overview for the platform architecture, and Blue Team Training for the use case.

Step 1: choose the scenario

Choose an attack scenario according to the training objectives and the threat you want to study, for example:

the impact the attacker is after (ransomware, data theft, ...);
the TTPs of a known intrusion set;
the exploitation of a vulnerability (Zerologon, Log4Shell, ...).

Open Scenarios in the left menu, or the scenario suggested on the Dashboard. The scenario page shows:

the description of the targeted organization and of the incident;
the difficulty and the estimated analysis time;
tags for the skills it trains (credential_theft, lateral_movement, phishing_analysis, powershell_analysis, ...);
the topology of the simulated information system, sometimes in several variants (for example Standard_en and Standard_fr, which differ in the language of the Windows machines).

This guide uses Lumidus, a ransomware attack against an organization in the education sector.

Click Create a lab to open the configuration wizard.

Step 2: configure the lab

The wizard has six steps. The one step you must not skip is step 5, Integrations: this is where you choose the SIEM.

2.1 Use case

Select Training. This mode turns on the features designed for team exercises:

Public link: a link to share the lab with your team (see step 4);
Assessment (optional): a questionnaire generated once the attack is over, which analysts answer by investigating the monitoring data;
Learning context (optional): the briefing your analysts see when they open the lab;
Flexible duration.

The other mode, Defense testing, is meant for testing a SOC's detection rather than training people.

2.2 Training options

Generate an assessment: keep it on if you want to measure what your analysts understood. The assessment needs an integration that supports investigation, that is a SIEM (selected in step 5).
Share a learning context with analysts: the text is pre-filled with the scenario's own briefing. You can edit it for this lab only, for instance to add your own instructions or rules of engagement. The shared scenario is not modified.

2.3 Topology and legitimate life

Choose the topology variant.
Turn on Enable legitimate life. Simulated users will browse the web, create documents and log in. This creates the background noise your analysts will have to separate from the attack, and it is what makes the training realistic.

2.4 Timeline

Max duration: the lab stops automatically after this time. If your plan allows it, choose an unlimited duration for a training session, so as not to be constrained, and stop the lab yourself once the debrief is over. Otherwise, choose a duration that covers both the investigation and the debrief: when the lab stops, your team loses access to the machines and the SIEM.
Delay: a range in minutes. Before and after each attack step, the platform waits for a random time within this range. This spreads the attack over time, as a real intrusion would be, and gives the team time to investigate between steps.
Execution mode, depending on your plan:
- automatic: the attack runs from start to finish without stopping;
- step-by-step: the lab pauses after each attack step, and you resume it with Resume on the lab page;
- custom: you choose after which attack steps the lab pauses.

A pause before the first attack step is useful to prepare the lab before the attack starts: deploy a tool that is not in the M&NTIS catalog, or add your own detection rules (see step 5).

2.5 Integrations: select a SIEM

This is the most important step for a SOC/CERT training. Without a SIEM, your analysts have nothing to investigate. No log is centralized, no alert is raised, and there is no starting point for the investigation.

When None is selected, M&NTIS only deploys the mandatory components. If the assessment is enabled, the wizard shows a warning and blocks the Next button until you select a SIEM.

The Basic tab offers ready-made monitoring stacks:

Preset	What gets deployed
Elastic	Elasticsearch and Kibana, Winlogbeat and Sysmon on Windows machines, Suricata network probe
Splunk	Splunk, Winlogbeat and Sysmon, Suricata
Graylog	Graylog, Winlogbeat and Sysmon, Suricata
Wazuh	Wazuh manager and Wazuh agents on the machines

Pick the one closest to the tools your team uses. If you have no preference, Elastic is a good first choice: Kibana gives analysts both the raw logs and the alerts. This guide uses Elastic.

The mention 2 integration(s) unavailable for this topology only means that some agents of the preset do not apply to the machines of this scenario. The preset still works.

The Advanced tab lets you assemble the monitoring chain yourself, to train on the tools your team actually uses:

EDR agents (CrowdStrike Falcon, HarfangLab, SentinelOne, Sekoia.io, ...): once selected, the agent is installed on all compatible workstations and servers;
external cloud SIEMs (Microsoft Sentinel, Elastic Cloud, Sekoia.io XDR): logs are sent to your own tenant, and analysts investigate from their usual console;
collaborative tools for the team (Etherpad, Nextcloud, Attack Flow).

Some of them need your own license key or tenant. See Monitoring and integrations.

2.6 Summary and launch

The last step summarizes your choices. Check that the Integrations block lists a SIEM (here Elasticsearch, Kibana, Logstash, Suricata, Sysmon and Winlogbeat).

Create lab saves the lab without starting it.
Run lab creates and starts the lab. If your plan counts lab runs in credits, a confirmation tells you how many credits it costs and how many remain. Click Confirm.

Step 3: follow the lab and find your way around its panels

After you confirm, the lab page opens. The status badge in the top right shows where the lab is (Initialization, then Running). Next to it, Stop ends the lab for good, and Resume continues a paused lab.

Setting up the environment takes up to 25 minutes: the platform reserves a Cyber Range instance, starts the virtual machines, then deploys the monitoring chain. Use this time to brief your team.

The lab page has seven tabs.

Tab	What it shows	Available
Information	Learning context, lab timeline, configuration, public link, and the Security monitoring and collaborative tools block	Always
Notifications	Live progress of the lab (environment setup, then scenario execution)	Always
Lab interaction	Remote access to the machines, file transfer, deployment automation	Once the machines are up, except while the attack steps run
Attack report	The attacker's steps, commands and results	After the reveal (see step 6)
Topology	Map of the simulated information system	Once the machines are up
IOC	The indicators of compromise left by the attack	After the reveal
Assessment	The questionnaire and the analysts' submissions	Once the attack is over

Information

Learning context: the briefing given to analysts.
Timeline: lab creation, start, end of the attack scenario.
Configuration: what you chose in the wizard, and the Public link to share with your team.
Security monitoring and collaborative tools: one card per analysis tool. The card for the SIEM (here Kibana) shows Interface starting up while it is being deployed. Once it is ready, the card gives the login credentials, an Open button, and the number of security alerts raised so far. The other deployed components (Elasticsearch, Logstash, Suricata, Sysmon, Winlogbeat) are listed underneath.

The SIEM deployed in the lab is reached directly from this card, through the browser: analysts do not need a workstation inside the lab to use it.

Notifications

The progress of the lab, as it happens: reservation of the Cyber Range instance, creation and start of the simulation, then the scenario steps.

Lab interaction

This tab gives access to the machines of the simulated information system, for analysts who need to go beyond the SIEM (live forensics, artifact collection, checking an hypothesis on the endpoint):

Remote desktop: a read-only viewer shows the screen of the selected machine. To take control of a machine, use the noVNC link (in the browser) or the SPICE link (desktop client). The key icon gives the machine's credentials.
Access Guacamole server: browser-based remote access to all machines, available while the lab is paused or once the scenario has finished.
File transfer: push tools into the lab (for example forensic tools) and pull out collected artifacts through the relay server. See File transfer.
Deployment automation: the command line to run your own Ansible playbook on a node with the M&NTIS CLI. See Customizing nodes.

Topology

The map of the simulated information system: the user, admin and server networks, the DMZ, firewalls, and the monitoring network where the SIEM components run. After the reveal, it also shows the attack path (see step 6).

In the Information tab, copy the Public link with the copy icon next to it and send it to your analysts. They do not need an M&NTIS account.

Through this link, analysts get a learner view of the lab:

Learner view opened through the public link

	Trainer (lab owner)	Trainees (public link)
Information (learning context, SIEM access and credentials, alert counter)	Yes	Yes
Lab interaction	Yes	Yes
Topology	Yes, with the attack path after the reveal	Yes, without the attacker's infrastructure
Assessment	Submissions, scores, answers	The questionnaire to fill in
Notifications, Attack report, IOC	Yes	No
Stop / Resume the lab	Yes	No

The learner view never discloses the attacker's steps: analysts have to find them by investigating. Everyone works on the same machines and the same SIEM at the same time, so you can split the work (one analyst per alert, one on the network logs, one on the endpoints) and consolidate the findings together.

Warning

Anyone who has the public link can open the lab and the SIEM. Share it only with your analysts.

Step 5: investigate the alerts in the SIEM

Prepare the detection (optional)

M&NTIS automatically deploys into the SIEM detection rules matching the scenario (Kibana, Splunk, Graylog and Wazuh). They give your analysts a starting point, as a real SOC would have, without telling them the whole story.

You can add your own detection rules on top of them, to train on your organization's detection content or to create more starting points. Do it before the attack steps run, for example while the lab is paused before the first step.

Wait for the attack

The attack scenario is played automatically once the environment is ready. The status goes from Running - SCENARIO_SETUP (deployment of the monitoring chain, of the attacker's infrastructure and of the legitimate activity) to Running - SCENARIO_EXECUTION (attack in progress), then Running - SCENARIO_FINISHED. Without delays between steps, the Lumidus attack steps take about 10 minutes.

Alerts are raised as the attack goes on. The SIEM card in the Information tab shows how many security alerts were raised (here 4 security alerts raised). In a session without pauses, let the scenario finish before your team starts, so that they investigate a complete intrusion. With pauses or delays, they can start as soon as the first alerts come in.

Open Kibana

Click Open on the Kibana card. Kibana opens in a new tab, on the Security > Alerts page. Log in with the credentials displayed on the card.

Start from the alerts

The detection rules deployed by M&NTIS are listed under Security > Rules, as custom rules. In this example, two rules fired, four alerts in total, all on host client1.

Click the expand icon of an alert to open its details: severity, rule, host, link to the source event, and the Investigation and Insights sections.

Pivot to the raw logs

An alert is only the starting point. To rebuild the intrusion, analysts pivot to the raw events in Discover, from the Kibana main menu. Widen the time range so that it covers the whole lab (for example Today), then filter.

The lab collects:

Windows event logs and Sysmon from the Windows machines, through Winlogbeat: process creation, network connections, file creation, logons, and so on;
Suricata events from the network probe: network flows, DNS queries, HTTP requests, IDS alerts.

A few KQL queries to get started:

Goal	Query
Everything that happened on the host of the alert	`host.name : "client1"`
Processes started on Windows machines (Sysmon event 1)	`event.code : "1"`
Network connections made by processes (Sysmon event 3)	`event.code : "3"`
Network events seen by the probe	`event.module : "suricata"`

Remember that legitimate activity runs in the lab too. Analysts have to tell a user browsing the web from a malicious download.

Answer the assessment

If you enabled the assessment, analysts open the Assessment tab of the learner view once the attack is over. The questions (ten for Lumidus) are answered from the evidence gathered in the SIEM: the payload server address, the process created by the payload, the hash of the payload, the Command & Control server, the number of compromised machines, and so on. Some questions come with a hint (light bulb icon). Each analyst clicks Submit when done.

Assessment from the learner's point of view

As the trainer, the Assessment tab of your lab lists every submission with its score. See questions with answers displays the expected answers for the debrief, and Take the test lets you go through the questionnaire yourself.

Assessment from the trainer's point of view

Step 6: debrief, reveal the attacker's steps

This is where a live lab pays off: the platform knows exactly what the attacker did, step by step, and can show it.

While the analysts investigate, the Attack report and IOC tabs are locked so that the trainer is not tempted to give away the answers. Once the scenario is finished, the Information tab shows a Reveal attack's information button. Click it when you are ready for the debrief.

The reveal unlocks these views in your lab page only. The learner view is unchanged, so share your screen to run the debrief.

Attack report

The Graph view shows every step of the kill chain and how each one led to the next. For Lumidus: setup of the attacker's infrastructure, phishing of a user, execution of the downloaded payload, discovery, exploitation of Zerologon against the domain controller, dumping of the NTLM hashes, lateral movement, and finally the encryption of the users' files on several machines.

Click a step to see its details:

the outcome, the start and end times, the source and target machines;
the MITRE ATT&CK tactic and technique;
Console: the commands the attacker ran and the raw output they got back;
Indicators: the traces left by this step;
Knowledge: what the attacker learned (hosts, credentials, ...) and reused in the next steps;
Alerts: the SIEM alerts that the platform has linked to this step.

Detail of an attack step, alerts linked to it

The Timeline view lays the same steps out over time, with attack steps on one line and simulated user actions (such as the user opening the phishing attachment) on another. Use it to compare the timeline your team rebuilt with the real one.

IOC

The IOC tab lists all the indicators of compromise left by the attack: domain names and IP addresses of the attacker's infrastructure, hashes and names of the payloads, URLs, and the hosts concerned. Each indicator is linked to the attack step that produced it (eye icon, See in attack report). It is the checklist for answering which IOCs did we find, and which did we miss?

Topology with the attack path

After the reveal, the Topology tab draws the attacker's path in red across the information system, from the attacker's infrastructure on the Internet to the compromised workstations and the domain controller.

Running the debrief

A simple structure for the debrief:

Let the team present its story first: the timeline it rebuilt, the machines it believes are compromised, the IOCs it found.
Walk through the attack report step by step and compare it with the team's findings.
Look at detection coverage: in the attack report, check which steps have alerts attached and which do not. In this run, only Zerologon exploitation and hash dumping raised alerts. Every other step had to be found by hunting in the logs. The steps that produced no alert show where your detection rules need work.
Go through the IOC tab to list what the team missed.
Review the assessment scores with See questions with answers.

Step 7: stop the lab

When the session is over, click Stop at the top of the lab page and confirm. Otherwise the lab stops by itself when its maximum duration is reached. Once stopped, the machines and the SIEM are no longer accessible. Your lab still appears in Labs in the left menu.

Going further

Replay the same scenario with a different SIEM, or with an EDR from the Advanced integrations, to train on the tools your team actually uses.
Use pauses and delays to turn the exercise into a step-by-step investigation, debriefed after each attack step.
To learn more about each integration, see Monitoring and integrations.
To prepare a lab with your own tools, see Customizing nodes.