FrameworkGuidesModulesRelease NotesAbout

Automating Payload Delivery with Veil-Catapult: Multi-Stage Pipelines

Master Veil-Catapult's multi-stage payload delivery automation for lab environments, understand the detection surfaces each delivery mechanism creates, and build monitoring for delivery chain activity.

Automating Payload Delivery with Veil-Catapult: Multi-Stage Pipelines

Payload generation is only half the challenge. Once you have a payload that evades detection, you still need to deliver it to the target, execute it, and clean up — all while generating the kind of telemetry that your defensive systems should be catching. Veil-Catapult automates this delivery and execution pipeline, turning manual file transfers and remote execution commands into a repeatable, consistent process.

For defensive teams, Catapult's value is not in making delivery easier — it is in making delivery consistent. When every delivery follows the same pattern with the same parameters, your detection coverage should be binary: you either catch all of them or none. Inconsistent detection across identical operations reveals reliability gaps in your monitoring.

What Changed Recently

Payload delivery automation has evolved alongside changes in enterprise environments:

  • Credential-based access tightening — As organizations enforce credential isolation, tiered admin models, and just-in-time access, traditional delivery mechanisms (WMI, PsExec, SMB) face new barriers. Testing delivery across these control boundaries validates enforcement.
  • Network segmentation testing — Automated delivery pipelines test whether network segmentation actually prevents lateral movement or just makes it slower.
  • Detection engineering integration — Security teams increasingly run automated delivery pipelines as part of continuous detection validation. A nightly run of Catapult against a lab environment verifies that yesterday's detections still work today.
  • Multi-stage delivery — Modern attack chains rarely deliver the final payload in a single step. Droppers fetch stagers that fetch loaders that fetch the actual payload. Each stage crosses a detection surface.

Multi-Stage Pipeline Architecture

A typical multi-stage delivery pipeline in a lab environment:

Stage 1: Initial Delivery

The first stage gets an initial foothold. Catapult supports several delivery mechanisms:

  • SMB file copy — Direct file transfer to an administrative share (C$, ADMIN$). Exercises file monitoring, share access logging, and antivirus scanning on write.
  • WMI process creation — Remote process execution through WMI. Exercises WMI event logging (Event ID 5857, 5858, 5861) and process creation monitoring.
  • Service creation — Creating and starting a Windows service that executes the payload. Exercises service creation logging (Event ID 7045) and service control manager monitoring.
  • Scheduled Task creation — Registering a scheduled task for deferred or triggered execution. Exercises task scheduler logging (Event ID 4698).

Stage 2: Stager Execution

The initial delivery mechanism places a small stager on the target. The stager:

  • Establishes communication back to the test C2 infrastructure
  • Downloads the next stage payload
  • May perform environmental checks before proceeding (similar to the sandbox awareness techniques discussed in the sandbox evasion article)

Stage 3: Final Payload

The final payload — generated by Veil-Evasion — executes in the context established by the previous stages. This is where the full post-exploitation toolset becomes available.

Stage 4: Cleanup

Catapult automates the removal of delivery artifacts:

  • Delete the transferred files
  • Remove service registrations
  • Delete scheduled tasks
  • Clear relevant event logs (in scenarios where this is tested)

Detection Surfaces by Delivery Mechanism

Each delivery mechanism exercises a different set of detection surfaces. This is what makes automated delivery testing so valuable — it validates detection coverage across all common lateral movement paths.

SMB Delivery Detection

| Telemetry | Event Source | What to Look For | |---|---|---| | Share access | Windows Security (Event ID 5145) | Connections to C$ or ADMIN$ from non-admin workstations | | File creation | Sysmon (Event ID 11) | Executable or script files created in system directories via SMB | | Network connection | Sysmon (Event ID 3) | SMB connections (port 445) between workstations |

WMI Delivery Detection

| Telemetry | Event Source | What to Look For | |---|---|---| | WMI activity | WMI-Activity/Operational (Event IDs 5857-5861) | Remote WMI operations from unexpected sources | | Process creation | Sysmon (Event ID 1) | Processes spawned by WmiPrvSE.exe with suspicious command lines | | Network connection | Sysmon (Event ID 3) | DCOM/WMI network connections (port 135 + dynamic ports) |

Service Creation Detection

| Telemetry | Event Source | What to Look For | |---|---|---| | Service install | System (Event ID 7045) | New services with executable paths pointing to unusual locations | | Registry modification | Sysmon (Event IDs 12-14) | Service registry key creation under HKLM\SYSTEM\CurrentControlSet\Services | | Process creation | Sysmon (Event ID 1) | Processes spawned by services.exe with suspicious characteristics |

Scheduled Task Detection

| Telemetry | Event Source | What to Look For | |---|---|---| | Task creation | Security (Event ID 4698) | New scheduled tasks, especially with inline PowerShell or executable paths | | Task execution | Task Scheduler/Operational (Event ID 200/201) | Task execution matching suspicious task names | | XML task files | File creation monitoring | .xml files in the Tasks directory |

Building a Delivery Test Pipeline

Lab Setup

Follow the sandbox lab guide for the base configuration. For delivery testing specifically, you also need:

  • Multiple target VMs — At least two Windows targets to test lateral movement between endpoints
  • A domain controller — For testing domain-authenticated delivery mechanisms (WMI, service creation, scheduled tasks)
  • Centralized logging — All targets forwarding logs to a SIEM for correlation

Test Execution Workflow

  1. Generate payloads with Veil-Evasion using the command-line reference
  2. Configure Catapult with the delivery mechanism to test
  3. Revert targets to clean snapshots
  4. Execute delivery through Catapult
  5. Verify detection — Check that your SIEM received the expected telemetry and that detection rules fired
  6. Document results — Record which delivery mechanisms were detected and which were missed
  7. Iterate — For any missed detections, analyze why and build new rules

Continuous Validation

The highest-value use of automated delivery is continuous validation:

  • Schedule automated delivery runs on a regular basis (nightly or weekly)
  • Compare detection results against previous runs
  • Any degradation in detection coverage triggers investigation
  • Track detection coverage metrics over time

Common Detection Gaps

  1. WMI monitoring not enabled — The WMI-Activity/Operational log is not always forwarded to SIEM. Without it, WMI-based delivery is invisible.
  2. Service creation noise — Legitimate software installations create services frequently. Without tuning, service creation alerts generate excessive false positives, leading analysts to ignore them.
  3. Lateral SMB treated as normal — In environments where administrative shares are used for file distribution, SMB-based delivery blends with normal traffic. Behavioral baselines are essential.
  4. Cleanup removes evidence — If the attacker cleans up artifacts before your detection fires, you may have no alerts. Detection must trigger on the delivery action, not the artifact.

Related Reading

Delivery automation is not about convenience — it is about consistency. When your delivery is repeatable, your detection testing is meaningful. Every gap in delivery detection is a gap in your lateral movement coverage.