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 proves less than counsel usually assumes, and each has an innocent explanation that has to be ruled out rather than dismissed. What follows is a map of that trail and where it breaks. It is a Windows map; macOS leaves a different and largely non-overlapping set of records.

Timing is usually the organizing question. Where copying is concentrated in the weeks before a resignation rather than spread across the employment, that concentration is itself substantive: it distinguishes routine work behavior from collection behavior. Examinations that look only at the departure window produce a picture opposing counsel can dismantle by showing the employee always plugged in a thumb drive on Fridays.

The difficulty is that most Windows artifacts are not built to answer how often. The registry holds a small fixed set of timestamps per device rather than a running count, and the journals and event-log channels that do capture individual events are capped, typically reaching back weeks or months rather than years. A baseline is assembled from what survived — the distinct devices that appear and when each was first installed, whatever log coverage remains, backup sets from earlier in the employment, the employer's own records — and the honest form of the argument states how far back that reaches. An examiner who describes a departure-month spike without saying what it is a spike against has offered a comparison the record cannot support.

Where Removable-Device History Runs Out

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 — vendor and product strings, a device instance identifier — with property values for when the device was first installed and when it was last connected and removed. The instance identifier is often the manufacturer-assigned serial number, but not always: where its second character is an ampersand, the operating system generated the value because the device reported no serial, and such identifiers are not unique. Reports treating every USBSTOR instance ID as a device serial invite a correction on cross-examination.

Drive letters come from elsewhere and are weaker than they look. The SOFTWARE hive's Windows Portable Devices key holds a friendly name for the volume — usually its label — and MountedDevices maps letters and volume identifiers to the underlying device. Both record the last state rather than a history, and letters are handed out again to later devices, so a mapping is a snapshot that must be dated against something else. Event logs, particularly the Partition/Diagnostic and Kernel-PnP channels, carry timestamped connection and disconnection records and on many builds the volume capacity — useful when the employee later produces a different drive and calls it the one at issue.

All of those keys sit in machine-wide hives and speak to the computer, not to a person. The per-user MountPoints2 key, in each user's own registry hive, records which volumes a particular account mounted — the difference between showing a device touched a shared workstation and showing the departing employee's account mounted it. On a machine several people used, that distinction is frequently the whole dispute.

What all this establishes is that a device matching a recorded descriptor was attached to a particular machine and, from the registry alone, when it first appeared and when it was last connected and removed. Those are a handful of moments, not a log: the registry does not count insertions, so any claim about how often a device was used has to come from the event-log channels, whose coverage is finite. What none of it establishes is that anything was copied. Insertion history is silent on file transfer, and treating it as proof of exfiltration is the most common overreach in these reports. Innocent explanations also survive further than counsel expects — presentations, IT-sanctioned backups, personal media — and ruling them out means knowing what the organization permitted in practice, not what the handbook said.

Corroboration comes from volume-level evidence recorded elsewhere. LNK shortcut files — and the LNK streams inside jumplists — contain a LinkInfo structure that can record the volume serial number and label of the drive holding the target file. Where that serial 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. The chain depends on the LinkInfo block being populated, which is not universal; volume serials are also not guaranteed unique and are reassigned on reformatting.

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 are among the most probative artifacts in the toolkit because they persist long after the source file and the source volume are 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 carry distributed link tracker ("droid") fields containing a NetBIOS name and a MAC address. Those are frequently absent or zeroed, and where present they describe 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 them further. Tracker data is a lead, sometimes corroborated against machine identifiers produced in discovery. Alone it does not place a file on a particular home or new-employer computer.

The limits

These record access, not copying. A file opened from a network share leaves the same kind of record as one staged on a USB drive first; the path and, where available, the volume serial are what distinguish them. Jumplists are application-dependent and trimmed as they age, so an absent record is weak evidence of absent access — and many applications and most portable tools bypass the shell entirely and generate nothing. Recent-folder LNK files are per-user, so an examination scoped to the wrong profile misses them.

What Shellbags Reconstruct After the Folder Is Gone

Shellbags are registry entries preserving the appearance and layout of folders a user browsed in Explorer — window position, view mode, and shell item data describing the folder itself, including its name and, for a drive node, the letter and volume label. They survive deletion of the folder, which makes them the standard way to reconstruct 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 jumplist streams. A shellbag entry alone therefore cannot tie a browsed folder tree to a specific physical device. It establishes that a user browsed a structure under a given drive letter and, where recorded, a given volume label. Device attribution requires correlating it with LNK or jumplist records carrying the serial, with registry device history, and with the timeline of which device held which letter when. Paired that way, and with LNK entries for the individual files inside those folders, the reconstruction can become specific enough to compare against a trade-secret identification list. Skip the correlation and the attribution is something the artifact cannot supply.

Interpretation is 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. An examiner who states a shellbag timestamp as a bare fact, without saying which event it reflects, invites effective cross-examination. And an employee who opened a folder looking for a personal file leaves an entry indistinguishable from one who opened it to select everything and drag it.

Webmail, File Sync, and the Browser-Side Record

Removable media is not the only channel worth examining, and frequently not the most productive one. Personal cloud storage, webmail and consumer sync clients move data with no device attached, and leave a different set of records — several able to supply a quantity rather than an inference, most expiring faster than anything on the disk.

• Browser history and cache entries for visits to personal webmail compose or upload endpoints, timestamped so they align against file-access records
• Sync-client artifacts: installation traces, configuration databases and per-file logs for personal Dropbox, Google Drive, OneDrive and Box accounts, which often enumerate uploaded filenames
• Proxy, firewall, CASB or endpoint DLP logs showing outbound volume by destination and time — the byte counts endpoint artifacts cannot supply
• Mail-server and message-tracking logs for mail sent from a corporate account to a personal address, with attachment names and sizes
• Windows SRUM 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 never appear as installed software
• Amcache and ShimCache (AppCompatCache) entries showing such binaries were present — these record file presence and metadata and do not, 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 it carries caveats: it is disabled by default on many server builds and can be switched off 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 strength of this channel is that it can produce a quantity rather than 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 coverage is limited, and proxy and DLP logs are often purged on short cycles. Preservation begun months after a departure arrives after the most quantitative evidence has aged out.

Printing and Archive Creation: The Channels People Forget

Print activity is routinely overlooked and is sometimes the cleanest evidence in a case, because printing is difficult to characterize as accidental. Print spooler artifacts, the PrintService operational log and print-server queues can record document names, page counts, timestamps and the submitting user. That channel is often disabled by default and must be checked rather than assumed; where it is on, 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 usually involves staging: files gathered into a folder, compressed, sometimes encrypted, then moved. That leaves traces even when the archive is deleted — NTFS $LogFile and $UsnJrnl entries for the creation and rename of a .zip or .7z, Prefetch showing a compression tool ran, LNK or jumplist records referencing the archive, shellbags for the staging directory. Journal coverage is finite and rolls over with volume activity, so a missing entry for an older event carries little weight.

Encrypted or password-protected archives warrant attention, but intent cannot be inferred from encryption alone. Policy or DLP rules sometimes require it, sanctioned backup workflows may encrypt by default, and some utilities apply encryption without an affirmative user choice. Establish which tool produced the archive, whether encryption was a default or a selection, and what the organization's tooling required — and 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 show what was taken, and they have mundane causes as well as guilty ones: scheduled cleanup utilities, storage-pressure routines, log channels that roll over on size. Document what was destroyed, when, by what mechanism, and whether that mechanism was user-initiated or automatic — and be candid where the content is simply unrecoverable.

Ruling Innocent Explanations In or Out

The defense is usually some version of: normal work behavior, personal files, an IT-sanctioned backup, a device that only ever held photographs. Each is testable, and the testing separates a report that survives from one that does not.

Baseline comparison is the primary tool, within the retention limits already described. Where the surviving records genuinely reach back, a rate comparison between the employment and the departure month turns the pattern argument from rhetoric into arithmetic. Where they do not, the comparison that remains is compositional. If the copied set consists of files the employee never opened in the ordinary course — documents outside their business unit, a full export of a system they had no operational reason to touch — the personal-use explanation weakens. If the volume holds family photographs alongside a handful of spreadsheets they edited weekly, an honest report says so.

Two things strengthen an examination materially. The first is having 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 there against the identified trade secrets establishes bit-for-bit identity of content — and nothing beyond it. A hash match does not show the transfer path, the date the file arrived, who put it there, or that it was not obtained legitimately. A non-match does not exclude copying either: re-saving, converting or re-compressing a document changes the hash while leaving the substance intact, which is why fuzzy hashing and content and metadata comparison belong 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 material identified in the pleadings produce volume without proof. Coupling also disciplines the examination itself: it forces early decisions about custodians, date ranges and systems, and it makes the expert's 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.