The SANS Internet Storm Center recently published a YARA rule for detecting orphaned VBA projects embedded inside DWG files — the native drawing format used by AutoCAD and a wide ecosystem of CAD tools. This matters more than it might appear at first glance. DWG files are ubiquitous in engineering, construction, manufacturing, energy, and defense environments. They routinely traverse email gateways, file shares, and collaboration platforms with minimal scrutiny, because most security stacks treat them as opaque binary design data rather than potential code containers.
Attackers have figured this out. By embedding VBA macro projects inside DWG files — including orphaned projects that are no longer properly referenced by the host document structure but still contain executable macro code — adversaries gain a delivery vehicle that sails past attachment filters tuned for DOCX, XLSM, and PDF. Any organization whose users receive DWG files from external parties (which is effectively every AEC, manufacturing, and critical infrastructure firm) needs detection coverage for this technique today.
Technical Analysis
What's actually happening
AutoCAD has supported embedded VBA (Visual Basic for Applications) projects for years. Historically, attackers have abused related mechanisms — malicious LISP routines (acad.lsp, acaddoc.lsp), VBA projects, and embedded OLE objects — to achieve code execution when a drawing is opened. The technique highlighted by the SANS ISC diary focuses on a subtler variant: orphaned VBA projects.
In a legitimate document (Office or otherwise), a VBA project is referenced by the container structure — a project stream, a dir stream, and module streams, all linked through the OLE compound file directory. An orphaned project is one where the VBA storage still exists inside the file's binary structure, but the normal references to it have been stripped, broken, or never properly linked. This is significant for defenders because:
- Static scanners miss it. Tools that enumerate OLE streams by walking the compound file directory tree will not find orphaned storages. The macro code is present in the raw bytes but absent from the parsed structure.
- It indicates deliberate tampering. Legitimate software does not produce orphaned VBA projects under normal circumstances. Their presence is a strong indicator of manual binary manipulation — exactly what you'd expect from an attacker hand-crafting a payload container or stripping a malicious project to evade detection while leaving artifacts (or a foothold for later re-linking) behind.
- Signature-based detection still works — if you look at raw bytes. Because the orphaned project exists in the file body, pattern-matching tools like YARA can still identify the telltale VBA structures: the
\x05\x00\x00\x00module stream headers, the_VBA_PROJECTstream signature, and performance cache (PCODE) markers.
Why DWG specifically
DWG is a proprietary binary format (header signatures such as AC1015, AC1027, AC1032 denote format versions). Email security gateways, DLP engines, and many EDR content scanners have far weaker inspection depth for DWG than for Office formats. Combine that with the fact that CAD users are conditioned to open large binary files from subcontractors and vendors, and you have a near-ideal social engineering surface. Engineering workstations also tend to run with elevated privileges, hold high-value intellectual property, and sit in network segments adjacent to OT/ICS environments — amplifying the blast radius of a successful compromise.
Exploitation status
This is an active, observed tradecraft documented by the SANS ISC handler team, not a theoretical attack. The published YARA rule exists precisely because malicious samples carrying these orphaned projects are being encountered in the wild. No CVE is associated with this technique — it is abuse of legitimate (if legacy) functionality, which means there is no patch coming. Detection and policy enforcement are the entire defense.
Detection & Response
YARA: The core detection artifact
The ISC diary's approach centers on matching VBA project structures inside files that present as DWG. Below is a hardened variant suitable for email gateway scanning (e.g., via a sandbox or mail-flow YARA integration) and file-share sweeps. It keys on the DWG magic header combined with VBA storage markers anywhere in the file body.
rule DWG_Orhphaned_VBA_Project
{
meta:
description = "Detects DWG files containing embedded/orphaned VBA project structures"
author = "Security Arsenal (based on SANS ISC diary 33434)"
date = "2026/04/06"
reference = "https://isc.sans.edu/diary/rss/33434"
hash_context = "Orphaned VBA projects inside DWG files"
strings:
// DWG version magic (AC1012 through AC1032+)
$dwg_magic = /AC10(12|15|18|21|24|27|32)/
// OLE compound file signature (embedded VBA storage)
$ole_sig = { D0 CF 11 E0 A1 B1 1A E1 }
// VBA storage stream names (UTF-16LE, as stored in compound files)
$vba_project = "_VBA_PROJECT" wide
$vba_dir = "VBA" wide
$vba_module = "dir" wide
// P-code / performance cache marker
$pcode = { 01 16 07 00 00 00 }
condition:
$dwg_magic at 0 and
($ole_sig or $vba_project or (2 of ($vba_*)) or $pcode)
}
Tune the condition to your noise floor. In most environments, $dwg_magic at 0 and $vba_project alone is high-fidelity — legitimate AutoCAD-generated DWGs do not carry VBA project storages unless a user deliberately saved macros into a DVB project workflow, which is rare in 2026.
Sigma rules
---
title: AutoCAD Process Spawning Suspicious Child Processes
id: 3b7e2f91-4c6a-4d8e-b9f2-1a5c7d9e3f01
status: experimental
description: Detects acad.exe or related CAD processes spawning script interpreters or shells, consistent with malicious embedded VBA/LISP execution from a weaponized DWG file.
references:
- https://isc.sans.edu/diary/rss/33434
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.execution
- attack.t1059.005
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith:
- '\acad.exe'
- '\acadlt.exe'
- '\accoreconsole.exe'
- '\civil3d.exe'
- '\revit.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
- '\certutil.exe'
- '\bitsadmin.exe'
condition: selection_parent and selection_child
falsepositives:
- Rare CAD plugin installers; verify against software inventory
level: high
---
title: DWG File Written to Email or Temp Staging Locations
id: 8d1f4a62-7b3c-4e9a-a2d5-6f8b1c4e7a92
status: experimental
description: Detects DWG files landing in locations typical of email attachment extraction or script-driven staging, where malicious drawings are commonly dropped before user execution.
references:
- https://isc.sans.edu/diary/rss/33434
- https://attack.mitre.org/techniques/T1566/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.initial_access
- attack.t1566.001
logsource:
category: file_event
product: windows
detection:
selection:
TargetFilename|endswith:
- '.dwg'
- '.dxf'
- '.dvb'
- '.lsp'
- '.fas'
- '.vlx'
selection_path:
TargetFilename|contains:
- '\AppData\Local\Temp\'
- '\AppData\Local\Microsoft\Windows\INetCache\'
- '\Content.Outlook\'
- '\Downloads\'
condition: selection and selection_path
falsepositives:
- Legitimate CAD downloads from vendors; correlate with file hash reputation and sender
level: medium
The first rule is the high-fidelity catch: AutoCAD spawning a script interpreter is almost never legitimate in an enterprise context. The second is a triage feeder — enrich it with hash reputation and email sender context before alerting.
KQL hunting query (Microsoft Sentinel / Defender)
// Hunt for CAD processes spawning suspicious child processes (weaponized DWG execution)
let Lookback = 14d;
let CADProcesses = dynamic(["acad.exe", "acadlt.exe", "accoreconsole.exe", "civil3d.exe", "revit.exe"]);
let SuspiciousChildren = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe", "bitsadmin.exe"]);
DeviceProcessEvents
| where TimeGenerated > ago(Lookback)
| where InitiatingProcessFileName in~ (CADProcesses)
| where FileName in~ (SuspiciousChildren)
| project TimeGenerated, DeviceName, AccountName,
InitiatingProcessFileName, InitiatingProcessCommandLine,
FileName, ProcessCommandLine, SHA256, ReportId
| order by TimeGenerated desc;
// Companion hunt: DWG/DVB/LSP files created by mail or browser processes
DeviceFileEvents
| where TimeGenerated > ago(Lookback)
| where FileName has_any (".dwg", ".dvb", ".lsp", ".fas", ".vlx")
| where InitiatingProcessFileName in~ ("outlook.exe", "msedge.exe", "chrome.exe", "firefox.exe", "thunderbird.exe")
| project TimeGenerated, DeviceName, FileName, FolderPath,
InitiatingProcessFileName, SHA256
| order by TimeGenerated desc;
Velociraptor VQL artifact
-- Hunt for DWG files containing embedded VBA project markers in user-writable staging paths
-- Deploy as a hunt across engineering/CAD user endpoints
SELECT FullPath, Size, Mtime,
string(data=read_file(filename=FullPath, length=4096)) AS HeaderSnippet
FROM glob(globs=[
'C:/Users/*/Downloads/**/*.dwg',
'C:/Users/*/AppData/Local/Temp/**/*.dwg',
'C:/Users/*/AppData/Local/Microsoft/Windows/INetCache/**/*.dwg'
])
WHERE read_file(filename=FullPath, accessor='ntfs') =~ '_VBA_PROJECT'
OR read_file(filename=FullPath, accessor='ntfs') =~ 'VBA'
For large fleets, narrow the glob to recently modified files (Mtime > now() - 1209600) and cap read_file reads — scanning full DWG binaries across thousands of endpoints is expensive. The _VBA_PROJECT wide-string match in the raw bytes is the orphaned-project indicator the YARA rule targets.
Remediation and verification script
# ScanDWG-VBA.ps1 — Sweep file shares and endpoints for DWG files containing VBA project markers
# Run as a scheduled task on file servers hosting CAD project data, or push via your RMM
param(
[string]$ScanRoot = "D:\Projects",
[string]$ReportPath = "C:\Reports\DWG-VBA-Scan-$(Get-Date -Format 'yyyyMMdd-HHmm').csv"
)
$results = @()
$dwgFiles = Get-ChildItem -Path $ScanRoot -Recurse -Include *.dwg,*.dvb,*.lsp -ErrorAction SilentlyContinue
foreach ($file in $dwgFiles) {
try {
$bytes = [System.IO.File]::ReadAllBytes($file.FullName)
$content = [System.Text.Encoding]::Unicode.GetString($bytes)
$isDwg = $bytes[0..4] -join '' -match 'AC10'
$hasVba = $content -match '_VBA_PROJECT'
if ($hasVba) {
$hash = (Get-FileHash -Path $file.FullName -Algorithm SHA256).Hash
$results += [PSCustomObject]@{
File = $file.FullName
SizeKB = [math]::Round($file.Length / 1KB, 2)
Modified = $file.LastWriteTime
SHA256 = $hash
Verdict = 'SUSPICIOUS - VBA project marker in drawing file'
}
}
} catch { Write-Warning "Could not read $($file.FullName): $_" }
}
$results | Export-Csv -Path $ReportPath -NoTypeInformation
Write-Host "Scanned $($dwgFiles.Count) files. $($results.Count) suspicious. Report: $ReportPath"
# Hardening: disable AutoCAD VBA auto-load and LISP auto-execution via registry policy
# (Set for all users; values align with Autodesk secure-load guidance)
$secureLoad = 'HKLM:\SOFTWARE\Autodesk\AutoCAD\R24.3\ACAD-7101:409\Variables\SECURELOAD'
if (Test-Path $secureLoad) {
Set-ItemProperty -Path $secureLoad -Name '(Default)' -Value 2 # 2 = only load from trusted paths
Write-Host 'SECURELOAD enforced: executables load only from trusted locations.'
}
Note: adjust the R24.3\ACAD-7101:409 key to match your deployed AutoCAD version — enumerate HKLM:\SOFTWARE\Autodesk\AutoCAD first to identify the correct release keys in your environment.
Remediation
Because this technique abuses legitimate functionality rather than a patched vulnerability, remediation is policy- and detection-driven:
- Enforce AutoCAD SECURELOAD. Set
SECURELOAD=2so AutoCAD only loads executable content (LISP, VBA, .NET assemblies) from designated trusted paths. Pair this withTRUSTEDPATHSlocked to read-only, centrally managed directories. This is the single most effective control against code execution from weaponized drawings. - Deploy the YARA rule at the email boundary. Integrate DWG-content scanning into your secure email gateway or sandbox detonation pipeline. Block or quarantine DWG/DVB/LSP/FAS/VLX attachments from external senders by default; require a business justification workflow for exceptions.
- Treat LISP and DVB as executables in your attachment policy.
acad.lsp,acaddoc.lsp,.dvb,.fas, and.vlxfiles are code. If your gateway allows.exeblocking but passes.lsp, you have a hole. - Baseline CAD process behavior. Deploy the Sigma rule above. AutoCAD spawning cmd.exe or PowerShell should page someone. In mature environments, use WDAC/AppLocker to constrain child processes from acad.exe.
- Sweep historical file shares. Run the PowerShell sweep (or the Velociraptor hunt at scale) against project archives. Orphaned VBA projects in archived drawings may indicate a past intrusion or a staged supply-chain payload from a compromised subcontractor.
- Segment engineering workstations. CAD users touch high-value IP and often bridge into OT. Ensure engineering VLANs have restricted egress, no direct domain admin logon, and monitored lateral movement paths.
- User awareness for the AEC workflow. Engineers exchange drawings constantly and will open files from subcontractors without hesitation. Brief them specifically on this vector: an unexpected DWG, even from a known contact, warrants verification through a second channel.
Related Resources
Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.