Can you trust the compile timestamp in a PE header to date a malware sample?
Short answer
Not on its own. The COFF header's TimeDateStamp is documented as indicating when the file was created, but nothing in the PE format authenticates it: the specification says values 0 and 0xFFFFFFFF are not real timestamps, and reproducible builds (IMAGE_DEBUG_TYPE_REPRO) deviate from the normal time_t format. Treat it as a weak, corroborating clue next to other evidence, not as proof of when a sample was built.
Analysts love the PE compile timestamp because it looks like free attribution data. The gotcha is that it is just a number the toolchain wrote into the header.
What the specification says
Microsoft's PE format documentation defines TimeDateStamp in the COFF file header as the low 32 bits of a C run-time time_t value that "indicates when the file was created." The same page also notes that a stamp value of 0 or 0xFFFFFFFF "does not represent a real or meaningful date/time stamp", and refers to IMAGE_DEBUG_TYPE_REPRO as an exception to the usual time format. That debug type exists for reproducible builds, where deterministic output is the goal.
Why that makes it weak evidence
The loader does not verify the field, and nothing in the format signs it (this is my inference from the spec, not a quoted statement). Anyone who can rewrite header bytes, or whose toolchain emits deterministic or zeroed stamps, controls what you see. Compile time in the future or in 1992 is a classic red flag, but a plausible value is not a proof either.
How to use it well
- Compare it against other artifacts: debug directory entries, the Rich header, embedded resources, first-seen dates in public sandboxes.
- Look for clusters across a campaign rather than trusting a single sample.
- Record it in the report as "claimed compile time".
Why the distractors are tempting
The "cryptographically bound" and "Windows rejects future timestamps" options invent enforcement that does not exist. "File size" confuses it with another header field.
What interviewers want
"Useful but untrusted: corroborate it." Mentioning the 0/0xFFFFFFFF and reproducible-build caveats shows you have read the spec.
Likely follow-ups
- What other artifacts can corroborate a build date (Rich header, debug directory, resources, VirusTotal first-seen)?
- What does a timestamp of zero usually suggest about the toolchain?
- How is this different from NTFS timestomping?