Proving Trade-Secret Theft by a Departing Employee: The Artifact Trail

Most departing-employee trade-secret cases turn on a narrow question: can you show that specific proprietary material moved, on specific dates, to a place the employer does not control. Suspicion is easy to generate and hard to convert. The Windows artifacts that bear on the question are well understood, but each one proves less than counsel usually assumes, and each one has an innocent explanation that must be affirmatively ruled in or out. What follows is a practical map of the artifact trail, what each entry can carry evidentiary weight for, and where it breaks. The artifacts discussed here are Windows artifacts; macOS leaves a different and largely non-overlapping trail that is outside the scope of this piece.

Timing is usually the organizing question in these matters. Where copying activity is concentrated in the period immediately preceding a resignation rather than distributed across the employment, that concentration is itself substantive, because it distinguishes routine work behavior from collection behavior. Arguing concentration requires a baseline: the same employee's activity over a long prior period on the same machine, measured the same way. Examinations that look only at the departure window produce a picture that opposing counsel can dismantle by showing the employee always plugged in a thumb drive on Fridays. The baseline is also where the examiner learns what the employee's normal file-handling looked like, which shapes every later inference.

USB Insertion and Volume History: Presence, Not Payload

On Windows, removable-device history is reconstructed from several independent sources that should agree with one another. The SYSTEM registry hive records device descriptors under USBSTOR and USB, including vendor and product strings and a device instance identifier. That identifier is often the manufacturer-assigned serial number, but not always: where the second character of the instance ID is an ampersand, the value was generated by the operating system because the device did not report a serial, and such identifiers are not unique to the device. Reports that treat every USBSTOR instance ID as a device serial invite a correction on cross-examination. The SOFTWARE hive and the Windows Portable Devices keys tie a device to a friendly name and drive letter. Event logs — particularly the Partition/Diagnostic and Kernel-PnP channels — carry timestamped connection and disconnection records, and on many builds include volume capacity, which becomes useful when the employee later produces a different drive and claims it is the one at issue.

What this establishes is that a device matching a recorded descriptor was attached to a particular machine at particular times. That is a meaningful fact and often a surprising one to a defendant who assumed the connection left no trace. What it does not establish is that anything was copied. Insertion history is silent on file transfer. Treating it as proof of exfiltration is the most common overreach in these reports, and it is easily exposed in deposition.

Corroboration comes from volume-level evidence recorded elsewhere. LNK shortcut files — and the LNK streams embedded inside jumplists — contain a LinkInfo structure that can record the volume serial number and volume label of the drive holding the target file. Where the volume serial recorded in a shortcut matches a volume associated with a device in the registry, and the shortcut points to a path like E:\Pricing\2Q-Forecast.xlsx, the record has moved from presence to interaction with named files. That chain depends on the LinkInfo block being present and populated, which is not universal, and on the volume serial being distinctive enough to be probative; serials are not guaranteed unique and are reassigned on reformatting. Innocent explanations survive here more often than counsel expects: employees legitimately carry drives for presentations, backups sanctioned by IT, and personal media. Ruling those in or out requires knowing what the organization actually permitted in practice, not only what the handbook said.

LNK Files and Jumplists: What Was Opened, and From Where

Windows creates a shortcut file in the user's Recent folder when a document is opened through the shell, and populates automatic jumplists per application. These artifacts are among the most probative in the toolkit because they persist after the source file and the source volume are long gone. A LNK file typically retains the target's full path, its size at the time of access, a set of timestamps for the target, and, where the LinkInfo block is populated, the volume serial and label.

LNK files may also contain distributed link tracker ("droid") fields that include a NetBIOS name and a MAC address. Those fields are frequently absent or zeroed, and where present they derive from the machine hosting the target volume rather than reliably identifying the machine on which the shortcut was created. Virtual adapters and randomized hardware addresses degrade the value further. Tracker data can be a useful lead, and it can sometimes be corroborated against known machine identifiers produced in discovery, but standing alone it does not place a file on a particular home or new-employer computer.

Where the destination machine is available for examination, LNK records on that machine may reference the employer's file server or removable-volume paths, which speaks to whether copied material was opened and used rather than merely moved. That distinction often matters more to damages and to the scope of requested relief than the fact of copying alone.

The limits

LNK files record access, not copying. A file opened directly from a network share leaves the same kind of record as a file opened after being staged on a USB drive; the distinguishing evidence is the path and, where available, the volume serial. Jumplists are application-dependent and are trimmed as they age, so absence of a record is weak evidence of absence of access. Many applications and most portable tools bypass shell interaction entirely and generate nothing. Recent-folder LNK files are also per-user and per-profile, so an examination scoped to the wrong profile can miss the relevant record entirely.

Shellbags: Directory Structure Reconstructed After the Fact

Shellbags are registry entries that preserve the appearance and layout of folders a user browsed in Explorer — window position, view mode, and the shell item data describing the folder itself, including its name and, for a drive node, the drive letter and volume label. They survive deletion of the folder, which makes them a standard method for reconstructing the structure of an external volume that was never produced.

Shellbags do not record volume serial numbers. That is a LinkInfo field found in LNK files and in the LNK streams inside jumplists. The practical consequence is that a shellbag entry alone cannot tie a browsed folder tree to a specific physical device; it can establish that a user browsed a folder structure under a given drive letter and, where recorded, a given volume label. Attribution to a device requires correlation with LNK or jumplist records that carry the volume serial, with registry device history, and with the timeline of which device held which drive letter when. Examiners who skip that correlation step and assert device attribution from shellbags alone are asserting something the artifact cannot supply.

With that correlation in place, shellbags can support testimony that a browsed volume contained folders named after client accounts, or a directory tree mirroring a proprietary engineering repository. That speaks to the character of what was accessible, not just its volume. Paired with LNK entries showing individual files inside those folders, the reconstruction can become specific enough to compare against a trade-secret identification list.

Shellbag interpretation is technical and contested in its details. Timestamp semantics vary by Windows version and by whether the entry reflects the shell item's recorded creation, last access, or last write value, and those embedded values describe the folder rather than the moment of browsing. Examiners who state a shellbag timestamp as a bare fact without explaining which event it reflects invite effective cross-examination. Shellbags also record browsing, not copying — an employee who opened a folder to look for a personal file generates an entry indistinguishable from one who opened it to select everything and drag it. Sequence and the presence or absence of contemporaneous file-open records are what separate the two.

Webmail, File Sync, and the Browser-Side Record

In the matters I have examined, removable media is increasingly not the primary channel. A large share of exfiltration runs through personal cloud storage, personal webmail, or a consumer sync client, and the artifacts are correspondingly different.

• Browser history and cache entries showing visits to personal webmail compose or upload endpoints, with timestamps that can be aligned against file-access records
• Local sync client artifacts: installation traces, configuration databases, and per-file sync logs for personal Dropbox, Google Drive, OneDrive, and Box accounts, which frequently enumerate uploaded filenames
• Proxy, firewall, CASB, or endpoint DLP logs showing outbound volume by destination and time, which supply the byte counts that endpoint artifacts cannot
• Mail-server and message-tracking logs for messages sent from a corporate account to a personal address, including attachment names and sizes
• Windows SRUM (System Resource Usage Monitor) records attributing network bytes sent and received to individual applications over time
• Prefetch entries indicating execution of archiving utilities, secure-delete tools, or portable browsers that do not appear as installed software
• Amcache and ShimCache (AppCompatCache) entries indicating that such binaries were present on the system — these record file presence and metadata and do not, standing alone, establish that the program ran

The distinction in the last two bullets matters under oath. Prefetch is the artifact that supports an execution inference, and even that carries caveats: Prefetch is disabled by default on many server builds and can be disabled by policy, so its absence proves little. ShimCache entries can be created by the shell merely enumerating a directory containing the file, and Amcache records installation and file metadata. An examiner who tells a jury that a ShimCache entry proves a wiping tool was run has stated something the artifact does not support.

The forensic strength of the cloud and webmail channel is that it can produce a quantity rather than only an inference. SRUM showing a browser process transmitting several gigabytes on a Sunday evening, aligned with a sync log enumerating thousands of files from a design directory, is a harder record to explain than a bare USB insertion. The weakness is retention. Browser history rolls over, SRUM retention is limited and varies by system, and proxy and DLP logs are often purged on short cycles. The practical consequence is that the value of these artifacts decays quickly, and preservation efforts undertaken months after a departure may arrive after the most quantitative evidence has aged out.

Printing and Archive Creation: The Channels People Forget

Print activity is routinely overlooked and is sometimes among the cleanest evidence in a case, because printing is difficult to characterize as accidental. Windows print spooler artifacts, the PrintService operational log, and print-server queues can record document names, page counts, timestamps, and the submitting user. Logging of the operational channel is often disabled by default and must be checked rather than assumed; where it is enabled, document names and page counts convert into a narrative a factfinder can follow without technical translation. Spool and shadow files, where they survive, may preserve the rendered content itself.

Archive creation is the other frequently missed step. Bulk collection commonly involves staging: files are gathered into a folder, compressed, sometimes encrypted, then moved. That staging leaves traces even when the archive is deleted — NTFS $LogFile and $UsnJrnl entries recording the creation and rename of a .zip or .7z, Prefetch indicating execution of a compression tool, LNK or jumplist records referencing the archive, and shellbags for the staging directory. Journal coverage is finite and rolls over as a function of volume activity, so the absence of a journal entry for an older event carries little weight.

Encrypted or password-protected archives warrant attention, but intent cannot be inferred from encryption alone. Corporate policy or DLP rules sometimes require encryption of data at rest or in transit, IT-sanctioned backup workflows may encrypt by default, and some archive utilities apply encryption without an affirmative user choice. The examiner's task is to establish which tool produced the archive, whether encryption was a default or a selected option, and what the organization's policy and tooling actually required — and to report that context alongside the finding rather than skipping to a conclusion about motive.

Anti-forensic activity

Wiping tools, mass deletion in the final days, cleared event logs, and browser-history purges are themselves artifacts. They do not prove what was taken, and an examiner should not pretend otherwise. They can also have mundane causes: cleanup utilities that run on a schedule, storage-pressure routines, and log channels that roll over on size. The examiner's job is to document what was destroyed, when, by what mechanism, and whether the mechanism was user-initiated or automatic, and to be candid that the content is unrecoverable where that is the case.

Ruling Innocent Explanations In or Out

The defense in nearly every one of these matters is some version of: this was normal work behavior, or personal files, or an IT-sanctioned backup, or a device that only ever held photographs. Each of those is testable, and the testing is what distinguishes a report that survives from one that does not.

Baseline comparison is the primary tool. Where an employee's USB activity across a multi-year employment averaged a small number of insertions per month and the departure month shows an order-of-magnitude increase, the pattern argument becomes quantitative rather than rhetorical. Where the copied set consists of files the employee never opened in the ordinary course — documents outside their business unit, or a full export of a system they had no operational reason to bulk-download — the personal-use explanation weakens. Conversely, where the volume in question contains family photographs alongside a handful of work spreadsheets the employee edited weekly, an honest report says so.

Two things strengthen an examination materially. The first is availability of the destination: the personal drive, the home computer, the new employer's laptop. Source-side artifacts show departure; destination-side artifacts show arrival and, sometimes, use. Hash-matching files at the destination against the employer's identified trade secrets establishes bit-for-bit identity of content, which is a stronger showing than circumstantial correlation. It establishes nothing more than that. A hash match does not show the transfer path, the date the file arrived, who placed it there, or that it was not obtained from a licit source. And a non-match does not exclude copying: opening and re-saving a document, converting its format, or re-compressing it changes the hash while leaving the substance intact, which is why fuzzy hashing, content comparison, and internal metadata comparison are needed alongside exact hashing.

The second is keeping the trade-secret identification list and the forensic findings tightly coupled. Examinations that report on tens of thousands of files without mapping them to the specific material identified in the pleadings produce volume without proof. Coupling also disciplines the examination itself: it forces early decisions about which custodians, date ranges, and systems are actually in scope, and it makes the eventual report legible to a factfinder who will not be reading hex.

Attorney advertising / expert services. General information, not legal advice. Case examples are anonymized except where publicly identified.