Defense Evasion a defender’s playbook for detection & response in Cybersecurity

CyberDefender 18 mins0

1 — Execution-environment manipulation (deep dive)

How it works (conceptual):
Adversaries aim to run malicious code while minimizing visible artifacts. They do this by embedding or executing code inside other processes (process injection), mapping executables into memory without touching disk (fileless), or by abusing legitimate runtime loaders.

Common sub-techniques (high-level):

  • Process injection / thread hijacking / APCs — place code inside a trusted process to inherit tokens and reduce suspicion.
  • In-memory PE loading / reflective loading / fileless scripts — binary exists only in memory.
  • Process hollowing / host process replacement — start a benign process, replace its memory with malicious code.
  • DLL side-loading with modified search order to load malicious DLLs into legitimate apps.

Defensive indicators (what to watch for):

  • Parent-child process relationships that don’t match expected app behavior (e.g., a text editor spawning a network service).
  • Processes with memory regions marked RWX (read-write-execute) or a high count of executable heap/stack allocations.
  • Unusually high frequency of remote thread creation or WriteProcessMemory calls recorded by kernel/ETW telemetry.
  • Imported modules or loaded modules that don’t match the binary signature or known manifests.

Detection approaches:

  • Instrument kernel-level process creation telemetry and record parent image path/hash and command line. Flag anomalies in parent/child chains.
  • Monitor memory protection changes (heap/region protections), RWX allocations, and unusual module loads.
  • Look for processes that show PE headers present in non-file-backed memory regions.
  • Use behavior-based models that correlate suspicious memory activity with unexpected network connections or token use.

Mitigations / hardening:

  • Apply application whitelisting (allow-listing) with strict rules for process-child relationships.
  • Enforce endpoint protection that inspects memory at runtime and restricts RWX pages when not required.
  • Use least privilege for services; avoid running day-to-day services as SYSTEM.
  • Enable process and module signing reputation checks.

Red-team vs Blue-team view (brief):

  • Red: Execute in a trusted process to inherit trust and lower telemetry fidelity.
  • Blue: Treat anomalous use of high-privilege processes as high-risk; correlate with network/identity telemetry.

2 — Telemetry suppression / manipulation

How it works (conceptual):
Instead of hiding the malicious code itself, adversaries target the defender’s sensors and logging pathways to remove or degrade visibility (clear logs, disable agents, tamper ETW).

Common sub-techniques (high-level):

  • Clearing or rolling Windows Event Logs.
  • Stopping or killing security agent services or corrupting their process space.
  • Patch/hook ETW providers or tamper with trace session settings.
  • Time-based evasion: sleeping beyond sandbox timeouts, checking for virtualization artifacts.

Defensive indicators:

  • Gaps in expected telemetry streams (sudden absence of logs from an endpoint).
  • Event log clear events, or sequence/offset anomalies in logs.
  • Agent process restarts, service stop events, or integrity changes to sensor binaries.
  • Time anomalies — processes that sleep for long durations or resume after large monotonic time jumps.

Detection approaches:

  • Monitor for log-clear events and correlate with subsequent suspicious activity on that host.
  • Treat any attempt to stop/disable an installed security agent as a high-priority alert.
  • Maintain off-host logging copies (central SIEM or immutable store) so local log clearing is insufficient.
  • Detect sandbox/evasion attempts via long sleeps coupled with other suspicious indicators (delayed network callbacks, one-off system calls to timing functions).

Mitigations / hardening:

  • Use write-once/append-only remote logging; separate logging from the endpoint (forward logs immediately).
  • Harden EDR/agent processes (run with protections, kernel service protections) to prevent easy termination.
  • Implement integrity monitoring and alert on tampering attempts.
  • Design instrumentation to send proof-of-life heartbeats independent of the OS kernel logging facility.

3 — Artifact obfuscation (strings & binaries)

How it works (conceptual):
Obfuscation reduces static detection surface: strings, API names, and control flow are transformed so signature-based tools and simple static analysis fail.

Common sub-techniques:

  • String encoding/packing (XOR, custom encodings, entropy-increasing compression).
  • Packing/unpacking: small bootstrap that decompresses/encrypts the real payload at runtime.
  • Control-flow obfuscation: opaque predicates, flattened CFGs.
  • Dynamic API resolution (hashes of API names resolved at runtime).

Defensive indicators:

  • High-entropy sections in binaries or data blobs not expected for that file type.
  • Presence of small stub loaders that allocate memory, set RWX, and then transfer execution.
  • Frequent use of string-building APIs and suspicious wide-character conversions at runtime.
  • Unusual API resolution patterns (resolving dozens of uncommon APIs via hashes).

Detection approaches:

  • Use entropy checks on files and attachments; flag unusually compressed/encrypted sections.
  • Inspect runtime behavior — unpacking activity, memory regions populated after process launch.
  • Behavioral heuristics: short-lived processes that allocate then execute from RWX memory and then connect out.
  • Heuristic analysis of API resolution patterns (e.g., many GetProcAddress-style calls using hashed names).

Mitigations / hardening:

  • Restrict the execution of unsigned/unknown binaries through allow-listing.
  • Implement robust sandboxing for suspicious files; prefer dynamic analysis that executes in instrumented environments able to capture unpacking behavior.
  • Reduce the attack surface by disabling legacy scripting engines and block risky file types at perimeter.

4 — Identity & permission evasion

How it works (conceptual):
Adversaries steal, escalate, or impersonate credentials/tokens to perform actions while appearing as legitimate identities.

Common sub-techniques:

  • Token theft / token impersonation / pass-the-hash / pass-the-ticket (conceptually): reusing harvested authentication artifacts.
  • Credential dumping from memory or LSASS-like stores (conceptually described).
  • Abuse of OAuth tokens, service principals, or long-lived API keys in cloud environments.
  • Lateral movement by reusing legitimate credentials.

Defensive indicators:

  • Unusual or impossible activity from legitimate accounts (time/location anomalies, impossible travel).
  • Creation or use of long-lived API keys inconsistent with policy.
  • Multiple authentication attempts followed by privileged actions from new hosts.
  • Token usage from endpoints that never used them before.

Detection approaches:

  • Enforce MFA for privileged accounts; monitor for bypass attempts and unusual token issuance.
  • Log and alert on abnormal API key creation, role modifications, and new service principal activity.
  • Use UEBA (User & Entity Behavior Analytics) to detect anomalous access patterns (geographic, temporal, or resource anomalies).
  • Correlate endpoint telemetry with identity telemetry to detect token reuse from unexpected hosts.

Mitigations / hardening:

  • Least privilege and role separation for identity artifacts.
  • Short-lived credentials, automatic rotation, and minimal scopes for tokens.
  • Credential vaulting and managed identity solutions rather than embedded keys.
  • Endpoint protections to prevent in-memory credential harvesters from accessing privileged stores.

5 — Abusing trusted execution paths (LOLBins, signed proxy execution)

How it works (conceptual):
Adversaries use legitimate, signed OS binaries (LOLBins) or signed helper binaries that can load arbitrary code to bypass allow-listing and exploit trust.

Common sub-techniques:

  • Run PowerShell, certutil, msiexec, regsvr32, and others to execute or decode payloads.
  • Use signed binaries that accept DLL paths or script content to execute code under a trusted signature (signed binary proxy execution).

Defensive indicators:

  • Uncommon command-line arguments to signed system binaries.
  • Signed binaries spawning new shells, downloading executables, or writing to suspicious locations.
  • Large numbers of base64 decode operations via certutil or PowerShell with encoded commands.

Detection approaches:

  • Monitor command-line parameters for LOLBin executions and flag suspicious or uncommon uses.
  • Create behavior-based allowlists (not just binary hashes) — e.g., expected argument patterns and parent processes.
  • Block/mitigate high-risk uses of signed proxies through AppLocker/LDAPS rules or shell-restrictions for certain accounts.

Mitigations / hardening:

  • Restrict the use of built-in administrative utilities to administrators and break common proxy execution patterns.
  • Apply application control policies that allow only specific whitelisted uses of otherwise trusted binaries.
  • Audit and, where necessary, disable rarely used binaries that provide proxy execution paths.

6 — Defeating behavior-based EDR

How it works (conceptual):
EDR often hooks user-mode APIs or installs kernel callbacks. Adversaries attempt to bypass these by calling syscalls directly, unhooking APIs, or exploiting vulnerable signed drivers.

Common sub-techniques:

  • Direct syscall invocation bypassing user-mode hooks.
  • Unhooking — rewriting hooked prologues or tampering with user-mode DLLs.
  • Loading signed but vulnerable kernel drivers to run code in kernel space (Bring Your Own Vulnerable Driver — BYOVD).
  • Rootkits to hide processes, files, or network sockets.

Defensive indicators:

  • Calls to syscall patterns not matching the typical user-mode API flow.
  • Unexpected kernel module loads (new drivers) or drivers with known vulnerable signatures.
  • Sudden disappearance of conventional artifacts (processes, network connections) from user-space views.

Detection approaches:

  • Use kernel-level telemetry where possible — system call entry/exit telemetry is harder to bypass.
  • Monitor driver loads and signed-driver installations; maintain a policy of allowed drivers and alert on new drivers.
  • Detect deviations in system-call sequences or direct mapping into syscall stubs used by unhooked invocations.

Mitigations / hardening:

  • Restrict driver installation to signed, vetted drivers and implement driver signing policies.
  • Keep kernel/EDR components patched, minimize use of drivers from third parties.
  • Use features like Windows Kernel Patch Protection and integrity verification for agents.

7 — Network evasion (C2 hiding, mimicry)

How it works (conceptual):
Hide command-and-control by using encryption, infrequent polling, domain fronting, or channels that look like normal traffic.

Common sub-techniques:

  • TLS-encrypted C2, use of legitimate cloud providers for hosting C2.
  • Domain fronting (leverage CDN/host headers to mask destination).
  • DNS tunneling for low-bandwidth exfil/C2.
  • Protocol mimicry — make C2 traffic look like web, update traffic, or popular SaaS traffic.

Defensive indicators:

  • Unusual DNS request patterns (large TXT responses, frequent subdomain changes).
  • Endpoint-generated TLS sessions to rare or newly-registered domains.
  • Traffic that structurally mimics web traffic but contains anomalous timing, size, or header values.
  • Unusually low-frequency beacons with occasional large transfers.

Detection approaches:

  • Analyze DNS for tunneling patterns and monitor TTLs, response sizes, and entropy of subdomains.
  • Use TLS fingerprinting and JA3/JA3S-style heuristics to detect anomalous TLS client/server stacks.
  • Correlate network flows with process telemetry — which process opened the connection, and is that expected?
  • Monitor cloud-hosted domains used in ways inconsistent with their normal behavior.

Mitigations / hardening:

  • Egress filtering and proxying; force all outbound web traffic through a vetted proxy that inspects TLS (where lawful & feasible).
  • Enforce strict DNS policies and split DNS where appropriate.
  • Block or warn on known risky cloud-hosted patterns when used by endpoints without corresponding business justification.

8 — Data & artifact hiding (ADS, registry, steganography)

How it works (conceptual):
Store payloads or exfil data in places that aren’t commonly inspected: NTFS Alternate Data Streams, registry blobs, or within media files.

Common sub-techniques:

  • NTFS ADS to hide executables or data in file system metadata.
  • Registry-based payload storage or persistence keys with encoded blobs.
  • Storing commands or payload in image/audio files (steganography).

Defensive indicators:

  • Files with ADS entries or unusual registry values that contain binary-looking blobs.
  • File metadata that doesn’t match content (e.g., JPEG header but large binary blob in data).
  • Unexpected large registry values or nonstandard use of registry run keys.

Detection approaches:

  • Periodic scanning for ADS usage, registry values over a size threshold, and forensic baseline checks on commonly monitored keys.
  • Use content inspection on file uploads/downloads and maintain heuristics for steganographic patterns (file size vs resolution mismatch, high entropy in media payloads).
  • Monitor registry writes from user processes and flag large/encoded blobs.

Mitigations / hardening:

  • Limit users’ ability to write to system-critical registry areas.
  • Block or monitor use of NTFS ADS where it’s not needed for business workflows.
  • Educate teams that steganography can obfuscate exfil and monitor high-risk channels.

CyberDefender