Registry access to the Office DDE enablement keys

Siemphony@siemphonymediumT1559.002unverified

Matches a handle request or a permission change against the per-user registry keys that decide whether Word and Excel will execute a DDE or DDEAUTO field — the `AllowDDE` value under HKCU\Software\Microsoft\Office\<version>\Word\Security and the Excel key beside it, which the technique's own description names as how DDE is turned back on after Microsoft disabled it. AN1393 lists "registry keys enabling DDE" alongside the process-creation leg, and the registry leg is the only one in this brief that is specific to this technique: an Office document host spawning cmd.exe or powershell.exe is a real DDE artefact, but nothing on Sysmon EventID 1 separates a DDEAUTO field from a VBA macro, an embedded OLE object or an XLL add-in, and that parent-child observable is already published in this corpus under T1203 and T1204 — a third copy under this ID would attribute one event to three techniques without adding evidence for any of them. What this rule buys instead is the preparation step, and it pays for it in coverage: a document that fronts DDE on a host where the setting is already permissive produces no registry event at all, and is not seen here. The Office Options branch — `DontUpdateLinks`, `DDEAllowed`, `DDECleaned` — is deliberately excluded because ordinary Office use rewrites that key constantly. Group-policy writes are filtered out by path, which also means an administrator-level attacker who sets the value through the Policies branch is filtered out with them. The rule is written in the raw Security-channel vocabulary (`EventID`, `ObjectName`, `ObjectType`); Security 4657 would name the value written and whether it was set to 1, but it is not among this brief's log sources and splits key and value across `ObjectName` and `ObjectValueName`, so that feed needs a field mapping before it could be used. 4656 reports the access requested, not the write that followed, so a match is the question and not the answer. Prerequisite: registry object access is not audited by default and is not in the MS or CIS baselines — without Audit Object Access (Registry) enabled and a SACL placed on these specific keys auditing Set Value and Create Subkey, this rule returns zero rows on every host, which reads as quiet when it means blind. A SACL that audits reads instead will match Word's own startup on every launch. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0504, 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.

SecurityEvent| where (((((EventID == 4656 or EventID == 4670) and ObjectType =~ "Key") and ObjectName contains "\\Microsoft\\Office\\") and (ObjectName contains "\\Word\\Security" or ObjectName contains "\\Excel\\Security")) and not (ObjectName contains "\\Policies\\Microsoft\\Office"))

Splunk · SPL

Run this as a search.

index=* (((((EventID="4656" OR EventID="4670") AND ObjectType="Key") AND ObjectName="*\\Microsoft\\Office\\*") AND (ObjectName="*\\Word\\Security*" OR ObjectName="*\\Excel\\Security*")) AND NOT (ObjectName="*\\Policies\\Microsoft\\Office*"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (((((event.code == 4656 OR event.code == 4670) AND TO_LOWER(ObjectType) == "key") AND TO_LOWER(ObjectName) LIKE "*\\\\microsoft\\\\office\\\\*") AND (TO_LOWER(ObjectName) LIKE "*\\\\word\\\\security*" OR TO_LOWER(ObjectName) LIKE "*\\\\excel\\\\security*")) AND NOT (TO_LOWER(ObjectName) LIKE "*\\\\policies\\\\microsoft\\\\office*"))

Wazuh · XML rule

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

<group name="sigma,windows,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="EventID" type="pcre2">(?i)(^4656$|^4670$)</field>    <field name="ObjectType" type="pcre2">(?i)^Key$</field>    <field name="ObjectName" type="pcre2">(?i)\\Microsoft\\Office\\</field>    <field name="ObjectName" type="pcre2">(?i)(\\Word\\Security|\\Excel\\Security)</field>    <field name="ObjectName" negate="yes" type="pcre2">(?i)\\Policies\\Microsoft\\Office</field>    <description>Registry access to the Office DDE enablement keys</description>    <mitre>      <id>T1559.002</id>    </mitre>  </rule></group>

At a glance

Logsource: security / windows
Level: medium
Category: office_macro_execution
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: e19a188a-b21b-4985-8ef3-67aa9f358209

ATT&CKT1559.002

T1559.002Dynamic Data Exchange

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.

Lessonoffice macro execution

office macro execution

01 · What this rule detects

A document application — Word, Excel, PowerPoint, Outlook, Publisher, Visio — starting a shell, a script host or a signed proxy binary. The document is the delivery vehicle and the child process is the first thing the attacker actually controls. It is one of the most durable detections available because the parent-child relationship is a property of how the payload has to run, not a string the attacker chooses.

02 · Telemetry you need

Process creation with ParentImage and the full command line — Sysmon EventID 1, or Security 4688 with Audit Process Creation plus the command-line inclusion policy; both off by default, and 4688 without the second one gives you the child process with no arguments
Sysmon EventID 7 (ImageLoad) for the macro runtime — VBE7.DLL and its companions loading into an Office process tells you a macro ran even when nothing was spawned
Sysmon EventID 11 (FileCreate) under %TEMP%, INetCache and the Outlook secure temp folder, where the attachment lands before it is opened
Sysmon EventID 15 (FileCreateStreamHash) for the Mark of the Web zone identifier, which records that the document arrived from outside
Sysmon EventID 3 (NetworkConnect) initiated by the Office process itself

03 · How the logic works

The rule is ParentImage in the Office set AND Image in a child set — shells, script hosts, the signed proxy binaries, and any process launched from a user-writable path. ParentImage carries the signal; the child list is the part you widen over time. The important weakness to teach is that the parent link is breakable: a macro that goes through WMI or a COM object gets its child reparented away from Office, and the rule silently stops matching for exactly the samples that bothered to evade it. That is why the macro-runtime image load and Office writing an executable file are worth having as separate rules rather than as extra conditions on this one — they survive the reparenting. Outlook deserves its own rule too: as a parent it means something different from Word, and the volume profile is different.

04 · Common false positives

Genuine business macros — finance and reporting workbooks that shell out, refresh external data or drive another application
Office add-ins and vendor integrations that launch helper processes, including document management and e-signature tooling
Mail merge, document conversion and reporting pipelines that automate Office on a server
Helpdesk and repair scripts that invoke Office repair or start a shell from a template
Office spawning ordinary Windows infrastructure processes as part of normal operation

05 · Detection maturity

Tier 1 — starting point: Matches an Office application spawning cmd.exe or PowerShell.
Tier 2 — tuned: Covers the full parent set against a broad child set including script hosts and proxy binaries, with named business macros excluded by document path.
Tier 3 — correlated: Adds the macro runtime load and the Mark of the Web, and correlates the chain with what the child process did on the network or wrote to disk.

Tuning & false positivesexperimental · 4 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

Exclude by the document or template path, or by the host running the automation, rather than by the child process — dropping cmd.exe from the child list to quieten one workbook blinds the rule everywhere
Raise severity when the document carries a Mark of the Web zone identifier, and again when it came from Outlook's temp folder
Keep the child list additive, and include 'anything launched from a user-writable directory' as a condition rather than trying to name every binary
Give outlook.exe as parent its own rule so the two can be tuned and prioritised independently
Where the telemetry has it, capture the grandparent as well, so the alert shows the analyst the whole chain rather than one hop

Declared by the author

A user changing Trust Center settings in Word or Excel — macro warnings, protected view, external content or link updating — which writes the same per-user Security key that DDE enablement lives under. On a normal desktop estate this is the most frequent match, and it cannot be separated from a malicious write at this event because 4656 does not carry the value.
Endpoint hardening and compliance remediation that sets AllowDDE and the macro-warning values directly in the user hive rather than through group policy, so the Policies filter does not remove it. This runs from a small fixed set of management binaries and is allowlistable on ProcessName rather than by lowering the level.
Office installation, repair and click-to-run channel updates, which recreate the per-user Security keys for each installed application and produce a burst of handle requests on them.
Profile roaming, user-state migration and registry backup tooling, which opens the Office branch of the user hive with write access as part of a whole-hive operation and generates the event without any value ever changing.

Noise check0 of 6 fired

Fires on none of the 6 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 6 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 T1559.002, evaluated against their — events.

Share this rule

/u/siemphony/e19a188a-b21b-4985-8ef3-67aa9f358209

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.

Registry access to the Office DDE enablement keys

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it