Malware Tips

Process loading ntdll twice

If you see a process loading ntdll twice, you are almost certainly dealing with malware.

One of the most common evasion tricks used by malware authors (and by red team tooling) is "unhooking". A typical approach is loading a fresh copy of the target DLL, often ntdll.dll, from disk and then using that clean copy to execute Windows API/syscall paths without hitting user-mode EDR hooks.

The idea is simple. If the EDR placed hooks in the in-memory ntdll.dll, a clean copy can bypass those trampolines and avoid the hooked code paths. The catch is that this technique is so well known that many EDRs detect it anyway. And even without an EDR, the behavior itself is suspicious. In legitimate software it is extremely unusual to have two ntdll.dll modules mapped into the same process. It practically never happens in normal application workflows.

The real problem is visibility. Many organizations without an EDR also don’t have Sysmon or a SIEM pipeline, so detections based on this behavior are rare outside of malware analysis or incident response work.

If you do have Sysmon, there is a straightforward angle. Sysmon Event ID 7 can reveal module load activity, including a second ntdll.dll being mapped. The tradeoff is volume. Event ID 7 is often disabled because it can get noisy fast. The practical approach is selective logging. Enable ImageLoad with tight filtering, focused on high-signal modules like ntdll.dll and suspicious source locations, instead of collecting everything