Defense Evasion: Reducing Noise Without Assuming You're Invisible

Every technique covered elsewhere on this site leaves some kind of footprint — a dropped file, a spawned process, a line in an event log, an unusual network request. Defense evasion isn't a separate phase you run in isolation; it's a lens applied to how you do everything else, aimed at reducing how much of that footprint a defender's tooling actually notices. This covers what the category includes and how to think about it responsibly — not a bypass-code cookbook, since most of what actually works here is specific to a target's exact AV/EDR product and version, changes constantly, and is exactly the kind of thing that goes stale the moment it's published publicly.

Evasion is scoped, just like persistence

The same rule from Maintaining Access applies here: whether an engagement wants you to test stealth at all is a specific line item in the rules of engagement, not something you default into. Some engagements are explicitly purple-team exercises — the whole point is finding out whether the client's SOC catches you, so evasion technique is the actual deliverable. Many others just want proof a vulnerability is real and exploitable; burning time on stealth nobody asked for, on an engagement that isn't testing detection capability, is effort spent on the wrong question. Read the scope for this specifically, the same way you would for persistence.

Common defense evasion technique categories

Log handling. Windows Event Logs, Sysmon, and application logs are how most detection and all incident response actually happens. Clearing them (wevtutil cl System) is possible, loud in its own right (log-clearing events are themselves commonly alerted on), and on most engagements actively counterproductive — it destroys the client's own evidence trail rather than serving the test. Treat log clearing as something that needs explicit authorization, not a default habit.
Living-off-the-land binaries (LOLBins). Signed, pre-installed OS binaries — certutil, mshta, regsvr32, rundll32, PowerShell itself — can be repurposed to download, decode, or execute content, instead of dropping an unfamiliar binary that trips signature-based AV the moment it lands on disk. The LOLBAS project documents these for Windows the same way GTFOBins does for Linux — worth knowing both exist, since the underlying idea (trusted binaries doing untrusted things) is the same skill pointed at two different operating systems.
AMSI awareness. Windows' Antimalware Scan Interface inspects script content — PowerShell, VBScript, and more — before it executes, giving AV/EDR products visibility into script-based attacks even when nothing ever touches disk. Attackers work around this by avoiding patterns AMSI's signatures key on, or by keeping payloads out of the specific code paths AMSI hooks. This is a fast-moving, product-specific cat-and-mouse game — what evades one AMSI provider's current signature set is not a stable, general technique, and shouldn't be treated as one.
In-memory / fileless execution. Reflective loading and process injection run a payload entirely in memory rather than writing an executable to disk, denying disk-based AV scanners a file to inspect at all. This trades one detection surface for another — EDR products increasingly watch process and memory behavior specifically because file-based scanning stopped being sufficient.
Obfuscation and payload variance. Changing a payload's strings, encoding, and structure between uses so a signature built from a previously-seen sample doesn't immediately catch the next one. Useful, but a weaker guarantee than it sounds — behavioral detection doesn't care what a payload's bytes look like, only what it does once running.
Traffic blending. Shaping outbound C2 traffic to resemble ordinary web traffic — covered in more depth in Command and Control Fundamentals — so network-based detection doesn't flag an obviously anomalous beacon pattern.

Silence isn't proof

This site's labs repeatedly make the same point about exploit verification: a tool claiming success is a claim, not a fact, and the only real proof is independent confirmation. The same standard applies here, in the opposite direction. No alert firing doesn't mean a technique was undetected — it might just mean nobody has reviewed the logs yet, or the relevant log source wasn't even being monitored. Treat "nothing happened" with the same skepticism you'd apply to a script printing "RCE: OK" — it's the absence of a signal, not confirmation of one.

Common mistakes

Clearing logs as a reflex instead of a scoped decision. On most engagements, this destroys evidence the client's own IR team needs afterward, and does so loudly enough to be its own indicator.
Treating "no alert fired" as proof of stealth. It's an absence of evidence, not evidence of absence — see above.
Reaching for heavy obfuscation before checking whether something simpler already avoids the problem. Every added layer of complexity is one more thing that can break mid-engagement, and a LOLBin that's already trusted is often quieter than a cleverly obfuscated custom tool.

Next step

For the mechanics of staying hidden at the network layer specifically, see Command and Control Fundamentals. For the Linux and Windows equivalents of the "trusted binary doing untrusted things" idea in a privilege-escalation context rather than an evasion one, see the script privesc checklist and Windows privesc checklist. For the discipline of tracking what you've actually done to a target regardless of how quietly you did it, see Maintaining Access.