Final Thought - Detect Fully Undetectable Malware In Memory

There’s no such thing as truly undetectable malware. But there is undetected malware, because the right logs weren’t collected, or the signal was lost in noise.

In 2026, your best defense isn’t a new tool. It’s focusing on the few things that must happen, memory allocation, process access, execution, and building detection around those.

Because in memory, the evidence is there. You just have to be looking in the right place, with the right context.

Focus on correlated event sequences, not isolated alerts. Start with:

  • Sysmon Event ID 10 (Process Access) where GrantedAccess includes PROCESS_VM_WRITE
  • Paired with Event ID 25 (Process Tampering) or Event ID 8 (CreateRemoteThread)
  • Filter by suspicious parent processes (e.g., powershell.exe, winword.exe) writing to high integrity targets like explorer.exe or svchost.exe

Avoid alerting on every VM_WRITE, instead, require multiple signals within 5 seconds. Most false positives come from installers or updaters; whitelist known benign sequences using your SIEM or EDR.

Indirect syscall abuse occurs when malware jumps to a legitimate syscall instruction inside ntdll.dll to bypass EDR hooks. Signs include:

  • A thread executing from non module memory (e.g., heap or private VAD regions)
  • Stack traces showing return addresses outside loaded DLLs
  • Syscall calls (e.g., NtWriteVirtualMemory) with no matching ntdll call stack

Modern EDRs like Microsoft Defender for Endpoint and CrowdStrike capture this via kernel level stack telemetry. Enable “suspicious thread execution” or “call stack anomaly” alerts, but verify with memory dumps using Volatility 3 to rule out false positives from .NET or JIT engines.

No, user mode tools alone are insufficient. BYOVD operates in kernel space, and its malicious activity (e.g., EDR disabling, process hiding) happens below the user mode visibility layer.

To detect BYOVD:

  • Monitor Windows Event ID 6 (Driver Loaded) from non system paths (e.g., C:\Users\Public\)
  • Cross reference drivers against LOLDrivers.io
  • Use kernel memory dumps (via LiveKd or hardware based capture) analyzed with Volatility 3’s driverscan and malfind plugins

User mode forensics may show sudden EDR process termination or unexplained lsass access, but the root cause lives in kernel memory.

Modern Educational malware avoids hardcoded strings like LoadLibraryA. Instead, it uses hash based API resolution, stack strings, or position independent shellcode, making string based YARA rules ineffective.

  • PE headers ({4D 5A}) in non file memory
  • Instruction patterns (e.g., API hash loops: {8B ?? ?? ?? ?? ?? 81 ?? ?? ?? ?? ?? 75})
  • RWX or RX memory regions with no backing file

Always run YARA in memory context (filesize == 0) and pair results with process behavior (e.g., “Is this in winword.exe?”). Tools like Velociraptor allow real time memory scanning with process filtering.

Yes, you don’t need Event ID 4663. Most organizations avoid SACLs due to performance impact. Instead, use:

  • Sysmon Event ID 10 (Process Access) to catch PROCESS_VM_OPERATION (used in VirtualProtect calls)
  • EDR telemetry that logs memory protection changes (e.g., Defender for Endpoint’s behavioral sensors)
  • Memory dumps analyzed for executable regions with no module mapping (via Volatility’s malfind)

Look for the sequence:
VirtualAlloc(RW) → VirtualProtect(RX) → Thread execution within <1 second.
This pattern is rare in legitimate software but common in loaders like IcedID or QakBot.