---
{
  "title": "Office Application Startup",
  "summary": "Office application startup mechanisms can trigger code when the application launches or specific features load.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1137"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1137: Office Application Startup",
      "url": "https://attack.mitre.org/techniques/T1137"
    }
  ],
  "editorialVersion": 2
}
---

## Application launch can trigger additional code

Office application startup abuse uses extensibility or startup-related features to execute unauthorized behavior when an Office application or relevant component starts. Legitimate templates, add-ins, and other integrations use these features to support ordinary work. Their presence alone is not evidence of compromise.

The investigator needs the specific feature, configuration, referenced artifact, creating identity, and runtime behavior. A general report that “Office started something” is too broad to establish the mechanism or scope.

## An add-in changes the launch sequence

At a fictional academy, a document application begins loading an unfamiliar add-in whenever a staff member opens it. The analyst reviews add-in registration, file provenance, installation history, relevant policy, and process or module-load evidence.

A recently approved productivity tool could explain the component. The team checks the owner, release source, expected permissions, and deployment scope. A familiar application hosting the add-in does not automatically make the add-in trustworthy.

Determine whether the component loads for one user, one device, or a broader managed population. A local registration and a centrally distributed configuration have different reach and recovery requirements.

## Separate registration, loading, and effects

A configured add-in shows an execution opportunity. Runtime evidence may establish loading, while additional records show file access, connections, or other actions. Keep those stages separate, especially if the component failed to load or was disabled by policy.

[[software-extensions]] describes the broader plugin trust model. [[template-injection]] concerns document template references and should not be assumed merely because an Office application is involved. [[persistence]] explains why behavior tied to routine application launches can survive the first process termination.

Preserve relevant configuration and artifacts before cleanup where practical. Unknown documents or components should be analyzed through an authorized isolated process rather than opened casually on a production device.

## Restore the intended application environment

Remove unauthorized registrations or components, review the authority that introduced them, and check for synchronized or centrally managed settings that could restore the change. Reinstalling the application may not address every user-profile or management configuration.

Coordinate with the application owner so legitimate templates and add-ins continue working. Verify startup behavior under the same conditions that previously triggered the suspicious action.

For practice, compare an approved teaching add-in with a fictional component installed by an unexplained process. Identify the registration, provenance, scope, load, and effect evidence needed for a decision. [[logs-and-telemetry]] supports the sequence, while [[incident-reporting]] distinguishes an installed component from confirmed unauthorized execution.

## Related concepts

- [[mitre-attack]]
- [[incident-response]]