« Red Team Engineer

Phase 07 — EDR Internals, Evasion Theory & Detection Engineering

Operation Cedar Lattice, Phase 07. Phase 06 produced the execution technique and the telemetry it emits to run on the next host. Now we answer the question the SOC will ask in the report: what did Meridian Freight's EDR, AMSI, and ETW actually see? This phase builds the detection-gap map — the picture of which sensors fired, which were blinded by which evasion, and which behaviors went dark — and then turns that map into durable detections the client keeps.

This is the most two-sided phase in the track, so its frame is the strictest: it is detection- forward. We explain how an EDR builds its picture and the theory of evasion only so you can predict what a sensor sees and build the detection. Every evasion concept is immediately turned into a detection or a visibility-gap finding. The deliverable is not "we beat the EDR." It is "here is exactly which sensor each technique needs, which evasion blinds it, which sensor survives anyway, and the detection that fires regardless."

Safety (non-negotiable). Authorized security-education only. This phase explains EDR internals and the theory of evasion strictly to predict telemetry and engineer detections. The labs are telemetry-gap analyzers and visibility-mappers over synthetic sensor metadata. There is no working EDR bypass, no unhooking code, no ETW/AMSI patch routine, and no deployable evasion in this repo. Every evasion concept ends in its detection. This is the same boundary as the security track.

Why this phase exists

You cannot engineer a detection for a sensor you do not understand, and you cannot understand a sensor without knowing what it sees and where its blind spot is. A red team consultant who can only say "the EDR didn't catch us" delivers nothing the client can act on. A consultant who can say "the EDR was blind to the injection because you do not collect ETW-TI, and here is the kernel-callback detection that would have caught it even if we unhooked ntdll" delivers a threat-informed defense roadmap — which is the actual product Mandiant sells.

This phase is also where the Pyramid of Pain stops being a slide and becomes engineering practice. A hash detection costs the adversary seconds; a robust behavioral detection over the right sensor costs them a redesign. Knowing which sensor survives an evasion is exactly how you build at the top of the pyramid.

Learning Objectives

By the end of this phase you can, without notes:

1. Draw the EDR architecture end to end — kernel-mode driver, user-mode agent, cloud backend — and say which component collects which telemetry and why.
2. Name the kernel callbacks an EDR registers (PsSetCreateProcessNotifyRoutine(Ex), PsSetLoadImageNotifyRoutine, PsSetCreateThreadNotifyRoutine, object/handle callbacks, minifilter file callbacks), what event each delivers, and why kernel residency matters.
3. Explain ETW and ETW-TI — providers, consumers, sessions — what each provider sees, and why patching EtwEventWrite blinds user-mode ETW but not the kernel-emitted ETW-TI — and the detection for the patch.
4. Explain user-mode API hooking in ntdll, how direct and indirect syscalls evade it, and the detection: call-stack and return-address anomalies, a second clean ntdll image-load.
5. Explain AMSI — where it sits, what it scans, the concept of a bypass — and the AMSI-bypass detection (the bypass is itself observable).
6. Build the sensor map for a host and identify its blind spots — the telemetry-gap analysis methodology (Lab 01).
7. Do detection engineering: write a Sysmon config change and a Sigma rule, apply the Pyramid of Pain, and tell a robust behavioral detection from a brittle IOC one.
8. State the phase's core invariant: user-mode evasions do not blind kernel sensors (Lab 02).

The sensor map — what each sees, how evasion blinds it, the detection

The pattern of the whole table: every evasion targets a specific sensor at a specific trust boundary, and a sensor at a lower boundary survives. That surviving sensor is the detection.

Labs

Each lab follows LAB-STANDARD.md: lab.py (TODOs), a complete solution.py, adversarial test_lab.py, README.md, requirements.txt — pure Python (stdlib + pytest), offline, deterministic, with the detection pairing built in.

cd lab-01-edr-telemetry-gap-analyzer
LAB_MODULE=solution pytest -q   # reference passes (11 tests)
pytest -q                        # your implementation after the TODOs

cd ../lab-02-amsi-etw-visibility-mapper
LAB_MODULE=solution pytest -q   # reference passes (12 tests)

Deliverables

• An EDR telemetry-gap analyzer that scores an org's ATT&CK detection coverage against its actual sensor inventory, classifies each technique detectable/partial/blind, names the single highest-value missing data source, and emits a prioritized telemetry-improvement plan.
• An AMSI/ETW residual-visibility mapper that proves which sensors survive a given evasion set, whether a behavior is still detectable, and the residual detection (including the detection of the evasion itself).
• The Operation Cedar Lattice Phase 07 artifact: Meridian's detection-gap map — what its EDR/ AMSI/ETW saw, which evasions blinded which sensor, the residual kernel detections, and the prioritized telemetry + Sigma/Sysmon remediation. Over synthetic metadata; no weaponization.
• The fluency to walk EDR internals, the theory of each evasion and its detection, the sensor map and its blind spots, and to write a Sysmon config change plus a Sigma rule that fires — in an interview.

Readings (primary sources)

• Microsoft docs: Process/Image/Thread notify routines, ETW (Event Tracing for Windows) and the Microsoft-Windows-Threat-Intelligence provider, AMSI (Antimalware Scan Interface), minifilter (FltRegisterFilter), WDAC.
• Elastic Security Labs and CrowdStrike/Microsoft engineering blogs on EDR internals, ETW-TI, and call-stack-based detection.
• The Sigma specification and rule repository; Sysmon + the SwiftOnSecurity and Olaf Hartong sysmon-modular configs.
• David Bianco — The Pyramid of Pain. MITRE ATT&CK data sources / data components and the CTID Sensor Mappings to ATT&CK.
• Windows Internals (Russinovich, Solomon, Ionescu) — the kernel notification and ETW chapters.

Common Mistakes

• Saying "we evaded the EDR." You blinded a sensor. Name it, name the boundary, name the survivor.
• Believing a user-mode patch is invisible. Patching EtwEventWrite/AMSI/ntdll hooks is itself an event — RWX on a system DLL, an amsi.dll write, a call-stack anomaly. The bypass is a detection.
• Treating ETW and ETW-TI as the same thing. User-mode ETW is patchable in-process; ETW-TI is kernel-emitted and is not. Conflating them is the single most common Phase 07 error.
• Detecting at the bottom of the Pyramid of Pain. A hash or AMSI signature string is trivial to change; build the behavioral detection on the surviving sensor.
• Calling "partial" coverage "covered." One missing data source in a multi-sensor technique is a brittle detection a single evasion drops below the line (Lab 01's partial).
• Shipping a brittle Sigma rule. A rule keyed on one command-line string is bypassed by renaming; key on the behavior the kernel sensor sees.
• No telemetry-gap methodology. Gut-feel "we should log more" is not a plan. The plan is the ranked, gain-maximizing sensor list (Lab 01).

Interview Questions

1. Walk me through how a modern EDR builds its picture — kernel driver, user agent, cloud — and which telemetry each part collects.
2. Which kernel callbacks does an EDR register, and what does each deliver? Why does kernel residency matter for evasion resistance?
3. Explain ETW vs ETW-TI. If an attacker patches EtwEventWrite, what goes blind, what survives, and how do you detect the patch?
4. How do user-mode ntdll hooks work, how do direct/indirect syscalls evade them, and what is the detection?
5. Where does AMSI sit and what does it scan? If someone bypasses AMSI, how is the bypass itself detectable?
6. A technique "evaded the EDR." How do you reason about what was actually blinded and what still saw it?
7. What is the Pyramid of Pain, and how does it decide whether a detection you wrote is worth keeping?
8. Walk me from a telemetry gap to a closed gap: the missing data source, the Sysmon config change, the Sigma rule, and how you verify it fires.

(Full principal-level answers are in WARMUP.md.)

Portfolio artifact

Meridian's EDR detection-gap map for Operation Cedar Lattice: the per-technique coverage table (Lab 01 output) classifying detectable/partial/blind with the highest-value missing sensor and the telemetry-improvement plan; the residual-visibility analysis (Lab 02 output) showing, for the engagement's key techniques, which sensors the evasions blinded and which kernel sensor survived; a Sysmon config diff and a Sigma rule that close one named gap; and the verification that the rule fires on a benign Atomic test. All over synthetic metadata, no real targets, no weaponization. This is part of 06-07-payloads-edr/ in the capstone portfolio.

Guides

• WARMUP.md — the from-zero deep dive: EDR architecture, kernel callbacks, ETW & ETW-TI, ntdll hooks & syscalls, AMSI, the sensor map & blind spots, detection engineering (Sysmon, Sigma, the Pyramid of Pain, robust vs brittle), and the telemetry-gap methodology — every evasion paired with its detection.
• HITCHHIKERS-GUIDE.md — on an owned range with Sysmon + ETW + a free EDR: run benign Atomic tests, observe which sensors fire, find a telemetry gap, close it with a Sysmon config change + a Sigma rule, and verify the rule fires. No bypass steps.