Registry Parser
← All articles

Microsoft Office forensics in the registry: File MRU and Trust Records

9 min read

Microsoft Office leaves two registry artifacts worth their place in almost every user-activity and malicious-document investigation: the Office MRU lists, which name the documents a user recently opened in each Office app and — unlike most MRU artifacts — carry a per-file last-opened timestamp baked into the value data, and the Office trust records, which name every document for which the user clicked "Enable Editing" or "Enable Content." For macro-enabled document forensics the second one is the artifact you reach for first: a trust record with the macro bit set is a near-direct statement that the user authorized macros to run in a specific file at a specific time. Both live in the per-user HKCU hive, so attribution is unambiguous, and both are trivially readable once you know the value formats. Neither is documented by Microsoft, so treat the field layouts as reverse-engineered conventions and hedge accordingly.

Office File MRU and Place MRU

The recently-opened lists live under the per-application Office key:

HKCU\Software\Microsoft\Office\<version>\<app>\File MRU
HKCU\Software\Microsoft\Office\<version>\<app>\Place MRU

<version> is the Office build number as a string — 16.0 for Office 2016 through Microsoft 365, 15.0 for 2013, 14.0 for 2010. <app> is the application name: Word, Excel, PowerPoint, and on systems where they keep MRUs, Access and Outlook. This parser walks exactly that set of apps and only descends into version keys whose name begins with a digit, which filters out the non-versioned policy and common keys that also sit under Microsoft\Office.

The split between the two lists is the useful part:

  • File MRU is the list of recently opened documents — the actual files. This is the one you care about for "what did this user open."
  • Place MRU is the list of recently used locations — folders, SharePoint/OneDrive sites, network shares. A Place MRU entry pointing at a SharePoint document library or a \\server\share UNC path places the user's Office session in that location even when no specific file from it survived in File MRU.

Each list holds numbered values (Item 1, Item 2, …) plus a Max Display value that sets how many entries the recent-files UI shows. Max Display is configuration, not activity; the parser skips it, and so should you.

The item format and the embedded FILETIME

This is what makes Office File MRU better than a plain recent-files list. Each Item value is a string with a small tagged prefix in front of the path:

[F00000000][T01D9F3A2B5C6E7F0][O00000000]*C:\Users\jdoe\Documents\Q3-forecast.xlsx

Read the bracketed tokens left to right:

  • [F........] — a flags field, typically F00000000. In practice it is usually all zeros; treat any non-zero value as worth a closer look rather than as a decoded fact.
  • [T................] — and this is the prize — a 16-hex-digit Windows FILETIME, big-endian as written, recording when the file was last opened in that app. Read the sixteen hex characters as a 64-bit integer (100-nanosecond intervals since 1601-01-01 UTC) and convert. 01D9F3A2B5C6E7F0 is well into the 2020s; the exact instant depends on the value, but the format is a standard FILETIME, not an Office-specific epoch.
  • [O........] — an offset/origin field, generally zero. Hedge: the precise meaning of the O token is not officially documented.

After the closing bracket of the tokens, a * separator precedes the full path. The path is a real absolute path — local drive, UNC, or a OneDrive/SharePoint URL — which is more than RecentDocs gives you, where the bare value is a display name rather than a guaranteed full path. See the RecentDocs and MRUListEx notes for that contrast.

So a single File MRU item gives you three things at once: the application (from the key path), the full path of the file, and a real per-file timestamp for the last open. That last point is the differentiator. Most registry MRU artifacts give you ordering plus one timestamp — the key's LastWrite, dating only the most-recent entry. Office File MRU embeds a timestamp in every item, so you can timeline the last-open time for each of the last N documents per app, not just the single most recent one.

A decoded set of File MRU rows looks like this:

App           List      Path                                          Last opened (UTC)
Excel 16.0    File MRU  C:\Users\jdoe\Documents\Q3-forecast.xlsx      2026-06-15 09:14:22
Excel 16.0    File MRU  \\fileserv\finance\budget-2026.xlsx           2026-06-11 16:02:08
Word 16.0     File MRU  C:\Users\jdoe\Downloads\invoice_8841.docm     2026-06-17 08:31:55
Word 16.0     Place MRU C:\Users\jdoe\Downloads\
PowerPoint 16.0 File MRU https://contoso-my.sharepoint.com/.../deck.pptx 2026-06-09 13:47:00

A current note on this parser: the Office File MRU plugin surfaces each item as its raw value string — app, list, and the full [F..][T..][O..]*path entry — rather than splitting the FILETIME into its own column. The timestamp is therefore present and readable in the output; you decode the [T....] token by hand. Do not assume the T token is always populated — entries written by some sync/cloud paths can carry a zeroed timestamp, in which case the item proves the file was in the list but not when it was last opened.

What File MRU proves: this user, in this Office app, opened a file at this path, most recently at the embedded time. Because it is in HKCU, the owning profile is the actor. What it does not prove: that the file still exists, that it was opened only once, or that the open happened on this host — roaming profiles and OneDrive Known Folder Move can carry MRU state between machines, so corroborate the host with a per-host artifact.

Office Trust Records: the maldoc artifact

When Office opens a document from an untrusted location — anything downloaded, mailed, or pulled off removable media gets the Mark-of-the-Web and opens in Protected View — the user sees the yellow bar and clicks Enable Editing or Enable Content. That click is recorded, per document:

HKCU\Software\Microsoft\Office\<version>\<app>\Security\Trusted Documents\TrustRecords

This parser walks that exact path for each Office app and version. Each value under TrustRecords is named for a document the user explicitly trusted — the value name is the document path, generally as a URI (file:///C:/Users/... and URL-encoded %5C%5Cserver%5C... UNC forms both appear). The presence of a value here is the assertion: this user deliberately dismissed Office's security boundary for this specific file.

The value data is a small binary structure carrying two things that turn "user trusted a file" into court-grade detail:

  • A FILETIME at the start of the record — when the trust decision was made. This is the moment the user clicked the button, typically the moment the document's active content was allowed to run.
  • A trailing flag — the last 4 bytes — distinguishing the level of trust. The widely-reported convention: a trailing 0xFFFFFFFF means the user enabled macros / active content ("Enable Content"), while a smaller value (commonly 0x01) means editing only (left Protected View). Treat the exact byte as a reverse-engineered convention, not a documented field, but the macro-vs-edit distinction is real and is the single most important bit in the record.

That flag is why TrustRecords is gold for phishing and maldoc cases. "Enable editing" means the user left the sandbox. "Enable content" with the macro flag set means the user authorized VBA to execute — on a malicious document, the exact instant of initial compromise. You get the file, the timestamp of the click, and a per-document yes/no on whether macros were turned on, all attributed to one profile.

A current note on this parser: the Office Trust Records plugin lists each trusted document — app, version, and the document name — and carries the note that these are documents where the user enabled macros/content. It surfaces the record (which document was trusted) directly; decoding the trailing macro flag and the trust FILETIME from the binary value data is the manual step you do on the raw value to separate "enabled editing" from "enabled macros." When you build a maldoc timeline, pull that flag — a TrustRecords entry without the macro distinction is half the artifact.

Investigative reading, in order:

  1. A .docm, .xlsm, .pptm, or an .xls/.doc with macros appears as a TrustRecords value with the macro flag set → the user enabled macros in a macro-capable document. Strong IOC.
  2. Cross the document path against Word/Excel File MRU to confirm the open and get the open-time, then against the trust FILETIME for the enable-time. The gap between them is the user reading the lure before clicking.
  3. The document path is typically in Downloads, a temp folder, or an Outlook attachment cache → arrival vector. Pivot to the [LNK files in Recent](https://www.lnkparser.com), to execution artifacts for any spawned process, and to email/proxy logs for delivery.

The high-value pattern: a macro-flagged TrustRecords entry for a document in \Downloads\ or \Temp\, with a File MRU open-time minutes before the trust-enable time, followed by child-process execution. That is the documented click-to-compromise sequence with attribution from the hive.

Tools

  • The parser on this site decodes both artifacts in its tree view: it enumerates Office MRU across Word/Excel/PowerPoint/Access/Outlook for every numbered Office version key, surfaces each File MRU and Place MRU item with its embedded [T....] FILETIME, and lists every document under Office trust records with the note that these are files where the user enabled macros/content — the core signal for macro-enabled document forensics. You can analyze a SOFTWARE hive in your browser, or the NTUSER.DAT for the per-user lists, with nothing uploaded.
  • RegRipper has oisc / Office-MRU-class and trust-record plugins that decode the FILETIME tokens and the trust flag in Perl. Read the plugin source to confirm exactly which fields each surfaces, and see the RegRipper plugins reference for where these sit in the artifact catalog.
  • Eric Zimmerman's RECmd with an Office batch file produces the same data in CSV for bulk timelining.

For the shell-driven recent-file lists that overlap these — RecentDocs and the common Open/Save dialog MRUs — see the RecentDocs plugin notes and the comdlg32 plugin notes. Office MRU sits apart: application-specific, and timestamped per item like neither of them.

The bottom line

Office File MRU answers "which documents did this user open in Word/Excel/PowerPoint, where were they, and — per file — when last." The embedded [T....] FILETIME is what lifts it above ordinary MRU artifacts: you get a real timestamp on every item, not just the most recent one. Office trust records answer the question that decides a maldoc case: "which documents did this user deliberately enable, and were macros among them." Decode the trust FILETIME and the macro flag, line the enable-time up against the File MRU open-time, and you have reconstructed the moment a user clicked through Office's last warning — with attribution, to the file, to the second. Read the tokens, respect the unofficial fields as conventions, and these two keys carry an investigation a long way.