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.[1][2]
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.
Analyst 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.
Analyst 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.
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.[1][2]
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1137 | Office Application Startup | This object subtechnique of Office Application Startup. |
Groups, software, and campaigns
G0007: APT28
APT28 is a threat group that has been attributed to Russia's General Staff Main Intelligence Directorate (GRU) 85th Main Special Service Center (GTsSS) military unit 26165.[1][2] This group has been active since at least 2004.[3][4][5][6][7][8][9][10][11][12][13]
APT28 reportedly compromised the Hillary Clinton campaign, the Democratic National Committee, and the Democratic Congressional Campaign Committee in 2016 in an attempt to interfere with the U.S. presidential election.[5] In 2018, the US indicted five GRU Unit 26165 officers associated with APT28 for cyber operations (including close-access operations) conducted between 2014 and 2018 against the World Anti-Doping Agency (WADA), the US Anti-Doping Agency, a US nuclear facility, the Organization for the Prohibition of Chemical Weapons (OPCW), the Spiez Swiss Chemicals Laboratory, and other organizations.[14] Some of these were conducted with the assistance of GRU Unit 74455, which is also referred to as Sandworm Team.
All related ATT&CK context
Mitigation direction
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.3 | Current bundle | 6793ae55225d… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Hexacorn Office Test
Hexacorn. (2014, April 16). Beyond good ol’ Run key, Part 10. Retrieved July 3, 2017.
Open source URL -
[2]
Palo Alto Office Test Sofacy
Falcone, R. (2016, July 20). Technical Walkthrough: Office Test Persistence Method Used In Recent Sofacy Attacks. Retrieved July 3, 2017.
Open source URL -
[3]
mitre-attack T1137.002Open source URL
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.