FrameworkGuidesModulesRelease NotesAbout

Veil Command-Line Usage

The Veil Framework supports both an interactive menu-driven interface and a fully scriptable command-line interface. This reference covers the CLI flags, module selection options, and output configuration for automated and repeatable security testing in lab environments.

For most users, the interactive mode is the place to start — it guides you through module and payload selection with prompts. But when you need to run the same test configuration repeatedly (as you do in structured purple team exercises), the CLI mode is essential.

Basic Invocation

The framework is invoked from the installation directory. The base command launches the interactive menu. Adding flags bypasses the menu and runs specific operations directly.

Common invocation patterns:

  • Launch interactive mode — no flags needed
  • List available modules and payloads — use the list flag
  • Generate a specific payload with predefined options — specify the tool, payload, and output parameters

Module Selection

The framework organizes payloads by module and by language. The selection hierarchy follows this pattern:

  1. Module — Which tool (Evasion is the primary payload generation module)
  2. Language — Python, C, PowerShell, Ruby, etc.
  3. Payload type — Specific payload variant within the selected language

Each combination produces different output characteristics, which matters for detection testing. A C-compiled payload interacts with the file system and AV engine differently than a PowerShell script.

Output Options

Generated payloads are saved to the configured output directory. You can control:

  • Output path — Where the generated file is written
  • File name — Custom naming for organized test runs
  • Handler configuration — Listener settings for callback-based payloads

For structured testing, establish a naming convention that includes the date, payload type, and test iteration. This makes it much easier to correlate payload files with detection events after a testing session.

Scripted and Automated Usage

For automated test suites, the CLI accepts all parameters directly. This allows you to script payload generation in shell scripts or CI-like pipelines.

A typical automation pattern for purple team exercises:

  1. Generate a set of payloads across different languages and configurations
  2. Deploy each payload to the target range sequentially
  3. Wait for detection events to propagate to your SIEM
  4. Compare expected detections against actual detections
  5. Document gaps

Automating this workflow ensures consistent test conditions across multiple iterations, which is critical for measuring detection improvement over time.

Common Flags Reference

| Flag | Description | |---|---| | --list-tools | List available tool modules | | --list-payloads | List payloads for a given tool | | -t, --tool | Select a specific tool module | | -p, --payload | Specify payload type | | -o, --output | Set output file path | | --clean | Remove cached compilation artifacts | | --update | Check for and apply updates |

Tips from Experience

Name your output files consistently. After a long testing session with dozens of generated payloads, you will thank yourself for a clear naming convention.

Script your monitoring checks alongside payload generation. If you automate the generation side, automate the detection verification too. A script that generates a payload and then queries your SIEM for the expected event within 60 seconds turns manual checking into automated regression testing.

Keep notes on what each payload configuration tests. Not all payloads exercise the same detection surface. Document which techniques each configuration maps to.

Related