What Your Files Say About You: EXIF and Document Metadata for OSINT and DFIR

Files talk

Every file has two layers: the content you meant to share and the data your software added without asking. The second layer records who made the file, with what, when, sometimes where, and occasionally what it looked like before you edited it.

For investigators this is a gift. Metadata has attributed anonymous documents, located photographers and linked phishing lures to a single builder. A well-known example: in 2005 the BTK killer in Kansas was identified partly because a floppy disk he sent police contained a Word document whose metadata pointed to his church and his first name. Another: in 2012, a magazine published a photo of John McAfee while he was in hiding, and the image's GPS tags reportedly gave away his location in Guatemala.

For defenders it is a liability. Your own published documents leak internal usernames, server paths and software versions that make an attacker's reconnaissance easier.

Image metadata: EXIF and friends

Images can carry several metadata formats at once: EXIF (camera and capture data, the most common in JPEG and many RAW and HEIC files), IPTC (captions, credits, keywords, used by newsrooms) and XMP (Adobe's XML-based format, often added by editing software).

What tends to matter for an investigation:

That last row is the classic trap. Some editing workflows update the main image but leave the embedded EXIF thumbnail untouched. Crop out a face or a street sign, and the thumbnail may still show it.

Extracting it

exiftool remains the reference tool, and it reads far more than EXIF:

# Everything, grouped by format, with tag names
exiftool -a -G1 -s photo.jpg

# Just the investigator's shortlist
exiftool -GPSPosition -DateTimeOriginal -OffsetTimeOriginal \
         -Make -Model -SerialNumber -Software photo.jpg

# Pull the embedded thumbnail to compare with the main image
exiftool -b -ThumbnailImage photo.jpg > thumb.jpg

For a quick look without installing anything, /tool/image-metadata reads the metadata of an image in your browser. When the extension looks wrong, check the real format first with /tool/file-signatures; a "JPEG" that is really a PNG or HEIC will have a different metadata layout.

Office documents

Modern Office files (.docx, .xlsx, .pptx) are ZIP archives of XML. Metadata lives in a handful of predictable places:

docProps/core.xml     creator, lastModifiedBy, created, modified, revision, title
docProps/app.xml      Application, AppVersion, Company, Template, TotalTime, Pages
docProps/custom.xml   custom properties (DMS IDs, classification labels, project codes)
word/settings.xml     rsid values (Word editing session identifiers)

You can read them directly:

unzip -p lure.docx docProps/core.xml | xmllint --format -
unzip -p lure.docx docProps/app.xml  | xmllint --format -

What investigators look for:

• Author and last-modified-by. Often a Windows username or a full name. Attackers increasingly scrub these, but builders and templates leak them anyway.
• Template. A non-default template name in app.xml can tie several lures together, and in malicious documents may point to a remote template (covered in our malicious Office documents guide).
• Company and AppVersion. Narrow the authoring environment.
• TotalTime. Total editing minutes. A "quarterly report" with two minutes of editing time was generated, not written.
• Custom properties. Sensitivity labels and document management IDs that should never leave the building.
• rsids. Word assigns revision save IDs per editing session. Documents sharing unusual rsid values were likely edited from a common original, which is useful for clustering campaigns.

Spreadsheets add their own leaks: hidden and very hidden sheets, defined names, external link targets with internal file paths, cached values of formulas pulling from other workbooks, and comments. /tool/xlsx-inspector is built for looking inside workbooks without opening them in Excel.

Legacy binary formats (.doc, .xls) store similar data in OLE property streams (SummaryInformation, DocumentSummaryInformation); exiftool and olemeta from the oletools suite read them.

PDF metadata

PDFs carry metadata in two places: the older Info dictionary (Title, Author, Creator, Producer, CreationDate, ModDate) and an XMP stream. They do not always agree, and the disagreement is itself information.

Creator names the authoring application (say, a word processor) and Producer the library that wrote the PDF. A "scanned invoice" whose producer is a PDF generation library used by a known phishing kit is not a scan.

The bigger PDF leak is structural:

• Incremental updates. PDFs can be edited by appending changes rather than rewriting the file. Earlier versions of the content can remain in the file and be recovered.
• Failed redaction. Drawing a black rectangle over text hides it visually; the text is still in the content stream and can be copied out. Real redaction tools remove the underlying text.
• Embedded files and form data, including attachments, JavaScript and filled-in fields.

exiftool -a -G1 report.pdf          # Info dict and XMP
pdfinfo report.pdf                   # quick summary (poppler-utils)
grep -c '%%EOF' report.pdf           # more than one often means incremental updates

Who strips what

Metadata survival depends entirely on the path a file took. Generalisations that hold reasonably well:

Do not rely on this table for your own operational security: platforms change behaviour without notice. Verify the actual file.

Stripping it properly

# Remove all writable metadata from images (keeps a _original backup by default)
exiftool -all= photo.jpg

# Keep orientation so the image does not rotate unexpectedly
exiftool -all= -tagsfromfile @ -Orientation photo.jpg

For documents meant for publication, the reliable path is: Office's document inspector, then export to PDF, then check the PDF with exiftool before it goes out. Make that check part of the publishing process, not an individual's memory.

Pitfalls that mislead investigators

Metadata is a claim, not a fact. Every field above can be written with the same tools that read it. A planted GPS coordinate or a fake author name is trivial. Use metadata to generate leads and correlate, then confirm with independent sources (visual geolocation, upload logs, server-side records).

Timezones. DateTimeOriginal is usually local device time with no zone. Unless OffsetTimeOriginal exists, you do not know the UTC time. Note the assumption explicitly when you put it in a timeline; /tool/timestamp helps with conversions once you know the offset.

Wrong clocks. Cameras with unset clocks produce plausible but wrong dates, often their factory default date. Compare against something that has a reliable clock.

Filesystem times are not metadata times. A file's modified time on disk reflects when it was copied or extracted, not when it was created. Archive extraction and email downloads reset it.

Absence is not evidence. No metadata usually means a platform stripped it, not that someone was hiding something.

Template inheritance. An author name in a document might be the person who created the template five years ago, not the person who wrote this version.

Takeaways

• [ ] Extract metadata from every lure, leaked document and image in a case, with exiftool -a -G1, and keep the output with the evidence.
• [ ] Check embedded thumbnails and PDF incremental updates for pre-edit content.
• [ ] Use template names, rsids, producer strings and custom properties to cluster related documents.
• [ ] Record timezone assumptions explicitly in timelines.
• [ ] Treat every field as attacker-controllable and confirm leads independently.
• [ ] Scan your own published documents and fix your publishing pipeline.

Metadata will not solve a case by itself. It will very often tell you where to look next.