T1137.002: Office Test
Adversaries may abuse the Microsoft Office "Office Test" Registry key to obtain persistence on a compromised system. An Office Test Registry location exists that allows a user to specify an arbitrary DLL that will be executed every time an Office application is started. This Registry key is thought to be used by Microsoft to load DLLs for testing and debugging purposes while developing Office applications. This Registry key is not created by default during an Office installation.CitationHexacorn Office TestCitationPalo Alto Office Test Sofacy
There exist user and global Registry keys for the Office Test feature, such as:
* HKEY_CURRENT_USER\Software\Microsoft\Office test\Special\Perf * HKEY_LOCAL_MACHINE\Software\Microsoft\Office test\Special\Perf
Adversaries may add this Registry key and specify a malicious DLL that will be executed whenever an Office application, such as Word or Excel, is started.
Security context for executives and security teams
Office Test is a Windows/Microsoft Office persistence technique where an adversary can cause Office applications such as Word or Excel to load a specified DLL when they start. The business issue is that this persistence may only activate when users open Office, so it can be missed by teams that focus only on common Run keys, services, or scheduled tasks. For organizations that rely heavily on Office, validating this behavior helps close a niche but material endpoint persistence blind spot.
Executive priority
Prioritize this as an endpoint resilience and audit-evidence question: can the organization prove it monitors unusual Office-related Registry persistence locations and DLL loading behavior? Because the relevant Office Test Registry keys are not created by default during Office installation, their presence can be a high-value review item for incident response, threat hunting, and control validation. This is especially relevant where Microsoft Office is widely deployed on Windows endpoints.
Technical view
This is a persistence sub-technique under Office Application Startup affecting Windows and Office Suite environments. Defenders should validate whether they collect and alert on creation or modification of the Office Test Registry paths under HKCU and HKLM, and whether endpoint telemetry can connect those keys to Office process startup and subsequent DLL loading. ATT&CK also links detection strategy DET0315, Detect Persistence via Office Test Registry DLL Injection, so detection engineering should use that relationship as a basis for coverage testing. ATT&CK records a relationship indicating APT28 has used this technique; treat that as threat-intelligence context, not as evidence of current activity in any environment.
Likely telemetry
- Windows Registry key creation and modification events for HKCU\Software\Microsoft\Office test\Special\Perf
- Windows Registry key creation and modification events for HKLM\Software\Microsoft\Office test\Special\Perf
- Office application process start events, such as Word or Excel starting on Windows endpoints
- DLL image-load telemetry associated with Office application processes
- Endpoint detection and response behavior telemetry for suspicious Office process, file, Registry, and API activity
Detection direction
- Confirm whether monitoring includes uncommon Office persistence Registry locations, not only standard startup folders, Run keys, services, or scheduled tasks.
- Tune detection around the fact that the Office Test key is not created by default during Office installation; its presence should be reviewed in local context.
- Correlate Registry value changes with later Office process startup and DLL loading to reduce weak single-event findings.
- Account for HKCU and HKLM scope separately, since user-level and global Registry locations are both described by ATT&CK.
- Use DET0315 as the ATT&CK-linked detection strategy reference, then validate coverage with environment-safe test data and approved change windows.
Mitigation priorities
- Apply endpoint behavior-prevention controls capable of blocking or flagging suspicious process, file, API, and Registry behavior, consistent with M1040.
- Review Office and endpoint software configuration settings for unnecessary or unsafe startup extensibility behavior, consistent with M1054.
- Restrict unauthorized Registry changes to sensitive Office-related persistence locations where operationally feasible.
- Include this key path in incident response persistence checks and endpoint hardening validation for Windows systems running Office.
- Document monitoring and control coverage as compliance or audit evidence where endpoint persistence monitoring is in scope.
Additional notes and limits
The most useful defensive question is whether the organization can see both sides of the behavior: the Registry persistence location and the Office process that later loads the referenced DLL. This technique can be easy to overlook because it uses an Office testing/debugging feature rather than a more common startup mechanism.
MITRE does not provide official detection text for this object. The take is based only on the supplied ATT&CK description, platforms, persistence tactic, external references, DET0315 detection relationship, M1040/M1054 mitigation relationships, the parent Office Application Startup technique, and the recorded APT28 use relationship. Local baselines are required to determine whether any observed Office Test Registry key is malicious, administrative, or benign.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Office Test
Adversaries may abuse the Microsoft Office "Office Test" Registry key to obtain persistence on a compromised system. An Office Test Registry location exists that allows a user to specify an arbitrary DLL that will be executed every time an Office application is started. This Registry key is thought to be used by Microsoft to load DLLs for testing and debugging purposes while developing Office applications. This Registry key is not created by default during an Office installation.CitationHexacorn Office TestCitationPalo Alto Office Test Sofacy
There exist user and global Registry keys for the Office Test feature, such as:
* HKEY_CURRENT_USER\Software\Microsoft\Office test\Special\Perf * HKEY_LOCAL_MACHINE\Software\Microsoft\Office test\Special\Perf
Adversaries may add this Registry key and specify a malicious DLL that will be executed whenever an Office application, such as Word or Excel, is started.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.