Verclsid spawned by an Office application or script host

Siemphony@siemphonyhighT1218.012unverified

Matches verclsid.exe created by a parent that has no reason to be verifying a shell extension — an Office application, a script host, or an interactive shell — which is MITRE's ParentProcessFilter knob applied as the whole of the logic, with winword.exe and excel.exe from MITRE's own text and the rest of the parent list authored here. The documented /S /C {CLSID} switches are deliberately not used as a gate, because Explorer passes the same switches during ordinary shell-extension verification and they therefore separate nothing; the parent does. Verclsid started through COM activation is attributed to svchost.exe under DcomLaunch and will not match, and the analytic's module-load and outbound-connection elements are separate events that a single process-creation record cannot carry. The rule is written in the Sysmon EventID 1 vocabulary the analytic supplies for this category, meaning Image and ParentImage; a Security 4688 feed holds the same facts under NewProcessName and ParentProcessName and needs that field mapping, plus Audit Process Creation enabled, before it can match at all. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0042, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Sentinel · KQL

Run this as a search.

DeviceProcessEvents| where (FolderPath endswith "\\verclsid.exe" and (InitiatingProcessFolderPath endswith "\\winword.exe" or InitiatingProcessFolderPath endswith "\\excel.exe" or InitiatingProcessFolderPath endswith "\\powerpnt.exe" or InitiatingProcessFolderPath endswith "\\outlook.exe" or InitiatingProcessFolderPath endswith "\\msaccess.exe" or InitiatingProcessFolderPath endswith "\\visio.exe" or InitiatingProcessFolderPath endswith "\\onenote.exe" or InitiatingProcessFolderPath endswith "\\wscript.exe" or InitiatingProcessFolderPath endswith "\\cscript.exe" or InitiatingProcessFolderPath endswith "\\mshta.exe" or InitiatingProcessFolderPath endswith "\\cmd.exe" or InitiatingProcessFolderPath endswith "\\powershell.exe" or InitiatingProcessFolderPath endswith "\\pwsh.exe" or InitiatingProcessFolderPath endswith "\\wmiprvse.exe"))

Splunk · SPL

Run this as a search.

index=* (Image="*\\verclsid.exe" AND (ParentImage="*\\winword.exe" OR ParentImage="*\\excel.exe" OR ParentImage="*\\powerpnt.exe" OR ParentImage="*\\outlook.exe" OR ParentImage="*\\msaccess.exe" OR ParentImage="*\\visio.exe" OR ParentImage="*\\onenote.exe" OR ParentImage="*\\wscript.exe" OR ParentImage="*\\cscript.exe" OR ParentImage="*\\mshta.exe" OR ParentImage="*\\cmd.exe" OR ParentImage="*\\powershell.exe" OR ParentImage="*\\pwsh.exe" OR ParentImage="*\\wmiprvse.exe"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(process.executable) LIKE "*\\\\verclsid.exe" AND (TO_LOWER(process.parent.executable) LIKE "*\\\\winword.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\excel.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\powerpnt.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\outlook.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\msaccess.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\visio.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\onenote.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\wscript.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\cscript.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\mshta.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\cmd.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\powershell.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\pwsh.exe" OR TO_LOWER(process.parent.executable) LIKE "*\\\\wmiprvse.exe"))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,process_creation,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="12">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)\\verclsid\.exe$</field>    <field name="ParentImage" type="pcre2">(?i)(\\winword\.exe$|\\excel\.exe$|\\powerpnt\.exe$|\\outlook\.exe$|\\msaccess\.exe$|\\visio\.exe$|\\onenote\.exe$|\\wscript\.exe$|\\cscript\.exe$|\\mshta\.exe$|\\cmd\.exe$|\\powershell\.exe$|\\pwsh\.exe$|\\wmiprvse\.exe$)</field>    <description>Verclsid spawned by an Office application or script host</description>    <mitre>      <id>T1218.012</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: high
Category: signed_binary_proxy
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: d297a8fe-2912-4ec8-b9aa-d3bd1b9a8824

ATT&CKT1218.012

T1218.012Verclsid

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonsigned binary proxy

signed binary proxyAI draft — unreviewed

01 · What this rule detects

AN0118 describes verclsid.exe abuse through process creation, CLSID arguments, module loads, and — if the CLSID points at remote content — outbound connections. This rule keeps only the process-creation slice: a verclsid.exe process whose parent is something that has no legitimate reason to be verifying a shell extension. MITRE's ParentProcessFilter knob is the entire logic here — there's no CLSID, module-load, or network check at all, because module load and network activity are separate event types a single process-creation record can't carry, and AN0118's TimeWindow knob that would join them has no equivalent without a correlation engine.

02 · Telemetry you need

category: process_creation, product: windows — the Sysmon EventID 1 vocabulary, meaning Image and ParentImage. The description correctly flags that a Security 4688 feed holds the same facts under NewProcessName and ParentProcessName, and needs both that field mapping and Audit Process Creation enabled before it can match at all — this rule is written against Sysmon only and doesn't attempt the 4688 form.

03 · How the logic works

Two selections, ANDed. selection_image is Image|endswith: '\verclsid.exe'. selection_parent is ParentImage|endswith against fourteen values: seven Office applications from winword.exe through onenote.exe, three script hosts (wscript.exe, cscript.exe, mshta.exe), two shells (cmd.exe, powershell.exe, pwsh.exe), and wmiprvse.exe. MITRE's own technique text names only winword.exe and excel.exe as example anomalous parents; the rest of the list — powerpnt.exe, outlook.exe, msaccess.exe, visio.exe, onenote.exe, and all the script-host and shell entries — are the rule author's additions. The documented verclsid.exe /S /C {CLSID} switches are deliberately not gated on: Explorer passes the same switches during ordinary, legitimate shell-extension verification, so the switches separate nothing and the parent carries the whole signal. Verclsid started through COM activation is attributed to svchost.exe under DcomLaunch and will not match this rule at all.

04 · Common false positives

The rule's own first false positive is the one to weigh most heavily: software deployment and packaging scripts driven from cmd.exe or powershell.exe calling verclsid.exe against a CLSID they just wrote are described as "the widest arm of this rule" — and that arm sits at the same level: high as the Office-application arm, which the review calls out as a genuine calibration slip. Winword or Outlook spawning verclsid.exe is close to zero-false-positive; cmd or wmiprvse spawning it is an administrator or an installer, and those are not the same confidence tier. Atomic Red Team and equivalent purple-team tests reproduce the documented switches from a shell on a schedule, adding recurring benign matches to the same shell arm.

05 · Detection maturity

tier_1: . Derived from a scaffold with no query logic, never executed against a log line. The reasoning that the parent — not the CLSID switches — carries the signal is sound on paper, but paper is all it is.
tier_2: run read-only, split hits by parent into the Office/script tier versus the shell/WMI tier, and confirm whether the shell arm's volume matches what the rule's own false-positive entry predicts before keeping a single `high` level.
tier_3: ** add rundll32.exe/regsvr32.exe to close the chain-break gap, and build MITRE's dropped module-load and network-connection legs as a companion correlation joined on TimeWindow, so a hit means "verclsid loaded a remote scriptlet" rather than "verclsid had an odd parent."

Tuning & false positivesexperimental · 3 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

The review's clearest fix: split the parent list into two selections at two levels — Office and script-host parents at high, cmd.exe, powershell.exe, pwsh.exe, and wmiprvse.exe at medium — or drop the shell/WMI entries and keep high honestly for the tighter list. Separately, the review flags a coverage gap worth closing: rundll32.exe and regsvr32.exe are absent from the parent list despite being the standard intermediate stage in chains that end at verclsid, so a macro that goes Word → rundll32 → verclsid breaks the rule entirely; add both. The review also names a false positive missing from the rule's own list — Office applications hosting Explorer-based shell UI (file-open/save dialogs, Outlook's attachment preview) can attribute verclsid.exe to the Office app rather than to explorer.exe, which undercuts the near-certain-malice premise behind the Office arm specifically.

Declared by the author

Software deployment that registers a shell extension and then validates it. Installer and packaging scripts driven from cmd.exe or powershell.exe can call verclsid.exe against the CLSID they have just written, and the shell parents are the widest arm of this rule.
Adversary-simulation and control-validation tooling. Atomic Red Team's test for this technique, and equivalent purple-team scripts, launch verclsid.exe from a shell with exactly the documented switches, so anywhere those tests are scheduled they are a recurring benign match.
An administrator running verclsid.exe by hand from a command prompt while debugging a broken context-menu or preview handler, which is the supported way to reproduce a shell-extension verification failure.

Noise check0 of 30 fired

Fires on none of the 30 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 30 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1218.012, evaluated against their process_creation events.

Share this rule

/u/siemphony/d297a8fe-2912-4ec8-b9aa-d3bd1b9a8824

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Verclsid spawned by an Office application or script host

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it