CVE-2012-1854 Google Chronicle · YARA-L

Detect CVE-2012-1854 - Microsoft VBA Insecure Library Loading (DLL Hijacking) in Google Chronicle

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.

MITRE ATT&CK

Tactic
Execution Persistence Privilege Escalation

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral 
rule cve_2012_1854_vba_dll_hijacking {
  meta:
    author = "df00tech Detection Engineering"
    description = "Detects VBA DLL hijacking via CVE-2012-1854 - Office apps loading VBA DLLs from non-standard paths"
    severity = "HIGH"
    priority = "HIGH"
    reference = "https://nvd.nist.gov/vuln/detail/CVE-2012-1854"

  events:
    $e.metadata.event_type = "PROCESS_MODULE_LOAD"
    $e.principal.process.file.full_path = /(?i)(WINWORD|EXCEL|POWERPNT|OUTLOOK|MSACCESS|MSPUB|VISIO)\.EXE$/
    $e.target.process.file.full_path = /(?i)(vbe7|vba7|vbe6|vba6|msvbvm60|msvbvm50)\.dll$/
    $e.target.process.file.full_path = /(?i)\\(Users|AppData|Temp|Downloads|Desktop)\\/

  condition:
    $e
}
high severity high confidence

Chronicle YARA-L rule detecting CVE-2012-1854 exploitation by monitoring PROCESS_MODULE_LOAD events where Office applications load VBA DLLs from suspicious user-writable directories.

Data Sources

Google ChronicleWindows Endpoint Telemetry

Required Tables

PROCESS_MODULE_LOAD

False Positives & Tuning

  • Legitimate portable Office installations with non-standard base paths
  • Developer environments with custom Office component deployments
  • Automated QA environments loading Office DLLs from test directories
  • Enterprise deployments using non-default Office installation directories

Other platforms for CVE-2012-1854

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) CrowdStrike LogScale (LogScale) All platforms (combined) →

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

Last updated: 2026-06-19 Research depth: standard
References (2)

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

Related Techniques

[object Object][object Object][object Object]

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