Detecting T1137 Office application startup

How T1137 Office application startup keeps a foothold in Office

T1137 Office application startup lets an adversary keep a foothold by placing code or configuration where Microsoft Office applications load it automatically each time they open. Those startup points include add-ins, templates and Outlook-specific hooks, so the malicious element runs whenever a user launches Word, Excel, PowerPoint or Outlook. In ATT&CK, this behavior sits under the Persistence tactic (TA0003), which describes adversaries trying to maintain their foothold. For a SOC lead, the difficulty is volume: Office launches many times a day on every endpoint, so a persistence entry that fires on launch blends into normal activity unless the startup locations themselves are watched.

The technique has six sub-techniques, which this page maps to ATT&CK version 20.0. They group into a few families: files that Office loads from template or startup folders, Office add-ins that register themselves for every session, Outlook mechanisms such as custom forms, the home page setting and mail rules, and registry-backed test or startup settings that cause Office to load content at launch. Intrusions tend to use the mail-centric variants because a user's mailbox is a durable, trusted place to hide a trigger, and the template and add-in variants often arrive inside a document or a shared file. Confirm the exact sub-technique IDs and names against the version 20.0 STIX bundle in the attack-stix-data repository before you write detection rules, since names and mappings can change between releases.

Start with a decision: which Office startup locations in your estate should never change outside a managed change window. Ask your endpoint team to confirm whether Outlook rules, home page settings and add-in registrations are visible in your current telemetry, because many gaps are found at this step rather than later in the rule-writing stage. Then ask for a baseline of approved add-ins and templates per user group. A baseline turns the high volume of normal Office launches into a short list of changes worth investigating, and it gives your cyber range exercise a clear expected state to test against.

Which telemetry reveals Office startup persistence

This table maps the main ATT&CK data components for T1137 to the signal a defender should look for and the open-source collector that captures it. Read it as a starting point for coverage: the primary sources come first, and the secondary sources add context rather than carry detections alone. Confirm the sub-technique coverage of each data source against the Enterprise ATT&CK 20.0 bundle before you rely on it.

Data component	Signal to look for	Open-source collector
Process Creation (DC0032)	Office applications such as Word, Excel or Outlook launching unexpected child processes, or Office binaries started with unusual arguments	Sysmon process creation events, Windows Security process auditing, Wazuh agent forwarding
File Creation (DC0039)	New files written to Office startup locations such as the Startup, XLSTART or Word startup folders, or to add-in folders	Sysmon file create events, Wazuh file integrity monitoring on the startup paths, Velociraptor hunts
Windows Registry Key Modification (DC0063)	New or changed values under Office add-in, trust or startup keys in the user or machine hives	Sysmon registry events, Windows registry auditing, Wazuh registry monitoring on Windows agents
Command Execution (DC0064), secondary	Commands run by Office processes or scripts that stage or load startup content, used to corroborate a primary alert	Sysmon and Windows command line logging, Velociraptor artifact collection
Application Log Content (DC0038), secondary	Office or Outlook application logs that record add-in loads or macro-related events, used for context and timeline	Windows Application event logs, Wazuh log collection from endpoints
Network traffic (Zeek or Suricata), limited use	Downloads of Office templates or add-ins from unusual hosts that precede a startup write, useful only as supporting evidence	Zeek HTTP logs, Suricata alerts, Security Onion correlation
Sub-technique coverage	Each sub-technique may rely on a different combination of the components above	Confirm the mapping in the Enterprise ATT&CK 20.0 STIX bundle before tuning rules

Detection logic for Office startup paths and add-ins

T1137 abuses the mechanisms Office loads automatically: startup folders, templates, add-in registrations and trusted locations. The cards below describe detection ideas for each mechanism, with the baseline and false positive sources that decide whether an alert is useful. Tune every idea against your own estate before it pages anyone.

New or modified files in startup folders

Alert on files created or changed in Office startup and template folders, such as the XLSTART, Word startup and Templates directories, and on new files in the add-in folders Office scans at launch. Build a baseline of what legitimate deployment tooling writes there during normal patch and template rollouts, then alert on writes by processes outside that set. Start with a narrow threshold, such as any new file from a non-deployment parent process, and widen only after reviewing a few weeks of results. Software deployment tools and approved template publishers are the main false positive sources, so match on the signed publisher and the change window, not the folder alone.

Registry changes under Office add-in keys

Watch for new or modified values under the Office add-in registration keys for Word, Excel, Outlook and PowerPoint, including the load behavior and manifest path values. Compare each change against an approved add-in inventory exported from your endpoint management platform, and treat any add-in key that is absent from that inventory as a priority. Tune by alerting on creation events first, since modifications to existing approved entries generate more noise after updates. Expect false positives from add-in vendors that register during their own installers, so require the installer hash or publisher to match before closing an alert.

Unexpected child processes from Office

Detect Office applications such as Word, Excel and Outlook launching command interpreters, script hosts, or unsigned executables. This is a Process Creation check, so it works regardless of which startup path triggered the launch. Begin with an allowlist of legitimate children observed in your environment, such as add-in helper processes and print or update components, and alert on anything outside it. Expect noise from macro-heavy business workbooks and from vendor add-ins that shell out to helpers, so review parent and child command lines together before tuning.

Changes to trusted locations

Monitor edits to the Office trusted locations and trusted documents settings, since adding a folder to the trusted list lets content there run without the usual prompts. Record the baseline of trusted paths per user group, then alert when a registry value adds a path, especially a path under a user profile, a temporary folder or a removable drive. Keep the threshold strict: any new trusted location outside an approved change ticket is a candidate finding. Group policy refreshes and imaging processes produce legitimate changes, so correlate with the policy source before escalation.

Validating tuning with a baseline review

Before any of the rules above go into production, export a baseline of startup folders, add-in registrations and trusted locations from a reference group of machines, and record which entries came from approved deployments. Replay sample events from a private cyber range against the rules and count true and false positives per rule. Document the ATT&CK version your mappings target, since detection coverage for T1137 sub-techniques is revised between releases such as v18 and v20. Ask your security tooling vendor or open-source rule maintainers which data fields each rule depends on before relying on them.

How to validate T1137 detections in a lab

This sequence proves that each T1137 detection fires on benign, marker-based emulation inside an isolated lab, and it records latency, false positives and coverage gaps so the rules can be tuned and retested. It is written against ATT&CK Enterprise 20.0, so every mapping names the version it targets.

Fix the ATT&CK 20.0 scope
The detection owner lists T1137 Office Application Startup and each of its six sub-techniques as they appear in the enterprise-attack 20.0 STIX bundle, then records the ATT&CK version next to every detection mapping. Confirm the sub-technique IDs against the bundle rather than an older copy of the matrix, because releases can rename, deprecate or revoke techniques. The step is done when a scope sheet lists each sub-technique, its data components (Process Creation, File Creation and Windows Registry Key Modification are the most referenced for this family) and the owning detection, with the version stamped on the sheet.
Build the isolated lab and baseline
The lab team deploys a Windows host with a supported Microsoft Office Suite installation, a Wazuh agent and a Sysmon-equivalent endpoint collector, all on a segment with no route to production or the internet. Before any emulation, the team captures a baseline of the Office startup locations and registry paths so that later changes can be attributed. The step is done when the baseline snapshot is stored with a hash and a timestamp, and when the forwarding path from the agent to the indexer is confirmed by a harmless test event.
Plan the benign marker emulation
The purple team writes a plan that describes, in plain language, which startup locations and registry keys each sub-technique concerns and what harmless marker each step will write, such as a labeled text file in a designated test folder. The plan states expected telemetry for each marker and names an owner for every sub-technique. Approval from the range lead and the security owner is recorded before execution. The step is done when the plan is signed off and each sub-technique has one expected detection outcome.
Run the marker emulation
A tester executes the approved markers in the lab only, one sub-technique at a time, and logs the start and end time of each action in the range notes. Markers are inert and removed after each run, and no payload, command line or evasion step is used. The step is done when every planned marker has been written and removed, with the times recorded and any deviations noted in the plan.
Confirm each Sigma or Wazuh rule fires
The detection engineer checks the SIEM for an alert produced by each Sigma-derived or Wazuh rule against its matching marker, and confirms the alert carries the fields needed for triage, such as host, user, file path or registry key and the ATT&CK tag. A rule that does not fire is logged as a failed test with the telemetry it did receive. The step is done when a pass or fail result is recorded for every sub-technique in the scope sheet.
Record latency, false positives and gaps
The team measures the delay between each marker action and the resulting alert, and counts alerts raised by normal Office updates, add-in installs and administrator changes during the same window. Any sub-technique with no matching telemetry is recorded as a coverage gap with the data component that is missing. The step is done when latency values, false positive counts and gap entries are stored together in the validation report. Ask the platform owner which latency target applies to your environment, since no figure is supplied here.
Tune rules and retest
The detection engineer adjusts logic that produced false positives or missed markers, such as narrowing a path condition or adding an allowlist for known Office add-in locations, and records each change with its reason and version. The same markers are then replayed in the lab to confirm that tuning fixed the problem without silencing the true detection. The step is done when a retest shows the expected result for every sub-technique and the change log is linked from the scope sheet.
Store evidence and schedule revalidation
The validation package, including the scope sheet, baseline, marker plan, rule results, latency data, gap list and change log, is archived with the ATT&CK version used. The team sets a revalidation trigger for each new ATT&CK release and for any change to Office or the endpoint collector, and assigns an owner. The step is done when the package is stored, the owner is named and the trigger is documented, so that auditors and responders can trace each detection to a tested result.

How the Office startup persistence chain fits together

The detection chain for T1137 runs from the endpoint to the SIEM, and each link has a different owner and a different trust level. An adversary who abuses Office application startup places a file or registry value where the Office client will load it at launch, so the Office client itself is the execution point. The endpoint produces the evidence: process creation events for the Office binary and anything it spawns, file creation events in the startup folders and add-in locations, and Windows registry key modification events under the Office add-in and trust settings keys. A collector such as Wazuh agent or Velociraptor gathers those events and forwards them, and the SIEM or analytics layer (for example Security Onion) correlates them. Confirm which of these sources your fleet actually emits before you write any rule, because a missing collector or audit policy looks identical to a clean host.

The trust boundary sits between user-writable locations and managed configuration. Per-user startup folders, per-user add-in paths and the current user's registry hive can be changed by any process running as that user, so changes there are common in normal operation and noisy to alert on. Machine-wide locations and policy-enforced settings are typically changed only by administrators or deployment tooling, so a write there outside a change window is a stronger signal. Decide, per Office version and per fleet, which paths are expected to change and which are controlled through Group Policy or a configuration management tool. Ask your endpoint team to document that split, because the detection thresholds depend on it.

The practical decision is where to enforce and where to observe. Mitigations such as Disable or Remove Feature or Program (M1042) and Update Software (M1051) reduce the attack surface by removing unneeded add-ins and keeping Office current, while the detection chain shows when something still gets through. Plan for the chain to be validated end to end: a test change made on a monitored endpoint should appear in the collector, reach the SIEM and generate the expected alert, and the same test should be repeatable in a private cyber range before it is trusted in production. Check with your security team which ATT&CK version your detection mappings target, since techniques and data components can change between releases.

Preventive controls against T1137

T1137 abuses Office features that load code or content automatically when an application starts. The controls below shrink that attack surface before detection is needed, and they are most effective when they are managed as one configuration baseline rather than as separate fixes.

Disable unneeded startup features

Start by inventorying which Office startup mechanisms your users actually depend on, such as add-in loading, template-based startup and macro-enabled content from certain locations. Under ATT&CK mitigation Disable or Remove Feature or Program (M1042), turn off or remove the features that no business process requires. Document each exception with an owner and a review date. Confirm which startup features your Office version exposes to central policy in your own environment, because the available settings vary by product and release.

Control add-in installation

Add-ins, including COM and VSTO components, are a common route for code to run at application start. Maintain an approved add-in list, block installation by standard users where your policy allows it, and remove add-ins that are no longer supported. Review add-ins after each Office upgrade, since a new release can re-enable or add entries that were previously disabled. Ask your vendor which add-in trust and load controls are available for your deployment method.

Keep Office current

Apply Update Software discipline to Office itself, along with the operating system components it depends on. Track vendor security updates through your normal patch cycle, and set a maximum acceptable lag for the Office channel your organization uses. Confirm the update channel, the deployment tool and the reporting method with your vendor, since these determine how you prove compliance to an auditor.

Restrict trusted locations

Limit which folders Office treats as trusted for templates, startup files and add-ins. Users who can write to a trusted location can often place a file there that Office then loads automatically. Pair trusted location settings with restricted file and directory permissions, and confirm with your administrators which locations are managed by policy and which can be changed by users.

Audit configuration changes

Under ATT&CK mitigation Audit (M1047), treat this as a supporting control rather than a replacement for hardening. Log changes to Office policy, add-in lists and trusted location settings so that unexpected changes can be reviewed. Route these events into your monitoring platform, and confirm with your vendor which policy changes generate auditable events in your version.

Rehearsing T1137 detection in a private cyber range

This tab covers the host-level view. The range should include a Windows image with a supported Microsoft Office installation, a Wazuh agent enrolled to the manager, and a baseline snapshot taken before any exercise starts. The question to answer is whether changes to Office startup locations, such as add-in registrations, template folders and registry-backed load settings, produce events that Wazuh collects and that a rule can match to a specific user, host and time.

Telemetry coverage: Confirm the agent collects the Windows event channels and file or registry monitoring you rely on, and document which Office startup paths are watched.
Rule mapping: Tag each rule with the ATT&CK technique and sub-technique it targets, and record the ATT&CK version the mapping was written against.
Baseline noise: Measure how often legitimate add-in installs and updates fire the same rules during a normal working day in the range.
Evidence retention: Check that raw events are stored long enough to reconstruct the change, including the account and process that made it.
Agent health: Verify the agent stays connected during the exercise, since a silent agent looks like a clean host.

Before closing the exercise, check that every alert in the test window can be traced back to a logged change or a documented inject.

What the SOC does when an Office startup alert fires

The first decision when an Office startup alert fires is whether the artifact is a known, approved add-in or an unexpected persistence mechanism. Confirm the exact file or registry value named in the alert: for add-ins, check the file path under the user's or the machine's Office startup locations, and for registry-based startup, the value name and the data it points to. Then look at the parent process that wrote or loaded the artifact. A legitimate installer, a managed deployment tool or a user action produces a very different picture from a script host or an unfamiliar binary spawning Office. Record what you find before changing anything, because the answers decide whether this is a false positive or an incident.

Next, compare the artifact against the approved add-in inventory your organization maintains for Office. If that inventory does not exist or is out of date, that gap is itself a finding to raise with the endpoint and application owners. Confirm the add-in's publisher, signature status and version against the approved list. Collect the artifact with a forensic tool such as Velociraptor, preserving the file, its hash, the registry export and the process context, so the evidence survives remediation. Scope the same artifact across other endpoints using the same hunt logic, including users who share a deployment image. Contain only after the scope is understood, and remove the persistence by disabling or uninstalling the add-in and cleaning the registry value, then confirm the autostart condition no longer fires. Document the ATT&CK mapping to the affected sub-technique, the telemetry that caught it and the lessons learned.

Questions detection engineers ask about T1137

How do I tell an approved Office add-in from a malicious one?

Start with an inventory and a baseline, not with signatures alone. Record every add-in, template and startup folder entry on a clean reference image, then compare each endpoint against that baseline and against your software approval list. Useful attributes include the publisher, the signing certificate, the install path, and whether the item was deployed by your management tooling or appeared on a user profile. Treat new entries that appear outside a change window as the signal to investigate. Confirm with each add-in vendor which file paths, registry locations and signing certificates their legitimate components use, because those details vary by product and version.

Which MITRE ATT&CK version should my detection rules target?

Pin the version explicitly in every rule, mapping and coverage report. The pages on DeployOpen use Enterprise ATT&CK version 20.0, which MITRE released on 2026-10-13 according to the attack-stix-data repository index. Releases can rename, deprecate or revoke techniques and sub-techniques, and v18 replaced detections in technique pages with detection strategies and analytics, so a rule written against an older mapping may not match the current data component names. Store the version in your rule metadata and re-check the mapping whenever you upgrade. The ATT&CK updates page lists the release history you should review before each upgrade.

How do I close sub-technique coverage gaps for Office startup techniques?

Map each sub-technique to a detection strategy, a data source you actually collect, and a test you have run. Build a coverage table with one row per sub-technique, the telemetry it depends on, the logging configuration required, and the date the rule last passed a validation test. Gaps usually come from missing audit policy, unforwarded Sysmon events, or registry paths that were never added to the collection set. Prioritize sub-techniques that touch loaded content on every launch of a common application, because those carry the most risk in a regulated environment. Document accepted gaps with a named owner and a review date so auditors can see that the gap was a decision.

Is Office telemetry alone enough to detect this technique?

No. Office application logs show what the suite loaded, but they rarely show how the item was written to disk or who wrote it. Pair them with Process Creation, File Creation and Windows Registry Key Modification events from the endpoint, collected through a Sysmon configuration or native Windows auditing. Add file integrity monitoring on the Office startup and template locations, and correlate those events with network and identity logs when the change follows an unusual sign-in. Office telemetry is most useful for confirming what ran after a suspicious change, so plan for both sources before you write the first rule.

How do I retest detection rules after an Office update?

Treat every major Office build and every add-in update as a change that triggers regression testing. Keep a small set of benign test artifacts that mimic legitimate add-in and template activity, plus a set of simulated persistence events created in a private cyber range. After each update, replay both sets against your SIEM, confirm the expected alerts fire, and confirm the benign set stays quiet. Record the Office build number, the rule version, and the result in your change record. Confirm with Microsoft's release documentation which Office channels and builds apply to your estate, because the paths and default settings can change between releases.

How do I reduce alert fatigue from frequent template changes?

Reduce noise by separating expected change from unexpected change before the alert reaches an analyst. Maintain an allowlist keyed to signed publishers, approved deployment packages and known change windows, and expire entries on a schedule so they do not accumulate. Route alerts from user-profile locations differently from alerts on managed images, because the risk and the expected volume differ. Track the ratio of true positive to false positive alerts per rule each month, and tune or retire rules that generate work without findings. Ask your detection vendor or internal team to show the tuning history for each rule, because undocumented suppressions are a common audit finding.

Can my own team run this detection without an outside partner?

Often yes, if the team has endpoint logging, a SIEM with rule management, and someone who owns the ATT&CK mapping. The work splits into one-time setup (telemetry configuration, baseline capture, rule build, cyber range rehearsal) and recurring work (version reviews, Office update regression testing, alert tuning, and evidence collection). Cost depends mostly on the size of the estate, the number of Office builds in use, and how much of the stack is already logging. DeployOpen implements and tests open-source detection stacks inside the client's own environment under a written, fixed scope, and offers retainers for ongoing testing. Ask any provider to itemize setup, tuning and recurring support in the quote.

Where to confirm the ATT&CK mapping for T1137

Confirm the T1137 mapping against source data before you write or tune any rule. Start with the technique entry on the MITRE ATT&CK site, then open the enterprise-attack 20.0 STIX bundle, which MITRE publishes as one JSON file per domain and version. In that bundle, find the sub-techniques related to T1137 and count them. ATT&CK lists six sub-techniques under T1137, so a different count means your copy is out of step with the version you target. Then check the data components and mitigations linked to T1137, including Process Creation, File Creation, Windows Registry Key Modification, Disable or Remove Feature or Program and Update Software. Record the bundle file name and download date in your detection-as-code repository so an auditor or peer can reproduce the mapping.

Treat the mapping as versioned, not permanent. ATT&CK v18, released October 28, 2025, replaced detections in technique pages with detection strategies and analytics and changed data components, so rules written against older wording may reference guidance that no longer matches. Before each review cycle, check the ATT&CK updates pages for renames, deprecations or revocations affecting T1137 or its sub-techniques, including the v19 release of April 28, 2026 and the v20 release of October 13, 2026. Assign one owner for the mapping, and store the ATT&CK version in every rule's metadata so that a change in the update notes triggers a review instead of silent drift.

How DeployOpen builds T1137 detections and range scenarios

DeployOpen approaches T1137 Office application startup as a fixed-scope engagement inside the client's own environment, starting from the Office telemetry the organization already collects. The work covers detection logic, validation in a private cyber range, documentation and optional ongoing support.

How we scope

Confirm which Office applications, Windows builds and endpoint fleets fall inside the written scope for T1137 detections.
Inventory which telemetry sources exist today, including process creation, file creation and registry key modification events.
Agree in writing which T1137 sub-techniques are covered, and name the ATT&CK version the detection mapping targets.

How we build

Write detection logic for T1137 in open formats such as Sigma rules, mapped to the relevant data components and detection strategies.
Configure collection and parsing in the client's chosen open-source stack, such as Wazuh, Security Onion or Velociraptor, where the scope requires it.
Document each rule's logic, known false positives and the mitigations it supports, including Disable or Remove Feature or Program and Update Software.

How we hand over

Run the detections against scripted scenarios in a private cyber range to show which alerts fire and which do not.
Deliver rule files, test results, runbooks and response steps in a format the client's security operations team can maintain.
Walk the operations team through alert triage, tuning decisions and how to re-validate rules after an ATT&CK release changes the mapping.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, rule updates and continuous testing for T1137 are available as a retainer, to be quoted from the written scope.
Ask for a written quote that separates one-time build work from recurring support, testing and range time.

T1137 Office application startup