author fields

Overview

Among all the metadata a file can carry, author fields are some of the most revealing — and the most sought-after in OSINT and forensics challenges. Fields like Author, Creator, lastModifiedBy, and the account name baked into device metadata connect a file to a person or account. A single author name can be the flag itself, a valid username for reconnaissance, or the thread that unravels who made something. This lesson focuses specifically on author-identity fields: where they come from, what they really mean, and how to interpret them responsibly.

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

Learning objectives

• Identify the author-identity fields across images and documents.
• Explain where these fields get their values (account/username, configured name).
• Use author fields for attribution while understanding their limits.
• Recognize the privacy and reconnaissance implications of leaked author data.

Core concept

Author fields are metadata entries that name the person or account associated with creating or modifying a file. They are populated from whatever identity the creating software has on hand — most often the operating-system account name or the display name configured in the application. The person is rarely asked "what name should I stamp here?"; the software simply uses the logged-in user or a saved profile. That is why author fields so often expose real usernames or full names without the author intending it.

The important nuance is that an author field records the identity the software was configured with, not a verified fact about who truly authored the content. It is a strong lead, not proof.

How it works

Author-identity fields appear across formats:

• Documents — office core properties include creator (original author) and lastModifiedBy (last person to save). PDFs carry an Author field. These usually come from the OS account or the app's configured user name.
• Images — EXIF/IPTC/XMP can include an Artist, Creator, Owner, or copyright field. Some cameras and apps let you configure an owner name that is then stamped into every photo.
• Software/producer overlap — while Software/Producer name the tool, they sometimes embed an account or organization string alongside the version.

Two files from the same person often share the same author value, which lets an analyst cluster files by likely creator. And because lastModifiedBy can differ from creator, a document can reveal two identities: who originally wrote it and who last touched it — a common finding when a template or a colleague's file is reused.

Practical example

A challenge provides three unrelated-looking files and asks, "Which two were made by the same person?" You read the author fields on copies of each (illustrative):

report_a.docx   creator: m.okafor    lastModifiedBy: m.okafor
photo_b.jpg     Artist : m.okafor
notes_c.pdf     Author : t.singh

The shared value m.okafor links report_a.docx and photo_b.jpg to one account, answering the challenge, while notes_c.pdf points to a different person. In a reconnaissance scenario, harvesting creator/lastModifiedBy from a set of an organization's public documents could yield a list of likely valid usernames — exactly the kind of information a defender wants to prevent leaking.

Cybersecurity relevance

Author fields sit at the intersection of attribution, reconnaissance, and privacy. For investigators, they provide attribution leads and let you cluster files by creator. For attackers performing OSINT, leaked author names from public files are a cheap source of valid usernames for phishing or password attacks, and they reveal internal naming conventions (for example first.last). For defenders, this is a direct argument for metadata sanitization before publishing any file: an author field can quietly disclose staff identities and account formats. The responsible-use point is essential — author fields are investigative leads to be corroborated, and the same data that helps an analyst can harm a real person's privacy if mishandled.

Common mistakes

• Treating an author field as proof of identity rather than as the configured/account name the software stamped.
• Checking only creator and missing lastModifiedBy, overlooking a second person involved.
• Forgetting images can carry author/owner fields too, not just documents.
• Ignoring that these fields are editable, so a name can be blank, generic, or deliberately faked.

Key takeaways

• Author fields (creator, lastModifiedBy, Author, EXIF Artist/Owner) tie a file to a person or account.
• Their values usually come from the OS account or the app's configured name, so they leak real usernames unintentionally.
• They are powerful attribution and clustering leads but are not verified identity — corroborate them.
• Leaked author fields aid reconnaissance and threaten privacy, which is why sanitizing metadata before publishing matters.

Check your understanding

• Where do author fields typically get their values, and why does that make them a privacy risk?
• Why should an author field be treated as an investigative lead rather than proof of who created a file?