FrameworkGuidesModulesRelease NotesAbout

Veil-Evasion

Veil-Evasion is the payload generation engine at the heart of the framework. It produces executables and scripts designed to test whether endpoint detection systems identify specific evasion techniques. This page covers the module's architecture, its role in detection research, and the defensive strategies that make evasion testing valuable.

If you have spent any time in purple team exercises, you know the frustration of discovering that your EDR was tuned for last year's threats. Evasion testing with a structured tool like this reveals exactly where those gaps are — not in theory, but against your actual deployment.

What "Evasion" Means in Security Testing

Evasion, in the context of penetration testing, refers to generating payloads that avoid detection by specific security controls. The purpose is diagnostic: if your antivirus or EDR does not flag a known evasion technique, you have a detection gap that needs addressing.

This is fundamentally a defensive exercise. The goal is never to "bypass all AV" — that framing misunderstands the purpose. Real-world evasion testing operates within a feedback loop: generate, deploy, observe, detect, tune, repeat. Each cycle strengthens your detection posture.

Detection-First Approach

Before you generate a single payload, your monitoring infrastructure needs to be in place. Without telemetry, evasion testing is noise.

Logging Requirements

At minimum, ensure these are configured in your lab environment:

  • Sysmon — Process creation (Event ID 1), network connections (Event ID 3), file creation (Event ID 11), and image load events (Event ID 7). The SwiftOnSecurity Sysmon configuration is a reasonable starting point, but you will likely need to tune it for your specific exercise.
  • PowerShell logging — Script block logging (Event ID 4104), module logging, and transcription. These are essential if you are testing PowerShell-based payloads.
  • Windows Event Forwarding — Centralize your logs. Reviewing events across twenty machines locally is not practical.
  • EDR telemetry — If your organization uses CrowdStrike, SentinelOne, Defender for Endpoint, or similar, put agents on your lab targets in audit mode.

What to Watch For

When a Veil-Evasion payload executes in your lab, your detection stack should ideally capture:

  • Process creation with suspicious parent-child relationships
  • Network callbacks to your listener
  • Memory allocation patterns consistent with shellcode injection
  • File writes to temp directories
  • Unsigned or anomalous executables

If you see none of these in your logs, your detection has blind spots that need immediate attention.

Supported Output Formats

Evasion supports multiple payload languages and output types:

  • Python — Compiled via PyInstaller; useful for cross-platform testing
  • C — Compiled to native PE; tests signature-based and heuristic detection
  • PowerShell — Script-based; exercises script block logging and AMSI
  • Ruby — Less common but useful for testing edge cases in detection rules

Each format interacts differently with security controls. C-compiled payloads test traditional AV signatures and heuristic engines. PowerShell payloads test script-based detection, AMSI integration, and constrained language mode. The variety matters because detection teams need coverage across all vectors.

Safety and Legality

Every test using Veil-Evasion must occur in an environment where you have explicit written authorization. This is not optional — it is a legal requirement in virtually every jurisdiction. Generate payloads in your lab. Test them against your targets. Do not move generated files to production networks or personal devices outside your lab boundary.

When you have finished testing, securely delete generated payloads. Leaving evasion payloads on disk, even in a lab, creates unnecessary risk and clutters your environment.

Detection Context: MITRE ATT&CK Mapping

Understanding where evasion techniques map to established frameworks helps defensive teams prioritize their detection efforts. The MITRE ATT&CK matrix for Defense Evasion (TA0005) catalogs the techniques that payload generators like Veil-Evasion implement — from obfuscated files (T1027) to process injection (T1055) to signed binary proxy execution (T1218).

Mapping your Veil-Evasion test cases to ATT&CK technique IDs allows you to systematically track which techniques your detection stack covers and which remain blind spots. This is how you turn ad-hoc testing into structured coverage measurement.

Where to Go Next