EDR evasion

EDR products watch a host through several sensors: kernel callbacks, user-mode hooks on common libraries, and telemetry sent to a cloud analytics backend. Evasion works against each layer. Instead of dropping a known malicious binary, an operator blends into legitimate activity using signed system utilities (living off the land binaries), runs payloads in memory to avoid writing a file to disk, unhooks or avoids the monitored functions, and shapes command and control traffic to look ordinary. None of this defeats the product outright. It defeats a specific detection: the goal is to stay below the threshold at which a human is asked to look.

The failure is treating a deployed agent as if it were coverage. On the estates we test, EDR is installed but tuned conservatively to avoid false positives, some hosts are in monitor-only mode, and the analytics that would catch a subtle chain are never reviewed because nobody has time. From the attacker’s seat this is the whole game: we do not need to disable the agent, we need one route where the action is technically visible but no rule turns it into an alert, or the alert fires into a queue no one works. The most effective operations are quiet, not clever, and they exploit the operational gap far more often than a product weakness.

An engagement that includes evasion produces two useful outputs: what we did, and whether it was seen. We record each action, the telemetry it should have generated, and whether the EDR alerted, blocked or stayed silent, so the client can hand the gaps straight to their detection engineering function. The finding is written against the missing detection, not against the product. This is how we test whether detection actually fires rather than assuming an installed agent equals coverage.