Native API DLL loaded from outside the system directories

1title: Native API DLL loaded from outside the system directories2id: 983573b7-3b35-41e2-840e-c1f5a2595b853status: experimental4description: |5  T1106 is defined by invoking the native API directly, and a syscall stub6  executing inside a process emits no record in any log source Sigma can address7  — so this rule takes the precursor AN1465 actually names and nothing beyond it:8  a module load of `ntdll.dll`, `kernel32.dll` or `kernelbase.dll` from a path9  that is not one of the directories Windows serves these modules from. Note what10  such an event is and is not: all three are KnownDLLs, already mapped into every11  process before user code runs, so a LoadLibrary against a private copy resolves12  by base name to the module already present and maps nothing. What produces this13  event is an image-section map of an on-disk copy — NtCreateSection with14  SEC_IMAGE plus NtMapViewOfSection, the pattern unhooking tooling uses to obtain15  a clean export table — which does drive the image-load notify routine. An16  implant that reads the file and maps the PE into RW memory itself remains17  invisible here. The module list is MITRE's `DllName` knob populated with the18  three low-level providers, and the path filter carries the entire signal, so it19  is anchored with startswith rather than contains: a contains filter would be20  satisfied by any attacker-created directory whose path merely embeds21  `\Windows\System32\`. It assumes Windows on C:, and it requires Sysmon EID 722  with ImageLoad enabled and these three modules not filtered out — ImageLoad is23  the most expensive Sysmon event class, and the widely copied configurations24  ship an include list that does not name them, so a quiet result usually means25  the events were never generated.26  UNVERIFIED — derived from MITRE ATT&CK DET0529 and never executed against logs.27references:28  - https://attack.mitre.org/techniques/T110629  - https://attack.mitre.org/detectionstrategies/DET052930author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)31date: 2026-08-1632tags:33  - attack.execution34  - attack.t110635logsource:36  category: image_load37  product: windows38detection:39  selection_module:40    ImageLoaded|endswith:41      - '\ntdll.dll'42      - '\kernel32.dll'43      - '\kernelbase.dll'44  filter_system_paths:45    ImageLoaded|startswith:46      - 'C:\Windows\System32\'47      - 'C:\Windows\SysWOW64\'48      - 'C:\Windows\WinSxS\'49      - 'C:\Windows\SyChpe32\'50      - 'C:\Windows\SysArm32\'51  condition: selection_module and not filter_system_paths52falsepositives:53  - "Endpoint security products that keep a pristine copy of ntdll.dll in their program directory and map it as an image on every integrity check to compare against the hooked in-memory copy. This is the same SEC_IMAGE mechanism the rule is looking for, so it is indistinguishable, and on an estate running such a product it is the highest-volume match by a wide margin — which is what the medium level reflects. Exclude that product's install directory and a residual hit means considerably more."54  - "Feature updates and servicing, which stage a complete system image under C:\\$WINDOWS.~BT\\, C:\\$WinREAgent\\ or C:\\Windows\\servicing\\ and then run setup binaries that map the staged copies of these DLLs for the duration of the upgrade."55  - "Build and test machines, where an instrumented or debug runtime and its dependent system modules are loaded from the build output directory rather than from System32."56  - "Imaging and offline-servicing sessions, where the running OS lives under X:\\Windows\\System32\\ in WinPE or the target image is mounted at a path such as C:\\mount\\Windows\\System32\\, so every ordinary module load in that session falls outside a filter anchored on C:\\Windows."57level: medium