RedTeam Nexus Labs
Module 18 · Lesson 02 // Metadata Analysis

document metadata

Metadata Analysis · CTF

Freereading · 10 min
On this page
  1. Overview
  2. Learning objectives
  3. Core concept
  4. How it works
  5. Practical example
  6. Cybersecurity relevance
  7. Common mistakes
  8. Key takeaways
  9. Check your understanding
LESSON

Overview

Images are not the only files that carry hidden metadata. Documents — word-processor files, spreadsheets, presentations, and PDFs — embed their own rich metadata describing who created them, what software produced them, and how they evolved. In forensics and OSINT challenges, document metadata frequently holds the flag or the decisive clue: an author name, an internal path, a hidden revision, or a comment that was never meant to ship. This lesson explains what document metadata is and the fields that matter most.

All analysis here is performed on files you own or that a challenge provides, in an authorized and isolated environment.

Learning objectives

  • Explain what document metadata is and why documents carry it.
  • Identify common metadata fields: author, software/producer, title, and revision data.
  • Describe how modern office documents store metadata internally.
  • Read document metadata without altering the source file.

Core concept

Document metadata is descriptive information the application stores about a document, separate from its visible text and images. When you save a file, the application records administrative details — who authored it, which program and version wrote it, when it was created and last modified, and often organizational data like company name or template used. This happens automatically, so the metadata reflects the real environment in which the file was produced.

Crucially, metadata can outlive the visible content. Text you deleted, a comment you resolved, or an earlier author's name can persist in the file's metadata or internal structures even though it no longer appears on the page.

How it works

Modern office formats (.docx, .xlsx, .pptx) are actually ZIP archives containing XML files. One of those internal parts stores core properties such as:

  • creator / author — the name (or username) of the person who created the document.
  • lastModifiedBy — who most recently saved it.
  • Application / producer — the software and version that generated the file (for a PDF this is often the Producer and Creator fields).
  • title, subject, keywords, description — descriptive fields the author may have filled in.
  • created / modified timestamps — when the document was first created and last changed.
  • revision / Company / Template — how many times it was saved, the organization, and the base template.

PDFs use a document information dictionary (and sometimes XMP metadata) with analogous fields like Author, Producer, Creator, CreationDate, and ModDate. Because .docx/.xlsx/.pptx are ZIP archives, you can also inspect their internal parts directly to find embedded data, comments, or leftover fragments. As with images, read metadata from a copy so the original stays intact.

Practical example

A challenge provides report_final.pdf and asks, "Who wrote this document, and what tool produced it?" You run a metadata reader on a copy and see (illustrative):

Title        : Quarterly Summary
Author       : j.rivera
Creator      : ExampleWriter 2.4
Producer     : ExamplePDF Engine 1.8
CreationDate : 2023:02:03 14:22:10
ModDate      : 2023:02:09 08:05:41

The Author field (j.rivera) may match a required flag or point you to a person, and Creator/Producer reveal the software chain. For a .docx, you might instead unzip the archive and read the core-properties XML to find creator, lastModifiedBy, and a revision count — sometimes exposing an internal username or a reviewer who was never named in the visible text.

Cybersecurity relevance

Document metadata is a classic information-disclosure channel. Organizations have repeatedly leaked internal usernames, employee names, software versions, and even network paths simply by publishing documents without cleaning metadata. For an attacker doing reconnaissance, creator and lastModifiedBy fields harvested from public documents can build a list of valid usernames and reveal the software in use (useful for targeting). For defenders, this is why "document sanitization" or "remove hidden data" features exist and why publishing workflows should strip metadata before release. Recognizing document metadata trains you to see files as carriers of organizational intelligence.

Common mistakes

  • Focusing only on visible text and missing the metadata block entirely.
  • Ignoring that .docx/.xlsx/.pptx are ZIP archives with inspectable internal parts and possible leftover fragments.
  • Overlooking PDF Author/Producer fields, which are trivial to read but often revealing.
  • Trusting the fields as verified identity — like all metadata, they can be edited or spoofed.

Key takeaways

  • Document metadata is administrative data stored about a file: author, software/producer, timestamps, revision count, and organization.
  • Office formats (.docx/.xlsx/.pptx) are ZIP archives whose internal XML holds core properties; PDFs use an info dictionary and XMP.
  • Metadata can persist even after the visible content it relates to is deleted, making it a common information-disclosure vector.
  • Always read from a copy, and remember creator/lastModifiedBy often expose real usernames.

Check your understanding

  • Why can a .docx file reveal internal usernames even if no name appears in the visible text?
  • What metadata fields would you check to identify the software used to produce a suspicious PDF?
FINISH THIS LESSON

Sign in to save your progress.

PreviousEXIFNexttimestamps