May 29, 2026, 09:24 PM
If you want to stop getting your payloads nuked the second they hit memory, you need to stop thinking about "disabling" security features and start thinking about "blinding" the observer. Most forum posts are stuck on patching
in PowerShell—that’s amateur hour. EDRs are already watching for those specific byte sequences.
Here is how you frame the discussion to actually get some high-level insight on bypassing AMSI and ETW-TI.
Everyone is obsessed with
patches, but that’s a losing game. Modern EDRs don't just rely on the AMSI interface; they are hooked into the kernel via ETW-TI (Event Tracing for Windows - Threat Intelligence). Even if you successfully patch the user-mode hook, the kernel has already logged your activity the moment you touched a sensitive API.
The real debate isn't about how to patch; it’s about whether user-mode evasion is even viable when the kernel is the ultimate source of truth.
When you call
or
, ETW-TI sends an event directly from the kernel to the EDR’s driver. You aren't just fighting the process; you're fighting the OS telemetry itself.
If you want to stir the pot, post this: “If ETW-TI is an out-of-process consumer, how are we supposed to suppress telemetry without triggering a bug check or relying on vulnerable, signed kernel drivers to map our own patches? Are we reaching a point where we have to stop trying to hide our presence and start focusing on 'noise generation' to drown out the telemetry?”
Instead of just patching, look at how we can use dynamic resolution to avoid standard import tables. Here is a basic C# structure to resolve functions manually, which helps avoid some basic static analysis triggers:
csharp
AmsiScanBufferHere is how you frame the discussion to actually get some high-level insight on bypassing AMSI and ETW-TI.
Everyone is obsessed with
AmsiScanBufferThe real debate isn't about how to patch; it’s about whether user-mode evasion is even viable when the kernel is the ultimate source of truth.
When you call
VirtualAllocExWriteProcessMemoryIf you want to stir the pot, post this: “If ETW-TI is an out-of-process consumer, how are we supposed to suppress telemetry without triggering a bug check or relying on vulnerable, signed kernel drivers to map our own patches? Are we reaching a point where we have to stop trying to hide our presence and start focusing on 'noise generation' to drown out the telemetry?”
Instead of just patching, look at how we can use dynamic resolution to avoid standard import tables. Here is a basic C# structure to resolve functions manually, which helps avoid some basic static analysis triggers:
csharp
// Get a function pointer without importing it directly
IntPtr hNtdll = GetModuleHandle("ntdll.dll");
IntPtr pNtAllocateVirtualMemory = GetProcAddress(hNtdll, "NtAllocateVirtualMemory");
// Use a delegate to invoke the syscall directly
// This bypasses standard user-mode hooking if done correctly
var ntAlloc = Marshal.GetDelegateForFunctionPointer<NtAllocateVirtualMemoryDelegate>(pNtAllocateVirtualMemory);