Let’s be clear: “fully undetectable” is a sales term—not a technical reality. It usually means the malware avoided detection on a specific system, with a specific toolset, at a specific time. Detecting fully undetectable malware in memory in 2026 requires moving beyond simple RWX alerts to monitoring specific behavioral sequences—like indirect syscall jumps from non-module memory and kernel-mode escalation via Bring Your Own Vulnerable Driver (BYOVD).

But even the stealthiest fileless loader has to run in memory. And when it does, it leaves traces. The problem isn’t that the signals don’t exist—it’s that most organizations aren’t collecting the right telemetry, or they’re buried in noise.

This guide reflects what actually works in 2026, based on public reports (Mandiant, Microsoft, CrowdStrike), MITRE ATT&CK, and real-world incident response. No invented features. No speculative tech. Just what you can deploy and use today.

What “FUD (Fully Undetectable)” Looks Like in 2026

Most modern in-memory threats follow a similar playbook:

  • They start via phishing, exploit, or compromised account.
  • They avoid writing files—instead using PowerShell, WMI, or macros to load payloads directly into memory.
  • They inject into trusted processes (explorer.exe, winword.exe, svchost.exe).
  • They use indirect syscalls to bypass EDR hooks (seen in IcedID and QakBot variants since late 2024).
  • In high-value targets, they escalate via BYOVD—loading a legitimate but vulnerable driver to gain kernel access.

According to Mandiant’s M-Trends 2025, the median dwell time is now 11 days. That’s not because the malware is magic—it’s because defenders miss the early memory-based signals.

Memory Is Observable—If You’re Looking

Fileless doesn’t mean traceless. Every memory-resident payload must:

  • Allocate virtual memory (usually via VirtualAlloc or NtAllocateVirtualMemory)
  • Write shellcode or decrypted payload
  • Change memory permissions (often to executable)
  • Start execution—via thread creation, APC injection, or process hollowing

These steps generate logs. The challenge is knowing which ones matter. You can see an example of this in Stealer, expected in 2026.

Forget “Event ID 23”—Here’s What Sysmon Actually Logs

A common mistake is assuming Sysmon has a dedicated event for memory protection changes.

It doesn’t.

As of Sysmon v15.13 (January 2026):

  • Event ID 23 = File Delete (has been since v11)
  • Event ID 25 = Process Tampering (detects code injection, hollowing)
  • Event ID 10 = Process Access — this is your best signal for memory manipulation

Focus on Event ID 10 (Process Access)

This event logs when one process accesses another’s memory. Look for:

  • SourceImage: powershell.exe, wmiprvse.exe, mshta.exe
  • TargetImage: explorer.exe, lsass.exe, or any high-integrity process
  • GrantedAccess: 0x0010 (PROCESS_VM_WRITE) or 0x0020 (PROCESS_VM_OPERATION)

Example: If winword.exe suddenly writes to dllhost.exe with VM_WRITE, that’s a red flag—Office apps don’t normally do that.

In practice, most teams correlate this with Event ID 8 (CreateRemoteThread) or Event ID 1 (Process Create) to reduce false positives.

Note: You can get memory protection changes from Windows Event ID 4663 (Object Access), but it requires SACLs on process handles—something few orgs enable due to performance overhead.

Indirect Syscalls: Real, But Hard to Catch Syscalls in Memory

Direct syscalls (calling syscall outside ntdll.dll) are now reliably flagged by EDRs.

So attackers shifted. By late 2024, malware like IcedID and BumbleBee started using indirect syscalls:

  • They find a real syscall instruction inside ntdll.dll
  • They jump to it indirectly (e.g., jmp rax)
  • To EDR, it looks like normal API usage

This isn’t theoretical—it’s in the wild.

Detection Requires More Than API Logs

You need call stack context. Specifically:

Does the return address point to a legitimate module?
If a thread calls NtWriteVirtualMemory, but its return address is in heap memory—that’s malicious.

Tools like Microsoft Defender for Endpoint and CrowdStrike can capture this via kernel callbacks. But it’s part of their EDR behavioral engine, not a separate “memory protection” product. Microsoft doesn’t market it that way—and you shouldn’t either for detect fully undetectable malware in memory.

BYOVD: The Kernel Problem Most Miss in FUD Malware Detection

If you’re only hunting in user space, you’re blind to a growing class of threats.

Bring Your Own Vulnerable Driver (BYOVD) is now routine in ransomware playbooks:

  • Attackers drop a signed driver (e.g., old ASUS, MSI, or anti-cheat software)
  • They exploit a known bug (like arbitrary read/write) to disable EDR or hide processes
  • Once in kernel mode, they can read any process—including lsass

This was documented in Black Basta (Mandiant, 2024) and Royal ransomware (Microsoft, 2025). You can read antivirus comparison article for more details.

How to Catch It

Watch for:

  • Windows Event ID 6 (Driver Loaded) from non-system paths (C:Users, C:Public)
  • Drivers matching known CVEs (use LOLDrivers.io as a reference)

Prevention: Enforce Windows Defender Application Control (WDAC) to block unsigned or vulnerable drivers. It’s not perfect—but it raises the attacker’s cost.

YARA Still Works—If You Stop Looking for Strings

Modern loaders don’t use LoadLibraryA in plain text. They use:

  • Hash-based API resolution (e.g., CRC32 of function names)
  • Stack strings (pushing characters to avoid static detection)
  • Encoded control flow

So string-based YARA rules fail.

Instead, hunt for structural artifacts:

YARA Rule: ReflectiveLoader_Memory 
rule ReflectiveLoader_Memory {
    strings:
        $pe = { 4D 5A }  // PE header
        $hash_loop = { 8B ?? ?? ?? ?? ?? 81 ?? ?? ?? ?? ?? 75 }
    condition:
        $pe and $hash_loop and filesize == 0
}

Run this in memory scans (e.g., via Velociraptor), and always filter by process context. A match in powershell.exe means something very different than in chrome.exe.

AI in Malware: Less Sci-Fi, More Scripting

No, malware isn’t shipping with Phi-3 or TinyLlama in 2026.

Even quantized models are too large (100s of MBs)—and file-size anomalies are trivial to detect.

What is happening:

  • Attackers use LLMs to generate phishing emails or obfuscated loader source code before deployment
  • Polymorphism is server-driven: C2 sends unique payloads per victim
  • Obfuscation is automated—but not adaptive on the endpoint

Defense: Don’t chase polymorphism. Chase behavior for detect fully undetectable malware in memory.

Hardware Memory Protection: Helpful, But Not for Forensics

Intel TDX and AMD SEV-SNP encrypt VM memory to protect against hypervisor attacks.

But here’s the catch: they also block defenders.

If malware runs inside a confidential VM, you can’t dump its memory externally. Tools like Volatility won’t work. Even cloud forensics tools are blind.

So while these technologies improve integrity, they reduce visibility. It’s a trade-off—use them where data confidentiality outweighs forensic needs.

Tools That Actually Work (No Hype)

  • Volatility 3: Still the gold standard for offline memory analysis. Use malfind, vadinfo, and psxview.
  • Velociraptor: Lets you run YARA and collect VAD trees across thousands of endpoints in real time.
  • Sysmon: Stick to Event ID 10 (Process Access) and Event ID 25 (Process Tampering). Ignore claims about “memory protection” events—they don’t exist.
  • Microsoft Defender for Endpoint: Its EDR engine detects suspicious memory activity, but it’s not a standalone “memory product.”

A Realistic Detection Workflow

1. Deploy Sysmon with rules for:

  • Process access with VM_WRITE to sensitive processes
  • Driver loads from non-system paths
  • Remote thread creation

2. Hunt for sequences, not single events:

  • powershell.exe starts →
  • writes to explorer.exe (Event ID 10) →
  • explorer.exe shows Process Tampering (Event ID 25)

3. When in doubt, dump memory:

  • Use Velociraptor or MAGNET RAM Capture
  • Analyze with Volatility for injected code

4. Prevent escalation:

  • Enable HVCI
  • Enforce WDAC to block vulnerable drivers

What Most Teams Get Wrong

  • Over-relying on alerts: Without sequence correlation, you’ll miss slow-burn implants.
  • Ignoring kernel space: BYOVD operates below your EDR.
  • Assuming “memory encryption = security”: It can make forensics impossible.

Also—most orgs can’t enable SACLs for Event ID 4663 due to performance. So design detection around what’s deployable, not what’s theoretically possible. Evasion antivirus videos will shows these reasons

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.

How do I detect reflective DLL injection with Sysmon?

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.

What are the signs of indirect syscall abuse in Windows memory?

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.

Can I detect BYOVD attacks with user-mode memory forensics?

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.

Why isn’t my YARA rule detecting in-memory FUD malware?

Modern FUD 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.

Scan for:

  • 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.

Can I detect fileless malware without Windows Event ID 4663?

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.