[p0l0v3r4]

I've been analyzing how modern AV engines respond to custom crypters, particularly when using lightweight XOR and dynamic API resolution techniques.
In a controlled lab setup (non-malicious payloads only), I observed:

• Basic XOR with a static key gets flagged by most engines.
  
• Adding polymorphic stubs reduced detection significantly.
  
• AVs relying more on behavioral detection (like Microsoft Defender ATP) flagged payloads during execution, not at rest.
  

Interesting finding: encoding shellcode into image metadata bypassed some heuristic scanners but failed against sandbox detonation.
I'm building a PoC crypter to test detection rates across different AVs.
 
Anyone else experimenting with evasion trends for research or red team tooling?
--
Note: All testing is done on isolated VMs with non-malicious payloads.

[Bragi]

Look into context only thread redirects, WrQueue waiting threads, etc. Can avoid all typical ETW stackwalks by EDR, no direct ntdll api calls, RWX suspiciousness, etc. If using WrQueue thread-pool abuse method(s) just make sure to include place holder and return original thread's bytes after you overwrite the WrQueue thread's return address to point to your implant's main function. Not totally necessary for stealth in many AV/EDR still, but better to future-proof and also for any humans investigating, ntdll-spawned threads in thread pools suddenly going rogue (and potentially crashing whatever PID you targeted) is a pretty massive red flag lol.

Also ... plenty of lolbins still work tbh. Standard arbitrary function extern, forward rest from whatever .dll some Microsoft signed PE calls + combine w/ something like context only RedirectThread method several times with context-dependent/dynamic switch cases for executing slightly different variations of same Redirect Threads or WrQueue waiting thread hijack to start a second, third, and fourth stage (i like to finish final stage w/ download of base64'd string of my AES256 .enc shellcode loader -> certutil to decode -> same base64'd string remote-read for passphrase -> allocate mem etc... -> decrypted shellcode.bin in mem --> execute --> profit(?)).

2025 CrowdStrike/Cortex evasion meta: touching disk = big bad unless necessary for part(s) of your attack chains. Still usually fine for initial delivery stages, especially when lolbins involved. Just be VERY mindful that none of the logic involved in this stage is a disclosure bad enough to sabotage OPSEC due to EDR analysis, ETW stackwalks, or human threat-hunters or SOC analysts.

Hardware break points (dev context AMSI bypass) still works to break out of low/medium integrity access token contexts in Windows environments that don't have strict WDAC policies. Otherwise, for WDAC... if totally locked down by competent blue-team, unfortunately your options will be extremely limited with out more clever social engineering or different initial-access targets that aren't as secure that you can hopefully leverage to pivot to your original target.