36 modules, 191 bricks and 322 labs, organised by domain. The brick is a standalone learning unit: a learner can order and complete it on its own, with its hands-on lab(s). Every component can be ordered individually — from the brick to the module up to the career path. Each module is detailed by its syllabus.
Choose your level of granularity — click Brick or Module.
Does cybersecurity feel reserved for specialists? This first course is here to prove otherwise. In a few days, with no advanced technical prerequisites, you will understand how a company's digital world works, how cyberattacks happen, and what can be done to protect against them.
Ransomware encrypts a small company's servers on a Friday night: what happened, and what was truly at stake? Answering it cleanly demands precise vocabulary — the vocabulary this building block establishes. You connect asset, threat and vulnerability, then risk: a potential scenario weighted by likelihood and impact. Crucially, you separate risk, which is anticipated, from the incident, which is its materialisation, and describe an incident by the security properties it breaches (confidentiality, integrity, availability). You begin to speak the shared language of risk management — the language that lets an organisation make, and defend, a security decision.
Objective : Qualify an incident against the CIA triad and the asset/threat/vulnerability/risk concepts.
Concepts : Confidentiality, Integrity, Availability, authenticity, non-repudiation · Asset, threat, vulnerability, risk · 2026 threat landscape
Challenge : Classify a provided incident (ransom note + logs) by the CIA properties violated.
Expected outcomes : Validated if the CIA classification is correct, the asset×threat matrix consistent and the rating justified; the flag attests a correct reading of the challenge incident.
Opening a network capture for the first time means facing thousands of seemingly indecipherable lines. With Wireshark, you learn to bring order to them: following a communication layer by layer, from the OSI model to the TCP handshake, and telling normal traffic from the abnormal — knowing that encrypted traffic still reveals its metadata (addresses, ports, volume). You practise on a capture that hides a port scan, which you must isolate. Reading traffic is a foundational skill you will reuse across defence and offensive analysis alike — the starting point of any investigation.
Objective : Read a communication layer by layer and spot an abnormal exchange.
Concepts : 7 OSI layers / 4 TCP-IP · Encapsulation, ports, TCP handshake · DNS/DHCP
Challenge : Find the scanning IP and the targeted port in the capture.
Expected outcomes : Validated if the handshake is correctly annotated and if the scan's source IP and targeted port are found in the capture (flag as proof).
Testing a security technique on your work machine risks irreversible damage; professionals work in a disposable environment they can compromise and reset. With Proxmox, you deploy a virtual machine on a segmented network and apply a first layer of hardening, handling three notions that recur everywhere: the hypervisor, the snapshot (a saved state to return to) and network segmentation. The challenge is a single proof — that no traffic leaves the machine except towards the lab server. You gain the prerequisite of every safe test bench: an environment that contains, rather than spreads, what you run in it.
Objective : Create a VM on an isolated network and apply minimal hardening.
Concepts : Type 1/2 hypervisor, snapshots · NAT/host-only/isolated networks · Basic hardening
Challenge : Prove that no network egress is possible except to the lab server.
Expected outcomes : Validated if the VM reaches no destination outside the lab server and if the reference snapshot exists; the isolation proof is expected.
How many services does an organisation leave exposed on the internet without knowing? Usually far more than it thinks. With Shodan and Censys, you map this external attack surface from already-collected data, without sending a single request to the target — passive reconnaissance. You read service banners, refine your filters, and surface what should never be reachable, down to the most critical exposed administration interface. This is, first, how a defender audits their own perimeter; and, in the same move, what an attacker sees before striking.
Objective : Discover an organisation's external exposure from open sources.
Concepts : External footprint, banners · Shodan/Censys filters · Risk of exposed admin panels
Challenge : Find the most critical exposed administration service.
Expected outcomes : Validated if the inventory of exposed services is complete and if the most critical administration service is correctly designated.
An organisation can run a firewall, an antivirus and backups, and still be paralysed: juxtaposed protections are not a defence if they overlap in places and leave blind spots in others. You map concrete measures onto the six functions of the NIST CSF 2.0 — Govern, Identify, Protect, Detect, Respond, Recover — one widely used framework among others (ISO 27001, national frameworks). You classify controls as preventive, detective or corrective, and pinpoint the weakest-covered function. You leave with a reusable grid to structure, assess and steer a security posture.
Objective : Map concrete controls to the 6 functions of NIST CSF 2.0.
Concepts : Layers of defence · 6 CSF 2.0 functions (Govern…Recover) · Preventive/detective/corrective
Challenge : Classify 12 controls and name the weakest function.
Expected outcomes : Validated if the twelve controls are correctly attached to the six functions and if the weakest function is correctly identified.
Encrypting a file, proving it has not been altered, requiring a second factor at login: three everyday acts, all built on applied cryptography. With OpenSSL you encrypt a file and verify its integrity by hashing, then stand up strong authentication — clarifying two distinctions that are routinely blurred: symmetric versus asymmetric encryption, and hashing versus encryption. The decisive point: not all second factors are equal. You deploy one that is genuinely phishing-resistant (FIDO2/passkeys), where a one-time code can be intercepted. You learn to protect both a piece of data and an access — and to prove it.
Objective : Protect a file and verify its integrity.
Concepts : Symmetric vs asymmetric · Hashing and integrity · Password good practice
Challenge : Give the SHA-256 of the sample file and prove the alteration.
Expected outcomes : Validated if the file is encrypted and decrypted without loss, and if the provided fingerprint proves the alteration of one byte.
Objective : Put in place MFA and a robust password policy.
Concepts : MFA, FIDO2/passkeys · Password manager · Credential phishing
Challenge : Prove that login requires a phishing-resistant second factor.
Expected outcomes : Validated if re-login requires a phishing-resistant second factor, with proof.
An American fuel-pipeline operator halts distribution after a ransomware intrusion that entered through a VPN account with no multi-factor authentication.
Mission : Place the main families of threat and explain how a single poorly protected access point becomes the materialisation of a major risk for an organisation and its users.
Hundreds of thousands of connected devices left on factory default passwords are enrolled into a network of compromised machines that paralyses large online services.
Mission : Discover the consumer attack surface and measure the scale effect of weak hygiene on the availability of third-party services.
Linux is the playground — and workplace — of all cybersecurity. This course makes you comfortable with it: the command line, automation, networking and Docker containers. You learn by doing, until the terminal becomes second nature.
On most servers and containers there is no graphical interface — everything runs through the command line. This building block makes you fluent there: the file system and its permissions (read, write, execute, and the SUID bit that runs a program with its owner's privileges), accounts and groups, then text processing with grep, awk and sed. You inspect a machine, flag an abnormal SUID binary (a classic privilege-escalation path), and pull the signal out of a bulky log. The command line stops being a barrier and becomes a tool you command.
Objective : Inspect a Linux system and its permissions at the CLI.
Concepts : FHS, rwx/SUID · Users/groups
Challenge : Find the unusual SUID binary.
Expected outcomes : Validated if the SUID binaries audit is completed and if the abnormal binary is correctly isolated.
Objective : Manipulate data with grep/awk/sed.
Concepts : Redirections, pipes · grep/awk/sed
Challenge : Give the most frequent IP in the provided log.
Expected outcomes : Validated if the filter chain produces the right count and if the most frequent IP is exact.
Automation saves time — until a fragile script erases what it was meant to back up. You learn to write Bash that fails cleanly and re-runs without harm (idempotence) and logs what it does, then to schedule and supervise recurring tasks with cron and systemd timers. You ship a backup script whose result can be verified, and prove that a scheduled job fired and recorded itself. You gain what it takes to make repetitive operations dependable — from backups to evidence collection.
Objective : Write a reliable, idempotent backup script.
Concepts : set -euo pipefail · Logging, idempotence
Challenge : Provide a script producing a verifiable archive.
Expected outcomes : Validated if the script produces a timestamped archive verifiable by its fingerprint, and runs without error when re-launched.
Objective : Schedule and supervise recurring tasks.
Concepts : Cron vs timers · Execution logs
Challenge : Prove the timer's triggering and its logging.
Expected outcomes : Validated if the timer triggers at the expected times and if its execution (and failure) are logged.
Two administration questions reveal much about a machine's security: what is running on it, and where did its software come from? With systemd and journalctl you diagnose processes and services; with APT and dpkg you manage packages and repositories while verifying their signatures. You uncover a service enabled behind your back — a form of attacker persistence — and an unsigned package, a possible foothold for a supply-chain compromise. You can then establish a system's true state and trace the provenance of its software.
Objective : Diagnose processes and services.
Concepts : Processes, signals · systemd/journalctl
Challenge : Give the malicious service enabled on the VM.
Expected outcomes : Validated if the diagnosis distinguishes the malicious service from the rest and names it correctly.
Objective : Package and manage dependencies cleanly.
Concepts : APT/dpkg · Repositories and signatures
Challenge : Give the unsigned package detected.
Expected outcomes : Validated if the signature verification is carried out and if the unsigned package is correctly identified.
A freshly installed machine usually listens on more ports than it needs, and every open port is another door. You configure addressing and routing under Linux (Netplan), then restrict inbound connections with UFW, layered over nftables. The objective is unambiguous: leave only SSH reachable from the lab subnet, and prove it. You can then cut a machine's network exposure down to the strict minimum — the simplest, highest-return hardening there is.
Objective : Configure addressing, routing and UFW.
Concepts : Netplan/ip, routes · nftables/UFW deny
Challenge : Expose only SSH to the lab subnet and prove it.
Expected outcomes : Validated if only SSH is reachable from the lab subnet, with ss/tcpdump verification as proof.
A container is not watertight by nature: its security is decided by how you build its image and how you run it. You build a hardened Docker image — non-root, with a read-only file system — while grasping its successive layers and the kernel isolation mechanisms (namespaces, cgroups). You scan it with Trivy and ship it free of known critical vulnerabilities. You can now produce a container that tightens the attack surface instead of widening it — the unit of trust of any cloud-native platform.
Objective : Build a non-root, read-only image.
Concepts : Images/layers, Dockerfile · Namespaces/cgroups, limits
Challenge : Deliver an image with no high CVE (Trivy report).
Expected outcomes : Validated if the image runs non-root, read-only, and if the Trivy report shows no high-severity vulnerability.
A contributor plants a backdoor in a compression library present on most Linux distributions, targeting the SSH daemon.
Mission : Understand the ecosystem of open-source packages and dependencies, and read a process tree to spot abnormal behaviour when a service starts.
A state actor persists in infrastructure networks using only legitimate system tools, deploying no detectable malware.
Mission : Identify common system commands diverted from their intended use and build the first reflexes for reading logs on Linux.
A bank sees more than a hundred million records exfiltrated after the abuse of an over-permissive technical role on a hosted instance.
Mission : Become familiar with isolation, service accounts and the separation of privileges across instances and containers.
This course teaches you to look at a network the way professionals do: spot what is flowing, what is wrong, and where vulnerabilities hide. It is the gateway to investigation, advanced defence and penetration testing.
You attack and defend only what you have mapped. With Nmap you discover hosts, ports and services — setting scan types, pace and version detection — then enumerate Windows services (SMB shares, LDAP directory) from Linux. You tie a service version to a known vulnerability (CVE) and surface a share open to anonymous access. It is the inventory a penetration tester draws up, and the one a defender needs to know their own perimeter.
Objective : Map hosts, ports and services.
Concepts : SYN/connect/UDP scans, timing · OS/version detection
Challenge : Identify the vulnerable service by its version and its CVE.
Expected outcomes : Validated if the mapping is complete and if the vulnerable service is linked to the right version and the right CVE.
Objective : Enumerate Windows services from Linux.
Concepts : SMB shares, null sessions · LDAP/directory
Challenge : Give the SMB share accessible for anonymous reading.
Expected outcomes : Validated if the SMB/LDAP enumeration is carried out and if the anonymously readable share is correctly identified.
The same capture can stay opaque or tell the whole story, depending on whether you keep it raw or turn it into structured logs. With Zeek you make that shift, converting traffic into usable logs — connections, DNS, HTTP, TLS — that you compare against a baseline. You catch a command-and-control server by its regular, repetitive traffic (beaconing), and pull out a credential travelling in clear text. You learn to separate signal from noise — the core skill of both detection and network investigation.
Objective : Turn a capture into usable logs.
Concepts : conn/dns/http/ssl logs · Baseline vs deviation
Challenge : Give the C2 domain identified by beaconing.
Expected outcomes : Validated if the Zeek logs are produced and if the command-and-control domain is isolated by its beaconing.
Objective : Decode common application protocols.
Concepts : Cleartext HTTP/FTP/DNS · Credential extraction
Challenge : Give the FTP credential captured in cleartext.
Expected outcomes : Validated if the FTP session is isolated in the capture and if the credential transmitted in clear is correctly extracted.
To detect a network attack, you first need to know it from the inside. In a controlled environment you practise ARP cache poisoning — which lets an attacker slip into a conversation (the on-path, or man-in-the-middle, attack) — then evasion techniques that try to slip past a detection sensor (fragmentation, decoys, timing). Each time the goal stays detection: find the attacker's address, name the technique that bypassed the sensor. You gauge what perimeter defences stop, and what slips around them.
Objective : Understand and detect ARP poisoning.
Concepts : ARP, spoofing, MitM · Detection via ARP table
Challenge : Give the MAC of the detected attacker.
Expected outcomes : Validated if the man-in-the-middle attack is set up and detected, and if the attacker's MAC is correctly recorded.
Objective : Understand detection-evasion techniques.
Concepts : Fragmentation, decoys, timing · IDS fingerprint
Challenge : Give the evasion technique that escaped the IDS.
Expected outcomes : Validated if the comparison of techniques is documented and if the one that escaped the IDS is correctly named.
Running a vulnerability scanner is easy; turning its output into sound decisions is not, because it also flags problems that are not real (false positives). With OpenVAS you run an assessment, prioritise by the CVSS severity score, validate what is genuinely exploitable, then drive the hardening loop: fix, re-scan, measure the gap. You isolate the most critical confirmed vulnerability and cut the attack surface to a single port, with proof. You close the cycle that underpins all remediation: assess, fix, verify.
Objective : Identify and triage network vulnerabilities.
Concepts : CVSS, false positives · Validation
Challenge : Give the most critical validated vulnerability.
Expected outcomes : Validated if false positives are ruled out and if the most critical validated vulnerability is correctly designated.
Objective : Fix the weaknesses found and re-scan.
Concepts : Attack surface · scan→fix→re-scan loop
Challenge : Reduce the surface to a single port and provide the diff.
Expected outcomes : Validated if the surface is reduced to a single port and if the before/after differential is provided.
An Australian telecoms operator sees the data of nearly ten million customers extracted through an application interface reachable without authentication, with sequential identifiers.
Mission : Discover scanning, enumeration and the risk of predictable identifiers, at an introductory level.
A critical flaw in a very widely used logging library triggers mass scanning of the internet in search of vulnerable targets.
Mission : Understand the mapping of the exposed surface and the urgency of an up-to-date inventory of software components.
Several energy suppliers are targeted on the same day through internet-facing firewalls, with a direct risk to the electricity supply.
Mission : Connect the network exposure of a perimeter device to a concrete consequence for users.
A widely deployed enterprise VPN gateway is exploited by chaining two flaws, opening remote access.
Mission : Grasp the notion of an exposed perimeter service and the principle of a chain of vulnerabilities.
Small-office and home routers, now end-of-life and unpatched, are compromised to conceal espionage activity.
Mission : Learn to inventory forgotten network equipment (shadow IT) and understand the risk it carries.
Cryptography protects everything else — provided it is used correctly. This module teaches you to use encryption, signatures and TLS/SSH properly, to spot dangerous configurations, all the way to the post-quantum challenge.
Encrypting data is not enough if you pick the wrong mode: an image encrypted in ECB mode still leaks its shape. With OpenSSL you work symmetric encryption hands-on — ECB, CBC, GCM modes, initialisation vector (IV), padding — and demonstrate the ECB leak for yourself. You then guarantee a message's integrity and authenticity with hashing and HMAC (a message authentication code built on a secret key). You leave able not just to encrypt, but to encrypt correctly, and to prove a message has not been tampered with.
Objective : Encrypt correctly in symmetric and demonstrate the ECB leak.
Concepts : ECB/CBC/GCM modes, IV · Padding
Challenge : Explain the ECB leak and give the correct mode.
Expected outcomes : Validated if the ECB leak is visually demonstrated and if the safe mode (GCM) is correctly justified.
Objective : Guarantee the integrity and authenticity of a message.
Concepts : SHA-2/3, collisions · HMAC, salt
Challenge : Give the HMAC of the sample file.
Expected outcomes : Validated if the alteration is detected and if the HMAC of the sample file is exact.
How do two machines that have never spoken establish a shared secret over an open network? That is the whole point of asymmetric cryptography. With OpenSSL you handle RSA and elliptic-curve (ECC) key pairs and the Diffie-Hellman exchange, then issue a certificate and sign a document through a public-key infrastructure (PKI). You connect digital signature and non-repudiation — the guarantee that a signer cannot deny their act. You grasp what makes your browser's padlock and a signed contract actually work, under the hood.
Objective : Handle asymmetric keys and Diffie-Hellman.
Concepts : RSA/ECC · Diffie-Hellman
Challenge : Give the fingerprint of the generated public key.
Expected outcomes : Validated if the DH exchange yields the same secret on both sides and if the public key fingerprint is correct.
Objective : Issue a certificate and sign a document.
Concepts : PKI, CA, revocation · Signature/non-repudiation
Challenge : Provide the signed certificate and the signature fingerprint.
Expected outcomes : Validated if the certificate is issued by the lab CA and if the signature verifies via the chain of trust.
An encrypted service can stay vulnerable if it still accepts old options: encryption is only as good as its configuration. With testssl.sh you deploy and audit TLS 1.3 — cipher suites, the HSTS header that forces HTTPS — then harden SSH access to the state of the art. You flush out an obsolete cipher suite on a decoy service and prove that SSH password login is refused in favour of keys. You can audit and tighten the configuration of the two protocols that secure most remote access.
Objective : Configure and audit TLS.
Concepts : TLS 1.3 handshake, suites · HSTS
Challenge : Give the obsolete suite detected on the trap service.
Expected outcomes : Validated if the audit is carried out and if the trap service's obsolete suite or version is correctly identified.
Objective : Secure an SSH access to the state of the art.
Concepts : Keys vs password · Modern algorithms
Challenge : Prove that password authentication is refused.
Expected outcomes : Validated if key access works and if password authentication is effectively refused.
Cryptography rarely breaks by attacking the algorithms themselves, but by exploiting how they are used. You first recover a password protected by a weak (unsalted) hash and exploit an initialisation-vector reuse — the most common implementation mistakes. You then anticipate the quantum threat and the 'harvest now, decrypt later' strategy (HNDL), identifying which uses to migrate to post-quantum algorithms (ML-KEM, ML-DSA). You leave able to spot misused cryptography and to prepare a transition that already concerns long-lived data.
Objective : Spot and exploit poorly used crypto.
Concepts : IV reuse · Unsalted hashing
Challenge : Recover the password protected by a weak hash.
Expected outcomes : Validated if the password is recovered and if the weakness (unsalted hash or reused IV) is explained.
Objective : Anticipate the PQC migration and manage keys.
Concepts : Quantum threat, HNDL · ML-KEM/ML-DSA
Challenge : List the 2 priority uses to migrate and the target algorithm.
Expected outcomes : Validated if the inventory is prioritised and if the two uses to migrate and the target algorithm are correctly designated.
A design weakness in the SSH protocol allows, through prefix truncation, the encrypted negotiation of a session to be weakened without alerting either party.
Mission : Analyse a flaw at the level of a cryptographic protocol and reason about the integrity of session negotiation rather than the strength of the algorithm alone.
An actor obtains a Microsoft account signing key and forges authentication tokens to reach mailboxes, including those of government bodies.
Mission : Understand the stakes of key management and measure the effect of a signing-key compromise on an entire authentication chain.
A well-segmented, hardened network is the first line of defence. This module teaches you to build it: deny-all segmentation, system hardening, detection (IDS/IPS), decoys and first steps toward Zero Trust.
A flat network lets an intruder roam freely once inside; segmenting it means compartmentalising to contain. With pfSense you carve up a network (VLAN, demilitarised zone — DMZ, micro-segmentation) and apply allow-list filtering — everything denied by default, only the necessary permitted. The challenge is concrete: prove that the management zone is isolated from the rest. You can design a partitioning that limits the spread of a compromise instead of easing it.
Objective : Segment a network and filter by allow-list.
Concepts : VLAN, DMZ, micro-segmentation · Default deny
Challenge : Prove the isolation of the management zone.
Expected outcomes : Validated if inter-zone flows are allow-listed and if the isolation of the management zone is proven.
A system shipped 'by default' is rarely a secure system: it exposes services and settings it does not need. You apply recognised hardening baselines — CIS benchmarks on Linux, Group Policy (GPO) on Windows — and measure the before/after gap. You push a CIS score above a threshold and identify the GPO setting that blocks a test attack. You can methodically shrink a fleet's exposure, leaning on standards rather than intuition.
Objective : Apply a CIS benchmark and measure the gap.
Concepts : CIS benchmarks · Service surface
Challenge : Bring the CIS score above the threshold.
Expected outcomes : Validated if five gaps are fixed and if the CIS score exceeds the threshold after re-measurement.
Objective : Secure Windows hosts via policies.
Concepts : GPO, baselines · Accounts/services
Challenge : Give the GPO parameter that blocks the sample attack.
Expected outcomes : Validated if the baseline is applied and if the GPO parameter blocking the attack is correctly identified.
Detecting an intrusion needs a sensor that knows what to look for — and that does not cry wolf at every turn. With Suricata you deploy an intrusion detection and prevention system (IDS/IPS), distinguishing signature-based from anomaly-based detection, and working with false positives. You write a rule that catches a decoy user-agent in the traffic. You can put in place useful network detection whose noise stays under control.
Objective : Deploy a detection and write a rule.
Concepts : Signature vs anomaly · False positives
Challenge : Provide the rule detecting the trap user-agent.
Expected outcomes : Validated if the custom rule triggers on the trap user-agent without obvious false positive.
What if, rather than waiting for the alert, you set a trap that only trips for an intruder? That is the principle of decoys. With Cowrie you deploy a honeypot (a fake service meant to lure the attacker) and honeytokens (baits — a file, a credential — whose every access is inherently suspect). The challenge: capture access to a honeytoken, with timestamp and address. You add early, low-noise detection to your arsenal, where an illegitimate access gives itself away.
Objective : Detect through decoys.
Concepts : Honeypots, canaries · Early detection
Challenge : Capture the access to the honeytoken (timestamp+IP).
Expected outcomes : Validated if the access to the honeytoken is captured with its timestamp and source IP.
'Never trust, always verify': the Zero Trust model overturns the idea of an inherently safe internal network. This building block lays its foundations from the NIST 800-207 framework — policy decision and enforcement points (PDP/PEP), identity as the perimeter — and has you sketch an access policy. The challenge: demonstrate a compliant denial when a request falls outside its authorised context. You grasp the deep shift Zero Trust brings, whose identity-side implementation you will deepen later in the path.
Objective : Sketch a Zero Trust access policy.
Concepts : NIST 800-207, PEP/PDP · Identity as perimeter
Challenge : Prove a compliant out-of-context access denial.
Expected outcomes : Validated if the policy allows in-context access and denies out-of-context access, with trace as proof.
Wireless extends the network beyond the walls — and the attack surface with it. With aircrack-ng you assess the security of a Wi-Fi access point (WPA2/3, EAP authentication) and spot a rogue access point, then control outbound traffic through a filtering proxy (Squid). You identify a rogue access point's SSID and prove the blocking of a known command-and-control domain. You cover both sides of an access: the wireless way in and the way out to the internet.
Objective : Assess the security of a wireless access.
Concepts : WPA2/3, EAP · Rogue AP
Challenge : Give the SSID of the detected rogue access point.
Expected outcomes : Validated if the robustness is assessed and if the rogue AP's SSID is correctly identified.
Objective : Control outbound flows via a proxy.
Concepts : Proxy, URL filtering · Inspection
Challenge : Prove the blocking of a known C2 domain.
Expected outcomes : Validated if the proxy logs accesses and if the C2 domain is effectively blocked.
Danish energy firms are compromised through remote code execution on internet-facing firewalls, via the IKE negotiation service.
Mission : Harden perimeter firewalls, close unnecessary exposed services and segment to contain an intrusion.
A memory leak on access gateways allows session tokens to be recovered and multi-factor authentication to be bypassed.
Mission : Put in place gateway hardening, session management and a patch policy on exposed equipment.
A chain of two flaws on widely deployed VPN appliances opens persistent remote access.
Mission : Segment and monitor perimeter appliances, and anticipate the scenario of a trusted appliance being compromised.
Unmaintained small-office routers serve as relays for a state actor.
Mission : Manage the life cycle of network equipment, retire obsolete hardware and harden default configurations.
An actor progresses through infrastructure networks relying on legitimate tools, with no malware.
Mission : Design internal segmentation that limits lateral movement and reduces the reach of an initial compromise.
At the heart of a SOC, you must see, understand and react fast. This module trains you to operate a tier-1 security operations centre: collect logs, correlate, alert, triage and launch first responses.
A SOC is only as good as the logs it receives: without the right source, the attack stays invisible. You design log collection for a security operations centre (SOC) — endpoint, network and cloud sources, and the N1/N2/N3 roles — then normalise heterogeneous logs to a common schema (ECS). You identify the missing source that hides an exfiltration and recover a normalised field after processing. You lay the foundations without which any later detection would be blind.
Objective : Design log collection.
Concepts : N1/N2/N3 roles, MTTD/MTTR · Endpoint/network/cloud sources
Challenge : List the absent source preventing detection of an exfiltration.
Expected outcomes : Validated if ingestion works and if the critical missing source is correctly identified.
Objective : Normalise heterogeneous logs (ECS).
Concepts : Parsing, ECS · Timestamps/time zones
Challenge : Give the ECS field of the source IP after normalisation.
Expected outcomes : Validated if the log is mapped onto ECS and if the ECS field of the source IP is correct.
Millions of events are useless if you cannot query and cross-reference them. With the KQL query language you pivot through a SIEM (the central system that aggregates and analyses logs), correlate events over a time window, then build dashboards and alert rules. You unmask the account targeted by a password-spraying attack and write an alert on ten failed logins in one minute. You turn a mass of logs into signals an analyst can act on.
Objective : Query the SIEM and correlate events.
Concepts : KQL/EQL, pivots · Time window
Challenge : Identify the password-spraying victim account and the IP.
Expected outcomes : Validated if the correlation establishes the password spraying and if the victim account and the IP are correct.
Objective : Build dashboards and alert rules.
Concepts : SOC indicators · Alert thresholds
Challenge : Provide the alert rule on 10 failures in 1 min.
Expected outcomes : Validated if the dashboard is operational and if the ten-failures/minute alert rule triggers correctly.
The network does not show everything; what runs on the machine, however, does not lie. With Sysmon and the logic of an EDR (the endpoint detection and response solution) you exploit endpoint telemetry: process tree, file creations, connections (Sysmon events 1, 3, 11). You trace a process back to the parent that launched the malicious payload, with its hash. You can read the story of a compromise as the machine itself tells it.
Objective : Understand endpoint telemetry.
Concepts : Process tree · Sysmon 1/3/11
Challenge : Give the parent that launched the payload and its hash.
Expected outcomes : Validated if the process tree is reconstructed and if the parent and the payload hash are correct.
A SOC analyst receives more alerts than they can handle: knowing which deserve a reaction is the heart of the job. With TheHive you triage alerts against a playbook (a documented decision procedure) — rating severity, discarding false positives, deciding whether to escalate. The challenge: deliver a triage decision and the matching containment action. You gain the method that sets an effective SOC apart from one drowning in noise.
Objective : Triage according to a playbook and decide escalation.
Concepts : Severity, FP · Escalation criteria
Challenge : Give the triage decision and the containment action.
Expected outcomes : Validated if the playbook is followed and if the triage decision and the containment action are justified.
Phishing remains one of the leading ways into an attack — and it leaves traces, in the email as on the network. You dissect a malicious email: headers, the SPF/DKIM/DMARC anti-spoofing mechanisms, URLs and attachments, to unmask the spoofed sender and the phishing address. You then spot, on the traffic side, the command-and-control domain contacted after it is opened. You connect both ends of an email attack: the lure received and the network activity it triggers.
Objective : Analyse a malicious email.
Concepts : Headers, SPF/DKIM/DMARC · URL/attachment
Challenge : Give the spoofed sender and the phishing URL.
Expected outcomes : Validated if the spoofing is demonstrated by the headers and if the spoofed sender and the URL are correct.
Objective : Exploit network telemetry in the SIEM.
Concepts : Zeek logs · Beaconing/exfiltration
Challenge : Give the C2 domain detected on the SOC side.
Expected outcomes : Validated if the beaconing is isolated and if the C2 domain is correctly identified in the SIEM.
As alerts multiply, a human can no longer handle everything by hand: what can be automated must be. With a SOAR tool (security orchestration, automation and response) — Shuffle — you build an automated response that enriches then isolates on an indicator of compromise (IOC). You then measure SOC performance (detection and response times, false-positive rate) and bring it down through fine-tuning. You connect automation and continuous improvement, two levers to carry the load without sacrificing quality.
Objective : Automate a simple response action.
Concepts : SOAR playbooks · Auto-enrichment
Challenge : Provide the playbook that enriches and isolates on an IOC.
Expected outcomes : Validated if the playbook enriches the IP and triggers isolation on the indicator.
Objective : Measure performance and reduce noise.
Concepts : MTTD/MTTR, FP rate · Tuning
Challenge : Give the FP reduction obtained after tuning.
Expected outcomes : Validated if the rule is refined without loss of detection and if the false-positive reduction is quantified.
Exploitation of a logging library generates outbound requests to attacker-controlled servers.
Mission : Write detection rules for JNDI/LDAP exploitation and sort through the noise of mass scanning.
A previously unknown SQL injection in a file-transfer tool allows a web shell to be planted and data to be exfiltrated from thousands of organisations.
Mission : Detect the trace of a web shell in web-server logs and build the corresponding alert.
Access to an identity provider's support system exposes customers' session files.
Mission : Correlate anomalous sign-ins and exploit authentication logs to spot session abuse.
Customer tenants on a data platform are plundered using credentials stolen by infostealers, in the absence of multi-factor authentication.
Mission : Build detections on improbable sign-ins (impossible travel, geography, timing) on top of a SIEM.
Access to cloud mailboxes is obtained using forged authentication tokens.
Mission : Analyse cloud access logs to spot the use of illegitimate tokens and instrument the alert.
You can operate a SOC; now it is about taking the initiative. This demanding module trains you in proactive threat hunting, incident response and detection-as-code — threat-informed defence.
Beyond basic detection, the expert analyst assembles their own platform and hunts the persistence that standard tools let through. With Security Onion (Wazuh, Sysmon, Elastic) you deploy a full detection stack, then hunt a persistence via WMI event subscription — a legitimate Windows mechanism subverted to survive reboots. You name the most suspect host and the malicious WMI subscription. You move up a level: from tool-driven detection to hunting on rich telemetry.
Objective : Deploy a complete detection stack.
Concepts : Security Onion · Advanced Sysmon
Challenge : Give the most suspicious host and the reason.
Expected outcomes : Validated if the stack ingests the telemetry and if the most suspicious host is correctly designated with its reason.
Objective : Hunt an advanced persistence.
Concepts : WMI event subscription · Rich telemetry
Challenge : Give the name of the malicious WMI subscription.
Expected outcomes : Validated if the WMI subscriptions are enumerated and if the malicious subscription is correctly named.
Hunting at random exhausts without finding; hunting from known attacker techniques changes everything. You practise threat-informed defence: translating a technique from the MITRE ATT&CK framework into a search query, framing a hypothesis, then confirming or refuting it from the data. You document a full hunt loop and bring proof of a confirmed ATT&CK technique. You adopt the structured approach that sets threat hunting apart from mere exploration.
Objective : Test ATT&CK-mapped hypotheses.
Concepts : Threat-informed defense · TTP→query
Challenge : Give the confirmed ATT&CK technique and its proof.
Expected outcomes : Validated if the hypotheses are translated into queries and if the confirmed ATT&CK technique is backed by proof.
Objective : Run a structured hunt end to end.
Concepts : Hunting loop · Documentation
Challenge : Give the hunt's result (confirmed/refuted) and the proof.
Expected outcomes : Validated if the hunt is documented and concludes clearly (confirmed/refuted) with proof.
An attacker who lands on one host immediately looks to bounce to others: spotting this lateral movement means stopping it before it reaches its targets. In Sysmon telemetry you detect the bounce techniques — credential-hash reuse (pass-the-hash), remote execution via WMI/WinRM, use of privileged accounts. You connect the two hosts a single lateral movement links. You can follow, step by step, an intruder's progress across a fleet.
Objective : Detect pass-the-hash and admin usage.
Concepts : PtH, WMI/WinRM · Privileged accounts
Challenge : Give the 2 hosts linked by the lateral movement.
Expected outcomes : Validated if the abnormal use is detected and if the two hosts linked by the lateral movement are correct.
A detection rule written for a single tool dies with it; expressed in a portable, version-controlled format, it is shared and maintained. With the Sigma format — an open standard translatable to different engines (backends) — you write rules and manage them as code, under Git. The challenge: produce a Sigma rule whose false-positive rate stays under 5%. You apply software-engineering practices to detection: portability, version control, review.
Objective : Write portable, versioned rules.
Concepts : Sigma, backends · FP, Git
Challenge : Provide the Sigma rule with FP<5%.
Expected outcomes : Validated if the Sigma rule is versioned, converted and tested with a false-positive rate below 5%.
When the incident hits, improvising is costly: response follows a proven cycle. You run the phases of incident response per the NIST 800-61 framework — from evidence preservation to containment — then investigate across an entire fleet with Velociraptor. You identify the entry point and the first containment action, then count the hosts touched by an indicator you hunt across the fleet. You can run a methodical response, from the first signal to measuring the spread.
Objective : Run the phases of a NIST 800-61 incident.
Concepts : IR cycle · Evidence preservation
Challenge : Give the entry point and the 1st containment action.
Expected outcomes : Validated if the IR cycle is followed and if the entry point and the first containment action are correct.
Objective : Collect and hunt across the fleet.
Concepts : Artefacts, hunts · Remote collection
Challenge : Give the number of hosts hit by the hunted IOC.
Expected outcomes : Validated if the hunt covers the fleet and if the number of hosts hit by the IOC is exact.
Modern command-and-control channels hide: they space out and blur their communications to blend into normal traffic. With Zeek and RITA you detect these C2s despite their tricks — interval variation (jitter), TLS handshake fingerprints (JA3) — then validate your coverage with a purple approach: replaying atomic attack techniques and measuring what slips through. You unmask a C2 despite its jitter and identify a technique executed but undetected. You close the virtuous circle: detect, validate, fix.
Objective : Detect modern C2s (JA3, jitter).
Concepts : JA3/JA3S · Jitter, sleep
Challenge : Give the C2 detected despite the jitter.
Expected outcomes : Validated if the beaconing is isolated despite the jitter and if the C2 is correctly identified.
Objective : Measure coverage through emulation.
Concepts : Atomic emulation · Coverage/gap
Challenge : Give the executed technique that went undetected.
Expected outcomes : Validated if the coverage is mapped and if the undetected technique is correctly designated.
A state actor persists in critical infrastructure using only system tools, evading antivirus.
Mission : Frame hunting hypotheses on living-off-the-land techniques and verify them in telemetry.
An actor obtains administrator access by impersonating an employee over the phone to a help desk, then bypasses multi-factor authentication.
Mission : Hunt the identity abuse and lateral movement that follow the compromise of a privileged account.
Exploitation of the transfer tool affects thousands of organisations within days.
Mission : Run a hunt on indicators of compromise across an estate and prioritise the affected hosts.
Stolen session tokens allow authenticated sessions to be replayed after the gateways are exploited.
Mission : Hunt the signs of post-exploitation session hijacking and reconstruct the access window.
An actor remains for several days in a healthcare organisation's network before triggering the ransomware, after entering through an access point with no multi-factor authentication.
Mission : Detect the lateral-movement window between initial access and impact, before the risk materialises.
Open-source intelligence (OSINT) is an art: finding information without exposing yourself, then turning it into something useful for defence. This module teaches it, from operational hygiene to automation.
Investigating a target from open sources can, through carelessness, warn that target it is being watched. This building block teaches you to collect without exposing yourself or leaving traces: compartmentalised investigation identities (sock puppets), routing through Tor and a VPN, and above all hunting the leaks that betray your real address (DNS, WebRTC). The challenge: prove your exit address and the absence of any leak. You establish the baseline hygiene without which an OSINT investigation turns against the investigator.
Objective : Collect without exposing yourself or alerting the target.
Concepts : Sock puppets, compartmentalisation · DNS/WebRTC leaks
Challenge : Give the egress IP and prove the absence of leak.
Expected outcomes : Validated if the collection does not leak (DNS/WebRTC) and if the egress IP is correctly recorded.
Before attacking or defending, you draw the map: which domains, servers, addresses and people does an organisation leave visible? With Maltego and SpiderFoot you build this digital footprint as an entity graph, then map the technical infrastructure (DNS, certificates, autonomous system numbers — ASN, subdomains). You flush out a forgotten administration subdomain, an exposed address, an accessible pre-production environment. It is the external inventory a defender must draw up before an attacker does it for them.
Objective : Map a target's digital footprint.
Concepts : Entity graphs, transforms · Source reliability
Challenge : Give the forgotten admin subdomain and the exposed email.
Expected outcomes : Validated if the footprint is mapped and if the admin subdomain and the exposed email are correct.
Objective : Map a target's technical infrastructure.
Concepts : DNS, certificates · ASN, subdomains
Challenge : Give the exposed pre-production subdomain.
Expected outcomes : Validated if the infrastructure is mapped and if the exposed pre-production subdomain is correct.
A person leaves, without thinking, a trail of clues across their accounts, photos and posts. With Sherlock you profile a human target — legally and on the record — by cross-referencing their social footprint, then exploit image metadata (EXIF data) and visual clues to geolocate them. You find a username reused on three platforms and extract a photo's GPS coordinates. On the defence side, this measures what an attacker can learn about your staff before a targeted attack.
Objective : Profile a human target legally.
Concepts : Social footprint · Cross-referencing
Challenge : Give the handle reused on 3 platforms.
Expected outcomes : Validated if the accounts are cross-referenced and if the handle reused on three platforms is correct.
Objective : Exploit metadata and visual clues.
Concepts : EXIF · Geo-clues
Challenge : Give the GPS coordinates extracted from the image.
Expected outcomes : Validated if the metadata is exploited and if the extracted GPS coordinates are correct.
When credentials leak, they often circulate on forums and marketplaces before the victim notices. This building block teaches you to monitor this exposure — data leaks, clandestine marketplaces — and to understand the risk it feeds: credential stuffing, where passwords stolen elsewhere are replayed against you. The challenge: count an organisation's leaked accounts and identify the most sensitive. You turn a rumour of a leak into a concrete risk assessment for the affected accounts.
Objective : Monitor exposure on breaches/darknet.
Concepts : Markets/forums · Credential stuffing
Challenge : Give the number of leaked accounts and the most sensitive.
Expected outcomes : Validated if the exposure is measured and if the number of leaked accounts and the most sensitive one are correct.
A manual collection takes a snapshot at one moment; what matters in monitoring is seeing what changes. You script a recurring OSINT collection — handling APIs and their rate limits, deduplicating results — then tool a specific collection in Bash. You produce a script that flags a new subdomain appearing and consolidate a usable result. You move from the one-off investigation to continuous watch over the exposed surface.
Objective : Script a recurring collection.
Concepts : API, rate · Deduplication
Challenge : Provide the script detecting a new subdomain.
Expected outcomes : Validated if the script collects, deduplicates and detects a new subdomain.
Objective : Tool up a specific collection.
Concepts : Light scraping · Parsing
Challenge : Provide the tool and the consolidated result.
Expected outcomes : Validated if the Bash tool collects, parses and exports a consolidated result.
Collecting intelligence is pointless if it does not lead to a decision: the value is in the action it triggers. This building block has you turn an OSINT collection into concrete defensive measures — telling actionable intelligence from mere noise, and prioritising. The challenge: name, among the exposures found, the one to fix first. You close the chain that runs from raw information to an effective reduction of risk.
Objective : Turn OSINT into defensive actions.
Concepts : Actionable intelligence · Prioritisation
Challenge : Give the priority exposure to fix.
Expected outcomes : Validated if the findings are prioritised and if the priority exposure to fix is correctly designated.
Access to customer tenants comes from credentials captured by infostealers and traded on underground markets.
Mission : Track in open sources the circulation of stolen credentials linked to an organisation and assess the exposure.
The actor identifies an employee through a professional network in order to impersonate them to the help desk.
Mission : Map an organisation's public footprint and the information exploitable in social engineering.
A very large theft of crypto-assets is attributed to a state group, via the compromise of a developer workstation.
Mission : Profile an actor from open sources and public indicators, and document its modes of operation.
An international operation dismantles the infrastructure of one of the most active ransomware groups.
Mission : Collect open-source intelligence on a criminal ecosystem (affiliates, infrastructure, leaks).
The data of millions of customers is put up for sale after an exposed API is exploited.
Mission : Assess the exposure of identities in open sources following a breach and measure the consequences for individuals.
Network traffic keeps the memory of an intrusion. This module teaches you to investigate from packets: session reconstruction, detection without decryption, and reporting.
A network capture sometimes contains, scattered across thousands of packets, whole files that just need reassembling. With NetworkMiner you reconstruct exchanges from a capture — reassembling TCP streams, extracting files travelling on the network (network carving). The challenge: extract the exfiltrated file and give its name and hash. You can make a capture talk, to recover, concretely, what left the network.
Objective : Reconstruct exchanges from a capture.
Concepts : TCP reassembly · Network carving
Challenge : Extract the exfiltrated file (name + hash).
Expected outcomes : Validated if the flow is reassembled and if the exfiltrated file (name and fingerprint) is correctly extracted.
It is often believed that encrypted traffic is opaque to analysis: it is not, its metadata says a great deal. With Zeek you detect without decrypting — TLS handshake fingerprints (JA3), exfiltration hidden in DNS requests — then investigate through firewall and proxy logs. You identify a DNS exfiltration domain and the internal address contacting a command-and-control server. You learn to read what encryption does not hide.
Objective : Detect without decrypting.
Concepts : TLS metadata, JA3 · DNS exfiltration
Challenge : Give the DNS exfiltration domain.
Expected outcomes : Validated if the TLS beaconing is spotted without decryption and if the DNS exfiltration domain is correct.
Objective : Investigate via network logs.
Concepts : Proxy/firewall logs · Correlation
Challenge : Give the internal IP contacting the C2.
Expected outcomes : Validated if the logs are correlated and if the internal IP contacting the C2 is correct.
An investigation does not stop at the finding: what you discover about an attack must become a detection for the next. This building block has you take that step — starting from an observed case to derive a Zeek indicator, then writing a targeted Snort signature. The challenge: produce the indicator that characterises the attack and the rule that detects its C2. You turn investigative work into durable detection capability, from the particular case to the reusable rule.
Objective : Turn a capture into detections.
Concepts : Zeek logs, scripts · From case to rule
Challenge : Give the Zeek indicator characterising the attack.
Expected outcomes : Validated if the Zeek logs are produced and if the characteristic indicator is correctly isolated.
Objective : Write network signatures.
Concepts : Snort rules · Test
Challenge : Provide the Snort rule detecting the C2.
Expected outcomes : Validated if the Snort rule detects the C2 without obvious false positive.
A network does not carry only files: it also carries conversations and discreet exfiltration channels. You reconstruct application communications, including voice over IP (VoIP), from a capture, then characterise a data exfiltration — by which channel, what volume, with what discretion. You restore the content of a communication and quantify the volume sent out through a covert channel. You measure what a leak actually carries away, beyond merely noting that it happened.
Objective : Reconstruct application communications.
Concepts : VoIP/HTTP · Reconstruction
Challenge : Give the reconstructed content of the communication.
Expected outcomes : Validated if the application communication is reconstructed and if the content is correct.
Objective : Quantify and characterise an exfiltration.
Concepts : Volume, channels · Stealth
Challenge : Give the channel and the exfiltrated volume.
Expected outcomes : Validated if the exfiltration channel is identified and if the estimated volume is consistent.
A piece of evidence on its own can be disputed; cross-referenced with others, it becomes a demonstration. You cross network, endpoint and logs to establish a solid timeline, then restore the investigation for two distinct audiences — the SOC and management. You date the time of compromise by cross-referencing and deliver a list of network indicators (addresses, domains, JA3 fingerprints). You turn scattered traces into a substantiated, communicable incident account.
Objective : Cross network, endpoint and logs.
Concepts : Correlation · Timeline
Challenge : Give the correlated time of compromise.
Expected outcomes : Validated if network and endpoint are correlated and if the time of compromise is correct.
Objective : Report for SOC and management.
Concepts : Network evidence · IOC
Challenge : Deliver the list of network IOCs (IP/domain/JA3).
Expected outcomes : Validated if the chain is synthesised and if the list of network IOCs (IP, domain, JA3) is usable.
Exploitation of firewalls goes through the IKE service, observable in the network flows.
Mission : Analyse network captures to characterise a perimeter exploitation and its follow-on.
The actor tunnels its activity through legitimate equipment to blend into traffic.
Mission : Detect, in the flows, tunnels and living-off-the-land behaviour that is hard to tell from normal traffic.
Exploitation triggers an outbound LDAP/JNDI connection to the attacker.
Mission : Spot in a capture the outbound callback characteristic of the exploitation and qualify it.
Data is extracted through the compromised web transfer application.
Mission : Trace data exfiltration in the application flows and estimate the volume.
Compromised routers communicate with a concealed command infrastructure.
Mission : Analyse the command traffic of compromised edge equipment in order to isolate it.
Producing structured cyber intelligence means moving from raw information to decision. This expert module teaches you to frame a CTI programme, analyse an intrusion with proven models, share via standards and operationalise intelligence.
An intelligence programme that collects without direction drowns in data: everything starts from the questions you seek to inform. This building block has you frame a Cyber Threat Intelligence (CTI) programme by its priority intelligence requirements (PIR) — the decision-driving questions that steer all collection — and distinguish the strategic, operational and tactical levels. The challenge: state prioritised PIRs and identify the source of the most critical one. You anchor intelligence production in the decision it must serve, rather than in accumulation.
Objective : Frame a CTI programme by needs.
Concepts : CTI cycle · Strategic/op/tactical levels
Challenge : Provide the prioritised PIRs and the source of the most critical.
Expected outcomes : Validated if three PIRs are prioritised and if the source of the most critical PIR is correctly associated.
Analysing an intrusion by instinct leads to hasty conclusions; proven models discipline the reasoning. You structure the analysis with the Diamond model — adversary, capability, infrastructure, victim, and the pivots that link them — testing competing hypotheses, then place the attack on the Cyber Kill Chain to decide where to break it. You identify an infrastructure pivot shared between intrusions and the chain stage at which to stop the attack at least cost. You gain frameworks that make an analysis reproducible and defensible.
Objective : Structure the analysis of an intrusion.
Concepts : Diamond, pivots · Competing hypotheses
Challenge : Give the shared infrastructure pivot.
Expected outcomes : Validated if the intrusion is modelled and if the shared infrastructure pivot is correctly identified.
Objective : Place an attack on the Kill Chain.
Concepts : Kill Chain · TTP mapping
Challenge : Give the Kill Chain stage at which to stop the attack.
Expected outcomes : Validated if the attack is placed on the Kill Chain and if the optimal stopping stage is justified.
Intelligence kept to oneself protects a single organisation; shared in a common format, it defends a whole community. You normalise and exchange intelligence with the STIX 2.1 (the object structure) and TAXII (their transport) standards, then enrich and qualify indicators with a reliability score. You produce a STIX bundle describing five attack techniques and name the most reliable indicator. You place your work within the sharing ecosystem that gives cyber intelligence its strength.
Objective : Normalise and share intelligence.
Concepts : STIX 2.1, objects · TAXII
Challenge : Provide the STIX bundle with 5 mapped TTPs.
Expected outcomes : Validated if the STIX bundle is shared via MISP with five correctly mapped TTPs.
Objective : Enrich and qualify indicators.
Concepts : IOC, scoring · False positives
Challenge : Give the most reliable IOC and its score.
Expected outcomes : Validated if the IOCs are enriched and if the most reliable IOC and its score are correct.
Naming a culprit is tempting, but a poorly conducted attribution steers the whole response in the wrong direction. You analyse actors by their characteristic techniques while measuring the limits of attribution — one actor can mimic another — and express a confidence level. Above all, you operationalise the intelligence: translating an attacker technique into a Sigma detection rule. You give the most likely actor with its confidence, and turn a technique into concrete detection. The value of intelligence is measured by what it changes in the defence.
Objective : Analyse and attribute cautiously.
Concepts : Actors, signature TTPs · Attribution limits
Challenge : Give the most probable actor and the confidence level.
Expected outcomes : Validated if the attribution is weighted and if the most probable actor and the confidence level are justified.
Objective : Turn intelligence into detections.
Concepts : TTP→rule · Procedural semantics gap
Challenge : Provide the TTP turned into a Sigma rule.
Expected outcomes : Validated if a TTP is turned into a tested Sigma rule.
Accurate but poorly delivered intelligence triggers no decision: the report is where the value materialises. You write a genuinely actionable CTI report, calibrated to its audience — from the decision-maker who wants three priorities to the analyst who wants the technical detail. The challenge: produce a report with three prioritised recommendations. You learn to land intelligence where it will be used, in the language of the one who decides.
Objective : Write a report actionable by audience.
Concepts : Report levels · Recommendations
Challenge : Provide the report with 3 prioritised recommendations.
Expected outcomes : Validated if the report is adapted to the audiences and proposes three prioritised recommendations.
A state-linked actor pre-positions itself in critical infrastructure for a possible future disruption.
Mission : Write a strategic intelligence report and map the observed techniques onto an ATT&CK matrix.
The takedown reveals the internal organisation, the affiliates and the infrastructure of a ransomware group.
Mission : Analyse a ransomware-as-a-service ecosystem, and work on attribution and infrastructure tracking.
A major theft of crypto-assets is tied to a state group by an official advisory.
Mission : Produce a substantiated attribution note and follow the pivots of infrastructure and laundering.
A mass-extortion campaign exploits a previously unknown flaw in a transfer tool.
Mission : Produce operational intelligence and indicators of compromise usable by a SOC.
When a Windows host is compromised, the investigator reconstructs what happened. This module trains you in forensic investigation: evidence acquisition, artefacts, memory, timeline and admissible report.
In investigation, badly collected evidence is lost evidence — or even inadmissible. With FTK Imager you acquire a disk and memory image of a Windows system while preserving its integrity: respecting the order of volatility (capture the most fleeting first), write-blocking, a verification hash. The challenge: provide the image's SHA-256 and prove it has not been altered. You perform the first, decisive step of any admissible digital investigation.
Objective : Acquire disk/memory image while preserving integrity.
Concepts : Order of volatility · Write-blocker, hash
Challenge : Provide the SHA-256 of the image and prove integrity.
Expected outcomes : Validated if the order of volatility is respected and if the image's SHA-256 proves integrity.
Even when an attacker deletes their files, Windows keeps a record of what ran. With RegRipper you reconstruct execution activity from little-known artefacts (Prefetch, Amcache, ShimCache) and flush out the mechanisms by which a program survives reboots — run keys, services, scheduled tasks. You name the malicious binary that ran and the persistence mechanism installed. You learn to read the traces the system keeps without the intruder's knowledge.
Objective : Reconstruct what was executed.
Concepts : Prefetch, Amcache · ShimCache
Challenge : Give the malicious executed binary.
Expected outcomes : Validated if the execution artefacts are extracted and if the malicious executed binary is correct.
Objective : Find the persistence mechanisms.
Concepts : Run keys, services · Scheduled tasks
Challenge : Give the persistence mechanism found.
Expected outcomes : Validated if the persistence points are enumerated and if the malicious mechanism is correctly identified.
The registry and browsing traces tell, hour by hour, what a user did on their machine. You extract evidence from the Windows registry — hives, connected USB devices, accounts and access — then reconstruct browser and email activity with Hindsight. You recover the serial number of the connected USB key and the URL from which malicious software was downloaded. You rebuild the thread of a user's actions, legitimate or compromised.
Objective : Extract evidence from the registry.
Concepts : Hives, USB · Accounts/access
Challenge : Give the serial number of the plugged-in USB key.
Expected outcomes : Validated if the hives are analysed and if the USB key's serial number is correct.
Objective : Reconstruct user activity.
Concepts : History, cache · Downloads
Challenge : Give the malware download URL.
Expected outcomes : Validated if the browser activity is reconstructed and if the malware download URL is correct.
Some threats never touch the disk: they live only in volatile memory. With Volatility you analyse a memory capture to reveal what hides there — processes, loaded libraries (DLLs), and above all code injected into a legitimate process. The challenge: identify the injected process and the command-and-control address it contacts. You reach the layer where the stealthiest attacks take refuge, invisible to disk analysis.
Objective : Reveal processes and injections.
Concepts : Processes, DLLs · Injections
Challenge : Give the injected PID and the C2 IP.
Expected outcomes : Validated if the injection is detected and if the injected PID and the C2 IP are correct.
An NTFS file system keeps meticulous accounts — which the investigator can exploit, and which the attacker tries to falsify. With MFTECmd you analyse the master file table (MFT) and the change journal ($UsnJrnl) to recover a deleted file, then spot anti-forensic traces: timestamp falsification (timestomping), log wiping. You identify the file deleted by the attacker and the one whose dates were tampered with. You learn to flush out not only the traces, but also the attempts to erase them.
Objective : Exploit the MFT and NTFS journals.
Concepts : MFT, $UsnJrnl · Timestamps
Challenge : Give the file deleted by the attacker.
Expected outcomes : Validated if the MFT and the NTFS journal are exploited and if the deleted file is correctly identified.
Objective : Spot the traces of erasure.
Concepts : Timestomping · Log wiping
Challenge : Give the file whose dates were falsified.
Expected outcomes : Validated if the anti-forensics is detected and if the file with falsified dates is correct.
At the end of an investigation, dozens of isolated artefacts are worth nothing unless tied into a coherent timeline. With Plaso you build a super-timeline — the assembly of all timestamped sources into a single frieze — then produce an admissible report, clearly separating hypotheses from evidence. You date the initial access and its vector, and deliver a report carrying the full timeline. You close the investigation with its restitution: a dated, substantiated account, usable beyond the technical circle.
Objective : Build a coherent chronology.
Concepts : Super-timeline · Correlation
Challenge : Give the time and the initial access vector.
Expected outcomes : Validated if the super-timeline is consistent and if the time and the initial access vector are correct.
Objective : Produce an admissible report.
Concepts : Hypotheses/evidence · Legal clarity
Challenge : Deliver the report with the complete chronology.
Expected outcomes : Validated if the report distinguishes facts from hypotheses and presents a complete chronology.
After impersonation to the help desk, the actor takes control of the identity environment and progresses towards the domain.
Mission : Investigate a Windows/Active Directory compromise following a social-engineering attack.
The actor moves through the network for several days before deploying the ransomware.
Mission : Reconstruct lateral movement and credential theft from Windows artefacts.
Stolen session tokens allow Windows hosts to be reached without authentication.
Mission : Trace a session hijack on Windows hosts and date the access window.
Ransomware encrypts systems after entry through a VPN with no multi-factor authentication.
Mission : Identify ransomware artefacts on Windows hosts and establish the execution timeline.
Illegitimate cloud access via forged tokens coexists with activity on endpoints.
Mission : Correlate cloud authentication artefacts with the telemetry of Windows hosts.
A compromised Linux server tells its story — to whoever can read it. This module teaches you Linux forensics: traces, persistence, file recovery, memory analysis.
When a Linux server is suspected of compromise, pulling the plug too soon can destroy volatile evidence. This building block has you collect in the right order: a live triage on the running system, then a memory capture (with LiME) and an offline disk image. The challenge: spot the suspect process from the live triage. You can act on a production machine without erasing what volatile memory alone holds.
Objective : Collect live and offline evidence.
Concepts : Live triage · LiME memory
Challenge : Give the suspicious process from the live triage.
Expected outcomes : Validated if the live triage and acquisitions preserve integrity and if the suspicious process is correct.
On Linux, what an attacker did and how they plan to return is readable in the logs and the system's configuration. You reconstruct activity through the logs (auth.log, journald) and flush out persistence mechanisms (cron, systemd services), then recover the commands run from the shell history. You identify the persistence mechanism and the account involved, and the command that downloaded the malicious code. You read the trace an intruder leaves, despite themselves, in the system's administrative memory.
Objective : Reconstruct activity and persistence.
Concepts : auth.log, journald · Cron/systemd
Challenge : Give the persistence mechanism and the account.
Expected outcomes : Validated if the logs are analysed and if the persistence mechanism and the compromised account are correct.
Objective : Reconstruct the executed commands.
Concepts : bash_history · Timestamps
Challenge : Give the malware download command.
Expected outcomes : Validated if the shell history is exploited and if the malware download command is correct.
Deleting a file does not truly erase it: its data stays on the disk until overwritten. With Foremost you recover deleted files by data carving — reconstruction from file signatures — and through the ext4 file-system journal. The challenge: recover a malicious script the attacker believed destroyed. You can resurrect a piece of evidence someone tried to make disappear.
Objective : Recover deleted files.
Concepts : Carving · ext4 journal
Challenge : Recover the erased malicious script.
Expected outcomes : Validated if the carving succeeds and if the erased malicious script is correctly recovered.
The most advanced Linux compromises hide where you look least: in kernel memory and in containers. With Volatility you analyse a memory capture to unmask a rootkit or a malicious kernel module, then investigate a compromised Docker container — its layers, mount points, logs. You identify the injected kernel module and the alteration introduced into the container. You carry the investigation into the corners where stealthy threats take refuge.
Objective : Detect rootkits and hidden processes.
Concepts : Linux profiles · Modules/rootkits
Challenge : Give the malicious kernel module loaded.
Expected outcomes : Validated if the dump is analysed and if the malicious kernel module is correctly identified.
Objective : Investigate a compromised container.
Concepts : Layers, mounts · Container logs
Challenge : Give the alteration introduced into the container.
Expected outcomes : Validated if the container layers are inspected and if the introduced alteration is correctly identified.
A competent attacker does not just act: they erase their tracks. You first spot these anti-forensic moves on Linux — wiped logs, falsified dates (timestomping) — then rebuild a reliable timeline despite them. You identify the wiped log and the method used, then date the initial access vector. You learn to investigate against someone actively trying to mislead you.
Objective : Spot the erasure of traces.
Concepts : Log wiping · Timestomping
Challenge : Give the erased log and the method.
Expected outcomes : Validated if the anti-forensics is detected and if the erased log and the method are correct.
Objective : Build a chronology.
Concepts : Super-timeline · Correlation
Challenge : Give the initial access vector.
Expected outcomes : Validated if the Linux timeline is built and if the initial access vector is correct.
An investigation that does not end in a clear report stays without effect: it is the document that turns analysis into a decision and, sometimes, into evidence. You write a structured Linux forensic report — separating established facts from hypotheses, with indicators of compromise and the timeline. The challenge: deliver a report carrying the IOCs and the sequence of events. You close the inquiry with its restitution, readable by a peer and a decision-maker alike.
Objective : Conclude the investigation.
Concepts : Evidence · IOC
Challenge : Deliver the report with IOCs and chronology.
Expected outcomes : Validated if the report compiles the IOCs and presents a complete chronology.
A backdoor grafted onto a compression library triggers within the SSH daemon process.
Mission : Investigate a compromised library and the associated process tree on a Linux host.
The activity leaves only traces of legitimate system tools.
Mission : Reconstruct an intrusion from shell histories, diverted binaries and logs on Linux.
Credentials are captured on endpoints by infostealers before being reused.
Mission : Search a Linux host for the traces of an infostealer and the harvesting of credentials.
A hosted instance is diverted to query the metadata service and steal tokens.
Mission : Analyse the artefacts of an exploited Linux instance and the request to the metadata service.
Linux embedded devices are enrolled via default credentials.
Mission : Analyse a Linux/embedded host enrolled in a botnet and characterise the persistence.
Forensics gains speed and reproducibility through automation. This module teaches you to script forensic collection and analysis in Python.
When evidence runs into gigabytes, manual analysis no longer holds: you have to program your tooling. In Python you write indicator extractors over large volumes, then decode Windows artefacts (Prefetch, registry) yourself with forensic libraries. You name the most active and most suspect address, and the executed binary your script decodes. You move from being a tool user to being the author of your own investigation tools.
Objective : Automate indicator extraction.
Concepts : os/struct · Mass parsing
Challenge : Give the most active and most suspicious IP.
Expected outcomes : Validated if the log is parsed and if the most active and most suspicious IP are correct.
Objective : Decode artefacts in Python.
Concepts : Prefetch/registry · Forensic libraries
Challenge : Give the executed binary decoded by the script.
Expected outcomes : Validated if the Windows artefact is decoded and if the executed binary is correctly extracted.
Replaying the same capture analysis by hand, incident after incident, wastes precious time. With Scapy and DSHELL you automate traffic analysis — detecting programmatically what an eye would search for by hand. The challenge: have your script identify, by itself, the address scanning the network. You turn an analysis skill into reproducible detection, ready for the next capture without starting from scratch.
Objective : Automate capture analysis.
Concepts : Scapy/DSHELL · Programmatic detection
Challenge : Give the scanning IP detected by the script.
Expected outcomes : Validated if the script reads the capture and if the scanning IP is correctly detected.
During an incident touching dozens of machines, collecting by hand is too slow and hard to reproduce. In Python you build a triage collector deployable across several hosts, which timestamps and hashes what it gathers (a verifiable manifest). The challenge: deliver the collector and its manifest. You gain a tool that makes collection fast, consistent and defensible against challenge.
Objective : Build a reproducible collector.
Concepts : Multi-host triage · Hash/manifest
Challenge : Provide the collector and the manifest.
Expected outcomes : Validated if the collector is reproducible and if the timestamped manifest with fingerprints is provided.
An indicator of compromise is only worth what you can search for everywhere, fast, and qualify. With scripted YARA rules you search for IOCs across a fleet, then enrich those indicators automatically through threat-intelligence APIs. You count the hosts matching an IOC and name the most critical enriched indicator. You connect mass detection and qualification, the two conditions of a response at scale.
Objective : Search for IOCs across an estate.
Concepts : Scripted YARA scan · Reporting
Challenge : Give the number of hosts with an IOC match.
Expected outcomes : Validated if the YARA scan is scripted and if the number of hosts with a match is exact.
Objective : Enrich IOCs via API.
Concepts : Threat-intel API · Correlation
Challenge : Give the most critical enriched IOC.
Expected outcomes : Validated if the API enrichment works and if the most critical enriched IOC is correct.
At massive scale, the anomaly is invisible to the eye: it surfaces from statistical processing. You analyse large log sets by aggregation and statistical-deviation detection, then chain collection, analysis and restitution into an automated pipeline. You surface the hidden statistical anomaly and produce an end-to-end generated report. You industrialise the investigation, where volume makes the manual approach unworkable.
Objective : Process massive log volumes.
Concepts : Aggregation · Statistical anomalies
Challenge : Give the detected statistical anomaly.
Expected outcomes : Validated if the volumes are aggregated and if the statistical anomaly is correctly detected.
Objective : Chain collection→analysis→report.
Concepts : Orchestration · Auto report
Challenge : Run the pipeline and provide the auto report.
Expected outcomes : Validated if the pipeline runs end to end and produces a consistent automatic report.
The campaign affects thousands of organisations within days, generating a massive volume of indicators.
Mission : Automate in Python the triage and enrichment of indicators across a large estate.
The vulnerable component is buried in countless application dependencies.
Mission : Script the search for vulnerable or compromised instances across a heterogeneous estate.
The illegitimate access is spread across many customer tenants.
Mission : Correlate in Python suspicious sign-ins across several tenants and produce a timeline.
The abuse of privileged accounts leaves traces in the identity logs.
Mission : Automate the extraction of identity logs and the building of a timeline.
Living-off-the-land techniques call for a search across many hosts.
Mission : Build a hunting script for living-off-the-land behaviour, deployable across an entire estate.
Understanding malware means knowing what it does, how it hides and how to detect it. This expert module trains you in malware analysis, static and dynamic.
Before running a suspect sample — a risky act — you examine it at rest, and it already reveals a great deal. With PEStudio you characterise a binary without launching it: the structure of the PE format (the Windows executable), character strings, entropy that betrays compressed or encrypted content. The challenge: propose a probable malware family and the decisive clue that supports it. You set the first filter of malware analysis, the one that steers everything else without taking a risk.
Objective : Characterise a sample without running it.
Concepts : PE format · Strings, entropy
Challenge : Give the probable family and the decisive clue.
Expected outcomes : Validated if the static analysis is carried out and if the probable family and the decisive clue are correct.
What a malware really does cannot always be guessed from the code: sometimes you must let it run — under glass. With Procmon and a fake internet (INetSim) you observe a sample detonating in an isolated sandbox, watching its actions on the system and the network. You note the persistence key it installs and the command-and-control host it contacts. You read a threat's real behaviour, without exposing a production environment.
Objective : Observe the behaviour in isolation.
Concepts : Isolated sandbox · Monitoring
Challenge : Give the persistence key and the C2 host.
Expected outcomes : Validated if the behaviour is captured in isolation and if the persistence key and the C2 host are correct.
Modern malware arrives packed and obfuscated to resist analysis: before understanding, you have to unpack. With x64dbg and CyberChef you bypass these protections — in-memory unpacking of a packed binary, data deobfuscation. The challenge: extract the command-and-control URL hidden in the configuration. You clear the first barrier a serious malware raises, the one that deters superficial analysis.
Objective : Bypass obfuscation.
Concepts : Packing · Memory unpacking
Challenge : Extract the C2 URL from the configuration.
Expected outcomes : Validated if the payload is unpacked and if the C2 URL is correctly extracted from the configuration.
The way into an attack is often a seemingly harmless document or script. With oletools you dissect a booby-trapped document (maldoc) and its VBA macros to trace the infection chain, then break down obfuscated PowerShell or JavaScript payloads. You recover the payload's download URL and the script's final action once decoded. You learn to neutralise the most common vectors of today's compromises.
Objective : Analyse a booby-trapped document.
Concepts : VBA macros · Infection chain
Challenge : Give the payload download URL.
Expected outcomes : Validated if the macro is deobfuscated and if the payload download URL is correct.
Objective : Analyse scripted payloads.
Concepts : Obfuscated PowerShell/JS · Decoding
Challenge : Give the final action of the decoded script.
Expected outcomes : Validated if the scripted payload is decoded and if its final action is correctly identified.
When behavioural analysis reaches its limits, you have to descend to the machine-instruction level. With IDA and Ghidra you read a malware's logic in disassembly (x86 assembly) to isolate its key functions, then write a decoder reproducing its configuration routine. You locate the command-and-control communication function and extract the full decoded configuration. You reach the level of analysis that lets you understand a malware thoroughly, not merely observe it.
Objective : Understand the logic in disassembly.
Concepts : x86 assembly · Key functions
Challenge : Give the C2 communication function.
Expected outcomes : Validated if the key functions are analysed and if the C2 communication function is correct.
Objective : Extract the malware's parameters.
Concepts : Encoded config · Decoders
Challenge : Provide the complete decoded configuration.
Expected outcomes : Validated if a decoder is written and if the complete decoded configuration is correct.
A running malware gives itself away in memory, even if it has dissolved on disk. With Volatility you flush out these in-memory threats — injection into a legitimate process, process hollowing — then write discriminating YARA rules to recognise them elsewhere. You identify the injection's host process and produce a YARA rule with no false positives. You connect analysis to fleet-wide spotting: find once, detect everywhere.
Objective : Find the malware in memory.
Concepts : Memory injection · Process hollowing
Challenge : Give the host PID of the injection.
Expected outcomes : Validated if the injection is detected in memory and if the host PID of the injection is correct.
Objective : Write discriminating signatures.
Concepts : YARA · FP
Challenge : Provide the YARA rule without false positive.
Expected outcomes : Validated if the YARA rule discriminates the sample without false positive on the benign.
A malware analysis only has defensive value if it is shared in a directly usable form. You synthesise a sample's behaviour and indicators, mapping its techniques onto MITRE ATT&CK and preparing IOC dissemination. The challenge: deliver a report carrying the ATT&CK techniques and the indicators. You turn a sharp analysis into shareable defensive ammunition that benefits the whole organisation.
Objective : Deliver behaviour and IOCs.
Concepts : ATT&CK synthesis · IOC dissemination
Challenge : Deliver the report with the ATT&CK TTPs and IOCs.
Expected outcomes : Validated if the report maps the TTPs onto ATT&CK and disseminates the IOCs.
Malware written in Go speaks directly to industrial controllers over Modbus and cuts the heating of hundreds of buildings.
Mission : Carry out the static and dynamic analysis of malware targeting industrial systems.
Malware targets the safety controllers of an industrial site, at the risk of neutralising the protections.
Mission : Take apart malware attacking a safety-instrumented system and its proprietary protocol.
The malicious payload is concealed in the test data of a compression library.
Mission : Analyse a backdoor payload buried in a library and its triggering mechanism.
The takedown operation makes samples and keys available.
Mission : Analyse a ransomware sample from an as-a-service model and its encryptor.
The botnet's published source code mixes components in C and in Go.
Mission : Study the source code of an IoT botnet and its propagation mechanisms.
Reverse engineering is reading a program in its rawest language to uncover its logic. This expert module trains you in it: assembly, debugging, vulnerability identification.
Reverse engineering begins with finding your way around a program stripped of its source code. With Ghidra and radare2 you navigate a binary at assembly level — PE and ELF executable formats, control-flow graph. The challenge: locate the address of the function that checks a condition (a password check, for instance). You acquire the basic orientation without which all the rest of reverse engineering stays unreadable.
Objective : Navigate a binary at the asm level.
Concepts : PE/ELF formats · Control flow
Challenge : Give the address of the verification function.
Expected outcomes : Validated if the binary is navigated at the asm level and if the address of the verification function is correct.
Reading a program at rest is not always enough: some logic only reveals itself while running. With a debugger (GDB) you follow a binary step by step — breakpoints, inspection of registers and memory, hot patching. The challenge: make the binary confess the password it expects. You learn to watch a program as it runs, and to bend its execution to understand what it hides.
Objective : Follow a hidden logic.
Concepts : Breakpoints · Hot patch
Challenge : Give the password expected by the binary.
Expected outcomes : Validated if the logic is followed in the debugger and if the expected password is correct.
Before exploiting a flaw, you first have to find it in the binary: that is the vulnerability researcher's work. With Ghidra and GDB you spot a program's exploitable weaknesses through analysis — dangerous functions, faulty input validation. The challenge: name the unsafe function and its exact offset. You adopt the eye that tells, in compiled code, what will hold from what will give under pressure.
Objective : Spot exploitable weaknesses.
Concepts : Dangerous functions · Input validation
Challenge : Give the unsafe function and the offset.
Expected outcomes : Validated if the weakness is traced and if the unsafe function and the offset are correct.
Malicious software often speaks a proprietary language and encrypts its exchanges with its own recipe: to listen in, you must first decipher it. With Wireshark and Ghidra you reconstruct an unknown communication protocol — message structure, fields, checksums — then recover a homemade encryption routine and its hardcoded key. You describe a message's structure and extract the key hidden in the binary. You open the black box of communications a malware believed unreadable.
Objective : Understand a proprietary protocol.
Concepts : Message format · Fields/checksums
Challenge : Give the decoded message structure.
Expected outcomes : Validated if the protocol is analysed and if the decoded message structure is correct.
Objective : Recover an encryption routine.
Concepts : Custom algorithm · Hard-coded keys
Challenge : Give the hard-coded encryption key.
Expected outcomes : Validated if the crypto routine is identified and if the hard-coded key is correctly extracted.
Binaries that refuse to be analysed fight back: they detect the debugger and blur their logic. You bypass these anti-reverse-engineering protections, then automate the analysis by scripting your disassembly tool (Ghidra) — because at scale, manual analysis no longer keeps up. You identify the anti-debugging technique defeated and count the dangerous calls your script flags. You connect manual cunning and automation, the two faces of advanced reverse engineering.
Objective : Bypass the protections.
Concepts : Anti-debug · Control-flow obfuscation
Challenge : Give the bypassed anti-debug technique.
Expected outcomes : Validated if the protections are bypassed and if the anti-debug technique is correctly named.
Objective : Automate the analysis.
Concepts : Ghidra scripting · Automation
Challenge : Give the number of dangerous calls detected.
Expected outcomes : Validated if the Ghidra script runs and if the number of dangerous calls detected is exact.
At the top of the analysis chain, the reverse engineer faces malware built to resist all scrutiny — and must restore their findings usefully. With Ghidra and Volatility you analyse a complex malicious binary, packed and equipped with evasion logic, then document your approach. You identify the malware's evasion technique and deliver a report reconstructing its logic. You close expert analysis with its transmission, the condition for individual knowledge to become a collective capability.
Objective : Analyse a complex malicious binary.
Concepts : Packed malware · Evasion logic
Challenge : Give the malware's evasion technique.
Expected outcomes : Validated if the binary is unpacked/analysed and if the evasion technique is correctly identified.
Objective : Document the analysis.
Concepts : Technical synthesis · Recommendations
Challenge : Deliver the report with the reconstructed logic.
Expected outcomes : Validated if the report reconstructs the binary's logic clearly.
A zero-interaction exploit abuses an image decoder (JBIG2) to provoke an integer overflow and build arbitrary computation.
Mission : Reverse-engineer an advanced exploitation primitive from a file format, at a controlled conceptual level.
The implant grafts itself via a function-resolution mechanism when the SSH daemon loads.
Mission : Reverse the implant and its trigger, and understand its stealthy integration.
The malware communicates with the controllers through an undocumented proprietary protocol.
Mission : Reverse-engineer a proprietary protocol and the logic of a safety controller.
The malware is a Go binary driving equipment over Modbus.
Mission : Reverse a Go binary and reconstruct its industrial command logic.
Analysis of the encryptor made it possible to produce decryption tools.
Mission : Reverse an encryptor and look for its implementation weaknesses.
When a crisis strikes, everything hinges on preparation and composure. This expert module teaches you to steer incident response and crisis management, end to end.
The quality of an incident response is decided before the incident: in the preparation. You tool that preparation along the NIST 800-61 cycle — roles and responsibilities clarified (a RACI matrix), written decision procedures (playbooks). The challenge: produce a playbook with three containment actions. You put in place what will make the difference on the day: not improvisation, but prepared, shared reflexes.
Objective : Prepare the organisation to respond.
Concepts : IR cycle 800-61 · RACI
Challenge : Provide the playbook with 3 containment actions.
Expected outcomes : Validated if the roles are defined and if the playbook provides three containment actions.
Facing an incident, two symmetric errors lurk: overreacting to a false alarm, or underestimating a major compromise. You first qualify an incident — justified severity, affected scope — then contain it without destroying the evidence the investigation needs. You establish severity and scope, identify the entry point and apply the right containment. You learn to act fast and well, keeping a cool head under pressure.
Objective : Qualify a major incident.
Concepts : Severity, scope · Criteria
Challenge : Give the justified severity and the scope.
Expected outcomes : Validated if the severity is justified and if the incident's scope is correctly delimited.
Objective : Contain while preserving evidence.
Concepts : Containment · Evidence preservation
Challenge : Give the entry point and the applied containment.
Expected outcomes : Validated if the evidence is preserved and if the entry point and the applied containment are correct.
Containing is not enough: as long as the attacker's persistence remains, they can return. You eradicate these footholds and harden in the same move, while running a fast investigation that does not slow the response. You identify the persistence mechanisms removed and count the hosts actually affected — often more than the first suspects. You hold the two requirements in tension: regain control fast, leaving nothing behind.
Objective : Eradicate the persistence and harden.
Concepts : Eradication · Hardening
Challenge : Give the eradicated persistence mechanisms.
Expected outcomes : Validated if the persistence is eradicated and if the eradicated mechanisms are correctly listed.
Objective : Investigate without slowing the response.
Concepts : Rapid forensics · Hunts
Challenge : Give the number of hosts really affected.
Expected outcomes : Validated if the hunt establishes the extent and if the number of hosts really affected is exact.
Restoring too fast risks re-injecting the compromise with the backup; restoring too slowly worsens the loss. You drive recovery within a business continuity and disaster recovery plan (BCP/DRP) — checking that backups are clean, ordering the restoration, measuring the recovery time (RTO) and acceptable data loss (RPO). The challenge: define the restoration order and meet the recovery objective. You connect the technical response to the continuity stakes, which are the business's.
Objective : Restore safely.
Concepts : Clean backups · RTO/RPO
Challenge : Give the restoration order and the RTO achieved.
Expected outcomes : Validated if the backups are verified and if the restoration order and the achieved RTO are consistent.
A major incident quickly overflows the technical sphere: it becomes a crisis, where decisions and communication weigh as much as the response on the ground. You run a crisis cell — trade-offs, internal and external communication — then design and run a tabletop exercise to train the organisation in cold conditions, drawing on recognised templates (CISA CTEP, ENISA). You deliver a justified critical decision and build an exercise scenario with its injected events. You connect cyber defence to crisis governance, where real resilience is decided.
Objective : Lead the crisis cell.
Concepts : Crisis cell · Communication
Challenge : Give the critical decision and its justification.
Expected outcomes : Validated if the cell is led and if the critical decision and its justification are relevant.
Objective : Design and run a cyber drill.
Concepts : Tabletop · Injects
Challenge : Provide the scenario with 4 injects and the objective.
Expected outcomes : Validated if the exercise is designed with four injects and a clear objective.
An incident handled but not analysed is a lost lesson — and often a relapse foretold. You run the post-crisis review (the after-action review, or AAR): reconstructing what happened without seeking blame, drawing lessons and a concrete improvement plan. The challenge: produce a review with five prioritised actions. You turn the ordeal into lasting progress — what sets an organisation that learns apart from one that repeats its mistakes.
Objective : Capitalise and improve.
Concepts : AAR · Improvement plan
Challenge : Provide the AAR with 5 prioritised actions.
Expected outcomes : Validated if the AAR is run and if five improvement actions are prioritised.
The encryption of a central healthcare actor's systems disrupts the reimbursement of care across a whole country.
Mission : Run a high-impact sectoral ransomware crisis: crisis cell, priorities, stakeholders.
The operator halts its distribution as a precaution and faces a public crisis.
Mission : Lead the shutdown decision, crisis communication and business continuity.
A major hotel chain sees bookings, keys and machines paralysed for several days.
Mission : Manage a prolonged operational crisis and the media pressure that accompanies it.
A supplier and its thousands of customers must respond simultaneously and notify the people affected.
Mission : Coordinate a response involving supplier, customers and notification obligations.
The penetration tester must methodically measure the entire attack surface of a secured environment. Step by step — from scoping the engagement to writing the report — you will adopt a professional's approach.
A penetration test without a clear frame is not a test: it is an intrusion. This building block first has you set a mission's rules of engagement — scope, written authorisation, confidentiality, following a recognised methodology (PTES) — before any technical move. You then run active reconnaissance to map the attack surface and name the most promising target, with justification. You learn that the rigour of the scoping is what separates an offensive-security professional from an attacker.
Objective : Legally frame a pentest engagement.
Concepts : Scope, authorization, PTES · Evidence/confidentiality
Challenge : Provide the validated rules of engagement.
Expected outcomes : Validated if the rules of engagement cover scope, authorization and evidence, and are validated.
Objective : Map the attack surface.
Concepts : Passive/active recon · Prioritization
Challenge : Give the most promising target with justification.
Expected outcomes : Validated if the surface is mapped and the most promising target is justified.
A raw scanner report mixes real flaws with false alarms: the work begins where the tool stops. You identify vulnerabilities, rank them by their CVSS severity score, and above all validate them by hand — because only a confirmed flaw justifies action. The challenge: name the most critical confirmed vulnerability and its identifier (CVE). You adopt the discipline that tells an exploitable result from mere scanner noise.
Objective : Identify and validate without false positives.
Concepts : Scanners, CVSS · Manual validation
Challenge : Give the most critical validated vuln (CVE).
Expected outcomes : Validated if two vulnerabilities are validated and the most critical (CVE) is correctly named.
Gaining a first foothold in the system is the key moment of a penetration test — and the trickiest to carry out cleanly. With Metasploit you exploit a flaw to gain a stable initial access (payloads, connection handlers), then compromise weak credentials through online attack and offline cracking. You provide proof of access (host and account obtained) and a valid credential. You cross, in a controlled and documented way, the line an attacker tries to cross in silence.
Objective : Obtain controlled initial access.
Concepts : Payloads, handlers · Stability
Challenge : Provide proof of access (hostname+user).
Expected outcomes : Validated if a stable session is obtained and proof of access (host+user) is provided.
Objective : Compromise weak credentials.
Concepts : Brute-force, spraying · Offline cracking
Challenge : Give the valid credential obtained.
Expected outcomes : Validated if the valid credential is obtained via the controlled attack.
An initial access is rarely an administrator access: between the two lies privilege escalation. With linPEAS and winPEAS you raise your rights on a Linux then a Windows target by exploiting misconfigurations — SUID binaries, sudo rules, scheduled tasks, poorly protected services, access tokens. You name the escalation vector used and the vulnerable service exploited. On the defence side, this is understanding exactly what an attacker will look for once inside, in order to shut it down.
Objective : Elevate privileges on the target.
Concepts : SUID, sudo, cron · Kernel
Challenge : Give the escalation vector used.
Expected outcomes : Validated if root is obtained and the escalation vector used is correctly identified.
Objective : Elevate privileges on Windows.
Concepts : Services, tokens · Misconfig
Challenge : Give the vulnerable service exploited.
Expected outcomes : Validated if SYSTEM is obtained and the vulnerable service exploited is correct.
The value of a penetration test lies not in the successful exploit, but in what you demonstrate and what you recommend. You run a clean post-exploitation — controlled persistence, collecting proof of business impact, cleanup — then write an actionable report, from executive summary to technical detail. You establish proof of real impact for the organisation and deliver a report linking the attack chain to three prioritised remediations. You close the mission with what makes it useful: helping the target fix itself.
Objective : Persist cleanly and collect impact.
Concepts : Controlled persistence · Collection/cleanup
Challenge : Provide the proof of business impact.
Expected outcomes : Validated if proof of business impact is produced and the persistence cleaned up.
Objective : Produce an actionable report.
Concepts : Executive/technical summary · Prioritized remediation
Challenge : Deliver the report with chain + 3 remediations.
Expected outcomes : Validated if the report presents the chain and three prioritized remediations.
A public portal remains vulnerable to a known flaw in an application framework, for want of the patch being applied everywhere.
Mission : Run through a testing methodology (reconnaissance, identification of a known vulnerability, proof) and deliver a prioritised report.
An exposed API returns customer data with no access control, via sequential identifiers.
Mission : Carry out enumeration and object-level authorisation testing (insecure direct reference).
A server-side request forgery makes it possible to reach an instance's metadata service.
Mission : Identify and demonstrate a server-side request forgery, then chain it towards the metadata.
A transfer tool presents a previously unknown SQL injection leading to code execution.
Mission : Test an SQL injection on an application and document the impact within an authorised scope.
Two chained vulnerabilities on a VPN appliance lead to remote code execution.
Mission : Chain two vulnerabilities for remote execution and document the attack path.
The best testers write their own tools. This module teaches you to develop your offensive instruments in Python: scanners, packet manipulation, exploitation automation.
Off-the-shelf tools stop where specific needs begin: to go further, you write your own. In Python you write a port scanner (TCP/UDP sockets, parallelism) then forge and analyse custom packets with Scapy. You deliver your own scanner and its result, and make a host respond to a custom scan. You understand from the inside what tools automate, and gain the autonomy to build what no tool does.
Objective : Program a port scanner.
Concepts : TCP/UDP sockets, threads · Timeouts
Challenge : Provide the scanner and the open ports detected.
Expected outcomes : Validated if the multithreaded scanner works and correctly reports the open ports.
Objective : Craft and analyze packets.
Concepts : Crafting, sniffing · Custom scans
Challenge : Give the host responding to the custom scan.
Expected outcomes : Validated if the custom packet is crafted and the responding host correctly identified.
Understanding how an attacker takes control means having coded it yourself. In Python you script a controlled password attack (rate handling, resume on failure) then write a remote shell — the connection through which a compromised machine is driven — distinguishing the reverse and bind variants. You find a valid credential and prove the execution of a remote command. You demystify two elementary building blocks of many intrusions, which also helps in detecting them.
Objective : Script a password attack.
Concepts : Brute-force, rate · State resume
Challenge : Give the valid credential found.
Expected outcomes : Validated if the script finds the valid credential while staying reliable.
Objective : Write a remote shell in Python.
Concepts : Reverse vs bind · Basic encryption
Challenge : Prove remote command execution.
Expected outcomes : Validated if the reverse shell runs a command remotely.
Repeating the same exploitation checks by hand, mission after mission, wastes time and invites omissions. In Python you automate these tasks: checking privilege-escalation paths, then driving Metasploit through its programmable interface (RPC) to orchestrate exploitation. You have your script detect the escalation vector and obtain a session through code. You industrialise the offensive gesture, a gain in reliability as much as in speed.
Objective : Check escalation automatically.
Concepts : Privesc checks · Reporting
Challenge : Give the escalation vector detected by the script.
Expected outcomes : Validated if the script correctly detects the escalation vector.
Objective : Automate exploitation.
Concepts : MSF RPC · Orchestration
Challenge : Prove obtaining a session via script.
Expected outcomes : Validated if a session is obtained via scripted driving of Metasploit.
Beyond public tools, the advanced practitioner shapes their own arsenal, fitted to their missions. In Python you build reusable tools — a reconnaissance module producing a structured report (JSON), then a packaged command-line offensive tool — and grasp antivirus-evasion concepts (obfuscation, payload encoding) by measuring the drop in detection. The work includes explicit ethical safeguards, because an offensive tool engages its author's responsibility. You gain tooling autonomy, with the rigour it demands.
Objective : Build a reusable recon tool.
Concepts : Modularity · Usable outputs
Challenge : Provide the tool and its JSON report.
Expected outcomes : Validated if the tool produces a usable JSON report of the reconnaissance.
Objective : Understand payload obfuscation.
Concepts : Obfuscation · Encoding
Challenge : Give the measured detection drop.
Expected outcomes : Validated if the detection drop is measured within an ethical frame.
Objective : Package a documented CLI tool.
Concepts : CLI, config · Ethics/guardrails
Challenge : Deliver the CLI tool running recon→exploit.
Expected outcomes : Validated if the documented CLI tool runs the recon→exploit chain.
Customer records can be retrieved by incrementing a numeric identifier.
Mission : Write in Python an API identifier enumerator, within an authorised testing scope.
The botnet spreads by trying factory credentials on connected devices.
Mission : Understand and code, in an isolated lab, a default-credential scanner.
The flaw is hard to inventory by hand across a large estate.
Mission : Automate in Python the detection of vulnerable instances at scale.
Exploitation leaves numerous traces in the application logs.
Mission : Script in Python the extraction and formatting of exploitation evidence.
Large volumes of stolen credentials circulate and must be tested without causing harm.
Mission : Automate, within a strict ethical scope, the validation of exposed credentials.
Web applications are the primary attack surface. This module teaches you to detect and exploit OWASP vulnerabilities, then fix them — following a reproducible audit process.
Before attacking a web application, you draw its complete map — including the pages its menu does not show. With Burp Suite you map an application (interception proxy, automatic crawling) then attack its authentication and session management. You flush out an unlinked sensitive endpoint and the parameter that lets you impersonate a session. You perform the two opening moves of any application test: see the whole surface, and test the front door.
Objective : Map a web application.
Concepts : Spidering, proxy · Web surface
Challenge : Give the sensitive endpoint not linked in the menu.
Expected outcomes : Validated if the application is mapped and the unlinked sensitive endpoint is found.
Objective : Attack authentication and sessions.
Concepts : Auth, session · Cookies/tokens
Challenge : Give the parameter enabling the hijack.
Expected outcomes : Validated if the parameter enabling session hijacking is correctly identified.
SQL injection remains, decades after its discovery, one of the most widespread and most serious web flaws. With SQLmap you detect and exploit a SQL injection — union, blind, error-based variants — then understand how to fix it. The challenge: extract the administrator password hash through the injection. You grasp both the mechanism of the attack and the parameterised query that would have prevented it.
Objective : Detect and exploit a SQL injection.
Concepts : Union/blind/error · Remediation
Challenge : Extract the admin hash via the injection.
Expected outcomes : Validated if the injection is exploited and the admin hash correctly extracted.
An application that trusts the data it receives risks seeing it turned against it. You exploit cross-site scripting (XSS) — injecting code into a page seen by other users, in its stored, reflected and DOM variants — then file injections (booby-trapped upload, file inclusion, XML external entities — XXE). You exfiltrate a session cookie through XSS and read a system file through an XXE. You understand how an uncontrolled input becomes an unintended execution.
Objective : Exploit a stored XSS.
Concepts : Stored/reflected/DOM XSS · Encoding
Challenge : Exfiltrate the session cookie via XSS.
Expected outcomes : Validated if the stored XSS exfiltrates the session cookie.
Objective : Exploit upload, LFI and XXE.
Concepts : Upload, LFI/RFI · XXE
Challenge : Read /etc/passwd via XXE.
Expected outcomes : Validated if the XXE allows reading /etc/passwd.
Many applications check who you are, but forget to check what you are entitled to. You exploit these authorisation flaws — direct access to another user's object (IDOR), privilege escalation — then unvalidated inputs leading to execution (deserialisation, command injection). You access another user's order by changing an identifier, and find the parameter that leads to code execution. You touch the access-logic flaws, among the most frequent and most underestimated.
Objective : Exploit authorization flaws.
Concepts : IDOR, BOLA · Privileges
Challenge : Access another user's order (ID).
Expected outcomes : Validated if the IDOR grants access to another user's order.
Objective : Exploit unvalidated inputs.
Concepts : Deserialization · Command injection
Challenge : Give the parameter leading to execution.
Expected outcomes : Validated if the parameter leading to execution is correctly identified.
The token that identifies you after login is also what an attacker seeks to forge. You attack modern session management, in particular JWT tokens (JSON Web Tokens): understanding their signature, session fixation, and forging a valid token with jwt_tool. The challenge: craft an administrator JWT the application accepts. You understand where trust in a token breaks, and therefore how to guarantee it.
Objective : Attack modern session management.
Concepts : JWT, signatures · Fixation
Challenge : Forge a valid admin JWT.
Expected outcomes : Validated if a valid admin JWT is forged.
Testing an application by hand does not scale; automating it without triage produces noise. With scanners (Nikto, ZAP) you industrialise web assessment while triaging their results, then fix flaws durably and verify the fix through code analysis (SAST with Semgrep). You deliver three confirmed vulnerabilities with their criticality and prove a validated fix. You connect both ends of the cycle: find fast, and fix for good.
Objective : Industrialize and make the assessment reliable.
Concepts : Scanners, limits · False positives
Challenge : Deliver the report of 3 confirmed vulns (CVSS).
Expected outcomes : Validated if three vulnerabilities are confirmed and rated (CVSS) in the report.
Objective : Durably fix web flaws.
Concepts : Parameterized queries · Validation/encoding
Challenge : Prove the fix validated by SAST.
Expected outcomes : Validated if the SQLi and XSS are fixed and the fix validated by SAST.
A malformed HTTP header triggers code execution in a vulnerable application framework.
Mission : Understand and test an injection leading to remote code execution.
A server-side request forgery reaches the instance's metadata service.
Mission : Exploit a server-side request forgery up to the cloud metadata.
The injection allows a web shell to be planted on the transfer server.
Mission : Chain an SQL injection and the planting of a web shell within an authorised scope.
The API does not verify that the requested object belongs to the caller.
Mission : Test object-level authorisation controls (insecure direct object reference).
A logged string triggers the resolution of a remote resource.
Mission : Exploit an unchecked interpolation leading to code execution.
Beyond classic flaws, the web expert must chain vulnerabilities and master modern API security. This demanding module takes you there: RCE, advanced injections, GraphQL/REST, SSRF, business logic.
Remote code execution is the web attacker's grail: it turns a flaw into control of the machine. You obtain it two ways — insecure upload chained to other weaknesses, then deserialisation exploited through object chains (gadgets) built with ysoserial. The challenge: land a proven code execution (the output of a system command). You link isolated flaws into a chain that ends in control, which reveals why defence in depth matters.
Objective : Obtain remote code execution.
Concepts : Insecure upload · Chaining
Challenge : Obtain an RCE (output of `id`).
Expected outcomes : Validated if an RCE is obtained (output of `id`).
Objective : Exploit a deserialization for RCE.
Concepts : Gadgets · Execution chains
Challenge : Obtain an RCE via deserialization.
Expected outcomes : Validated if an RCE is obtained via deserialization.
When automatic tools fail and an application firewall stands guard, SQL injection becomes a craftsman's work. You exploit the hard cases by hand — blind injection, by boolean response or by timing — then bypass a web application firewall (WAF) through encodings and payload mutations. You extract data through a time-based injection and find the mutation that gets past the WAF. You reach the level where the attack is done by hand, where the protection believed it had won.
Objective : Exploit where tools fail.
Concepts : Blind boolean/time-based · WAF bypass
Challenge : Extract the flag via time-based blind.
Expected outcomes : Validated if the flag is extracted via a time-based blind injection.
Objective : Evade application protections.
Concepts : Encodings · Payload mutations
Challenge : Give the mutation that bypasses the WAF.
Expected outcomes : Validated if the mutation bypassing the WAF is correctly identified.
Modern applications expose most of their logic through APIs — so many doors, often less watched than the web interface. You test the security of GraphQL APIs (schema introspection, object- and function-level authorisation flaws — BOLA/BFLA) and REST, in the light of the OWASP API Top 10. You access another user's resource and an administration function without the right. You test the surface that today concentrates the most authorisation flaws.
Objective : Test a GraphQL API.
Concepts : Introspection · BOLA/BFLA
Challenge : Access another user's resource (ID).
Expected outcomes : Validated if the GraphQL BOLA grants access to another user's resource.
Objective : Attack a modern REST API.
Concepts : OWASP API Top 10 · Rate limiting
Challenge : Give the admin function accessible without rights.
Expected outcomes : Validated if the admin function accessible without rights is correctly identified.
Some features fetch a resource on your behalf — and can be diverted to reach what is off-limits to you. You exploit server-side request forgery (SSRF) — making the server query internal targets — until you reach a sensitive service. The challenge: read a cloud environment's metadata through the SSRF, a classic route towards taking over an infrastructure. You understand how a harmless feature opens a bridge to the internal network.
Objective : Exploit an SSRF to reach the internal network.
Concepts : SSRF · Cloud metadata
Challenge : Read the cloud metadata via SSRF.
Expected outcomes : Validated if the SSRF allows reading the cloud metadata.
Not all flaws are technical: some lie in the application's very logic, or in the trust it grants the browser. You exploit the client side (offensive JavaScript, CSRF, session theft with BeEF) then divert the business logic — reasoning flaws, race conditions — to obtain an undue gain. You exfiltrate a simulated victim's cookie and find the logic abuse that grants an unintended advantage. You explore flaws scanners do not see, because they belong to meaning, not syntax.
Objective : Exploit client-side trust.
Concepts : Advanced XSS, CSRF · Session theft
Challenge : Exfiltrate the simulated victim's cookie.
Expected outcomes : Validated if the simulated victim's cookie is exfiltrated.
Objective : Subvert application logic.
Concepts : Logic flaws · Race conditions
Challenge : Give the logic abuse enabling an undue gain.
Expected outcomes : Validated if the logic abuse enabling an undue gain is demonstrated.
An expert audit is not a list of flaws: it tells how their chaining leads to a major impact. You restore an advanced web audit by building the critical chain — how combined weaknesses end in compromise — and framing remediations to match. The challenge: deliver a report carrying the full impact chain. You turn technical expertise into a demonstration understandable by those who decide on the fixes.
Objective : Convey an expert web audit.
Concepts : Impact chaining · Remediation
Challenge : Deliver the report with the full critical chain.
Expected outcomes : Validated if the report presents the full, prioritized critical chain.
An exposed API delivers data without authentication.
Mission : Audit an API, its authentication and authorisation flaws, and mass enumeration.
A forged request provokes a memory leak containing tokens.
Mission : Exploit an out-of-bounds read on the appliance side and extract secrets from it.
An appliance combines an authentication bypass and an injection.
Mission : Chain an authentication bypass and execution on an appliance.
The request forgery leads to the metadata and then to role tokens.
Mission : Push a request forgery towards cloud API post-exploitation.
The tool exposes an exploitable API and upload surface.
Mission : Exploit a transfer application through its API and upload surface.
Active Directory is the heart — and the Achilles' heel — of most enterprises. This expert module teaches you to understand Windows internals and exploit the weaknesses of an AD domain.
Attacking an Active Directory domain begins by knowing it better than its administrator. With PowerView and Impacket you enumerate a Windows system and domain — processes, tokens, user account control (UAC), SMB/LDAP/Kerberos services. The challenge: spot a service account exposing an exploitable service principal name (SPN). You draw the internal map that makes all the following attacks possible — the one the defender should know first.
Objective : Enumerate a Windows system and domain.
Concepts : Processes, tokens, UAC · SMB/LDAP/Kerberos
Challenge : Give the service account with an exploitable SPN.
Expected outcomes : Validated if the service account with an exploitable SPN is correctly identified.
Kerberos, Active Directory's authentication protocol, holds weaknesses in the way it is often configured. With Rubeus you exploit two of them: kerberoasting — requesting service tickets to crack the associated accounts' passwords offline — and AS-REP roasting, which targets accounts with pre-authentication disabled. You recover a kerberoasted password and a cracked AS-REP account. You understand why these attacks remain so effective — and what neutralises them.
Objective : Compromise Kerberos service accounts.
Concepts : SPN, tickets · Cracking
Challenge : Give the kerberoasted password.
Expected outcomes : Validated if the kerberoasted password is correct.
Objective : Exploit accounts without pre-auth.
Concepts : AS-REP · Pre-auth disabled
Challenge : Give the cracked AS-REP account.
Expected outcomes : Validated if the AS-REP account is cracked and correctly identified.
On Windows, you do not always need the clear-text password: its hash is sometimes enough to move. With CrackMapExec you move laterally by reusing an authentication hash (pass-the-hash), via WMI and WinRM, then run code in memory while bypassing Windows' built-in defences (AMSI, ETW logging). You prove execution on a second host and pull off an evasion technique. You touch the moves that turn the compromise of one endpoint into the compromise of an entire fleet.
Objective : Move laterally without a password.
Concepts : PtH · WMI/WinRM
Challenge : Prove execution on a second host.
Expected outcomes : Validated if execution on a second host via pass-the-hash is proven.
Objective : Execute code in memory stealthily.
Concepts : Offensive PS · AMSI/ETW
Challenge : Give the successful evasion technique.
Expected outcomes : Validated if the payload runs in memory and the successful evasion technique is named.
In Active Directory, rights granted too broadly and misconfigured delegations open attack paths invisible to the naked eye. You exploit Kerberos delegations (constrained, unconstrained, resource-based — RBCD) and access-rights abuse (ACLs) — a misplaced GenericAll or WriteDACL. You identify the delegation type exploited and the ACL that leads to your target. You reveal the class of flaws tools like BloodHound make mappable, and that administrators underestimate.
Objective : Abuse misconfigured delegations.
Concepts : Constrained/unconstrained delegation · RBCD
Challenge : Give the delegation type exploited.
Expected outcomes : Validated if the delegation is exploited and its type correctly identified.
Objective : Exploit excessive rights.
Concepts : ACE, GenericAll/WriteDACL · Paths
Challenge : Give the exploited ACL and the target reached.
Expected outcomes : Validated if the ACL is exploited and the ACL and target reached are correct.
Once inside, an attacker seeks to stay — discreetly — and to turn a stolen authentication into access. You install a stealthy Windows persistence (tasks, services, registry keys) then mount a coercion and NTLM-relay attack: forcing a machine to authenticate, then replaying that authentication elsewhere (with ntlmrelayx and Coercer). You name the stealthiest persistence mechanism and prove a successful relay and its impact. You understand two techniques defence teams still struggle to detect.
Objective : Maintain stealthy access.
Concepts : Tasks/services · Registry keys
Challenge : Give the stealthiest persistence mechanism.
Expected outcomes : Validated if two persistences are established and the stealthiest is correctly named.
Objective : Force an authentication and relay it.
Concepts : Coercion · NTLM relay
Challenge : Prove the successful relay and its impact.
Expected outcomes : Validated if the NTLM relay succeeds and its impact is proven.
All the offensive work on Active Directory makes sense, here, only to defend it better. This building block connects attack to countermeasure: the tiering model that compartmentalises privileges, automatic management of local administrator passwords (LAPS), group managed service accounts (gMSA), and the matching detections. The challenge: name the three measures that would break the attack chain built in the previous bricks. You close the module by attacking to defend, which is a red team's reason for being.
Objective : Connect offense and defense.
Concepts : Tiering, LAPS, gMSA · Detections
Challenge : Give the 3 measures that would break the chain.
Expected outcomes : Validated if the three measures breaking the attack chain are correctly identified.
The actor takes control of the identity environment and then the domain.
Mission : Carry out a privilege escalation in a hybrid Active Directory environment.
The actor harvests credentials to move towards the critical assets.
Mission : Carry out Windows lateral movement and credential theft.
Forged tokens open access to cloud resources.
Mission : Abuse tokens and authentication in a hybrid-cloud context.
Session hijacking provides a first internal access.
Mission : Take a foothold through session hijacking, then progress on Windows.
The actor abuses built-in tools (management, directory-database copy) to stay stealthy.
Mission : Use stealthy persistence and collection techniques specific to Windows.
You can test a system; now think like an offensive team. This module puts you in the shoes of a Red Team operator facing an Active Directory domain: foothold, mapping, credential theft, lateral movement, up to domain dominance — without being detected.
A red team operation resembles a real attack: it starts far from the target and progresses while staying invisible. On a representative training environment (GOAD), you reconnoitre an enterprise then gain and stabilise a first foothold — managing a command channel (C2) and operational discretion (OPSEC). You name the initial-access service targeted and the foothold obtained. You adopt the stance of a patient, methodical adversary, the one defences must learn to detect.
Objective : Map the target before intrusion.
Concepts : External/internal recon · AD surface
Challenge : Give the targeted initial access service.
Expected outcomes : Validated if the AD surface is reconned and the targeted initial access service is relevant.
Objective : Obtain and stabilize a first access.
Concepts : Access vectors · C2, OPSEC
Challenge : Give the foothold (host+user).
Expected outcomes : Validated if the C2 agent is deployed and the foothold (host+user) is provided.
In a large domain, the path from a plain account to full control almost always exists — you just have to see it. With BloodHound and SharpHound you map these attack paths, representing Active Directory's objects, rights and relationships as a graph. The challenge: find the shortest path to the domain administrator and the decisive edge (relationship). You adopt the tool that turned both the attack and the defence of Active Directory into graph analysis.
Objective : Map paths to Domain Admin.
Concepts : AD objects, ACL · Shortest paths
Challenge : Give the shortest path to DA and the key edge.
Expected outcomes : Validated if the shortest path to DA and the key edge are correctly identified.
On a compromised machine, the credentials of logged-in users are often recoverable — straight from memory. With Mimikatz you extract these secrets (hashes, Kerberos tickets) from the LSASS process, working with modern memory protections, then compromise service accounts by kerberoasting. You recover a privileged account's NTLM hash and a service account's password. You understand why protecting credentials in memory has become a central concern of Windows defence.
Objective : Extract secrets from a compromised host.
Concepts : LSASS, tickets · Memory protection
Challenge : Give the NTLM hash of an extracted privileged account.
Expected outcomes : Validated if memory secrets are extracted and the NTLM hash of a privileged account is correct.
Objective : Compromise service accounts.
Concepts : SPN, service tickets · Cracking
Challenge : Give the service account and the password.
Expected outcomes : Validated if the ticket is cracked and the service account and its password are correct.
Between the first compromised endpoint and control of the domain lies a succession of bounces and escalations. With Impacket and Rubeus you chain lateral movement — by reusing a hash or a ticket (pass-the-hash, pass-the-ticket), via WMI/WinRM — and escalation to domain administrator by abusing rights and delegations. You prove execution on a second host then the obtaining of domain administrator rights. You reconstruct the full progression a defence team must be able to retrace afterwards.
Objective : Move laterally via PtH/PtT.
Concepts : Pass-the-hash/ticket · WMI/WinRM
Challenge : Prove execution on a second host.
Expected outcomes : Validated if execution on a second host is proven.
Objective : Reach domain control.
Concepts : ACL abuse · Delegation
Challenge : Prove obtaining Domain Admin rights.
Expected outcomes : Validated if Domain Admin rights are obtained and the chain documented.
Total control of a domain is measured not by an access, but by the ability to extract all its secrets and return at will. You run a DCSync attack — impersonating a domain controller to replicate its secrets, including the krbtgt account's hash — then forge a stealthy persistence (Golden Ticket). You recover the krbtgt account's hash and, above all, identify the recommended detection of a Golden Ticket. You reach the summit of the AD attack, where understanding the offence is the only way to build the detection.
Objective : Extract the domain secrets.
Concepts : DCSync, krbtgt · Replication
Challenge : Give the krbtgt account hash.
Expected outcomes : Validated if the DCSync succeeds and the krbtgt account hash is correct.
Objective : Retain control (Golden Ticket).
Concepts : Golden/Silver Ticket · Stealthy persistence
Challenge : Give the recommended Golden Ticket detection.
Expected outcomes : Validated if the Golden Ticket is demonstrated and the recommended detection is relevant.
Reaching a segmented network from a compromised endpoint means digging a tunnel — and doing it without being spotted. With Chisel you pivot across segments (port forwarding, SOCKS proxy) then refine your operational discretion against modern defences (bypassing AMSI and ETW logging, command-channel stealth). You reach a host on a segmented network and pull off an evasion technique. You connect access and invisibility, the two requirements of a realistic offensive operation — and therefore of a test that truly prepares the defence.
Objective : Reach segmented networks.
Concepts : Pivot, port forwarding · SOCKS
Challenge : Give the segmented-network host reached.
Expected outcomes : Validated if the pivot is established and the segmented-network host reached is correct.
Objective : Evade modern defenses.
Concepts : AMSI/ETW bypass · C2 stealth
Challenge : Give the evasion technique that worked.
Expected outcomes : Validated if the protection is bypassed and the successful evasion technique is named.
The intrusion starts with a call to the help desk and ends in control of the identity environment and the domain.
Mission : Simulate a Red Team operation running from social engineering to the domain controller.
After entry through remote access with no multi-factor authentication, the actor progresses towards the critical assets.
Mission : Replay a lateral-movement and privilege-escalation scenario in an Active Directory environment.
The actor uses only system tools to remain undetected.
Mission : Conduct a stealthy Red Team operation based on living off the land.
Forged tokens give access to organisations' cloud resources.
Mission : Exploit token and identity abuse in a hybrid Active Directory environment.
Session hijacking provides an entry point into the internal network.
Mission : Take an initial foothold through session hijacking, then progress through the directory.
Understanding how a program runs at the lowest level is the key to exploit development. This expert module trains you in it: memory, assembly, shellcode, stack overflow.
Exploit development begins where abstraction stops: in the processor's memory and registers. This building block has you understand a program's memory layout (stack, heap, registers) and the overflows that occur there, then read and write x86 assembly. The challenge: find the exact offset that overwrites the return address, and identify a system call. You lay the foundations without which no low-level exploitation makes sense.
Objective : Master memory for exploitation.
Concepts : Stack/heap, registers · Overflows
Challenge : Give the offset to overwrite the return address.
Expected outcomes : Validated if the overflow is mastered and the return-address offset is correct.
Objective : Read and write assembly.
Concepts : Registers, instructions · Syscalls
Challenge : Give the number of the system call executed.
Expected outcomes : Validated if assembly is read/written and the system-call number is correct.
Taking control of a program is useless without a payload to run: that is the role of shellcode, a self-contained machine-code fragment. With NASM you write a working shellcode in assembly, meeting strict constraints — notably the absence of null bytes that would cut its copy short. The challenge: provide a null-free shellcode and give its size. You learn to craft, byte by byte, the payload your exploit will deliver.
Objective : Write a null-free shellcode.
Concepts : execve shellcode · Null-free constraints
Challenge : Provide a null-free shellcode and its size.
Expected outcomes : Validated if the /bin/sh shellcode runs, with no null byte, and its size provided.
Two of the founding vulnerabilities of software exploitation are worked here end to end. You assemble a complete stack-overflow exploit — taking control of the instruction pointer, a NOP sled — then exploit a format-string vulnerability, which offers arbitrary read and write in memory. You obtain a shell on a vulnerable binary and overwrite a chosen address through the format string. You turn a memory weakness into execution control, the core of the craft.
Objective : Assemble a complete exploit.
Concepts : EIP control · NOP sled
Challenge : Obtain a shell on the vulnerable binary.
Expected outcomes : Validated if a shell is obtained on the vulnerable binary.
Objective : Exploit a format string vulnerability.
Concepts : Format string · Arbitrary read/write
Challenge : Give the address overwritten via format string.
Expected outcomes : Validated if the address overwritten via format string is correct.
Finding a flaw in a binary whose source you do not have demands two complementary approaches: analysing it, and bombarding it with inputs. You first reverse-engineer an unknown binary to understand its logic, then build a simple fuzzer — a tool that generates random inputs until it triggers a revealing crash. You locate a verification function and find the input that crashes the program. You connect understanding and discovery, the two routes to an exploitable vulnerability.
Objective : Analyze an unknown binary.
Concepts : Control flow · Logic identification
Challenge : Give the address of the verification function.
Expected outcomes : Validated if the address of the verification function is correct.
Objective : Find crashes automatically.
Concepts : Fuzzing · Crash detection
Challenge : Give the input causing the crash.
Expected outcomes : Validated if the fuzzer finds the input causing the crash.
Developing an exploit by hand is instructive; making it reliable and replaying it requires tooling. With pwntools you tool exploit creation, which automates interaction with the target binary, then identify the modern protections an exploit will have to bypass: stack canary, non-executable memory (NX), address randomisation (ASLR/PIE). You deliver a working pwntools exploit and list the active mitigations. You connect building the exploit to knowing the defences standing in its way.
Objective : Tool up exploit creation.
Concepts : pwntools · Automation
Challenge : Provide the working pwntools exploit.
Expected outcomes : Validated if the pwntools exploit is reliable and working.
Objective : Understand the protections to bypass.
Concepts : Stack canary, NX · ASLR/PIE
Challenge : List the binary's active mitigations.
Expected outcomes : Validated if the binary's active mitigations are correctly listed.
An unchecked interpolation leads to application code execution.
Mission : Build an application-exploitation proof of concept from the primitive.
A previously unknown SQL injection opens the way to code execution.
Mission : Develop an injection exploit leading to code execution.
An out-of-bounds read reveals the content of the appliance's memory.
Mission : Write a memory-disclosure exploit (out-of-bounds read) and make the extraction reliable.
Two distinct primitives combine into a remote execution.
Mission : Assemble an exploitation chain from two primitives.
The advisory describes the flaw before it is mass-exploited.
Mission : Reverse-engineer a code execution from a security advisory and write the trigger.
Modern protections — DEP, ASLR, canaries — make exploitation harder, but not impossible. This expert module teaches you to bypass them: heap corruption, ROP, information leaks, weaponisation.
After the stack, the heap: the dynamically allocated memory region whose corruption opens subtler exploitations. You exploit heap corruption by understanding how the allocator works (the blocks, or chunks) and the classic bugs — use-after-free, double free. The challenge: execute a hidden function by corrupting the heap. You move up a level of difficulty, where exploitation becomes a chess game against memory management.
Objective : Exploit heap corruption.
Concepts : Allocator, chunks · UAF/double free
Challenge : Execute the hidden function via heap corruption.
Expected outcomes : Validated if the heap corruption executes the hidden function.
When data memory can no longer be executed (DEP/NX protection), you no longer inject code: you reuse what is already there. You build a return-oriented programming (ROP) chain — an assembly of existing code fragments (gadgets) that, strung together, perform the intended action, such as making a region executable via mprotect. The challenge: provide the ROP chain that opens a shell. You learn the technique that brought exploitation back to life against a major protection.
Objective : Build a ROP chain.
Concepts : DEP/NX, gadgets · mprotect
Challenge : Provide the ROP chain opening a shell.
Expected outcomes : Validated if the ROP chain opens a shell.
Address randomisation (ASLR) prevents knowing where the code to reuse is — unless an information leak reveals it. You defeat ASLR by exploiting a leak to recover the C library's address (the return-to-libc technique), then divert the imported-functions table (GOT) through a format string. You compute the libc base to obtain a shell and redirect the GOT to your code. You combine several primitives to undo a protection once thought sufficient.
Objective : Defeat ASLR via a leak.
Concepts : ASLR/PIE · ret2libc
Challenge : Give the libc base and obtain a shell.
Expected outcomes : Validated if the libc base is found and a shell obtained (ret2libc).
Objective : Obtain arbitrary read/write.
Concepts : Format string · GOT overwrite
Challenge : Hijack the GOT and execute code.
Expected outcomes : Validated if the GOT is hijacked and code executed.
Some flaws exist only for an instant: between the moment a program checks a condition and the moment it acts. You exploit such a race condition (TOCTOU — check then use) on a privileged binary, then approach Linux kernel exploitation and its primitives. The challenge: obtain root rights through the race, and describe the kernel primitive obtained. You touch two advanced frontiers of exploitation, where time and the heart of the system become the playing field.
Objective : Exploit a race condition.
Concepts : TOCTOU · SUID
Challenge : Obtain root via the SUID race.
Expected outcomes : Validated if root is obtained via exploiting the SUID race condition.
Objective : Understand Linux kernel exploitation.
Concepts : User/kernel spaces · Kernel primitives
Challenge : Give the kernel primitive obtained.
Expected outcomes : Validated if the kernel primitive obtained is correctly described.
Windows has stacked, over the versions, protections that make exploitation far harder than it once was. With WinDbg you study and bypass these modern mitigations — control-flow integrity (CFG), hardware-enforced stack (CET), exception handling (SEH). The challenge: identify the mitigation bypassed in the scenario. You gauge the true state of the art on the Windows side, where each protection calls for an ever more sophisticated counter.
Objective : Bypass Windows mitigations.
Concepts : CFG, CET · SEH
Challenge : Give the mitigation bypassed.
Expected outcomes : Validated if the bypassed Windows mitigation is correctly named.
An exploit that works one time in ten is not a weapon, it is a lab curiosity. You make an exploit reliable for real use — stable success rate, cleanup of traces — then assemble a full chain, from the initial bug to root rights. You measure the success rate obtained and demonstrate an end-to-end compromise. You reach the culmination of exploit development: a reliable, reproducible demonstration that establishes, beyond doubt, the reality of a risk.
Objective : Make an exploit reliable for real use.
Concepts : Multi-attempt reliability · Cleanup
Challenge : Give the measured success rate.
Expected outcomes : Validated if the success rate of the reliable exploit is measured.
Objective : Assemble an end-to-end chain.
Concepts : Chaining · From bug to root
Challenge : Obtain root via the complete chain.
Expected outcomes : Validated if root is obtained via the complete exploitation chain.
An integer overflow in an image decoder serves as the basis for a zero-interaction exploitation.
Mission : Study an advanced primitive (integer overflow towards arbitrary computation) at a rigorous conceptual level.
The implant triggers when the SSH daemon loads, through a diverted mechanism.
Mission : Analyse an advanced backdoor and its triggering, and reconstruct its integration.
A prefix truncation weakens the session after the key exchange.
Mission : Design, in a lab, a protocol-level attack and measure its conditions.
The malware reprograms safety controllers via a proprietary protocol.
Mission : Study the exploitation of a safety controller at an advanced level, in a lab.
The memory disclosure provides reusable tokens.
Mission : Push a memory exploitation through to reconstructing a complete session.
Bridging the gap between attack and defence is the purpose of purple teaming. This expert module teaches you to emulate an adversary in a controlled way, write the missing detections, and continuously measure your coverage.
To know whether a defence works, nothing beats confronting it with real attack techniques — under control. This building block has you emulate an adversary: replaying atomic ATT&CK techniques with Atomic Red Team, then playing an automated, contained attack chain with Caldera. You identify a technique executed but undetected and obtain the report locating the detection stage. You measure the defence by ordeal rather than by assumption — the founding principle of purple teaming.
Objective : Replay controlled ATT&CK techniques.
Concepts : Emulation vs simulation · Atomic tests
Challenge : Give the executed technique that went undetected.
Expected outcomes : Validated if coverage is mapped and the undetected technique is correctly named.
Objective : Run an automated attack chain.
Concepts : Abilities, adversary profiles · Containment
Challenge : Provide the Caldera report and the detection step.
Expected outcomes : Validated if the Caldera operation is run and the report and detection step are provided.
Discovering a detection gap is pointless if you do not close it and keep a record. This building block has you write detections for the blind spots revealed by emulation — managed as code, tested in continuous integration — then track a purple campaign's progress with VECTR. You measure the coverage gain after adding a detection and the campaign's final score. You close the virtuous purple cycle: attack, measure the gap, close it, verify.
Objective : Write detections for the gaps.
Concepts : Purple cycle · Detection CI
Challenge : Give the coverage gain after adding them.
Expected outcomes : Validated if a detection is written per gap and the coverage gain is measured.
Objective : Track purple campaigns.
Concepts : Detection scoring · Campaigns
Challenge : Give the campaign's final detection score.
Expected outcomes : Validated if the campaign is tracked and the final detection score is correct.
Emulating an isolated technique is useful; reproducing a real actor's full modus operandi is more so. This building block has you build an emulation plan faithful to a documented threat actor, then validate your security controls' real effectiveness through continuous simulation (BAS — automated defence validation). You give the three signature techniques of the emulated actor and identify the control that proves ineffective. You test your defence against a credible adversary, not an abstract threat.
Objective : Reproduce an actor's modus operandi.
Concepts : Threat-informed · Emulation plan
Challenge : Give the 3 signature TTPs of the emulated actor.
Expected outcomes : Validated if the actor is emulated and its three signature TTPs are correctly identified.
Objective : Test the real effectiveness of controls.
Concepts : BAS · Preventive/detective controls
Challenge : Give the ineffective control identified.
Expected outcomes : Validated if effectiveness is measured and the ineffective control is correctly identified.
Purple teaming reaches its peak when offensive and defensive teams work together, in real time, rather than each on their own side. This building block has you run a joint purple exercise — attack and detection responding live — then draw an actionable after-action review (AAR) from it. You identify the most critical blind spot observed and produce an AAR with three improvements and their owners. You turn a confrontation into shared progress, which is the whole value of the approach.
Objective : Run a real-time red/blue exercise.
Concepts : Real-time coordination · Injects
Challenge : Give the most critical blind spot observed.
Expected outcomes : Validated if the joint exercise is run and the most critical blind spot is identified.
Objective : Produce an actionable AAR.
Concepts : AAR · Improvement plan
Challenge : Provide the AAR with 3 improvements and owners.
Expected outcomes : Validated if the AAR provides three improvements with their owners.
Producing detections by hand cannot keep up with the pace of threats: you have to industrialise. This building block has you build a detection-engineering pipeline — where each rule is tested automatically at every change, like software code. The challenge: deliver the pipeline that validates the rules at each commit. You apply to detection the engineering practices that guarantee its quality and durability, beyond the one-off.
Objective : Industrialize detection production.
Concepts : Detection pipeline · Automated tests
Challenge : Provide the pipeline validating rules at every commit.
Expected outcomes : Validated if the pipeline validates the rules at every commit.
Exploitation of the gateways results in the theft of session tokens.
Mission : Emulate the exploitation in a lab, then write and validate the corresponding detection.
The JNDI exploit is simple to replay in a controlled environment.
Mission : Replay the exploit in a lab and measure the coverage of existing detection.
The techniques rest on social engineering and account abuse.
Mission : Emulate identity-abuse techniques and close the detection blind spots.
Living-off-the-land techniques evade classic signatures.
Mission : Test the detection of living-off-the-land behaviour and refine the rules.
Industrial systems run energy, water and factories — and follow rules quite different from office IT. This module helps you understand this OT world and its security stakes.
In business IT, you protect confidentiality first; in industry, it is the safety of people and the availability of the process that come first — an inversion that changes everything. This building block has you place an industrial system's components (programmable logic controller — PLC, SCADA supervision, operator interface — HMI) within the Purdue model, which ranks the levels of an industrial network. The challenge: place a controller at the right Purdue level. You adopt the reading grid that structures all industrial-systems security.
Objective : Place ICS components and their priorities.
Concepts : Safety/availability priorities · DCS/SCADA, HMI/RTU/PLC
Challenge : Give the Purdue level of the PLC.
Expected outcomes : Validated if the chain is mapped per Purdue and the PLC's level is correct.
The protocols that drive factories and power grids were designed for reliability, in an era when security was not a concern: many authenticate nothing. This building block has you analyse Modbus — and observe that a command is accepted there without any identity check — then the energy protocols (DNP3, IEC-104). You read a tank-level register's value and identify an observed control command. You understand why industrial security plays out first on intrinsically vulnerable protocols.
Objective : Analyze Modbus and its lack of security.
Concepts : Modbus, functions · No authentication
Challenge : Give the value of the tank-level register.
Expected outcomes : Validated if Modbus is analyzed and the tank-level register value is correct.
Objective : Understand energy protocols.
Concepts : DNP3, IEC-104 · Telemetry/commands
Challenge : Give the control command observed.
Expected outcomes : Validated if the observed DNP3 control command is correctly identified.
In an industrial setting, you cannot fix everything or shut everything down: the first defence is to compartmentalise. This building block has you segment an OT environment along the zones and conduits of the IEC 62443 standard — the industrial-systems security standard — then deploy an industrial decoy (a honeypot, with Conpot) to detect a probe. You name the zone to isolate first and the address that probed the decoy. You apply the two countermeasures that protect a process you can neither patch nor freely interrupt.
Objective : Segment an OT environment.
Concepts : Zones/conduits · OT segmentation
Challenge : Give the zone to isolate first.
Expected outcomes : Validated if zones and conduits are defined and the zone to isolate first is justified.
Objective : Detect via an industrial decoy.
Concepts : OT honeypot · Probe detection
Challenge : Give the IP that probed the OT honeypot.
Expected outcomes : Validated if the honeypot is deployed and the IP that probed it is correctly noted.
In industrial security, a risk is measured not in lost data but in physical consequences: a leak, a production halt, a danger to lives. This building block has you run an OT risk assessment with the CSET tool, reasoning first about the physical impact of scenarios. The challenge: name the scenario with the greatest physical impact. You learn to rank industrial risks by what truly matters in this world: safety above all.
Objective : Assess risk with physical impact.
Concepts : Physical consequences · Methodology
Challenge : Give the scenario with the greatest physical impact.
Expected outcomes : Validated if the assessment is conducted and the scenario with the greatest physical impact is correct.
You do not defend an industrial estate you do not know — but inventorying it must never disturb the process. This building block has you passively discover an OT network's assets, that is, identify them without emitting risky traffic, then harden a controller and its operator access. You identify the model of a discovered controller and the hardening measure to apply first. You take on board the founding constraint of OT: acting without ever putting production at risk.
Objective : Inventory without disrupting the process.
Concepts : Passive discovery · Equipment identification
Challenge : Give the discovered PLC model.
Expected outcomes : Validated if the passive discovery succeeds and the PLC model is correct.
Objective : Secure a PLC and its access.
Concepts : PLC hardening · HMI access
Challenge : Give the priority hardening measure.
Expected outcomes : Validated if the hardening is applied and the priority measure is correctly named.
An intrusion that started in the office network reaches the control stations and cuts electricity to some 230,000 households.
Mission : Understand the architecture of an industrial system and how an IT attack reaches the operational side.
The operator halts distribution as a precaution while the attack affects the IT side.
Mission : Distinguish the IT impact from the precautionary operational shutdown, and grasp the continuity stakes.
Investigating an industrial incident means doing so without ever endangering the process. This expert module teaches you OT forensics and incident response under safety constraints.
Investigating an industrial incident imposes a rule that classic forensics ignores: never compromise the process's safety to collect a piece of evidence. This building block has you acquire evidence in OT under that constrained order, then analyse traffic to detect a process manipulation against a reference activity. You name the evidence source to favour first and the malicious Modbus command. You adapt the investigation to an environment where a wrong move can have physical consequences.
Objective : Collect without disrupting the process.
Concepts : Safety constraints · OT volatility order
Challenge : Give the evidence source to prioritize first.
Expected outcomes : Validated if the plan is non-intrusive and the evidence source to prioritize is correct.
Objective : Detect a process manipulation.
Concepts : OT baseline · Abnormal commands
Challenge : Give the malicious Modbus command.
Expected outcomes : Validated if the anomaly is detected and the malicious Modbus command is correct.
The most serious industrial attacks do not steal data: they modify a controller's program to act on the physical world. This building block has you investigate a compromised controller — spotting a change to its program logic — then characterise a malware specialised in OT. You identify the controller's program modification and the industrial protocol the malware targets, with its intended effect. You touch the very heart of what sets an industrial cyberattack apart: its goal is physical.
Objective : Investigate a compromised PLC.
Concepts : PLC logic · Program modification
Challenge : Give the detected PLC program modification.
Expected outcomes : Validated if the comparison succeeds and the PLC program modification is correctly identified.
Objective : Characterize OT malware.
Concepts : ICS families · OT indicators
Challenge : Give the targeted OT protocol and the intended effect.
Expected outcomes : Validated if the targeted OT protocol and the intended effect are correct.
Reconstructing an industrial incident means crossing two worlds: the IT traces and the physical values of the process. This building block has you rebuild an OT incident's timeline then detect an abnormal physical deviation — a sensor value falsified to mask a manipulation, as in the most notable attacks against industry. You date the initial access vector and identify the sensor whose value was rigged. You learn to read an incident where the digital and the physical meet.
Objective : Reconstruct an incident's sequence.
Concepts : Multi-source correlation · Timeline
Challenge : Give the time and the initial access vector.
Expected outcomes : Validated if the timeline is coherent and the time and initial access vector are correct.
Objective : Spot an abnormal physical deviation.
Concepts : Process values · Safety thresholds
Challenge : Give the sensor whose value was falsified.
Expected outcomes : Validated if the overshoot is detected and the falsified sensor is correctly identified.
In industrial incident response, the most obvious action — cut, isolate — can be the most dangerous if it destabilises a physical process. This building block has you contain an OT incident in a safety-compatible way, in IT/OT coordination, then bring the process back to a safe state before any return to service. You choose the containment that introduces no risk and the safe recovery order. You take on board OT's absolute priority: protecting people and the process before the data.
Objective : Contain without physical risk.
Concepts : Safety-compatible containment · IT/OT coordination
Challenge : Give the containment introducing no risk.
Expected outcomes : Validated if the applied containment introduces no physical risk.
Objective : Restore the process safely.
Concepts : Safe state · Validation before restart
Challenge : Give the secure recovery order.
Expected outcomes : Validated if the recovery is planned and the secure recovery order is correct.
An industrial lessons-learned review is judged not by its technicality, but by its ability to prevent the next incident — and the next danger. This building block has you restore an OT incident in a safety-oriented report, then draw concrete lessons from it. The challenge: deliver a report with three prioritised improvements. You turn an industrial incident into a security gain, in a sector where every unlearned lesson can cost dearly in the literal sense.
Objective : Report and improve.
Concepts : Safety-oriented report · Lessons
Challenge : Provide the report with 3 prioritized improvements.
Expected outcomes : Validated if the safety-oriented report presents three prioritized improvements.
Malware speaks directly to controllers over Modbus and cuts the heating of hundreds of buildings.
Mission : Analyse industrial malware and the traces it leaves on the Modbus protocol.
The malware targets a site's safety controllers, at the risk of neutralising the protections.
Mission : Investigate an attack on a safety-instrumented system and its TriStation protocol.
The intrusion combines malware, takeover of the control stations and trace wiping.
Mission : Reconstruct the timeline of an intrusion on an operational network.
Twenty-two energy firms are affected through perimeter equipment, sometimes on the same day.
Mission : Conduct a coordinated incident response across several victims in the same sector.
A state actor pre-positions itself durably in infrastructure networks.
Mission : Carry out hunting and response against stealthy persistence in a critical environment.
Connected devices multiply attack surfaces, from firmware to hardware. This expert module teaches you to analyse and exploit them: firmware extraction, hardware interfaces, IoT protocols.
A connected object's embedded software — its firmware — often holds secrets its designers believed unreachable. This building block has you extract and analyse a firmware (compressed file systems, telltale entropy), emulate it to analyse it running (MIPS/ARM architectures), then reverse-engineer it. You find a hardcoded credential, an exposed vulnerable service, and even a backdoor. You reach the innards of connected objects, where countless flaws invisible from the outside reside.
Objective : Extract and analyze an IoT firmware.
Concepts : Formats, SquashFS · Entropy
Challenge : Give the hardcoded credential found.
Expected outcomes : Validated if the firmware is extracted and the hardcoded credential is correct.
Objective : Dynamically analyze a firmware.
Concepts : MIPS/ARM emulation · Network surface
Challenge : Give the exposed vulnerable service.
Expected outcomes : Validated if the firmware is emulated and the exposed vulnerable service is correct.
Objective : Analyze the embedded binary.
Concepts : Embedded binary · Auth logic
Challenge : Give the credential of the backdoor found.
Expected outcomes : Validated if the backdoor is found and its credential is correct.
An object's security does not stop at its software: on its circuit board, debug ports sometimes offer direct access. This building block has you access a device through its hardware interfaces — the UART serial console, and its cousins JTAG and SPI — often left active in production. The challenge: obtain a command interpreter (shell) through the UART, from the bootloader banner. You understand that physical access to a connected object opens a route no software protection closes.
Objective : Access via hardware debugging.
Concepts : UART/JTAG/SPI · Serial console
Challenge : Obtain a shell via UART (bootloader banner).
Expected outcomes : Validated if a shell is obtained via UART (bootloader banner).
Connected objects talk through lightweight protocols — convenient, but often without access control. This building block has you exploit these protocols (MQTT, CoAP, UPnP) then a network vulnerability of an IoT device. The challenge speaks for itself: publish on the channel (topic) that drives an actuator, and prove the access obtained on the device. You measure how a poorly protected connected object becomes a control point for anyone who knows how to talk to it.
Objective : Exploit a weak IoT protocol.
Concepts : MQTT/CoAP/UPnP · Weaknesses
Challenge : Publish on the topic controlling the actuator.
Expected outcomes : Validated if publishing on the topic controlling the actuator succeeds.
Objective : Exploit an IoT network flaw.
Concepts : IoT vulns · Exploitation
Challenge : Prove the access obtained on the equipment.
Expected outcomes : Validated if access to the equipment is obtained and proven.
Many objects communicate over no cable at all: their security plays out in the airwaves. This building block introduces you to the radio attack surfaces (Bluetooth Low Energy — BLE, Zigbee) with software-defined radio, then has you chain a full attack — from firmware to network to physical control. You identify a radio message type and take control of an actuator end to end. You connect all of a connected object's surfaces in a single demonstration, the one that reveals the true scale of the risk.
Objective : Understand radio surfaces.
Concepts : BLE/Zigbee · Radio capture
Challenge : Give the radio message type identified.
Expected outcomes : Validated if the identified radio message type is correct.
Objective : Chain firmware→network→control.
Concepts : Chaining · From firmware to control
Challenge : Take control of the actuator end to end.
Expected outcomes : Validated if control of the actuator is obtained end to end.
Having seen where a connected object gives way, you flip the perspective: how to make it safe, from deployment to end of life. This building block has you frame IoT hardening recommendations covering the device's whole life cycle. The challenge: name the three priority hardening measures. You close the IoT approach with its defensive purpose: turning knowledge of the flaws into concrete protection.
Objective : Recommend a hardening.
Concepts : Lifecycle · Best practices
Challenge : Give the 3 priority hardening measures.
Expected outcomes : Validated if the three priority hardening measures are relevant.
Connected devices on factory credentials form a large-scale botnet.
Mission : Analyse a botnet of connected devices: default credentials, propagation, scale effect.
Unmaintained small-office routers are enrolled to conceal state activity.
Mission : Study the compromise of end-of-life edge equipment and the hardening measures.
Exposed firewalls are exploited on their negotiation service.
Mission : Exploit in a lab and then harden firewalls of industrial use.
The malware manipulates controllers and deprives hundreds of buildings of heating.
Mission : Connect the industrial connected device to a physical impact via the Modbus protocol.
The actor settles on peripheral network equipment to last.
Mission : Study persistence on edge equipment and the means to dislodge it.
Testing an industrial environment without ever compromising process safety is the whole art of OT pentesting. This expert module trains you in it, methodically and carefully.
A penetration test run as in business IT can, in an industrial setting, cause a production halt — or even an accident. This building block has you adapt the pentest to OT constraints: a methodology where passive always precedes active, and where safety prevails over the objective. You state the golden rule of OT pentesting and passively map a controller, down to measuring its exposure on the internet. You take on board what makes industrial offensive testing so particular: you never test a process at the cost of its safety.
Objective : Adapt the pentest to OT constraints.
Concepts : Physical risks · Passive first
Challenge : Give the golden rule of OT pentesting.
Expected outcomes : Validated if the OT-safe methodology is defined and the golden rule is correctly stated.
Objective : Map without emitting risky traffic.
Concepts : Passive discovery · External exposure
Challenge : Give the discovered PLC and its Internet exposure.
Expected outcomes : Validated if the PLC is discovered without noise and its Internet exposure is verified.
On an industrial protocol with no authentication, proving an attack's impact comes down to injecting a command nothing distinguishes from a legitimate one. This building block has you demonstrate — in a simulated, controlled environment — injection and replay on Modbus, then on the energy protocols (DNP3, IEC-104). You change the state of a simulated controller's output and inject a control command. You establish the reality of a risk operators often struggle to believe, while staying within a danger-free frame.
Objective : Demonstrate the impact of a Modbus injection.
Concepts : Injection/replay · Controlled impact
Challenge : Change the state of a simulated PLC output.
Expected outcomes : Validated if the state of a simulated PLC output is changed in a controlled way.
Objective : Target energy protocols.
Concepts : DNP3/IEC-104 · Control commands
Challenge : Give the injected control command.
Expected outcomes : Validated if the injected control command is correctly described.
Searching for flaws in industrial equipment by fuzzing — bombarding it with malformed inputs — demands extreme caution: a crash can stop a production line. This building block has you practise cautious OT fuzzing with boofuzz then attack a supervision interface (HMI/SCADA), often a simple, poorly protected web application. You find the input that triggers instability and obtain an access on the HMI. You test two critical surfaces, measuring at every step the physical risk that others ignore.
Objective : Find weaknesses via cautious fuzzing.
Concepts : Cautious OT fuzzing · Crash detection
Challenge : Give the input causing the instability.
Expected outcomes : Validated if cautious fuzzing isolates the input causing the instability.
Objective : Compromise a supervision interface.
Concepts : Web HMI/SCADA · Application weaknesses
Challenge : Give the access obtained on the HMI.
Expected outcomes : Validated if an HMI weakness is exploited and access obtained.
Most industrial attacks do not arrive directly: they pass through the office network before crossing the boundary into OT. This building block has you demonstrate that IT→OT crossing — pivoting from business IT to an industrial device — then show an impact on the process with no real danger, within a strict safety frame. You reach an OT device from IT and demonstrate a contained process effect. You establish the scenario operators most dread, proving it is real without ever making it dangerous.
Objective : Demonstrate the IT→OT crossing.
Concepts : IT/OT boundary · Pivot
Challenge : Reach an OT device from IT.
Expected outcomes : Validated if an OT device is reached from IT via the pivot.
Objective : Show impact without real danger.
Concepts : Simulated impact · Safety frame
Challenge : Give the demonstrated process effect.
Expected outcomes : Validated if the process effect is demonstrated on the twin, with no real danger.
An industrial audit report that recommends 'shut down and fix' is an inapplicable report: in OT, shutting down is not a default option. This building block has you restore an OT audit aligned with the IEC 62443 standard, reasoning in terms of physical risk and remediations achievable without interrupting production. The challenge: propose three OT-compatible, prioritised remediations. You learn to frame recommendations an industrial operator can actually apply.
Objective : Report aligned with IEC 62443.
Concepts : Physical-risk-oriented report · No-shutdown remediations
Challenge : Provide 3 prioritized OT-compatible remediations.
Expected outcomes : Validated if three prioritized OT-compatible remediations are provided and mapped to 62443.
The attack travels from the office network to the control stations.
Mission : Map an operational network and its IT-to-operational entry points, in a lab.
The safety controllers communicate through a poorly protected proprietary protocol.
Mission : Assess the security of a safety-instrumented system and its proprietary protocols.
The malware exploits the reachability of controllers over Modbus.
Mission : Test in an isolated lab the exposure of controllers over Modbus/TCP.
The perimeter firewalls of the energy sites are exposed to the internet.
Mission : Audit the perimeter exposure of an operational network.
The IT incident feeds into the operational decision.
Mission : Assess the IT/operational boundary and the quality of segmentation.
Securing OT at scale means building a programme, not stacking tools. This expert module teaches you to structure it per the IEC 62443 standard, in the context of critical infrastructure.
Industrial security has its own structuring, internationally recognised body of standards: the IEC 62443 series. This building block has you understand its architecture — its standard families, its roles (operator, integrator, supplier), its zones and its security levels (SL) — then run a per-zone risk assessment under part 3-2. You determine a critical zone's target security level and the most important gap to close. You take ownership of the framework that sets the reference for governing an industrial site's cybersecurity.
Objective : Master the 62443 structure and responsibilities.
Concepts : Families 1/2/3/4 · Roles, zones, SL
Challenge : Give the target SL of the critical control zone.
Expected outcomes : Validated if zones/conduits and SL are defined and the target SL of the critical zone is correct.
Objective : Conduct a per-zone assessment.
Concepts : Per-zone assessment · SL-Target
Challenge : Give the most critical SL gap.
Expected outcomes : Validated if the per-zone assessment succeeds and the most critical SL gap is correct.
Monitoring an industrial network is not done like an office network: detection must be passive and suited to the field protocols. This building block has you design an OT monitoring architecture then build an industrial incident-response plan where safety always comes first. You name the priority collection point and deliver a playbook whose first three actions are safe for the process. You connect detection and response in the only frame acceptable in OT: the one that never puts the process at risk.
Objective : Design detection adapted to OT.
Concepts : Passive OT monitoring · Adapted detection
Challenge : Give the priority collection point.
Expected outcomes : Validated if the monitoring architecture is passive and the priority collection point is correct.
Objective : Build an industrial IR playbook.
Concepts : OT IR · Safety first
Challenge : Provide the playbook with the first 3 safe actions.
Expected outcomes : Validated if the OT playbook places safety first and provides the first three safe actions.
Two recurring weaknesses of industrial sites: an organisation untrained for crisis, and poorly secured remote-maintenance access. This building block has you design and run an OT-specific tabletop exercise, drawing on recognised templates (CISA CTEP), then secure third-party remote access (jump-host relaying, strong authentication). You build the exercise scenario and its measurable objective, and settle on a safe remote-access architecture. You handle two major entry points that recent industrial attacks have widely used.
Objective : Prepare and run a cyber drill.
Concepts : Tabletop · Injects
Challenge : Give the main inject and the measured objective.
Expected outcomes : Validated if the exercise is designed with four injects and a measurable objective.
Objective : Secure remote maintenance.
Concepts : Remote access · Jump host/MFA
Challenge : Give the chosen remote access architecture.
Expected outcomes : Validated if the remote access enforces jump host, MFA and logging.
Securing an industrial site over time means meeting regulatory requirements — often reinforced for critical infrastructure and regional sovereignty — and measuring your progress. This building block has you align an OT programme with the relevant critical regulations, including in the SWANA context, then assess its maturity and improve it continuously (a PDCA approach, the C2M2 model). You identify the most structuring regulatory requirement and the weakest maturity domain. You connect industrial cybersecurity to compliance and governance, an OT security leader's horizon.
Objective : Align with regional critical requirements.
Concepts : Critical regulations · Sovereignty
Challenge : Give the most structuring regulatory requirement.
Expected outcomes : Validated if the most structuring regulatory requirement is correctly identified and mapped.
Objective : Steer the OT program over time.
Concepts : OT maturity · PDCA
Challenge : Give the weakest maturity domain.
Expected outcomes : Validated if the maturity is measured and the weakest domain is correctly named.
The attack reveals insufficient partitioning between office and control networks.
Mission : Draw governance requirements (zones and conduits) from a real incident, in the spirit of IEC 62443.
The precautionary shutdown raises the question of continuity governance.
Mission : Define business continuity and crisis governance on the operational side.
A sectoral CERT coordinates the response of multiple energy firms.
Mission : Think through sectoral governance, CERT coordination and the pooling of resources.
The attack targets precisely the site's safety function.
Mission : Articulate safety and security requirements, and place the IEC 62443 security levels.
The cloud changes the rules of security — shared responsibility, IAM, traceability. This module teaches you to secure a cloud environment (AWS/Azure/GCP) and respond to an incident.
In the cloud, the first flaw is not an exploit: it is a permission granted too broadly. This building block has you manage identity and access (IAM) at the tightest level — the principle of least privilege — and understand the shared-responsibility model, which splits security between provider and customer. You spot an over-permissive IAM policy and its risk, and enforce federated authentication with a second factor. You lay the foundation of cloud security, where most real incidents concentrate.
Objective : Master cloud IAM and least privilege.
Concepts : Shared responsibility · Roles, policies
Challenge : Give the over-permissive IAM policy and the risk.
Expected outcomes : Validated if a minimal role is created and the over-permissive policy and its risk are correct.
Objective : Secure access to cloud accounts.
Concepts : SSO federation · MFA
Challenge : Prove federated access with mandatory MFA.
Expected outcomes : Validated if federated access is proven with mandatory MFA.
In the cloud, everything leaves a trace in the activity logs — you just have to enable them and know how to read them. This building block has you centralise cloud logging (CloudTrail, activity logs) then detect a compromise, both manually and via a managed detection. You spot the event revealing an unauthorised access-key creation and the compromise alert raised. You build the visibility without which a cloud environment stays a blind spot.
Objective : Enable traceability and detect.
Concepts : CloudTrail/Activity Logs · Centralization
Challenge : Give the event revealing the unauthorized key creation.
Expected outcomes : Validated if logging is enabled and the unauthorized key-creation event is detected.
Objective : Detect a cloud compromise.
Concepts : Managed detection · Abnormal behavior
Challenge : Give the compromise alert generated.
Expected outcomes : Validated if managed detection generates the compromise alert.
Most cloud data leaks come not from a hack, but from a storage bucket left open by mistake. This building block has you assess and fix a cloud account's security posture with posture-management tools (CSPM) — Prowler, ScoutSuite — and measure compliance against baselines (CIS benchmarks). You identify an exposed storage and its fix, then the most critical compliance gap. You hunt the most ordinary and most costly class of cloud error: misconfiguration.
Objective : Assess and fix the configuration.
Concepts : Misconfigurations · CSPM
Challenge : Give the exposed storage and the fix.
Expected outcomes : Validated if the exposed storage is identified and fixed.
Objective : Assess an account's compliance.
Concepts : CIS cloud benchmarks · Compliance
Challenge : Give the most critical compliance gap.
Expected outcomes : Validated if the most critical compliance gap is correctly named.
Three levers protect data in the cloud: encrypting it, managing its secrets, and controlling the network flows. This building block has you encrypt data and manage its keys and secrets with a key-management service (KMS) and a vault, then restrict the network with security groups. You prove the encryption and the sound management of a secret, and that no administration port is open to the public. You bring together the three basic protections every cloud deployment should have.
Objective : Protect data and secrets.
Concepts : KMS · Vaults
Challenge : Prove the encryption and the secret management.
Expected outcomes : Validated if encryption and secret management are proven.
Objective : Restrict cloud flows.
Concepts : Security groups · Segmentation
Challenge : Prove that no admin port is open to the public.
Expected outcomes : Validated if no admin port is open to the public, with proof.
Investigating an incident in the cloud differs from a classic inquiry: evidence is ephemeral and the infrastructure is programmable. This building block has you run a cloud incident response — exploiting the logs, freezing a resource by snapshot to analyse it. The challenge: identify the malicious action and the affected resource. You adapt response reflexes to an environment where everything is created and erased in seconds.
Objective : Investigate a cloud incident.
Concepts : Cloud forensics · Snapshots
Challenge : Give the malicious action and the affected resource.
Expected outcomes : Validated if the malicious action and the compromised resource are correctly identified.
A request forgery reaches the instance metadata and recovers the tokens of an over-broad role.
Mission : Understand identity and access management, instance metadata and hardening (version 2 of the metadata service).
Customer tenants are plundered using stolen credentials, for want of multi-factor authentication.
Mission : Put in place multi-factor authentication, manage cloud identities and data sharing.
An AI service's database is left reachable without authentication, exposing keys and histories.
Mission : Prevent the exposure of misconfigured managed storage and services.
A stolen signing key makes it possible to forge access tokens.
Mission : Manage keys and tokens in the cloud and establish defence in depth on authentication.
Containers and Kubernetes have their own attack surface. This expert module teaches you to secure them: hardening, admission control, runtime security and image supply chain.
Kubernetes orchestrates thousands of containers — and multiplies the attack surface as much if you ignore how it works. This building block has you understand a cluster's architecture (control plane, etcd store, namespaces) and its authorisation model (RBAC). The challenge: spot the over-privileged service account, the most common cluster flaw. You acquire the mental map without which no securing of Kubernetes is possible.
Objective : Understand Kubernetes and its risks.
Concepts : Control plane, etcd · RBAC, namespaces
Challenge : Give the over-privileged service account.
Expected outcomes : Validated if the cluster is mapped and the over-privileged service account is correct.
Securing Kubernetes means hardening the cluster and controlling what you deploy before it runs. This building block has you apply CIS benchmarks to the cluster with kube-bench, then set up an admission control (with Kyverno or OPA) that filters deployments. You fix the most critical CIS gap and prove the blocking of a privileged container. You combine hardening the existing and guarding the entrance, the two stages of a Kubernetes defence.
Objective : Apply the benchmarks.
Concepts : CIS K8s · Pod Security
Challenge : Give the most critical CIS gap fixed.
Expected outcomes : Validated if three CIS gaps are fixed and the most critical is correctly named.
Objective : Control what is deployed.
Concepts : Admission control · Policies
Challenge : Prove the block of a privileged pod.
Expected outcomes : Validated if the admission policy blocks a privileged pod.
A container can pass every build-time control and behave abnormally once running: you have to watch it at runtime. This building block has you detect these runtime behaviours with Falco (which observes system calls) and segment the cluster's internal network with network policies (Cilium). You trigger and read a Falco alert and prove east-west isolation between containers. You cover the running cluster's security, where attacks actually show up.
Objective : Detect abnormal behaviors.
Concepts : Runtime, syscalls · Detection
Challenge : Give the Falco alert triggered.
Expected outcomes : Validated if the Falco alert is triggered by the abnormal behavior.
Objective : Segment the cluster network.
Concepts : Network policies · East-west
Challenge : Prove east-west isolation between pods.
Expected outcomes : Validated if east-west isolation between pods is proven.
A cluster is only safe if the images it runs are — and if you can prove where they come from. This building block has you secure image building (vulnerability analysis with Trivy, a component inventory — SBOM) then guarantee their provenance by signature, with an admission control that rejects unsigned images. You fix a critical vulnerability in an image and prove the rejection of an unsigned image. You establish trust in the chain that runs from code to the production container.
Objective : Secure image building.
Concepts : Scan, signature · SBOM
Challenge : Give the critical CVE fixed in the image.
Expected outcomes : Validated if the image is scanned and signed and the fixed critical CVE is correct.
Objective : Enforce trusted images.
Concepts : Provenance · Signature-based admission
Challenge : Prove the rejection of an unsigned image.
Expected outcomes : Validated if an unsigned image is rejected at admission.
Two recurring weaknesses of containerised platforms: secrets stored in clear text, and containers from which you can escape to the host. This building block has you manage Kubernetes secrets securely (encryption, Vault) then study a container escape — understanding how an attacker breaks out of the container towards the machine — to prevent it better. You prove that no secret is in clear text in the repository and identify an escape vector and its fix. You handle two risks that turn a container flaw into a compromise of the whole infrastructure.
Objective : Manage secrets securely.
Concepts : K8s secrets · Encryption/vault
Challenge : Prove that no secret is in cleartext in the repo.
Expected outcomes : Validated if no secret is in cleartext in the repo, with proof.
Objective : Understand escapes to defend better.
Concepts : Container escape · Privileges
Challenge : Give the escape vector and its fix.
Expected outcomes : Validated if the escape vector and its fix are correct.
A flaw in a remote-administration tool propagates ransomware through providers to their customers.
Mission : Secure a deployment chain and access in a multi-tenant context.
A database service is exposed without authentication to the internet.
Mission : Harden exposed containerised services: ports, authentication, segmentation.
The illegitimate access crosses many customer tenants.
Mission : Strengthen multi-tenant partitioning and the management of machine identities.
A booby-trapped library can end up in container images.
Mission : Secure images and dependencies in a cloud-native chain.
Security is not bolted on at the end: it is embedded across the software lifecycle. This module teaches you DevSecOps — CI/CD, automated testing, secrets, supply chain.
The chain that builds and deploys software has become a target — and an ideal control point for security. This building block has you integrate controls into a continuous integration and deployment pipeline (CI/CD), with gates that stop delivery on a problem, and restricted pipeline permissions. The challenge: make the pipeline fail on a dependency carrying a critical vulnerability. You turn the delivery chain into a first line of defence, rather than an open door.
Objective : Integrate controls into the pipeline.
Concepts : Security gates · Pipeline permissions
Challenge : Prove the failure on a dependency with a critical CVE.
Expected outcomes : Validated if the pipeline fails on a dependency with a critical CVE.
Finding an application's flaws early and automatically costs far less than fixing them in production. This building block has you combine the three families of application testing: code analysis (SAST), dependency analysis (SCA) and testing the running application (DAST). You fix a vulnerability spotted in the code, update a vulnerable dependency and detect a flaw on the deployed application. You tool the 'shift-left': securing as early as possible in the development cycle.
Objective : Analyze code statically.
Concepts : SAST · False positives
Challenge : Give the SAST vulnerability fixed.
Expected outcomes : Validated if the fixed SAST vulnerability is correct.
Objective : Secure the dependencies.
Concepts : SCA · Updates
Challenge : Give the vulnerable dependency updated.
Expected outcomes : Validated if the vulnerable dependency is updated and the alert cleared.
Objective : Test the deployed application.
Concepts : DAST · CI integration
Challenge : Give the DAST vulnerability detected.
Expected outcomes : Validated if the detected DAST vulnerability is correct and the DAST integrated in CI.
A password forgotten in the code or a badly declared infrastructure is enough to compromise a whole environment. This building block has you hunt clear-text secrets, including in a Git repository's history (with gitleaks), then secure infrastructure described as code (IaC) by detecting its misconfigurations (Checkov, tfsec). You identify a secret buried in the Git history and fix an infrastructure misconfiguration. You close two discreet but frequent leaks of DevOps chains.
Objective : Eliminate cleartext secrets.
Concepts : Secret detection · Vaults
Challenge : Give the secret detected in the Git history.
Expected outcomes : Validated if the secret detected in the Git history is correct and revoked.
Objective : Secure infrastructure-as-code.
Concepts : IaC scan · Misconfigurations
Challenge : Give the IaC misconfiguration fixed.
Expected outcomes : Validated if the fixed IaC misconfiguration is correct.
Modern software is largely made of third-party components: its security depends on that of a supply chain you do not fully control. This building block has you trace these components through a software inventory (SBOM, with Syft) and apply the chain-integrity principles (SLSA), then scan container images in the pipeline. You produce an SBOM revealing a risky component and prove the blocking of a vulnerable image in continuous integration. You handle the attack surface behind the most resounding compromises (SolarWinds, XZ Utils).
Objective : Trace and secure the components.
Concepts : Supply chain · SBOM, SLSA
Challenge : Provide the SBOM and the at-risk component.
Expected outcomes : Validated if the SBOM is generated and the at-risk component is correctly identified.
Objective : Scan images in the pipeline.
Concepts : CI image scan · Gate
Challenge : Prove the block of a vulnerable image in CI.
Expected outcomes : Validated if a vulnerable image is blocked in CI.
Security tools are useless if teams work around them: DevSecOps is first a culture. This building block has you embed security in the development cycle — shifting controls earlier (shift-left), defining gates teams accept, and measuring to steer. The challenge: name the three priority security gates. You connect technical tooling to human buy-in, without which no DevSecOps programme holds.
Objective : Anchor security in the cycle.
Concepts : Shift-left · Metrics
Challenge : Give the 3 priority security gates.
Expected outcomes : Validated if the three priority security gates are relevant.
A malicious maintainer plants a backdoor in a very widely used dependency.
Mission : Secure the open-source supply chain: software inventory, review, weak signals.
A compromised deployment tool distributes a malicious payload at scale.
Mission : Guarantee the integrity of the build and deployment chain.
The vulnerable component is pulled in indirectly by countless applications.
Mission : Put in place dependency management and software composition analysis in the pipeline.
An available patch is not deployed everywhere, leaving a portal exposed.
Mission : Tool up vulnerability management and the automation of patches.
Identity is the new perimeter. This module teaches you to design modern identity management and a Zero Trust architecture, from federation to policy-as-code.
Identity has become the real security perimeter: it is what gets attacked to get in. This building block has you set up modern federated authentication (OIDC, SAML protocols) and manage account life cycles with Keycloak, then enforce phishing-resistant multi-factor authentication (FIDO2, passkeys). You prove a working federated login and the requirement of a genuinely resistant second factor. You secure the door most of today's attacks aim at first.
Objective : Set up federated authentication.
Concepts : OIDC/SAML · Lifecycle
Challenge : Prove the working federated login.
Expected outcomes : Validated if the OIDC federated login works.
Objective : Enforce strong authentication.
Concepts : MFA, FIDO2/passkeys · Phishing resistance
Challenge : Prove the requirement of a resistant second factor.
Expected outcomes : Validated if the requirement of a phishing-resistant second factor is proven.
Authenticating a user says nothing about what they should be entitled to: that is the role of authorisation. This building block has you design fine-grained authorisations — by role (RBAC) or by attribute (ABAC) — respecting separation of duties, then govern privileged accounts (PAM) with access granted just in time and for a limited duration. You spot an account over-accumulating rights and prove a temporary, traced administrator access. You fight privilege creep, the main aggravating cause of a compromise.
Objective : Design fine-grained authorizations.
Concepts : RBAC/ABAC · Separation of duties
Challenge : Give the over-accumulating account detected.
Expected outcomes : Validated if the account over-accumulating rights is correctly detected.
Objective : Limit privileges in time.
Concepts : PAM · JIT
Challenge : Prove the temporary, logged admin access.
Expected outcomes : Validated if admin access is temporary, logged and expiring.
Zero Trust shifts the security decision from the network perimeter to every request: you verify at each access, according to context. This building block has you apply a Zero Trust policy (policy decision and enforcement points — PDP/PEP) then express these rules as version-controlled, testable code (policy-as-code, with OPA and the Rego language). You prove a compliant out-of-context denial and write the policy that achieves it. You operationalise a principle often invoked but rarely concretely implemented.
Objective : Apply a Zero Trust policy.
Concepts : PDP/PEP · Per-request verification
Challenge : Prove a compliant out-of-context access denial.
Expected outcomes : Validated if out-of-context access is denied per the policy.
Objective : Manage access policies as code.
Concepts : Policy-as-code · Policy tests
Challenge : Provide the policy denying a non-compliant access.
Expected outcomes : Validated if the Rego policy denies a non-compliant access.
Once an identity is compromised, the attacker acts 'legitimately': detecting it means spotting the abnormal within the normal. This building block has you detect identity abuse — login from two incompatible locations (impossible travel), abnormal privilege escalation — via the SIEM, then harden the identity provider (IdP), whose failure would paralyse all access (single point of failure — SPOF). You identify the event signalling the compromise and the measure reducing the SPOF risk. You protect the identity infrastructure, now a very high-value target.
Objective : Spot identity compromises.
Concepts : Impossible travel · Abnormal elevation
Challenge : Give the event flagging the compromise.
Expected outcomes : Validated if the event flagging the identity compromise is correctly identified.
Objective : Secure the identity provider.
Concepts : IdP as SPOF · Resilience
Challenge : Give the measure reducing the SPOF risk.
Expected outcomes : Validated if the measure reducing the single-point-of-failure risk is relevant.
When an identity is compromised, every minute counts: as long as sessions stay open, the attacker keeps control. This building block has you respond to an identity theft — revoking active sessions, rotating secrets, restoring a state of trust. The challenge: determine the first response to apply. You acquire the emergency reflexes of an identity incident, among the most frequent and the fastest to spread.
Objective : React to an identity theft.
Concepts : Session revocation · Rotation
Challenge : Give the first response to the compromise.
Expected outcomes : Validated if the sessions are revoked and the first response to the compromise is correct.
Access to an identity provider's support system exposes customers' session files.
Mission : Secure an identity provider and sessions, within a Zero Trust logic.
The plundered accounts are not protected by a second factor of authentication.
Mission : Enforce multi-factor authentication and conditional access.
An actor gains access by manipulating the phone-based reset procedure.
Mission : Harden reset and identity-verification processes.
Forged tokens pass an insufficiently strict validation.
Mission : Strengthen token validation, key management and defence in depth.
AI creates new attack surfaces — and new defences. This expert module teaches you to secure AI systems and LLMs: adversarial ML, prompt injection, AI-driven defence.
Artificial intelligence introduces vulnerabilities of a new kind, unlike anything classic security knows. This building block has you explore the attack surface specific to machine learning, structured by the MITRE ATLAS and OWASP ML taxonomies: fooling a model with adversarial examples (imperceptible perturbations) and corrupting its learning through data poisoning, up to planting a backdoor in it. You misclassify an input, measure the induced error rate and trigger a model's backdoor. You take the measure of a still poorly understood risk, as AI settles in everywhere.
Objective : Understand ML-specific threats.
Concepts : ATLAS/OWASP ML taxonomy · Evasion/poisoning
Challenge : Make an input misclassified and give the ATLAS technique.
Expected outcomes : Validated if an input is misclassified and the corresponding ATLAS technique is correct.
Objective : Fool a classification model.
Concepts : Adversarial perturbations · Robustness
Challenge : Give the error rate induced on the model.
Expected outcomes : Validated if the adversarial examples induce the announced measured error rate.
Objective : Corrupt the learning.
Concepts : Poisoning · Model backdoor
Challenge : Give the trigger of the implanted backdoor.
Expected outcomes : Validated if the backdoor activates and its trigger is correct.
A large language model follows the instructions it is given — including those an attacker slips into data it processes. This building block has you exploit prompt injection (referenced in the OWASP LLM Top 10), direct and indirect, up to making it reveal the protected system instruction, then divert an LLM agent equipped with tools to exfiltrate data. You unmask the hidden instruction and the diverted tool. You understand the structural flaw of applications built on LLMs, whose use is exploding.
Objective : Exploit LLMs via injection.
Concepts : OWASP LLM Top 10 · Direct/indirect
Challenge : Make the protected system prompt revealed.
Expected outcomes : Validated if the protected system prompt is revealed via injection.
Objective : Hijack an LLM agent.
Concepts : Agents/tools · Capability abuse
Challenge : Give the hijacked tool and the exfiltrated data.
Expected outcomes : Validated if the hijacked tool and the exfiltrated data are correct.
Having seen how an LLM is attacked, you flip the perspective: how to build an application that resists it. This building block has you design a robust LLM application — a clear trust boundary, output validation — then secure an architecture that queries documents (RAG, retrieval-augmented generation), vulnerable to injection through the documents themselves. You prove the blocking of a malicious output and the filtering of a booby-trapped document. You carry AI security to the builder's side, where it must be integrated from the design stage.
Objective : Design a robust LLM app.
Concepts : Trust boundary · Output validation
Challenge : Prove the block of a malicious output.
Expected outcomes : Validated if a malicious output is blocked by the guardrails.
Objective : Secure a RAG architecture.
Concepts : RAG · Injection via documents
Challenge : Prove the filtering of a malicious document.
Expected outcomes : Validated if a malicious document is filtered by the RAG.
AI is not only a target: it is also a defence tool — provided you keep the human in the loop. This building block has you use AI to support the defence (assisted triage, with a human safeguard — human-in-the-loop) then govern its use under a risk-management framework (NIST AI RMF), accounting for bias and sovereignty stakes. You measure the triage gain while placing the human safeguard, and name the priority AI risk and its measure. You connect AI to its governance, the condition of a use that is both useful and responsible.
Objective : Use AI to defend (HITL).
Concepts : Assisted triage · Human-in-the-loop
Challenge : Give the triage gain and the human safeguard.
Expected outcomes : Validated if the triage gain is measured and the human safeguard is maintained.
Objective : Frame the use of AI.
Concepts : NIST AI RMF · Bias, sovereignty
Challenge : Give the priority AI risk and the measure.
Expected outcomes : Validated if the priority AI risk and the governance measure are relevant.
A tribunal finds an airline liable for incorrect information given by its conversational agent.
Mission : Think through the governance and liability of a language-model assistant in production.
An AI service's database is left open, exposing keys and conversation histories.
Mission : Secure the infrastructure and data of an AI service (storage, keys, logs).
A flaw in a caching library briefly exposes conversation titles and subscriber data.
Mission : Understand the infrastructure risks (cache, session) specific to consumer language-model services.
Data platforms used for analytics and AI are plundered using stolen credentials.
Mission : Protect the datasets and machine identities that feed AI pipelines.
Steering security means governing through risk and compliance, not technology alone. This management-level module teaches you to structure a programme: CSF 2.0, risk management, compliance, oversight.
An organisation can stack up tools and stay vulnerable if no one steers its security as a whole: that is the role of governance. This building block has you structure that governance with the NIST CSF 2.0 framework and its recently added 'Govern' function, situating maturity by tiers and profiles. The challenge: name the least mature function and the priority that follows. You adopt a common language that lets a leadership team steer its cybersecurity as it steers its other risks — the NIST CSF being one reference framework among others, alongside ISO 27001.
Objective : Structure governance via the 6 functions.
Concepts : Govern function · Tiers and profiles
Challenge : Give the most immature function and the priority.
Expected outcomes : Validated if maturity is assessed and the most immature function and the priority are correct.
Absolute security does not exist: to govern is to decide which risks to treat, transfer or accept. This building block has you run a structured risk analysis with a recognised method (EBIOS Risk Manager, aligned with ISO 27005), down to the residual risk — what remains after the measures. The challenge: name the highest residual risk and the decision to take. You connect the technical to the leadership decision, because it is the leadership that, in the end, owns the accepted risk.
Objective : Conduct a risk analysis.
Concepts : ISO 27005/EBIOS RM · Residual risk
Challenge : Give the highest residual risk and the decision.
Expected outcomes : Validated if the register is rated and the highest residual risk and the decision are correct.
Compliance is not an end but a foundation: it structures security and, increasingly, it is imposed by law. This building block has you prepare an information security management system (ISMS) under ISO 27001 and its annex of controls, then map the applicable regulatory requirements — the European NIS2 directive and the frameworks of the SWANA region (Saudi ECC, SAMA, ANCS, NCA). You identify the most critical compliance gap and the most structuring regulatory obligation. You connect security to the obligations that legally bind the organisation, regional context included.
Objective : Prepare an ISMS and an audit.
Concepts : ISMS, Annex A · Evidence
Challenge : Give the most critical compliance gap.
Expected outcomes : Validated if the controls are mapped to ISO and the most critical gap is correct.
Objective : Map the regional requirements.
Concepts : NIS2 · ECC/SAMA/ANCS/NCA
Challenge : Give the most structuring regulatory obligation.
Expected outcomes : Validated if the obligations are mapped and the most structuring is correctly identified.
Unwritten rules are not applied, and rules written but unverified are hardly better. This building block has you deploy a coherent documentary corpus — policies and procedures with measurable indicators — then steer its continuous improvement through internal audit (the PDCA approach: plan, do, check, act). You write a policy with its indicator and build an audit plan identifying a major non-conformity. You give security the documentary backbone and the control without which it stays merely declared.
Objective : Deploy the document framework.
Concepts : Policies/procedures · Consistency
Challenge : Provide the policy with its measurable indicator.
Expected outcomes : Validated if the policy is written with a measurable indicator.
Objective : Steer continuous improvement.
Concepts : Internal audit · PDCA
Challenge : Give the audit plan and the major non-conformity.
Expected outcomes : Validated if the audit plan is defined and the major non-conformity is identified.
Technology protects only part of the risk: the other depends on human behaviour and the leadership's attention. This building block has you build a security culture (awareness measured by human indicators) then steer and report at the highest level, translating security into the executive committee's (board's) language. You design an awareness campaign with its indicators and select the three key indicators most relevant to leaders. You connect cybersecurity to the two levers that decide its success: people and governance.
Objective : Build a security culture.
Concepts : Awareness · Human metrics
Challenge : Provide the campaign with its indicators.
Expected outcomes : Validated if the awareness campaign is designed with its indicators.
Objective : Steer and report to executives.
Concepts : Strategic indicators · Executive reporting
Challenge : Give the 3 most relevant KPIs for the executive board.
Expected outcomes : Validated if the three most relevant KPIs for the executive board are correctly chosen.
The markets regulator charges the company and its security officer over the communication made to investors.
Mission : Place governance, the accountability of leadership and transparency towards stakeholders.
A record penalty is handed down for non-compliant personal-data transfers.
Mission : Address the compliance of data transfers, the GDPR framework and the penalties regime.
A public audit report links the scale of the incident to management failings.
Mission : Conduct risk management and accountability, and connect a missing patch to its regulatory consequences.
The paralysis of a central actor disrupts a whole sector and triggers notification obligations.
Mission : Manage third-party risk, continuity and notification obligations.
