Linux Purple Team/Detection Engineering loop
Intro
With the adoption of AI, our cybersecurity world has accelerated even further. Based on my experience in training rooms and recent observations from conferences, I conclude that patching is not enough. Detection is also not. Well, they never were, but now it’s so crucial to change priorities. As Linux experts, we need to use our experience and knowledge to drive the development of customized and architecturally just-in-point prevention and response mechanisms to survive the wave of AI-assisted exploitation of everything. Based on my 25 years of hands-on experience with Linux, I am convinced that the training approach I provide shows not only the methodology loop, but above all, real examples in red vs blue convention, based on which you can build a better security posture for your critical Linux infrastructures. This is confirmed by the fantastic recommendations that you can read here:
- Training testimonials → https://edu.defensive-security.com/about
Anyway, let me describe in more detail my overall teaching approach around the Linux Purple Teaming and Detection Engineering loop, which is the fundamental part of my Black Hat USA 2026 4-day “Practical Linux Attack Paths and DFIR/Hunting for Red and Blue Team v2.0” training:
Attack →When working on offensive scope, think as a blue teamer.
I have been following the offensive Linux ecosystem for over 20 years. Understanding red team tradecraft, the approach and techniques used by attackers, always allows you to detect blind spots in your infrastructure faster. I see great value in emulating full attack paths — ideally driven by CTI, but also in focusing on individual techniques and implementations of specific tools. Without this experience, it’s generally difficult to properly secure your systems. You need to know what you’re defending against and be able to test whether your approach is working properly. You need sensitivity to detect what is good and what is suspicious or malicious. This is also where — from my point of view — the idea of Purple Teaming comes in, aimed at close cooperation between attacking and defending teams, which means the labs placed participants in the role of both attacker and defender. For RT and PT exercises, but also for training and course purposes, I have prepared a project called EDRmetry Linux Matrix, which is a central, searchable knowledge base in the playbook format that allows for Detection Coverage/Incident Response testing by executing dedicated Linux offensive chunks mapped to the MITRE ATT&CK™ Framework. The idea is to get started with single tests and create advanced attack paths later. Training participants love this component, and they regularly use this JSON database in their red team and purple team exercises. Recently, they’ve also been connecting to AI and experimenting with hybrid custom attacks, which I also cover in the training. Thanks to EDRmetry Playbook, you’ll have practical experience in deeply evaluating your Linux security product of choice (like EDR/Runtime Security/SOAR/SIEM/DFIR) against simulated attacks. You will get a better understanding of the defensive technology in use to address potential loopholes in your system’s configuration visibility. Long story short, you will learn hundreds of offensive techniques useful during red teaming that can be found in real attacks against Linux systems. As of today, I have almost 500 different techniques included and mapped to the MITRE Attack Framework, and their number is constantly growing. Some examples of chained attack paths have been listed below:
- eBPF credentials stealer, process memory dumpers
- mremap() + ptrace() process inject + custom SSL callback
- /proc/PID mem manipulations
- fileless memfd_create executions
- remote exploitation of network services (kafka, tomcat, spring, reactjs, httpd, nginx, custom C service)
- user space / kernel space / io_uring and eBPF rootkits + magic packet
- udev, cron, bashrc, pam_exec persistence
- copyfail, fragnesia, dirtypage, local socket LPE
- container escaping
- process masquerading
- C2 implants, including Sliver, Mythic, MSF, custom reverse shells
- SOCKS proxy, tunneling, backdoors for application servers
- Hijacking SSH client sessions
- Data exfiltration over different channels
These are just examples. We have the ability to dynamically create attack chains based on nearly 500 dedicated offensive test definitions, ready to use in copy-paste format.
I will end this part with the following quote, which fits the context perfectly:
“If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.”
― Sun Tzu, The Art of War
Detection → When doing the detection part, think as a red teamer:
Your detection can be as good as your telemetry really is. Knowing a true good system behavior from the perspective of generated events is crucial. Long story short, it’s all about researching the artifacts, understanding the importance of particular security events, drilling down into contextual relationships between different events, pivoting from one data source to the other, and mapping the technique to the MITRE ATT&CK® framework. One more comment: You are responsible for the generated offensive TTPs, which brings us to the subtitle of this section of the article and another valuable style of thinking: “When doing the detection part, think as a red teamer”. During the class, we deep dive into at least this set of visibility events, which constitute the core of understanding your Linux box behavioral profile: execve, execve_script, exit, exit_group, clone, prctl, kill, ptrace, init_module, bpf_prog_load, bpf_socket_filter, mprotect_exec, mmap_exec, connect, send_data, dns_query, read, read_config, write, write_config, file_rename, file_create, file_unlink. This is the list of events supported by Kunai Runtime Security, which is an absolutely great project. We use Kunai raw events, the non-signature-based telemetry, to pivot to Falco’s signature visibility (and in the opposite direction as well ), thus gaining a complete picture of the situation. On this basis, we build Tetragon Tracing Policies, which I describe in the Prevention/Response section. However, pivots to other data sources are also presented, such as to index=zeek and index=suricata, which, thanks to the support of community_id flow hashing, provide another interesting perspective on the network and system context. This approach works perfectly for training, as each of you has different security tooling in production, while I try to adopt a generic approach. I always say that it’s not about the tools, but about understanding their internals. The results of my detection development process are included in course materials, in the step-by-step instructions, and are always driven by the adversary’s behavior and the visibility provided by the supported logs and telemetry. It’s worth mentioning that active SQL-like/VQL/sandflies detection queries are also provided thanks to OSquery, Velociraptor, or Sandfly Security.
Linux Forensics → Find what to look for and where to look:
As part of the course program, I also include forensic aspects. Linux Forensics is the discipline of systematically collecting, preserving, and analyzing evidence from Linux systems to reconstruct attacker activity, understand the scope of a compromise, and support incident response. Linux presents unique challenges and opportunities, from the rich runtime telemetry exposed through pseudo-filesystems like /proc and /sys (revealing live process memory maps, open file descriptors, network socket states, kernel module lists, and namespaces that attackers rarely think to clean up) to volatile artifacts that evaporate on reboot. Effective triage leverages tools like UAC (Unix Artifacts Collector) for structured, repeatable artifact acquisition, Velociraptor for scalable remote live-response across fleets, and Sandfly Security for agentless, SSH-based detection of rootkits, hidden processes, and fileless implants without touching the compromised host’s toolchain. When persistence, evasion, or process injection has occurred at the kernel or memory level, Volatility Framework becomes essential, enabling deep memory forensics against Linux profiles to hunt for injected code, rogue kernel threads, hooked syscalls, or hidden LKMs that no filesystem artifact would betray. Crucially, the best forensicators aren’t pure investigators — knowing how attackers operate (offensive tradecraft) and how detections fire (EDR/SIEM logic) closes the full Attack → Detection → Forensics → Response loop, letting you instantly recognize why a memory region is suspicious, what a Tetragon or Falco alert was trying to tell you, and where the attacker’s next move was likely headed. Again, long story short, you can dynamically trigger triage at any point in the course, including automatic RAM acquisition per your TARGET_X instance — the VM you are attacking and defending simultaneously.
Prevention/response → Patching and detection are not enough. Custom prevention is the key:
As of today, the number of critical vulnerabilities discovered is enormous. The timeframe is extremely short. You don’t know from which side you will be attacked. You can bet it won’t be a one-shot only. Saying that, I believe we’ve entered a phase of mass exploitation risk. Which incident will you handle first: a critical 0-day remote exploitation of your Java or ReactJS, or Django, or custom C app? Maybe VPN or LPE on the kernel? What if all these components are ultra-important to you? Another question that arises here is, what if from your CTI you know that all of these components are actively exploited, but there’s no update available yet? And what if you don’t know anything about it? You can only assume with certainty that you will be attacked today or tomorrow.
Personally, I like to see Linux security as an ecosystem. When you get this, you can prepare and react appropriately, even proactively. That’s why, among other things, I believe that generic, custom lockdown policies, implemented at the lowest possible Linux layers, have great justification and value. But you have to approach this wisely, and this needs to be approached thoughtfully and in a repeatable manner, yet giving full control over the way new prevention logics are activated and delivered. For example, I present four concepts as part of the training:
- Generic prevention for the parent-child process spawning
- Baseline profiling and enforcement
- Anti-Pivoting / anti-lateral movement
- Live Patching
Consider contextually blocking process spawning of /bin/sh or any other lolbin from your Java app, fileless execution based on memfd_create only for a given K8S pod, allowing network communication with your Splunk server only from the forwarder process, blocking the use of /dev/tcp from bash or piping curl/wget | to interpreter, or enforcing the use of only your local DNS servers, or blocking modifications to modprobe_path or execution of call_usermode_helper, or allowing ptrace only with strace or allowing bpf for your EDR process only. With eBPF, the possibilities are virtually endless. 70 different generic tracing policies are included as of today.
How to run such a big training program and exercises in a hands-on style effectively? => PurpleLabs Cyber Range
The answer is PurpleLabs. PurpleLABS is a dedicated virtual infrastructure for conducting detection and behavioral analysis of attackers with respect to the offensive techniques, tactics, procedures, and tools they employ. The infrastructure is fully compatible with course materials and the EDRmetry Linux Matrix. The environment is designed to continuously raise competencies in threat hunting and to build familiarity with current offensive trends (red teaming) through a direct detection lens (blue teaming/forensics). By providing high-quality training materials together with a PurpleLabs environment, I aim to enable organizations to improve the detection capabilities of their Linux security teams/SOC and achieve better visibility and resilience against attacks. As of today, the following system and network components are supported and running by default:
- HOST: Syslog, Auditd, Elastic EDR, Falco Runtime Security, Kunai Runtime Security, Tetragon Runtime Security, Tracee Runtime Security, Sysmon4Linux, Velociraptor IR, OSQuery/Sunlight, Sandfly Security, Linux IR Scripts, UAC, Yara, LKRG, SELinux, and more
- NETWORK: Zeek NIDS, Suricata NIDS, Arkime/Moloch FPC, Modsecurity WAF
- SIEM: Elastic, Splunk, Wazuh
- MEMORY: Volatility2/3 Framework
Each participant will receive a dedicated, private set of VPN and SSH credentials.
Interested? Join me in Black Hat 2026 in Vegas, USA. Registration is still open:
Alternatively, take a look at the self-learning course program here: