How Metadata Can Expose Fraudulent Documents

When a party in litigation or an internal investigation produces a critical contract, board minute, or invoice that conveniently resolves a factual dispute, scrutiny must move beyond the visible text. Fraudulent documents rarely fail on typography alone. Modern forgers have access to professional layout software, convincing corporate templates, and high-resolution corporate seals. Where they almost universally fail is in reconciling the hidden, automated audit trails generated by modern operating systems and productivity applications.

Metadata provides an objective, machine-generated chronology of a document's lifecycle. It records when an artifact was created, which hardware or user account generated it, what application versions were used, and whether its contents were modified after the purported execution date. In commercial disputes governed by the Civil Procedure Rules (CPR) and Practice Direction 57AD, demonstrating that a key document is backdated or altered can transform a case, leading to strike-out applications, adverse inferences, committal proceedings for contempt of court, or formal criminal referrals.

The Anatomy of Metadata: File System versus Application Properties

To identify document fraud, investigators must distinguish between file system metadata and internal application metadata. Confusing the two often leads to flawed theories that collapse under cross-examination.

File system metadata is maintained by the operating system hosting the file, such as NTFS on Windows or APFS on macOS. It records when a specific instance of a file was created, modified, or accessed on that storage volume. Crucially, file system timestamps reflect interactions with the storage medium, not necessarily the authoring of the text. For example, copying a legitimate five-year-old agreement from a corporate network share onto a USB flash drive generates a new file system creation date matching the exact second of the copy operation, while the last modified date may remain unchanged.

Application metadata resides inside the file structure itself, written by software like Microsoft Word, Adobe Acrobat, or Google Workspace. This internal metadata travels with the file when emailed or moved across systems. It routinely records the original author name, registered organisation, template path, total editing time, revision numbers, and precise internal timestamps for creation and modification. In fraud investigations, irreconcilable discrepancies between application metadata and file system records often provide the first concrete proof of fabrication.

Telltale Signatures of Document Manipulation

Forgers typically work backwards. They draft an agreement or invoice in the present day and attempt to make it appear as though it originated months or years earlier. This workflow leaves distinct forensic signatures that forensic analysis routinely uncovers.

Anachronistic Software Versions and Environments

Productivity suites embed build numbers and application signatures into file streams. If a disputed contract purportedly signed in June 2018 contains internal XML tags generated exclusively by Microsoft 365 Version 2208 (released in 2022), the document is an undeniable anachronism. Similarly, fonts that were not commercially available or system defaults that did not exist at the purported date of execution expose backdating instantly.

Discrepancies in Editing Time and Revision Counts

Microsoft Word tracks properties such as Total Editing Time (recorded in minutes) and internal revision counters. A 40-page, highly complex commercial lease purportedly negotiated over several weeks that displays a total editing time of four minutes and a revision count of one strongly indicates that the text was pasted wholesale into a fresh document or generated from an external source to create a clean, scrubbed draft.

Template and Path Leakage

Office documents frequently cache the local or network file path of the template on which they were based. In employee fraud and intellectual property theft, forensic analysis often reveals user profile paths embedded in the document header - such as C:\Users\suspect_name\AppData\... - proving that a document purportedly issued by a third-party vendor was actually drafted on the defendant's work laptop.

Deep-Dive: PDF and Office Document Structures

The vast majority of forged business records are presented as PDFs or Office Open XML files (.docx, .xlsx). Each format requires specific forensic techniques to deconstruct.

Uncovering Incremental Updates in PDFs

The PDF specification allows for incremental updates. When a user modifies a PDF - for instance, by changing an invoice bank account number, altering a total figure, or pasting a signature image - the software does not always rewrite the entire file. Instead, it frequently appends a new revision to the end of the existing file, leaving the previous version intact within the binary structure.

By conducting hex-level analysis and extracting previous cross-reference (xref) tables, a digital forensics practitioner can recover the original, unedited text, uncover the exact layer where the new signature was introduced, and extract the timestamp of that subsequent modification.

Parsing Office Open XML Archives

Modern Word and Excel files are zipped archives containing XML files, media folders, and relationship trees. Investigators do not rely on standard document properties displayed in desktop operating systems. Instead, they extract the package and examine core files directly:

• docProps/core.xml: Contains standard Dublin Core properties, including UTC creation dates (dcterms:created) and modification dates (dcterms:modified).
• docProps/app.xml: Contains application metrics, total editing time, word counts, and software versioning strings.
• word/document.xml: Contains the raw body text. Comparing the timestamps inside the XML header with the modification dates of the individual sub-files within the ZIP container reveals whether external tools were used to manually manipulate dates.

Document Provenance Across the eDiscovery Workflow

Uncovering metadata anomalies requires rigorous handling throughout the standard eDiscovery lifecycle. Standard disclosure workflows can inadvertently destroy the very evidence required to prove fraud.

Identification and Forensic Collection

Self-collection by custodians is catastrophic in fraud investigations. Simply opening a suspect Word document to review its contents updates the file system last accessed timestamp, updates internal cached fields, and potentially alters application metadata. Custodians must be prevented from handling target repositories. Forensics teams must preserve files using bit-stream physical imaging or forensically verified logical preservation that captures all NTFS Master File Table (MFT) records and file system metadata without alteration.

Processing and Metadata Preservation

During eDiscovery ingestion, processing engines extract document text and map metadata fields into database columns. Legal teams must ensure that processing parameters do not overwrite or ignore granular metadata. Fields such as PDF Producer, PDF Version, Internal Create Date, Word Revision Number, and Author must be systematically extracted and preserved rather than stripped during automated deduplication.

Review and Analysis

Within the review platform, litigators should use metadata filtering to isolate chronological outliers. A search comparing the visible document date against the application creation date quickly surfaces anomalies. Documents where the visible date predates the internal creation date by more than 48 hours should be flagged for detailed forensic inspection.

Disclosure and Production under PD 57AD

Under Practice Direction 57AD of the Business and Property Courts, parties are generally required to produce documents in their native format with full metadata intact. If an opposing party produces flattened single-page TIFFs or printed PDFs for key disputed documents, litigators should immediately demand native production with complete metadata, citing potential issues regarding authenticity and document provenance.

Practitioner Checklist: Investigating Suspect Files

When an opposing party or uncooperative employee produces a suspicious document, solicitors and investigators should apply this practical workflow to determine its authenticity.

• Demand Native Files: Insist on the native electronic file accompanied by its original cryptographic hash value (SHA-256). Reject flattened, converted, or printed substitutes where provenance is disputed.
• Isolate the Master File Table (MFT): For internal investigations where hardware is accessible, capture the NTFS MFT to inspect the $STANDARD_INFORMATION and $FILE_NAME attributes. Discrepancies between these attributes expose timestamp manipulation (timestomping).
• Verify Time Zone Alignments: Ensure all internal application timestamps - recorded in Universal Coordinated Time (UTC) - are correctly reconciled against local daylight saving time and the geographical location of the purported author.
• Extract PDF Object Trees: Interrogate the PDF file for multiple xref tables, flattened form fields, and non-standard image compression that suggest digital signature pasting or redaction circumvention.
• Correlate with Surrounding Context: Compare the document's purported creation date against email server logs, calendar entries, network firewall records, and backup archives to verify whether the file existed anywhere on the corporate infrastructure at that time.
• Instruct an Independent Expert Early: If preliminary checks indicate manipulation, instruct a digital forensics expert to prepare a CPR Part 35 compliant report detailing the technical methodology and evidentiary findings before putting the allegation to the opposing side.