Threat scenarios
A threat scenario is a sequence of attacker gestures: a phishing email received, the link clicked, a risky sign-in, a mailbox rule… The library under Configuration → Threat scenarios is the one place where threats are configured, and every scenario serves two uses:
- grafted at random onto a community — it then takes turns, hour after hour, with the other scenarios of its rotation on the compromised hosts (see Attacker background noise);
- launched on demand from a community's Threats tab — now, for a bounded duration.
Threats used to be archetypes of “threat” kind, configured with the editor of working days. They became scenarios: an archetype is now always a business day.
The library, pre-populated
| Scenario | Family | What it chains |
|---|---|---|
| Compromission de messagerie (BEC) | Business email compromise | Phishing email → click → risky sign-in from abroad → stolen session → forwarding rule → mailbox reading → fraudulent transfer request → payload on the workstation → privilege escalation → credential theft → pivot → privilege escalation on the server |
| Déni de service distribué | Denial of service | Probing of a site → burst of requests from thousands of addresses → legitimate traffic comes back |
| Rançongiciel | Ransomware | Payload → execution → persistence → reconnaissance → credential theft → pivot → data egress → mass encryption and deletion of documents → detection |
| Pulvérisation de mots de passe | Credential attack | Bursts of authentication failures from outside → spray detected → successful sign-in, flagged as risky → second factor requested |
| Sabotage d’automate (type Triton) | Industrial control systems | C2 beacon → control-network scan → tampering with a safety controller's program → the controller is stopped |
| Débordement de l’IT vers l’OT | Industrial control systems | Payload → execution on a management workstation → credential theft → pivot → discovery of the control network → a controller is stopped |
| Homme du milieu industriel | Industrial control systems | ARP spoofing on the control segment → unauthorized control commands injected into the controller |
| Micrologiciel piégé | Industrial control systems | Malicious domain resolved → firmware retrieved → a non-vendor firmware is loaded → the controller is restarted |
| Déni de service industriel | Industrial control systems | Control-network scan → SYN flood that saturates the controller |
| Commandes de conduite malveillantes (type Industroyer2) | Industrial control systems | IEC-104 reconnaissance → breaker-open commands → station controllers stopped |
| Pirate | Network intrusion | The full attack chain, from brute force to exfiltration, in under an hour |
| Balise vers le serveur de commande | Command and control | Resolution of the command server → beacon every ten minutes |
| Téléchargement de charge | Network intrusion | Resolution → retrieval of the second stage → execution |
| Reconnaissance | Network intrusion | Directory enumeration |
| Vol d’identifiants et rebond | Credential attack | Secret extraction → pivot to another host |
| Exfiltration | Data exfiltration | Upload to the attacker → detected bulk egress |
| Ancrage et persistance | Network intrusion | Implant wake-up → anchoring on the machine |
| Battement de l’implant | Command and control | A beacon every two hours — a background scenario |
The last eight are the threats that existed before the library — they were converted, not rewritten. Scenario names are seeded data, not interface, which is why they stay in French. Seeding is create-only: a scenario edited from the screen survives the next seed.
Six scenarios demonstrate detection on industrial (OT) networks, with Nozomi Vantage as the
sensor. Because the targeted controller is a destination, the Nozomi alert and the flow observers
(firewall, EDR) name the same IP and port at the same second — the STOP command is not seen by the
probe alone. Run them on an industrial population (for example demo-cyberdyne-systems): on a
population without field devices, their OT steps are skipped.
A scenario's identity
| Field | What it decides |
|---|---|
| Family | A label to file the library by — nothing is decided on it |
| Targets | Which slices of the population can play its steps: workstations, servers, sites |
| Background scenario | When grafted, it plays all day long outside the rotation — the implant heartbeat is the case |
A scenario that targets only sites — the denial of service — cannot be grafted: the graft compromises workstations and servers. It is launched on demand.
The steps
Each step is a gesture of the action catalogue — the same one archetypes assemble — placed at an offset in minutes from the start of the scenario.
| Column | What it says |
|---|---|
| Offset | Minutes from the start — or from the start of the hour, in a rotation |
| Action | The gesture: a threat action, or a business one the scenario borrows (a fraudulent email is mail) |
| Label | How the gesture is named in the threat journal — the catalogue's label when empty |
| Times | How many gestures — empty means “until the end”, every interval minutes |
| Every | Minutes between two gestures, required as soon as the step repeats |
| Jitter | Up to an hour of spread around each due time |
| Parallel | Simultaneous gestures at each due time — a denial-of-service burst — up to fifty |
| Played by | A slice, or any target of the scenario that the action admits |
| Off site | The gesture happens away from the office — a sign-in from abroad |
Each step waits for the end of the previous one. A spread can therefore never make the click happen before the email arrives. A step repeated “until the end” has no end to wait for: the next one then chains to the last bounded step before it.
In a rotation, a scenario replays in every hour that falls to it, from the start of that hour. A step whose offset goes beyond the first hour never happens there — the editor warns about it, without refusing: the same scenario can be launched by hand over two hours.
Under each step, the editor names the log sources that have a message for its action, on a line that spans the whole width of the table. Up to three sources, it is unfolded from the start; beyond that, it folds down to its count and the first names — “Seen by 14 sources, 3 alert only — Bind · Fortinet FortiGate · …” — and unfolds with a click. Unfolded, it sorts the sources into two groups of chips, Emitting then Alert only. The line follows the select as soon as the action changes, before anything is saved. A source in the Alert only group covers the gesture with alert message types only: a launch sends them, as a fallback when the source has nothing else to describe the gesture; the rotation of a graft, which plays the normal flow, keeps them silent. The phishing email received is the case: both Office 365 sources describe it only with alerts. When no source covers the action, the line says so in amber. The list names every source of the catalogue, whereas a launch only plays the technologies of its community, and sends only for those with an intake key: a step that none of them covers appears among the “Steps that no active technology covers”.
Without JavaScript, the sequence is edited as JSON in the same field — one object per step — and the log sources of the saved steps are listed under it. The editor and the API validate it with the same function: the screen cannot accept what the API would refuse.
Saving the steps reaches, within the minute, the communities grafting the scenario: their day plan goes stale and is rebuilt on the next tick. A grafted scenario cannot be deleted — the refusal names the communities; its past launches survive it, under its name.
The threat actions
Eleven threat gestures existed; six were added for the scenarios, and the coverage of the corpus names them:
| Action | What the logs show of it |
|---|---|
| Phishing email received | Office 365 threat intelligence, quarantine in the message trace |
| Click on a trapped link | Office 365 URL click |
| Risky sign-in | Entra ID risk detection, Google Workspace risky authorisation |
| Malicious mailbox rule | Office 365 inbox rule, Google Workspace external forwarding |
| Privilege escalation | Windows privileged service, Office 365 admin role, SentinelOne Identity |
| Denial-of-service burst | Akamai WAF rate limit and bot / reputation denials — played by a site |
Most of these event types are reserved for alerts: the per-minute flow never emits them. A scenario launched on demand emits them when the technology has nothing else to describe the gesture with — without that, a business email compromise would be silent at the mailbox.
There is no ransomware action: no event type of the corpus names one. The Ransomware scenario is therefore built from existing gestures — the encryption is a burst of document modifications.