Microsoft introduced Jump Lists in the Windows 7 desktop operating system as a mechanism to enhance user interaction efficiency by presenting dynamic lists of recently accessed files, directories, and application-specific tasks. These structures are instantiated across the majority of modern applications, affording rapid access to documents, web resources, Remote Desktop Protocol (RDP) connections, and contextual tasks such as initiating Incognito sessions, creating compressed archives, or launching virtual machines.
From a digital forensics perspective, the advent of Jump Lists represented a significant evolution in the recovery of user activity artifacts. Before their introduction, forensic examiners were largely reliant on Windows Registry keys—principally the Most Recently Used (MRU) and Most Frequently Used (MFU) entries—to reconstruct user behavior. In contrast, Jump List data files constitute substantially richer and more probative sources of evidentiary information. These artifacts enable the extraction of comprehensive metadata, including MRU and MFU sequences for both users and applications; full file paths; logical file names; Modified/Accessed/Created (MAC) timestamps; originating volume names and serial numbers; as well as unique volume and object identifiers. Notably, such records frequently persist in an intact state even after the deletion or removal of the associated files and hosting applications.
Jump Lists are maintained on a per-application basis through AutomaticDestinations and CustomDestinations files, each keyed by a unique Application ID (AppID). However, not all executables generate Jump Lists; native system utilities such as Regedit, Command Prompt, and the Run dialog, among others, typically do not produce these artifacts.
Forensically, Jump Lists represent an exceptionally robust repository for reconstructing user interaction history. While overlapping data may reside in artifacts such as the Registry’s RecentDocs key or LNK files within the Recent folder, Jump Lists frequently preserve significantly greater depth and temporal coverage. Each entry within a Jump List encapsulates a structured shell item equivalent to a full LNK file, thereby providing an extensive array of metadata identical to that recoverable from traditional shortcut files. Furthermore, consistent with LNK behavior, references to deleted, overwritten, or wiped items are not purged from Jump List records, creating a valuable forensic opportunity to identify historical artifacts long absent from the active filesystem. In high-volume usage scenarios, a single application may yield hundreds or even thousands of embedded LNK-equivalent entries.
By default, Jump Lists are enabled for all user accounts. They may be disabled via the Control Panel through Personalization → Start → "Show recently opened items in Jump Lists on Start or the taskbar". Activation of this setting not only disables future population but also clears the contents of both Automatic and Custom Jump Lists, thereby impacting the preservation of potentially critical evidentiary material.
Windows Jump Lists are fundamentally composed of two distinct categories: Destinations and Tasks. These elements are primarily defined and implemented by the application developer, reflecting both user-specific activity and application-wide functionality.
In their default configuration, Jump Lists typically expose the most recently accessed or frequently used items (such as documents, media files, or other content) alongside standard tasks, including pinning the application to the taskbar, launching the executable, and closing all associated windows. Additional or customized functionality beyond these automatic entries is achieved through Custom Jump Lists, which allow developers to expose application-specific actions. As defined in the Windows Software Development Kit (SDK):
"...Destinations are items that appear in the Recent, Frequent, or custom categories, based on an individual’s usage. Destinations can be files, folders, websites, or other content-based items, but are not necessarily file-backed. Destinations can be thought of as things or nouns. Destinations can be pinned or removed from the Jump List by the user."
"...Tasks are common actions performed in an application that apply to all users of that application regardless of an individual’s usage patterns. Tasks can be thought of as actions or verbs. Tasks cannot be pinned or removed."
From a forensic standpoint, two primary Jump List structures facilitate this functionality:
- AutomaticDestinations: Generated automatically by the Windows operating system for each application based on user interaction patterns.
- CustomDestinations: Explicitly created and populated according to developer-defined logic and application-specific features.
Both Automatic and Custom Jump List files are stored within the user’s Recent folder (C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Recent\), the same directory that houses traditional LNK shortcut files, under the subfolders AutomaticDestinations and CustomDestinations. Each file is identified by a unique Application Identifier (AppID). Automatic and Custom Jump Lists are stored in different formats and hence hold different information.
Automatic Jump Lists
Automatic Jump Lists constitute the most forensically significant component of the Jump List ecosystem. They consistently yield a greater volume of entries, contain substantially richer metadata, and preserve a more comprehensive set of user activity artifacts compared to their Custom counterparts.
These files are stored in the Microsoft Object Linking and Embedding (OLE) Compound File Binary (CFB) format—also referred to as "Structured Storage"—and bear the .automaticDestinations-ms file extension. AutomaticDestinations files contain two primary categories of streams that are of critical importance to forensic examiners: SHLLINK streams and the DestList stream.
Multiple SHLLINK streams may exist within a single AutomaticDestinations file. Each of these streams mirrors the binary structure of a standard Windows Shortcut (LNK) file, encapsulating rich metadata such as full target paths, file sizes, MAC timestamps, volume serial numbers, and object identifiers. In contrast, the DestList stream possesses a specialized structure unique to Jump Lists. This stream is of particular forensic value because it records the chronological ordering of accessed destinations—effectively functioning as a Most Recently Used (MRU) list—along with access frequency counts that serve as a Most Frequently Used (MFU) list for the associated application as well as the last recorded interaction timestamp (Last Modified time) for each destination.
The header of the DestList stream maintains a fixed length of 32 bytes across all Windows versions. However, forensic practitioners must exercise caution when parsing this structure, as the semantic interpretation and layout of individual fields within the DestList header vary significantly between different Windows distributions and versions (e.g., Windows 7, 8, 10, and 11). These version-specific differences can impact the accurate reconstruction of temporal sequences and usage patterns.
Although the precise retention algorithms vary across applications and remain partially undocumented, empirical testing indicates that Automatic Jump Lists can retain up to approximately 2,000 entries per application. Even a modest subset of this capacity constitutes a substantial, highly probative repository of historical user activity, often extending far beyond the temporal and quantitative scope of traditional artifacts such as Registry MRU keys or standalone LNK files.
Custom Jump List
Custom Jump Lists are stored in a significantly simpler binary format compared to their Automatic counterparts. They consist of a sequential concatenation of MS-SHLLINK binary format segments, utilizing the .customDestinations-ms file extension. The file begins with a minimal header, followed directly by a series of complete LNK objects appended one after another.
Unlike Automatic Jump Lists, Custom Jump Lists lack a directory structure and dedicated streams such as DestList. Consequently, they do not preserve supplementary metadata, including MRU ordering or additional timestamps beyond those embedded in the individual LNK files. All forensically relevant information recoverable from Custom Jump Lists resides exclusively within the constituent LNK structures—one per entry—which explains their comparatively limited informational depth.
Nevertheless, Custom Jump Lists frequently contain high evidentiary value, particularly in revealing user-intentional activity. Common artifacts include pinned/favorited items, recently closed tabs, most-visited web pages, cloud-stored files, and data associated with multiple browser profiles. Examiners should pay particular attention to the Arguments field, which often encapsulates exotic or application-specific data not present in the Target ID Absolute Path. The Entry Name field may also provide valuable contextual insight into the nature of the recorded activity.
Due to the inherently bespoke and developer-driven nature of Custom Jump Lists, forensic examiners must exercise heightened caution when drawing temporal inferences from their timestamps. Unlike AutomaticDestinations files, the population and modification of data within Custom Jump Lists are predominantly application-dependent, with the operating system exerting limited direct control over their creation and updating logic. Consequently, the creation and last-modified timestamps of .customDestinations-ms files are governed by application-specific behaviors rather than standardized Windows mechanisms. Certain user actions may trigger the creation or modification of these files, yet the precise conditions vary significantly across applications. Application-specific testing and validation are therefore essential to reliably interpret the temporal metadata associated with each Custom Jump List database.
Forensically, analysts should approach temporal data in Custom Jump Lists with particular scrutiny. These lists are not invariably instantiated upon first execution of the application, thereby diminishing the investigative value of the file creation timestamp relative to AutomaticDestinations files. Moreover, LNK target timestamps embedded within Custom Jump Lists frequently reference the host application’s executable rather than the accessed artifact (e.g., a document, media file, or webpage). This pattern is both common and expected in certain contexts, such as browser-related entries, where timestamps correspond to the browser executable itself. In cases of ambiguity, examiners are strongly advised to cross-reference target timestamps against full path information, Entry Name fields, Arguments fields, and corroborating artifacts from other system sources.
Custom Jump Lists consist fundamentally of concatenated MS-SHLLINK (LNK) structures. As such, an earlier forensic analysis technique involved directing file carvers at the CustomDestinations folder and applying the standard LNK file header signature (0x4C 0x00 0x00 0x00 0x01 0x14 0x02 0x00) to extract individual shortcut objects, which were subsequently parsed for embedded metadata. Although this carving methodology proved reasonably effective for artifact recovery, modern digital forensic practice has largely transitioned to specialized parsing tools (Eric Zimmerman's JLECmd, TZWorks jmp, Jumplist-Browser, Magnet AXIOM, and others) that provide more comprehensive, structured, and efficient extraction and interpretation of data from these files.
Jump List configuration files are identified by a hexadecimal filename, typically consisting of 16 digits, appended with either the .automaticDestinations-ms or .customDestinations-ms extension. This hexadecimal prefix represents the unique Application Identifier (AppID) associated with the specific executable or application that generated the Jump List.
Although nomenclature based on application names would have greatly simplified forensic analysis, Windows Jump Lists instead identify each file through a unique hexadecimal Application Identifier (AppID). The AppID is computed by the Windows operating system using a CRC-64 checksum based on the file path of the application. An application that is executed from two different locations has two different AppIDs associated with the application. This design prevents conflicts between similar applications within the same software family (e.g., Microsoft Word 2013 versus Microsoft Word 365) and ensures that each application maintains a consistent, system-independent AppID across all Windows installations.
Consequently, the existence of well-maintained AppID lookup tables is of considerable value to examiners. Public repositories, most notably the configuration database maintained by Eric Zimmerman’s JLECmd tool, provide extensive mappings. For undocumented applications, examiners may conduct targeted research or perform controlled installations on a test system to determine the corresponding AppID. From a forensic perspective, accurate identification and mapping of these AppIDs is essential, as they enable examiners to attribute the contained artifacts to the responsible application.
A frequently overlooked yet highly probative aspect of Jump List analysis is that the mere presence of a Jump List file constitutes strong evidence that a specific application was installed and executed on the subject system. These artifacts often persist even after the application has been uninstalled or removed. For AutomaticDestinations files, the creation timestamp typically corresponds to the first time the application opened an item, while the last modification timestamp reflects the most recent such interaction. Temporal interpretation of CustomDestinations files is more challenging due to their application-driven update logic, but they nonetheless provide a reliable indicator of the time window during which the application was present on the system.
The AppID generation algorithm is identical for both Automatic and Custom Jump Lists. Therefore, once an AppID of interest is identified in the AutomaticDestinations folder, examiners can readily determine whether a corresponding CustomDestinations file exists. In general, the CustomDestinations folder contains significantly fewer files, as Custom Jump Lists are optional and not implemented by all applications. AppIDs found in CustomDestinations are typically a subset of those present in AutomaticDestinations; however, exceptions do occur. A notable example is the CCleaner application, which commonly generates a Custom Jump List without a corresponding AutomaticDestinations file. This underscores the necessity of examining both folders for a comprehensive forensic review.
While AppID values can be manually cross-referenced against public lists, JLECmd (by Eric Zimmerman) automates this process and maintains an actively updated database. The tool attempts to resolve each AppID to its associated application name and details. When an “Unknown AppID” is returned, it becomes the examiner’s responsibility to assess relevance. Contextual analysis of the Jump List contents often enables reliable attribution—for instance, a predominance of .pptx files strongly suggests Microsoft PowerPoint. In contrast, image file formats indicate an image viewer or editor. This inference is valid because an application must be registered as a handler for a given file type (though not necessarily the default handler) for such items to appear in its Jump List.
Although the command-line version of JLECmd is most commonly used in casework, a GUI variant, JumpList Explorer, is also available. The graphical interface is particularly useful for training, visualization of internal structures, and detailed manual review. Both tools are freely available as part of the Zimmerman Tool Suite.
The above example illustrates typical output from JLECmd when parsing a single Automatic Jump List. The tool first identifies the associated Application Identifier (AppID) and provides a resolved description—in this instance, mapping the identifier to Windows “Quick Access.” As previously noted, examiners may occasionally encounter an “Unknown AppID,” in which case attribution must be inferred through contextual analysis of the embedded destinations.
Because this is an Automatic Jump List, JLECmd also extracts and displays key metadata from the DestList stream, including the expected number of entries versus the actual number recovered. Such discrepancies serve as important indicators of potential data corruption, incomplete records, or structural anomalies. Additional mismatches between the DestList and the underlying directory entries will trigger warnings, along with guidance for recovering any orphaned shell items. The DestList version field, while rarely of direct investigative interest, is noteworthy as it reflects evolutionary changes in Jump List data structures since their introduction in Windows 7. This necessitates periodic updates to parsing tools such as JLECmd to maintain compatibility with newer Windows versions.
For each entry in the DestList, JLECmd enumerates critical details, including the entry index (reflecting MRU ordering), full path, creation time, last modified time, hostname, and system MAC address. Forensic practitioners must understand the nuances of these timestamps. The Created time corresponds to the “Birth DROID” (Distributed Record Object Identifier) value maintained by the Windows Link Tracking Service. This timestamp is generally of limited evidentiary value, as it frequently reflects the system boot time during the session in which the object was first referenced rather than the actual creation time of the target file. In most cases, it can be safely deprioritized in favor of the far more relevant MAC timestamps contained within the embedded LNK shell items. Conversely, the Last Modified time in the DestList is highly significant, as it records the most recent time the item was accessed (or visited, in the case of browser Jump Lists). By correlating these timestamps across entries, examiners can reconstruct the precise chronological sequence of user interactions. Newer implementations of Automatic Jump Lists also include an Interaction Count value, which appears to increment upon item access, although further validation across diverse applications and file types is recommended.
Given the substantial volume of data often present in Jump Lists, JLECmd defaults to displaying only DestList metadata when parsing individual files. To extract comprehensive shell item (LNK) information—including target MAC timestamps, file size, attributes, absolute paths, volume details, and extended blocks—the --fd (full dump) switch should be utilized. Output can be redirected to a text file for thorough review or, alternatively, the --dumpTo option may be employed to export all embedded shell items as individual LNK files for parsing with other tools.
While the example above pertains to an Automatic Jump List, parsing of Custom Jump Lists follows a similar process. However, Custom Jump Lists yield significantly less contextual metadata, notably lacking DestList information, MRU ordering, and interaction counts.
The above figure demonstrates the execution of JLECmd against a user’s Recent folder, processing all available Jump Lists and exporting the parsed results into structured CSV files suitable for detailed analysis. Such outputs typically contain voluminous data; effective triage is therefore achieved by filtering on specific Application Identifiers (AppIDs) or their resolved descriptions. In the illustrated case, entries include those associated with Windows Explorer, Windows Connected Devices, Quick Access, Microsoft Office Word, Microsoft Office PowerPoint, and Microsoft Office Excel.
Once the data source has been identified through its AppID, forensic analysis should proceed to the DestList metadata for the respective application. This stream maintains the full object path, the last accessed time (Last Modified timestamp), and the Most Recently Used (MRU) ordering of items, with index 0 representing the most recently interacted destination.
Each DestList entry is further augmented by a complete embedded LNK shell item. These structures provide extensive metadata, including target Modified/Accessed/Created (MAC) timestamps, file size, drive type, volume name, volume serial number, and additional volume and object identifiers. While the path recorded in the DestList is often sufficient for initial analysis, the associated shell item’s Target ID Absolute Path may supply critical supplementary context, particularly for anomalous or non-standard entries.
Even a cursory examination of the limited excerpt presented reveals the extraordinary evidentiary richness of Jump Lists. The data encompasses files originating from both local fixed drives and removable media. For each artifact, examiners obtain precise file sizes along with original creation and modification timestamps. These target timestamps further enable the detection of file copying or transfer activity — for example, when a file’s modification time precedes its creation time on the current volume. This represents only a fraction of the available information. It is evident that Jump Lists constitute an indispensable component of any comprehensive digital forensic examination and should form part of every practitioner’s standard analytical toolkit.
Jump List Updates In Windows 10+ Versions
Jump Lists have undergone substantial structural and functional enhancements in Windows 10 and Windows 11, paralleling the evolution of LNK shell items. These modifications have considerably expanded the breadth and depth of recorded artifacts, thereby increasing their evidentiary value in digital forensic examinations. While some alterations may appear subtle, they collectively afford investigators significantly richer insights into user behavior and system activity. Notable changes introduced in Windows 10 and 11 include the following:
Detecting and Recovering Deleted Jump Lists
Informed users frequently attempt to conceal their activity by deleting Jump List files from their hidden storage locations. Such evidence destruction typically occurs through two primary methods: (1) the selective removal of individual entries via the “Remove from this list” option in the Taskbar or Start menu, or (2) the complete deletion of all Jump List files, either manually using Shift+Delete or through the execution of privacy-cleaning utilities.
While the removal of individual entries is difficult for the average user to detect, forensic examiners can reliably identify such tampering by carefully parsing the header of the DestList stream within AutomaticDestinations files. Specifically, a discrepancy between the total number of current entries and the last issued entry ID serves as a clear indicator of deletion activity. The numerical difference between these values directly corresponds to the number of entries that have been removed.
It is important to note that even after individual entries are removed from the DestList, residual (partial) data belonging to the deleted entries may persist elsewhere within the Jump List file. Although no fully automated tool currently exists for the systematic carving of these removed entries, skilled examiners can recover them through manual binary analysis and carving techniques applied directly to the raw data of the AutomaticDestinations file.
Post a Comment