FrameworkGuidesModulesRelease NotesAbout

Blue Team Monitoring: Detecting Veil Framework Activity in Logs

Practical guide for blue teams on detecting Veil Framework payload generation, delivery, and execution through log analysis, SIEM rules, and endpoint telemetry correlation.

Blue Team Monitoring: Detecting Veil Framework Activity in Logs

If you are a blue team analyst, SOC operator, or detection engineer, you will eventually encounter payloads generated by the Veil Framework — either in authorized purple team exercises or in real incidents where adversaries use similar techniques. Understanding what Veil-generated activity looks like in your logs, SIEM, and endpoint telemetry is the difference between catching the test and missing the real thing.

This article provides a practitioner-focused guide to detecting Veil Framework activity across the full kill chain: payload generation artifacts, delivery indicators, execution telemetry, post-exploitation behavior, and the evasion techniques that make each stage harder to detect.

What You Are Looking For

Veil Framework payloads do not have a single, universal signature. The framework's purpose is evasion — generating payloads that avoid signature-based detection. Instead of looking for a specific hash or string, you need to detect the behavioral patterns that Veil payloads share with real-world threats.

The detection model has four phases:

  1. Delivery — How the payload reaches the target
  2. Execution — How the payload runs and establishes itself
  3. Post-exploitation — What the payload does after execution
  4. Evasion artifacts — What the obfuscation and evasion techniques leave behind

Phase 1: Delivery Detection

Veil payloads can be delivered through any mechanism. The common lab delivery paths — and their log signatures — include:

Email/Web Delivery

  • Proxy logs — HTTP requests downloading executable or script files. Pay attention to User-Agent strings, download source domains, and file types.
  • Email gateway logs — Attachments with suspicious file types, links to recently registered domains.

Network Delivery (via Catapult)

  • SMB Event ID 5145 — Share access for payload transfer. Alert on access to C$ and ADMIN$ shares from non-administrative workstations.
  • WMI Event IDs 5857-5861 — Remote process execution through WMI.
  • Service creation Event ID 7045 — New services registered for payload execution.

For the complete delivery detection surface, the Catapult delivery pipelines article maps each mechanism to specific telemetry sources.

LOLBAS Delivery

Veil payloads delivered via living-off-the-land binaries:

  • certutil.exe with -urlcache -split -f and an external URL
  • bitsadmin.exe creating transfer jobs
  • mshta.exe executing remote HTA content
  • powershell.exe with download cradle patterns

See the LOLBAS detection article for comprehensive detection rules.

Phase 2: Execution Detection

PowerShell-Based Payloads

Veil generates several PowerShell payload types. Detection opportunities:

  • Script Block Logging (Event ID 4104) — The decoded payload content. Look for:

    • Base64-encoded content being decoded
    • .NET reflection ([Reflection.Assembly]::Load)
    • Shellcode allocation patterns (VirtualAlloc, CreateThread)
    • AMSI bypass attempts
    • Network connection establishment

  • Process creation (Sysmon Event ID 1) — PowerShell launched with:

    • -EncodedCommand or -enc arguments
    • -ExecutionPolicy Bypass
    • -NoProfile -WindowStyle Hidden
    • Pipe from another process (cmd.exe | powershell)

The PowerShell hardening guide details the monitoring configuration.

Compiled Payloads (C, C#, Go, Python)

  • File creation (Sysmon Event ID 11) — New executables in user-writable directories (Downloads, Temp, AppData)
  • Process creation (Sysmon Event ID 1) — Unsigned executables, executables running from unusual paths, or executables with suspicious parent processes
  • Code signing verification — Unsigned or self-signed executables in environments that expect signed software

Python-Based Payloads (Pyherion-obfuscated)

  • Python interpreter spawning — python.exe or pythonw.exe launched with script arguments from unexpected paths
  • exec() and compile() usage — If Python execution logging is available, these function calls indicate dynamic code execution
  • Standalone Python executables — PyInstaller-packaged payloads create temporary directories during extraction; monitor for PyInstaller extraction paths

For obfuscation-specific detection, see the Pyherion obfuscation article.

Phase 3: Post-Exploitation Detection

After a Veil payload executes successfully, the post-exploitation phase generates significant telemetry:

Process Injection

  • Sysmon Event ID 8 (CreateRemoteThread) — Remote thread creation in another process
  • Sysmon Event ID 10 (ProcessAccess) — Cross-process handle acquisition with write/execute permissions
  • Memory allocation patterns — PAGE_EXECUTE_READWRITE allocations in processes that should not have them

The process injection trends article covers the full detection surface.

Credential Access

  • LSASS access — Sysmon Event ID 10 targeting lsass.exe
  • Registry extraction — reg.exe save targeting SAM, SYSTEM, or SECURITY hives
  • Kerberoasting — Unusual TGS requests (Event ID 4769) with RC4 encryption

The Veil-Pillage credential harvesting article maps these techniques to specific detections.

Network Activity

  • Sysmon Event ID 3 (NetworkConnect) — Outbound connections from payload processes to C2 infrastructure
  • DNS queries — Resolution of C2 domains from unexpected processes
  • Beaconing patterns — Regular interval connections to the same destination

Active Directory Reconnaissance

  • LDAP query volume — Bursts of LDAP queries from a single endpoint
  • PowerView function calls — Script Block Log entries with AD enumeration patterns

The PowerView reconnaissance article covers AD-specific detection.

Phase 4: Evasion Artifact Detection

Veil's evasion techniques leave their own detectable traces:

AMSI Bypass

  • Script Block Log — The bypass code itself is often logged before AMSI is disabled. Search for patterns: amsiInitFailed, AmsiScanBuffer, AmsiUtils
  • ETW provider modification — Patching of ETW providers to disable telemetry

Sandbox Detection

  • API call patterns — Calls to GetCursorPos, GetLastInputInfo, Win32_DiskDrive WMI queries early in execution indicate sandbox awareness
  • See the sandbox evasion article

Encryption and Obfuscation

  • High entropy payloads — Encrypted or heavily obfuscated payloads have measurably high entropy
  • Decryption-before-execution patterns — Memory allocation followed by a compute-intensive loop followed by execution transfer
  • See the chaos encryption article

Building a Detection Dashboard

For continuous monitoring, build a SIEM dashboard that tracks:

| Panel | Data Source | Purpose | |---|---|---| | PowerShell suspicious commands | Event ID 4104 | Real-time script content monitoring | | LSASS access events | Sysmon Event ID 10 | Credential access attempts | | New service creation | Event ID 7045 | Payload delivery via services | | Unsigned executable launches | Sysmon Event ID 1 + code signing | Unknown payload execution | | Cross-process injection | Sysmon Event IDs 8, 10 | Process injection activity | | Unusual network connections | Sysmon Event ID 3 | C2 communication | | AMSI bypass indicators | Event ID 4104 | Evasion attempts |

Practical Workflow for Purple Team Exercises

When your red team runs Veil Framework exercises:

  1. Pre-exercise — Verify all logging is functional. Check that Sysmon, PowerShell logging, and event forwarding are working.
  2. During exercise — Monitor the dashboard in real time. Note which phases generate alerts and which do not.
  3. Post-exercise — Conduct a comprehensive log review. Identify every action the red team took and verify that corresponding telemetry exists.
  4. Gap analysis — For any red team action without corresponding telemetry, investigate the logging gap and remediate.
  5. Rule development — Build or refine detection rules for identified gaps. Test them in the lab environment.

Related Reading

Your logs tell the story of every attack — if you are collecting the right telemetry and know what patterns to look for. The Veil Framework generates the activity. Your SIEM must catch it. Test, validate, iterate.