Microsoft Office File MRU and Trust Artifacts: Reconstructing Document Access and Macro-Enabled Malware Infections

 

In digital forensic examinations of Windows systems, the operating system’s RecentDocs registry key (typically located at NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs) provides only limited visibility into user activity—primarily filenames organized by extension—while Microsoft Office maintains far richer, application-specific Most Recently Used (MRU) artifacts that significantly enhance timeline reconstruction and user intent attribution.

Each Office application (Word, Excel, PowerPoint, etc.) records detailed evidence of document interaction within dedicated registry structures under the user’s NTUSER.DAT hive. For contemporary deployments (Office 2016, 2019, 2021, and Microsoft 365), these reside predominantly under Software\Microsoft\Office\16.0\[Office Application]\File MRU. The versioning schema stabilized at 16.0 because these releases share a common codebase, with differentiation achieved primarily through subscription licensing, feature gating, and branding rather than architectural divergence.

When users authenticate with a personal Microsoft Account, Office isolates MRU data beneath identity-specific containers such as \User MRU\LiveID_[hex identifier]\File MRU. For enterprise environments leveraging Azure Active Directory (now Entra ID) or organizational accounts, entries are typically segmented under ADAL/OrgID-linked buckets. This compartmentalization aids forensic attribution by tying activity to specific cloud identities.

Value entries within File MRU follow a predictable nomenclature (Item 1, Item 2, …), with Item 1 representing the most recent interaction. Modern versions routinely preserve well over 100 entries, often extending further back in time than native Windows MRU mechanisms. Each value contains a structured string in the format [F00000000][T[64-bit FILETIME hex]][O00000000]*[full path], where the 8-byte Big-Endian hexadecimal timestamp immediately following the T marker encodes a precise Windows FILETIME (100-nanosecond intervals since 1601-01-01 UTC) corresponding to the last open/access event. This granular temporal metadata constitutes a substantial evidentiary advantage over the filename-only RecentDocs key.

Adjacent to File MRU resides the Place MRU key, which catalogs folder/path contexts associated with open/save operations. While frequently duplicative, Place MRU entries may update independently and prove valuable for reconstructing navigation patterns, network share access, or cloud storage interactions (e.g., OneDrive/SharePoint).

These artifacts frequently survive file deletion, persist across sessions, and reveal access to both local and remote resources. They enable strong correlation with complementary sources such as LNK files, Jump Lists, ShellBags, and Application Experience telemetry, supporting robust timelines of document-centric user activity. Analysts should systematically enumerate all Office version branches (10.0 [= Office XP], 11.0 [= Office 2003], 12.0 [= Office 2007], 14.0 [= Office 2010], 15.0 [= Office 2013], 16.0 [= Office 2016/2019/2021/M365]), User MRU subkeys, and associated LastWrite times on the parent keys for complete coverage.

Consider the following illustrative case drawn from a user’s NTUSER.DAT hive: the document located at C:\Users\Joseph\Documents\Attacking Active Directory With Linux.docx was accessed via Microsoft Office 2021 (version 16.0) Word. The corresponding File MRU entry encodes a high-fidelity temporal marker within its structured value data: 1DCFF27D04D0C30 represents a Big-Endian Windows FILETIME (64-bit value denoting 100-nanosecond intervals since 1601-01-01 UTC). Automated tools such as Registry Explorer’s Office MRU plugin perform this conversion natively, yielding 2026-06-18 13:38:57 UTC (note: precise validation against raw hex is recommended, as minor transcription variances can occur). This embedded timestamp reflects the last known open/access event for the specific document.

Unlike the filename-centric RecentDocs key maintained by the Windows Shell, each File MRU record furnishes the complete filesystem path (local, network, or cloud-synced), enabling precise attribution of user interaction with both extant and previously deleted or relocated artifacts. The presence of per-entry timestamps constitutes a notable exception in registry forensics—most MRU mechanisms rely solely on key LastWrite times—affording analysts granular, item-level chronology that significantly strengthens timeline reconstruction and corroboration with LNK files, Jump Lists, ShellBags, and Prefetch/Application Experience data.

Immediately subordinate or adjacent to the File MRU key lies the Place MRU structure, which enumerates folder and container paths associated with open/save dialogs. This key frequently retains historical path information for directories no longer represented in active File MRU entries—which is particularly useful when documents have been moved, renamed, or deleted. It can reveal navigation patterns to sensitive network shares, OneDrive/SharePoint libraries, removable media, or encrypted containers, providing additional context on user workflow and potential data exfiltration vectors.

Forensic practitioners should parse all relevant Office versions, User MRU identity containers (LiveID/ADAL/OrgID), and correlate parent key LastWrite timestamps. Automated parsers (Plaso, Registry Explorer, custom RegRipper plugins) streamline extraction while minimizing interpretation errors. These artifacts often persist beyond file system deletion and serve as high-confidence indicators of user knowledge and intent.

The Reading Locations registry structure—introduced with Office 2013 (version 15.0) and retained through all subsequent releases, including Microsoft 365—captures the user’s last known reading position within documents, implementing the “Pick up where you left off” functionality. This yields behavioral telemetry unavailable in most other registry MRU mechanisms.

The primary hive resides at NTUSER.DAT\Software\Microsoft\Office\<version>\Word\Reading Locations. The feature exists in PowerPoint (and potentially other apps), but forensic documentation and tool support (e.g., parsers) are most mature for Word. Fewer public details exist for full decoding in non-Word applications. Individual subkeys are sequentially named Document 0, Document 1, … (typically retaining up to approximately 50 distinct documents before older entries are culled). Each subkey contains the following high-value artifacts:

• File Path: The complete filesystem path (local, network share, or removable media) of the accessed document.
• Position: A partially decoded binary or string-encoded value representing the precise scroll/reading location at the time of closure. Current research indicates this comprises at least two space-separated integers: the first frequently mapping to a w14:paraId (paragraph identifier) within the document’s internal Open XML structure, and the second denoting a character offset or viewport position. Notably, this records the visible scroll position independent of cursor insertion point.
• DateTime: The timestamp of the document’s last closure, typically recorded in YYYY-MM-DDTHH:MM format using local system time. This datum is temporally complementary to the File MRU last-opened timestamp, enabling forensic reconstruction of approximate session duration and user engagement patterns.

These entries reliably document access originating from local drives, network shares, and removable media. However, documents opened directly from OneDrive (particularly those leveraging cloud-native synchronization) are frequently absent due to divergent handling by the Office desktop client. Synced files from alternative providers (e.g., Google Drive) are more likely to appear when resolved to local paths. While the underlying “continue reading” capability exists in PowerPoint and other Office applications, comprehensive forensic parsing and documentation remain most mature for Microsoft Word.

Registry Explorer’s Office MRU plugin automatically surfaces Reading Locations data, populating a dedicated LastClosed column alongside File MRU entries. Parent key and subkey LastWrite times further enrich temporal analysis.

The Position value, though not fully decoded in all scenarios, retains substantial evidentiary utility. When precise reconstruction of the user’s viewing state is material (e.g., in intellectual property, data breach, or insider threat investigations), analysts may employ the following validated method:

1. Export a pristine copy of the subject document.
2. On a forensic test system with a matching Office version, open the document to populate baseline Reading Locations data.
3. Modify the Position value in the test system’s registry to mirror the suspect system’s value.
4. Reopen the document; the application will advance to the historical scroll position.
5. Capture screenshots of the resulting view for inclusion in reports.

This technique leverages native Office behavior and can visually demonstrate the exact document state observed by the user. Correlation with File MRU, Place MRU, LNK files, Jump Lists, ShellBags, and file system MACB metadata is strongly recommended to construct comprehensive timelines. These artifacts frequently persist beyond deletion of the source documents and provide rare insight into user intent, knowledge, and engagement depth.

The TrustRecords registry keys represent a critical repository of user trust decisions, particularly relevant in malware, ransomware, and advanced persistent threat (APT) cases where malicious macros serve as a primary initial access vector. Families such as Locky, REvil (Sodinokibi), and Emotet have historically leveraged macro-enabled documents with exceptional success, prompting Microsoft to implement default blocking of macros in files bearing the Mark of the Web (MotW) Alternate Data Stream (Zone.Identifier) beginning in 2022.

The TrustRecords structure has existed since at least Office 2010 (version 14.0) and persists across subsequent versions, including 15.0, 16.0 (Office 2016/2019/2021/Microsoft 365). It is located under application-specific paths within the user’s NTUSER.DAT hive:

• Software\Microsoft\Office\<version>\Word\Security\Trusted Documents\TrustRecords
• Software\Microsoft\Office\<version>\Excel\Security\Trusted Documents\TrustRecords
• Software\Microsoft\Office\<version>\PowerPoint\Security\Trusted Documents\TrustRecords (and analogous keys for other supported applications).

When a user encounters Protected View and explicitly enables editing or content (macros), Office records the decision to suppress future prompts for that specific document. Each entry manifests as a REG_BINARY value whose name is the full filesystem path (local, removable media, network share, or Microsoft 365/OneDrive-synced locations). The binary data begins with an 8-byte Windows FILETIME timestamp (typically reflecting the file’s creation time or the trust event), followed by additional metadata, and terminates with four bytes indicating the trust level:

• 01 00 00 00 — User enabled editing.  
  
  
  
• FF FF FF 7F — User enabled macro/content execution (high forensic significance for malware attribution). 
  
  
  

This mechanism supports Windows’ protective check for previously trusted documents, resulting in a long-term archive often spanning hundreds of entries across multiple years. The persistence of these records—independent of file system deletion or relocation—makes TrustRecords exceptionally valuable for identifying suspicious documents, mapping user risk acceptance, and reconstructing infection chains.

Additional Analytical Details

• A LastPurgeTime value may exist at the parent Trusted Documents level, providing context on when the trust cache was last maintained.
• Entries frequently survive file deletion and correlate strongly with File MRU, Place MRU, LNK files, Jump Lists, ShellBags, and Prefetch data.
• In incident response and malware investigations, macro-enabled trust records (FF FF FF 7F) serve as high-confidence indicators of potential compromise, enabling targeted collection of associated documents for static/dynamic analysis, YARA scanning, and sandbox detonation.
• Tools such as Registry Explorer, RegRipper (trustrecords/msoffice plugins), Volatility, and custom PowerShell scripts automate parsing, timestamp decoding, and macro-flag identification.

Forensic examiners should enumerate all Office version branches (14.0+), cross-reference with MotW-tagged files in the file system, and integrate findings into broader timelines. These artifacts offer rare, explicit evidence of user interaction with potentially malicious content, supporting attribution, scope determination, and defensive hardening in enterprise environments where legacy macro-dependent workflows persist.

The directory %APPDATA%\Microsoft\Office\Recent (resolved as C:\Users\<username>\AppData\Roaming\Microsoft\Office\Recent) serves as a dedicated repository for automatically generated Windows Shortcut (LNK) files corresponding to documents and related resources accessed via Office applications, notably Microsoft Word.

Key Characteristics and Forensic Value

• LNK Generation: Each time a user opens a document (e.g., .docx, .doc, .rtf) through Word, Excel, PowerPoint, or associated Office components, the application triggers creation (or update) of a corresponding .LNK file in this folder. Filenames typically mirror the target document with its original extension appended (e.g., Report.docx.LNK or Attacking Active Directory With Linux.docx.LNK).
• Embedded Metadata: These LNK files contain rich Shell Link structures, including:
  • Full target path (local, network, or cloud-synced).
  • Timestamps (creation, modification, access) for both the LNK itself and the target file.
  • Volume serial number, machine ID, and NetBIOS name for attribution.
  • MAC addresses or other system identifiers in some cases.
  • File size, attributes, and working directory information.
• Image and Embedded Asset Tracking: Office applications frequently generate LNK entries for supporting resources such as embedded or inserted images (.jpg, .png, etc.), templates, or other media referenced during document editing. This occurs when images are loaded, previewed, or inserted via the Office UI, providing additional context on document composition and potential data staging.

Complementary Artifacts

• An index.dat file in the same directory often maintains configuration or MRU-like indexing for Office Recent items.
• These artifacts complement (and frequently overlap with) registry-based sources such as File MRU, Place MRU, Reading Locations, and TrustRecords, as well as the broader Windows Recent folder (%APPDATA%\Microsoft\Windows\Recent).
• Persistence: LNK files in this location can survive deletion or relocation of the original documents, offering long-term evidence of user activity spanning months or years.

Forensic practitioners should:

• Acquire and parse all *.LNK files in this directory using tools such as LECmd.
• Correlate LNK timestamps and target paths with File MRU timestamps, ShellBags, Jump Lists, Prefetch, and file system metadata.
• Recover deleted LNK entries via carving (signature 4C 00 00 00 01 14 02 00) when necessary.
• Pay particular attention to entries involving macro-enabled documents, network paths, or removable media in malware, insider threat, or IP theft investigations.

This location provides high-fidelity, application-specific visibility into document-centric workflows that is often more targeted than the general Windows Recent artifacts.

The dedicated OAlerts.evtx event log provides high-value visibility into dialog boxes, security warnings, and notifications explicitly presented to the user during Office application sessions.

• File Path: C:\Windows\System32\winevt\Logs\OAlerts.evtx
• Event Viewer Navigation:
  1. Open Event Viewer (eventvwr.msc).
  2. Navigate to Applications and Services Logs > Microsoft Office Alerts (or load the .evtx file directly).
• All events in this log typically share Event ID 300, with the critical intelligence residing in the event description fields (including the full text of the dialog, affected filename, application, and precise timestamp).

This log records a wide array of user-facing alerts, including but not limited to:

• Protected View warnings (e.g., files from the internet or untrusted locations).
• Macro/Content Enablement prompts and trust decisions (complementing the TrustRecords registry key).
• Unsaved Changes dialogs when abruptly closing documents (e.g., “Want to save your changes to [filename]?”).
• Security notices related to blocked active content, data connections, or policy tips.
• Outlook-specific actions such as emptying Deleted Items folders or other destructive operations.
• Other informational or warning dialogs displayed via the Message Bar or modal prompts.

Key Advantages:

• Timestamps are directly tied to the moment the alert was shown to the user, offering strong behavioral context.
• Captures intent and decision points (e.g., whether a user acknowledged a macro warning or Protected View prompt).
• Persists independently of document deletion and often spans significant time periods.
• Serves as excellent corroboration for registry artifacts (File MRU, TrustRecords, Reading Locations), LNK files in %APPDATA%\Roaming\Microsoft\Office\Recent, and file system metadata.

Forensic examiners should:

• Export and parse the full OAlerts.evtx using tools like Event Viewer, EvtxECmd, or full-spectrum parsers.
• Filter by time range, application (Word, Excel, etc.), and keyword searches within descriptions (e.g., macro, Protected View, save changes).
• Correlate events with TrustRecords (for macro enablement), File MRU timestamps, and LNK metadata to build robust timelines of user knowledge and actions.
• Pay special attention in malware, insider threat, or data exfiltration cases where macro-enabled documents or suspicious file handling occurred.

This artifact is frequently overlooked yet provides rare, direct insight into what the user actually saw and responded to within the Office suite. It is available on systems with Office 2010 and later versions.

The user-specific Startup directory at C:\Users\<username>\AppData\Roaming\Microsoft\Word\STARTUP constitutes a high-value location for identifying automatically loaded templates and add-ins upon Microsoft Word initialization. When Word launches, it automatically loads compatible files from this directory (in addition to the system-wide Startup folder under the Office installation path). Supported file types include:

• .dot (legacy Word Template)
• .dotx (Word Template without macros)
• .dotm (Word Template with macros enabled)

These templates can contain VBA macros, custom styles, AutoExec procedures, or other automation that execute with the privileges of the launching user, making this folder a classic persistence vector (MITRE ATT&CK T1137.001 – Office Template Macros). Adversaries frequently drop malicious .dotm files here to achieve execution on Word startup. This technique has been observed in targeted attacks and commodity malware campaigns. The folder also serves as an indicator of compromise when legitimate users or administrators install custom templates or add-ins.

• The location can be overridden via registry values such as HKCU\Software\Microsoft\Office\<version>\Word\Options\STARTUP-PATH or HKCU\Software\Microsoft\Office\<version>\Common\General\Startup, allowing adversaries to redirect loading to arbitrary directories (e.g., %TEMP%).
• Files in this folder are loaded globally (affecting all documents) unless scoped otherwise.
• Timestamps on the template files (creation, modification, access) and parent directory metadata provide temporal context for when persistence was established.
• Correlation opportunities exist with TrustRecords (macro enablement), File MRU, LNK files in %APPDATA%\Roaming\Microsoft\Office\Recent, and OAlerts.evtx (for related dialog activity).

Forensic analysts should:

• Enumerate and hash all files in both the user-specific and system-wide Startup folders.
• Perform static analysis on any .dotm files for VBA macros (using tools like olevba, olevba3, or sandbox detonation).
• Check registry keys controlling the Startup path for tampering.
• Cross-reference with Normal.dotm (in %APPDATA%\Roaming\Microsoft\Templates) and other Office autostart locations (e.g., XLSTART for Excel).
• Recover deleted files via carving or volume shadow copies, as malicious templates may be removed post-execution.

This artifact offers strong evidence of both legitimate customization and malicious persistence, particularly valuable in malware, insider threat, and APT investigations involving Office-based initial access or backdoors.

The VBAWarnings registry value under Group Policy-enforced paths provides critical insight into macro security posture and potential adversary tampering. The primary location is NTUSER.DAT\Software\Policies\Microsoft\Office\<version>\Word\Security\VBAWarnings (REG_DWORD). Analogous keys exist for other applications (Excel, PowerPoint, etc.) and under non-policy paths (Software\Microsoft\Office\<version>\Word\Security) when configured via the Trust Center UI.

Interpreted Values (forensic significance noted):

• 1 — Enable all macros (not recommended; highest risk). All macros, signed or unsigned, execute silently without warnings or prompts. This setting is a strong indicator of compromise in malware investigations, as adversaries frequently modify it (alongside AccessVBOM) to enable unrestricted macro execution.
• 2 — Disable all macros with notification (default/recommended in most secure environments). Displays the Trust Bar/Message Bar for user decision on macro-enabled documents.
• 3 — Disable all macros except digitally signed macros. Only trusted, signed macros from trusted publishers are permitted; unsigned macros are blocked silently or with limited notification.
• 4 — Disable all macros without notification. All macros are blocked outright, with no user prompts. This is among the most restrictive and secure configurations.

Forensic Context

• The Policies hive indicates enterprise Group Policy enforcement (often domain-controlled), while user-writable keys may reflect local tampering.
• Correlate with the companion AccessVBOM (Trust access to the VBA project object model) value, which, when set to 1, further lowers defenses by granting programmatic access to the VBA model.
• LastWrite timestamps on the parent Security key, combined with OAlerts.evtx entries and TrustRecords, help reconstruct when and how security settings were altered.
• In ransomware (e.g., REvil, Emotet) or APT campaigns, a change to value 1 is a high-confidence indicator of defense evasion (MITRE T1112) and macro-based execution.

Examination Recommendations

• Enumerate all Office version branches (14.0–16.0) across Word, Excel, and PowerPoint.
• Flag any VBAWarnings=1 or unexpected AccessVBOM=1 entries, especially if recently modified.
• Cross-reference with TrustRecords, File MRU, Startup templates, and %APPDATA%\Roaming\Microsoft\Office\Recent LNK files to map malicious document interactions.
• Tools such as Registry Explorer, RegRipper, and Elastic detection rules automate identification of these high-risk modifications.

These settings directly influence the efficacy of macro-based initial access and persistence techniques, making them essential artifacts in any Office-centric investigation.

In examinations of temporary and cache artifacts, the directory C:\Users\<username>\AppData\Local\Microsoft\Windows\INetCache\Content.Word) serves as a primary repository for Word’s internal scratch files and working copies during document processing. Microsoft Word generates temporary files in this location when handling documents, particularly macro-enabled files (.docm, .dotm), complex .docx files, or documents opened from untrusted sources (Protected View). Common file patterns include:

• WRCxxxx.tmp (Word Recovery Cache or working cache files)
• Other temporary files with .tmp or auto-generated naming

These scratch files often contain:

• Fragments of the original document content (text, embedded objects, images, tables).
• VBA macro source code (especially valuable in malware investigations).
• Metadata, revision history, or undo information.
• Remnants of deleted or modified content that may no longer exist in the primary document.
• OLE objects and embedded file streams.

Key Advantages in Investigations

• These files frequently persist even after the original document is closed, deleted, or overwritten.
• They can survive user attempts to clear Office caches and are especially useful when the source document has been sanitized or removed.
• In malware cases involving malicious macros (Emotet, REvil, etc.), WRC*.tmp files may contain unobfuscated macro code or dropped payloads.
• Timestamps (creation/modification) on these temporary files provide precise indicators of document interaction sessions.

Complementary Locations

• C:\Users\<username>\AppData\Local\Microsoft\Office\16.0\Word\ (and version-specific subfolders) – additional cache and AutoRecovery files.
• %APPDATA%\Roaming\Microsoft\Word\ – supporting files and templates.
• Temporary Internet Files / INetCache subfolders for documents opened from web/OneDrive sources.

Examination Recommendations

• Recursively list and analyze all *.tmp files, with emphasis on WRC*.tmp entries.
• Use tools such as strings, bulk_extractor, olevba, or hex viewers to extract readable text, VBA code, and embedded artifacts from these files.
• Carve for OLE structures or ZIP-compressed Office XML content within the temp files.
• Correlate timestamps and content with File MRU, TrustRecords, Reading Locations, %APPDATA%\Roaming\Microsoft\Office\Recent\*.LNK files, OAlerts.evtx, and Startup templates.
• Recover deleted temporary files via file system carving (signatures for Word temp files) or Volume Shadow Copies.

These cache artifacts frequently yield high evidentiary value in intellectual property theft, insider threat, data exfiltration, and malware investigations by revealing document content and user activity that would otherwise be unavailable. They should be collected systematically during live response or full disk imaging.

In digital forensic examinations of email-borne threats and Microsoft Office interactions, the Outlook Secure Temporary Folder (also known as the attachment cache) at %LocalAppData%\Microsoft\Windows\INetCache\Content.Outlook\<random alphanumeric subfolder>\ (typically C:\Users\<username>\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\XXXXXXXX\) is a critical location for recovering documents opened directly from email messages.

When a user double-clicks or opens a Microsoft Word attachment (.doc, .docx, .docm, etc.) from within Outlook, the application extracts a working copy of the file into this randomly named subfolder to facilitate safe handling in Protected View or the full editor. This behavior is especially relevant in malware investigations, as malicious macro-enabled documents (.docm) delivered via spear-phishing emails are a longstanding initial access vector.

Key artifacts commonly found

• Full or partial copies of the original attachment, preserving original filenames where possible (or renamed with numeric suffixes like (2) on subsequent openings of similarly named files).
• Macro-laden Word documents, including embedded VBA code that may have executed upon enablement.
• Timestamps (creation, modification, access) on the cached files, which closely correlate with the time the attachment was opened.
• Remnants of documents even after the user closes Outlook or deletes the email, as cleanup is not always immediate or complete (particularly if the attachment remains open or Outlook crashes).

The exact path is dynamically stored in the registry under NTUSER.DAT\Software\Microsoft\Office\\Outlook\Security\OutlookSecureTempFolder (REG_SZ value). This key should always be consulted to identify active or historical cache folders.

Additional Analytical Value

• Malware Context: In campaigns involving Emotet, REvil, or other macro-based ransomware, these temporary copies often contain unobfuscated malicious code suitable for static analysis or sandbox detonation.
• Persistence of Evidence: Files may survive email deletion, user cleanup attempts, or even partial system wiping, and can be recovered via carving, Volume Shadow Copies, $USN Journal, or $LogFile analysis.
• Newer Outlook Behavior: In modern Microsoft 365/Outlook clients (including WebView2-based components), attachments may also appear in Chromium-style caches under %LocalAppData%\Microsoft\Olk\, but the classic Content.Outlook path remains highly relevant for desktop attachment handling.

Examination Recommendations

• Enumerate all subfolders under Content.Outlook and analyze files with Office-specific tools (olevba for macros, Registry Explorer for correlation).
• Cross-reference with OAlerts.evtx (Protected View / macro prompts), TrustRecords, File MRU, %APPDATA%\Microsoft\Office\Recent\*.LNK, and email metadata in OST/PST files.
• Recover deleted temporary files aggressively, as adversaries often rely on users opening attachments without saving them permanently.

This artifact provides direct, high-fidelity evidence of email-based document interaction and is indispensable in phishing, malware, and insider threat investigations involving Office attachments.