CVE-2012-1854

CVE-2012-1854 - Microsoft VBA Insecure Library Loading (DLL Hijacking)

Execution Persistence Privilege Escalation Last updated:

Detects exploitation of CVE-2012-1854, a DLL hijacking vulnerability in Microsoft Visual Basic for Applications (VBA). Attackers can place a malicious DLL in a directory searched before the legitimate library path, causing Office applications loading VBA to execute attacker-controlled code. This vulnerability is listed in CISA's Known Exploited Vulnerabilities catalog.

Vulnerability Intelligence

KEV — Known Exploited

Affected Software

Vendor
Microsoft
Product
Visual Basic for Applications (VBA)

Weakness (CWE)

CWE-426

Timeline

Disclosed
April 13, 2026

CVSS

7.8
High (7.0–8.9)

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Write-up coming soon

What is CVE-2012-1854 CVE-2012-1854 - Microsoft VBA Insecure Library Loading (DLL Hijacking)?

CVE-2012-1854 - Microsoft VBA Insecure Library Loading (DLL Hijacking) (CVE-2012-1854) maps to the Execution and Persistence and Privilege Escalation tactics — the adversary is trying to run malicious code in MITRE ATT&CK.

This page provides production-ready detection logic for CVE-2012-1854 - Microsoft VBA Insecure Library Loading (DLL Hijacking), covering the data sources and telemetry it touches: Microsoft Defender for Endpoint, Microsoft Sentinel. The queries below are rated high severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Execution Persistence Privilege Escalation
Microsoft Sentinel / Defender
kusto 
let SuspiciousDLLPaths = dynamic(['\\Users\\', '\\AppData\\', '\\Temp\\', '\\Downloads\\', '\\Desktop\\']);
DeviceImageLoadEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName has_any ('WINWORD.EXE', 'EXCEL.EXE', 'POWERPNT.EXE', 'OUTLOOK.EXE', 'MSACCESS.EXE', 'MSPUB.EXE', 'VISIO.EXE')
| where FileName has_any ('vbe7.dll', 'vba7.dll', 'vbe6.dll', 'vba6.dll', 'msvbvm60.dll', 'msvbvm50.dll')
| where FolderPath has_any (SuspiciousDLLPaths)
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessFolderPath, FileName, FolderPath, SHA256, InitiatingProcessCommandLine
| extend RiskIndicator = 'VBA DLL loaded from non-standard path'
| order by Timestamp desc

Detects Office applications loading VBA-related DLLs from non-standard paths such as user profile directories, AppData, Temp, or Downloads folders, indicative of DLL hijacking exploitation of CVE-2012-1854.

high severity high confidence

Data Sources

Microsoft Defender for Endpoint Microsoft Sentinel

Required Tables

DeviceImageLoadEvents

False Positives

  • Legitimate software testing or development environments where VBA DLLs are deployed in non-standard locations
  • Software installation or update processes temporarily placing DLLs in user directories
  • Portable Office applications or sandboxed environments with non-standard directory structures
  • Antivirus or DLP tools staging files in temporary locations during scanning

Sigma rule & cross-platform mapping

The detection logic for CVE-2012-1854 - Microsoft VBA Insecure Library Loading (DLL Hijacking) (CVE-2012-1854) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for CVE-2012-1854 Sigma rules on detection.fyi

Platform-specific guides for CVE-2012-1854

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-06-19 Research depth: standard
References (2)

Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1VBA DLL Hijack - Place Malicious DLL in Temp Directory

    Expected signal: Sysmon Event ID 7 showing WINWORD.EXE loading vbe7.dll from %TEMP% path; DeviceImageLoadEvents in MDE showing FolderPath containing \Temp\

  2. Test 2VBA DLL Hijack - Place Malicious DLL in Downloads Directory

    Expected signal: Sysmon ImageLoad event with ImageLoaded path in \Downloads\; Windows Security log showing file creation event in Downloads directory followed by Office process DLL load

  3. Test 3VBA DLL Hijack - Simulate Document-Triggered DLL Load via PowerShell

    Expected signal: Sysmon Event ID 7 with POWERPNT.EXE as initiating process and vba7.dll loaded from TEMP\vba_hijack_test path; process creation event showing PowerShell as parent of POWERPNT

Response Playbook

Triage

  1. Identify the Office application and specific VBA DLL loaded from a non-standard path; capture the full DLL path, hash (SHA256), and timestamp to distinguish malicious placement from benign software behavior.
  2. Determine the DLL origin: check file creation time, parent process of the Office application, recent downloads, email attachments opened, or documents accessed from network shares around the time of the event.
  3. Correlate with user activity: review whether the user recently opened a document from an untrusted source (email attachment, USB, web download) that could have triggered DLL search-order hijacking.
  4. Check whether the loaded DLL hash matches known-malicious hashes via threat intelligence platforms (VirusTotal, MISP, internal TI feeds) and compare against the expected legitimate DLL hash from Microsoft.

Containment

  1. Isolate the affected endpoint from the network immediately if a malicious DLL is confirmed, to prevent lateral movement or C2 communication initiated by the injected code.
  2. Terminate the affected Office process and quarantine the malicious DLL file, preserving a forensic copy before removal; revoke any tokens or credentials accessible in the context of the compromised process.
  3. Apply MS12-046 patch if not already applied; audit all endpoints for the presence of unpatched VBA components and enforce application control policies (AppLocker/WDAC) to restrict DLL loads from user-writable paths.

Evidence Collection

  1. Collect Sysmon Event ID 7 (ImageLoad) logs, Windows Security Event Logs, and prefetch files from the affected host; preserve the malicious DLL with full metadata including creation/modification timestamps and ACL.
  2. Capture memory dump of the Office process at time of detection if still running, and extract network connection artifacts (netstat, DNS cache, browser history, recent email attachments) to establish the full infection chain.

Escalation Criteria

  • ! Escalate to incident response if the malicious DLL establishes network connections, creates additional processes, modifies registry run keys, or accesses credential stores — indicating active post-exploitation rather than a stale artifact.
  • ! Escalate immediately if multiple endpoints show the same malicious DLL hash or if the DLL was delivered via a shared network drive, indicating a potential supply chain or mass-targeting campaign.

Investigation Guide

Forensic Artifacts

  • > Malicious DLL file in user-writable directories (e.g., %TEMP%, %APPDATA%, %USERPROFILE%\Downloads) with a name matching a legitimate VBA runtime library
  • > Sysmon Event ID 7 records showing the exact DLL load path and loaded DLL hash deviating from the expected system32/SysWOW64 path
  • > Windows Prefetch files for the Office application capturing the DLL load sequence
  • > Registry entries or LNK files pointing to the malicious document that triggered the hijacking
  • > Network connections from Office processes to external IPs/domains following the DLL load event

Tuning Guidance

Start by baselining legitimate VBA DLL load paths across your environment; in most enterprise deployments all VBA DLL loads should originate from C:\Windows\System32\ or C:\Windows\SysWOW64\. Whitelist known-good software that legitimately deploys VBA runtimes to non-standard paths (e.g., specific LOB applications). Exclude virtualization platforms (Citrix, AppV) which may redirect DLL paths. Tune severity downward for endpoints with confirmed portable Office installations. Consider enriching alerts with the hash of the loaded DLL compared against Microsoft-signed expected hashes to reduce false positives to near-zero.

Hunting Queries

Threat hunt for VBA DLL loads from non-standard locations over the past 30 days, identifying endpoints where Office applications loaded VBA libraries from outside expected System32/SysWOW64 paths, which may indicate latent or historical CVE-2012-1854 exploitation.

Hunting — KQL
kql 
DeviceImageLoadEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName has_any ('WINWORD.EXE', 'EXCEL.EXE', 'POWERPNT.EXE', 'OUTLOOK.EXE', 'MSACCESS.EXE')
| where FileName has_any ('vbe7.dll', 'vba7.dll', 'vbe6.dll', 'msvbvm60.dll')
| summarize LoadCount=count(), UniquePaths=dcount(FolderPath), Paths=make_set(FolderPath) by DeviceName, AccountName, FileName
| where UniquePaths > 1 or Paths !has 'System32'
| order by LoadCount desc
Hunting — SPL
spl 
index=windows sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational EventCode=7 earliest=-30d
| where match(Image, "(?i)(WINWORD|EXCEL|POWERPNT|OUTLOOK|MSACCESS)\.EXE$")
| where match(ImageLoaded, "(?i)(vbe7|vba7|vbe6|msvbvm60)\.dll$")
| rex field=ImageLoaded "(?P<DLLDir>.*)\\\\"
| stats count values(DLLDir) as Paths dc(DLLDir) as UniquePaths by Computer ImageLoaded
| where UniquePaths>1 OR NOT match(Paths,"(?i)system32|syswow64")
| sort -count

Atomic Red Team Tests

Test 1 VBA DLL Hijack - Place Malicious DLL in Temp Directory
windows

Simulates CVE-2012-1854 by copying a benign DLL renamed to vbe7.dll into %TEMP%, then launching Word to demonstrate DLL search-order hijacking. Lab environment only.

Command

powershell 
copy C:\Windows\System32\calc.exe %TEMP%\vbe7.dll && echo [*] Malicious DLL planted at %TEMP%\vbe7.dll && start "" "C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE"

Cleanup

powershell 
taskkill /f /im WINWORD.EXE 2>nul & del /f %TEMP%\vbe7.dll

Expected Telemetry

Sysmon Event ID 7 showing WINWORD.EXE loading vbe7.dll from %TEMP% path; DeviceImageLoadEvents in MDE showing FolderPath containing \Temp\

Expected Detection

Alert fires on VBA DLL loaded from non-standard path; detection rule matches InitiatingProcessFileName=WINWORD.EXE and FolderPath containing \Temp\

Test 2 VBA DLL Hijack - Place Malicious DLL in Downloads Directory
windows

Plants a renamed DLL in the user's Downloads folder to simulate an attacker delivering a malicious document alongside a spoofed VBA DLL, exploiting DLL search-order when Office opens the document.

Command

powershell 
copy C:\Windows\System32\notepad.exe "%USERPROFILE%\Downloads\msvbvm60.dll" && echo [*] Malicious VBA runtime DLL placed in Downloads && start "" "C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE"

Cleanup

powershell 
taskkill /f /im EXCEL.EXE 2>nul & del /f "%USERPROFILE%\Downloads\msvbvm60.dll"

Expected Telemetry

Sysmon ImageLoad event with ImageLoaded path in \Downloads\; Windows Security log showing file creation event in Downloads directory followed by Office process DLL load

Expected Detection

Detection fires matching EXCEL.EXE loading msvbvm60.dll from Downloads directory; alert enriched with file hash mismatch against known-good Microsoft hash

Test 3 VBA DLL Hijack - Simulate Document-Triggered DLL Load via PowerShell
windows

Uses PowerShell to simulate the scenario of a malicious document placing a DLL in the working directory before launching an Office process, mimicking the attacker delivery chain for CVE-2012-1854.

Command

powershell 
New-Item -ItemType Directory -Force -Path "$env:TEMP\vba_hijack_test" | Out-Null; Copy-Item 'C:\Windows\System32\calc.exe' "$env:TEMP\vba_hijack_test\vba7.dll"; Set-Location "$env:TEMP\vba_hijack_test"; Start-Process 'C:\Program Files\Microsoft Office\root\Office16\POWERPNT.EXE'; Write-Host '[*] Simulated VBA hijack: POWERPNT launched from directory containing spoofed vba7.dll'

Cleanup

powershell 
Stop-Process -Name POWERPNT -Force -ErrorAction SilentlyContinue; Remove-Item -Recurse -Force "$env:TEMP\vba_hijack_test"

Expected Telemetry

Sysmon Event ID 7 with POWERPNT.EXE as initiating process and vba7.dll loaded from TEMP\vba_hijack_test path; process creation event showing PowerShell as parent of POWERPNT

Expected Detection

Alert triggers on POWERPNT.EXE loading VBA DLL from non-standard path; investigation note flags PowerShell as parent process, indicating scripted delivery of the document/DLL combination

Related Detections

Tactic Hubs

TA0002ExecutionTA0003PersistenceTA0004Privilege Escalation

Related Techniques

T1574.001DLLT1574.002DLL Side-LoadingT1059.005Visual Basic

Same Tactic: Execution

Popular Detections