In NTFS forensics, what do the M, A, C and B timestamps each record?

## The four fields Every file and directory on an NTFS volume carries four timestamps, abbreviated **MACB**: | Field | Name | What actually updates it | |---|---|---| | **M** | Modified | A write to the file's **data** | | **A** | Accessed | A read of the file — where the OS is recording reads at all | | **C** | Changed (MFT-entry modified) | A change to the file's **metadata record**: rename, attribute or permission change, move within the volume, size/allocation bookkeeping | | **B** | Birth (created) | The file first coming into existence **on this volume** | The single most common mistake is reading **C as "created"**. It is not. C stands for *changed*, in the Unix `ctime` sense — the inode or MFT record changed. Renaming a file that nobody has opened in a year updates C and leaves M, A and B alone. Conversely, the creation time is **B**, and B answers a narrower question than people assume: *when did this file appear here*, not *when was this content authored*. ## Copies, moves and downloads This matters because file arrival is the most common thing you are actually looking at. When a file is copied onto a volume — a download, a sync client writing a file, a copy from a share — a **new** file is created, so **B is the time of the copy**, while **M is inherited from the source** and can be months older. A move *within* the same volume is a rename: it updates C and leaves B and M as they were. A move *across* volumes is a copy plus a delete, so it behaves like a copy. Reading a set of MACB values without knowing which of these produced them is how examiners talk themselves into a story the file system never told. ## Stored in UTC, shown in local time NTFS stores each of the four as a 64-bit **FILETIME**: 100-nanosecond intervals since 1601-01-01, in **UTC**. The local-looking time in a directory listing or a forensic tool is a conversion applied at display, using whatever zone the operating system or the tool was configured with. Two examiners can look at the same volume and print two different times for the same file and both be reporting the same stored value. Removable media formatted FAT or exFAT are different again — those record local time at coarse resolution with no zone attached, so a file's dates shift when it moves between machines in different zones. ## A is the weakest field Last-access updating on Windows has been switched off or throttled by default for many years — the `NtfsDisableLastAccessUpdate` setting controls it — and even where it is on, updates are written lazily rather than on every read. On top of that, antivirus scans, backup agents, search indexers and an examiner who mounted the volume read-write all touch files without a human ever opening them. So a fresh A value is weak evidence that a person read the file, and a stale A value is not evidence that nobody did. ## What MACB can and cannot support MACB records **file-system operations carried out by some process running under some account**. It does not record a person, an intent, or the application that did the work. "The file was created at 22:16:44 UTC" is a defensible statement from the MFT record. "The user created the file at 22:16:44" is a different claim that needs other artefacts — an application log, an authentication record, a proxy entry — to support it. ## Orderings worth recognising - **B equal to C, both later than M** — the file arrived here as a copy, carrying the source's write time. - **M later than B** — the content was written after the file appeared here: ordinary editing in place. - **C later than M, M unchanged** — metadata moved without the data: a rename, a permission change, or an in-volume move. None of these is a conclusion on its own. Each is a hypothesis about a file-system operation that you then confirm against a second source that recorded the same event from a different angle.