Module 8: Detection, CET & Nighthawk

Real-world deployment, hardware security compatibility, detection strategies, and the Nighthawk “Evanesco” production implementation.

1. Intel CET and Shadow Stacks

Intel Control-flow Enforcement Technology (CET) is a hardware-based security feature in recent Intel processors (11th gen+ Alder Lake and later) that prevents Return-Oriented Programming (ROP) and Jump-Oriented Programming (JOP) attacks. It has two components:

CET is increasingly enabled by default in Windows 11 and recent builds of Windows Server. Any evasion technique that manipulates return addresses or uses ROP-like chains will fail on CET-enabled systems.

2. Why Ekko/Zilean/FOLIAGE Break Under CET

Traditional sleep obfuscation techniques fundamentally conflict with CET’s Shadow Stack:

3. FunctionPeekaboo’s CET Compatibility

FunctionPeekaboo is fully compatible with CET because it uses legitimate control flow:

4. Nighthawk C2 and “Evanesco”

MDSec’s Nighthawk is a commercial C2 framework designed for red team operations. Version 0.3.3 introduced “Evanesco” — a production implementation of FunctionPeekaboo’s per-function self-masking concept.

5. Detection Strategies for Defenders

Understanding FunctionPeekaboo from a defensive perspective is essential for blue team operations. Several detection approaches can identify per-function self-masking:

5.1 VirtualProtect Monitoring

Detection Rule (Pseudocode)rule FunctionPeekaboo_VProtect:
  trigger: NtProtectVirtualMemory
  conditions:
    - target address is within a PE .text section
    - protection changed from PAGE_EXECUTE_READ to PAGE_READWRITE
    - followed within 1ms by PAGE_READWRITE to PAGE_EXECUTE_READ
    - same small region (< 0x2000 bytes)
    - occurs repeatedly during process lifetime
  action: alert "Potential per-function self-masking detected"

5.2 Custom PE Section Detection

5.3 TEB UserReserved Monitoring

5.4 Timing-Based Detection

The handler adds ~4-20μs overhead to every function call. While individually undetectable, statistical analysis of function call timing across many calls might reveal the overhead pattern. This is a research-level detection approach, not currently deployed by any known EDR.

5.5 Memory Scan Timing

6. YARA Rules for Detection

YARArule FunctionPeekaboo_Sections {
    meta:
        description = "Detects PE with FunctionPeekaboo custom sections"
        author = "Blue Team"

    condition:
        uint16(0) == 0x5A4D and
        for any i in (0..pe.number_of_sections - 1): (
            pe.sections[i].name == ".funcmeta" or
            pe.sections[i].name == ".stub"
        )
}

rule FunctionPeekaboo_EP_Anomaly {
    meta:
        description = "Entry point outside .text section"

    condition:
        uint16(0) == 0x5A4D and
        not for any i in (0..pe.number_of_sections - 1): (
            pe.sections[i].name == ".text" and
            pe.entry_point >= pe.sections[i].virtual_address and
            pe.entry_point < pe.sections[i].virtual_address +
                pe.sections[i].virtual_size
        )
}

rule FunctionPeekaboo_Stub_Pattern {
    meta:
        description = "Detects the CALL/POP PIC pattern followed by register saves"

    strings:
        // CALL +5 (E8 00000000) followed by POP RBX (5B)
        // then multiple PUSH instructions
        $pic_trick = { E8 00 00 00 00 5B 50 51 52 41 50 41 51 }

    condition:
        uint16(0) == 0x5A4D and $pic_trick
}

7. Comparison with Other Evasion Techniques

8. Limitations and Future Work

9. Operational Deployment Considerations

10. Course Summary