In a data-exfiltration investigation, such as may be necessary after an employee leaves in bad faith, files copied to a USB drive are particularly interesting. Unfortunately, it’s not so simple as consulting a Windows “file copy log.” While newer versions of Windows offer some auditing of files and removable storage, these features are not enabled by default.
In a recent client investigation, we discovered that a former employee had installed TeraCopy on their company-issued laptop. TeraCopy is a common file copying/moving application with a variety of added features. As with any software, the more it helps, the more it stores. For example, it tracks a short-term history of copied files. We used this to compile an extensive list of documents that were copied to a USB device shortly before the employee quit.
As TeraCopy keeps historical data for only a short time, it is not difficult to accidentally trigger an automatic purge. Casual live analysis, such as opening TeraCopy on the system, or copying files with it, is therefore risky. TeraCopy only keeps, by default, one week of history.
TeraCopy stores its job history in multiple SQLite databases. As this is a well-defined format, an examiner can readily read it with various SQLite browsing tools. The databases are all found in the user’s profile folder.
Putting these sources together, we can determine when TeraCopy was used to copy (or move) files, where they came from, where they went, what they were called, and even their MD5 hashes. This wealth of data is invaluable to an exfiltration investigation and can be combined with other forms of forensic analysis such as USB device activity, LNK files, and shellbags.
- state: Indicates whether the job is active.
- 0 = pending (active job)
- 2 = done (job history)
- name: File name of the associated file list database.
- started: Timestamp for when this job started (stored in Julian format).
- Note: This is easily converted to an Excel-compatible timestamp: =[started] – 2415018.5
- operation: Type of operation carried out in the job.
- 1 = Copy
- 2 = Move
- 3 = Verify
- files: Number of files in the job.
- size: Total size of the files in the job (in bytes).
The main database is accompanied by FileList.dat. This plain-text document is a list all files & folders selected in the most recent operation. It should be noted that because TeraCopy works recursively on folders, this is not necessarily a list of all files copied. We can extract that from the history databases.
In the History subfolder, there are individual file history databases for each job in main.db. Each is named in the format of YYMMDD-HHMMSS.db, representing a UTC timestamp. These files contain detailed logs of files and a wealth of data about them. Each history database matches a row in main.db, tying to the “name” field.
Some of the more interesting fields are:
- Source: Full path to the source file.
- Offset: The index position in source where the file’s name begins.
- State: Records the outcome of the operation:
- 0 = Added
- 1 = OK
- 2 = Verified
- 3 = Error
- 4 = Skipped
- 5 = Deleted
- 6 = Moved
- Size: File size (in bytes).
- Creation, Access, Write: File timestamps in Julian format (see main.db).
- SourceCRC, TargetCRC: These are the MD5 (not CRC32) hashes for the source (and target, depending on user options) file.
This historical data is volatile and subject to routine deletion. By default, TeraCopy retains the history for one week. It can be configured to keep it for only one day or not keep it at all.
Herein lies a danger of data loss in careless live analysis. Imagine a scenario in which an employee leaves a company and is suspected of having copied confidential data on the way out. A manager asks IT staff to log in as the user to “look around”. Merely opening TeraCopy out of curiosity, or trying to copy files with it (often automatic due to its Windows integration), will purge any old history! This highlights the importance of “hands off” policy with any computer until a forensics expert can preserve its contents.