Registry Parser
← All articles

Application MRUs: Adobe, 7-Zip, WinRAR and MMC history in the registry

7 min read

Most file-access investigation in the user's NTUSER.DAT registry hive starts and stops at the shell artifacts: RecentDocs, comdlg32, the Recent jump lists. That is a mistake, because the shell only sees files opened through Explorer. The moment a user opens a PDF from inside Acrobat's own File menu, extracts an archive from the 7-Zip file manager, or feeds a path straight to WinRAR, the file may never touch a shell MRU. But it almost always lands in the application's own MRU — its private list of recently used files, kept in its own HKCU\Software subkey. These per-application MRUs are a rich, under-used source of file-access evidence, and the single most productive habit you can build for NTUSER analysis is to enumerate the per-application Software subkeys, not just the Microsoft ones.

This post walks four concrete examples that this parser decodes — Adobe Reader, 7-Zip, WinRAR, and MMC — straight from the plugin code, and then draws the general lesson.

Why application MRUs catch what RecentDocs misses

A program writes an MRU because it wants a "recent files" submenu, a path drop-down, or a remembered last-used folder. That bookkeeping is incidental to the user's task, which is exactly what makes it good evidence: nobody is curating it. And critically, an application populates its MRU from its own code path. A double-click in Explorer goes through the shell and lands in RecentDocs. A File > Open inside Acrobat goes through Acrobat and lands in cRecentFiles — and may never appear in RecentDocs at all. The overlap is partial and the gaps are informative: a file in the application MRU but not in RecentDocs tells you how the file was reached.

The other reason these are valuable: archivers. WinRAR and 7-Zip history answers a question RecentDocs cannot — "what did this user compress or extract" — which is the core of data-theft and exfil-staging investigations.

Adobe Reader / Acrobat: cRecentFiles

The Adobe MRU lives under, per product and version:

HKCU\Software\Adobe\<product>\<version>\AVGeneral\cRecentFiles

This parser's adoberdr plugin does not hardcode a product or version. It enumerates every subkey under Software\Adobe, then every version subkey under each product, then walks AVGeneral\cRecentFiles. That matters operationally: you will see Acrobat Reader, Adobe Acrobat, and multiple version numbers side by side, and the plugin surfaces all of them rather than guessing at one path. Under cRecentFiles is a series of numbered slot subkeys (c1, c2, …), and the actual filename lives in each slot's tDIText value. The plugin reads tDIText per slot and emits a row of Product/version, Slot, Recent file:

Product                Slot   Recent file
Acrobat Reader 11.0    c1     /C/Users/jdoe/Documents/severance-agreement.pdf
Acrobat Reader 11.0    c2     /C/Users/jdoe/Downloads/2025-cap-table.pdf
Acrobat Reader 11.0    c3     /D/exfil/board-minutes.pdf

Two things to flag. First, Adobe stores paths in its own forward-slash, drive-letter-as-folder notation (/C/Users/...), not a normal Windows path; do not be thrown by it, and normalize before you correlate. Second, what this proves: the named PDF was opened in Acrobat/Reader by the user who owns the hive. That is file access with clean attribution, and the slot ordering (c1 newest) gives you relative recency. It does not, on its own, give a reliable per-file timestamp — the key LastWrite dates only the most recent change, the same single-timestamp limit you live with in RecentDocs. Hedge accordingly.

7-Zip: panel, compression, and extraction history

7-Zip spreads its history across three subkeys under HKCU\Software\7-Zip, and this parser's sevenzip plugin pulls one value from each:

  • Software\7-Zip\FM → PanelPath0: the last folder shown in the 7-Zip File Manager panel.
  • Software\7-Zip\Compression → ArcHistory: archive history — what was compressed.
  • Software\7-Zip\Extraction → PathHistory: extraction destination history — where archives were unpacked.

The plugin output is a simple Setting/Value table, dropping any of the three that is empty:

Setting               Value
FM panel path         C:\Users\jdoe\Desktop\client-data
Compression history   C:\Users\jdoe\Desktop\client-data\export.7z
Extraction history    C:\Users\jdoe\AppData\Local\Temp\unpacked

Note that ArcHistory and PathHistory are multi-string-style history values: in practice they can hold more than one path, newest first, so treat the raw value as a list to split rather than a single string. This parser surfaces the raw value; expect to break it into individual paths yourself.

For an exfil investigation this is gold. Compression history is a direct answer to "did this user package data for removal," and the panel path plus extraction history tell you which folders they were staging from and unpacking into. A .7z named after a customer dataset in the compression history, with a panel path pointing at a share, is a sentence you can write in a report.

WinRAR: ArcHistory

WinRAR's archive history is the simplest of the four:

HKCU\Software\WinRAR\ArcHistory

The winrar_history plugin reads the values directly off that key and emits Slot/Archive rows — the value name and its string value, one per archive WinRAR has recently touched:

Slot   Archive
0      C:\Users\jdoe\Desktop\handover\source-code.rar
1      \\fileserver\finance\Q2.rar
2      E:\backup\photos.zip

This is the same exfil-staging signal as 7-Zip's compression history, from the other dominant archiver. WinRAR is heavily favored by both legitimate users and intruders for packaging data before removal, so ArcHistory is a high-value enumeration target on any insider or intrusion case. As with the others, the value ordering gives recency and the key LastWrite dates only the most recent change — read it as "these archives were handled by this user," not as a timestamped log.

(WinRAR also keeps an extraction-path history under DialogEditHistory in some versions; this parser's plugin reads ArcHistory specifically, so check the sibling subkeys by hand if you need extraction destinations as well.)

MMC: recent snap-ins

The odd one out, and a favorite of mine for the admin-activity angle:

HKCU\Software\Microsoft\Microsoft Management Console\Recent File List

The mmc plugin reads that key's values, filters to names matching File1, File2, … (the standard recent-file naming), and prints each value — the path to a recently opened .msc snap-in:

Entry   Snap-in (.msc)
File1   C:\Windows\System32\dsa.msc
File2   C:\Windows\System32\gpedit.msc
File3   C:\Windows\System32\compmgmt.msc

This is not user-data file access; it is an admin-tool usage history. dsa.msc is Active Directory Users and Computers, gpedit.msc is the Group Policy editor, lusrmgr.msc is local users and groups. A profile with these in its MMC recent list was doing directory or policy administration from this console — useful for establishing who held the keys, and for spotting a standard user account that suddenly opened administrative snap-ins. The Recent File List is a generic MFC MRU pattern; you will see the same File1/File2 shape in plenty of older applications, so the filter the plugin applies is the right way to read any of them.

The general lesson: enumerate the Software subkeys

The four above are the ones this parser decodes out of the box, but the pattern is everywhere. Office keeps recent-file and recent-folder MRUs per app. Media players, IDEs, FTP clients, image editors, PDF tools, and CAD packages all keep their own. The keys are not standardized — cRecentFiles\<slot>\tDIText for Adobe, three separate subkeys for 7-Zip, a flat ArcHistory for WinRAR, an MFC File1..n list for MMC — which is precisely why a generic shell-artifact-only workflow misses them.

So the habit: when you load an NTUSER.DAT, do not stop at the Microsoft tree. Walk HKCU\Software top to bottom and treat every third-party vendor subkey as a potential MRU. For each application that mattered to the case, look for anything named Recent, History, MRU, LastUsed, RecentFiles, or per-slot numbered subkeys. The decode is usually trivial — a string value or a numbered series — and the payoff is file-access evidence that the shell never recorded.

Two consistent caveats to carry into every one of these:

  • Timestamps are weak. Application MRUs almost never carry per-entry times. You get ordering from the slot numbering and exactly one anchor from the key's LastWrite. Pivot to LNK files in Recent\, Prefetch, and the MFT for real timing.
  • Paths are vendor-formatted. Adobe's /C/... notation, UNC paths in archiver history, and shell-folder references all need normalizing before correlation. Read what the application stored, not what you expect.

Tools

  • This browser-based registry parser decodes all four MRUs above as dedicated plugins (adoberdr, sevenzip, winrar_history, mmc) in its tree view, reading the exact values described here. You can analyze NTUSER.DAT in your browser with nothing uploaded.
  • RegRipper ships adoberdr, sevenzip, winrar, and related per-application MRU plugins; see the RegRipper plugins reference for the full catalog and how application MRUs sit alongside the shell artifacts.
  • Eric Zimmerman's RECmd with custom batch files will pull arbitrary Software subkeys to CSV — the right tool when you have found a vendor MRU that no canned plugin covers.

The bottom line

RecentDocs and the shell MRUs are the front door, but applications keep their own books. Adobe's cRecentFiles, 7-Zip's compression/extraction/panel history, WinRAR's ArcHistory, and MMC's Recent File List each record file access — or, for the archivers, file packaging — that the shell artifacts can miss entirely. The archiver histories in particular are the cleanest registry answer to "what did they stage for exfil." Enumerate the per-application Software subkeys on every NTUSER you touch, respect the weak-timestamp limit, and you will routinely surface file-access evidence the shell-only workflow walks right past.