$MFT lives at the start of every NTFS volume and Windows holds an exclusive lock on it for as long as the volume is mounted. xcopy will fail. Robocopy will fail. A naive PowerShell Copy-Item will fail or, on certain configurations, silently produce a truncated copy that looks correct in size and is internally broken. You need a tool that reads the raw volume, bypasses the filesystem lock, and assembles $MFT from its cluster runs.

There are three options I trust in practice. They cover the live-host triage cases I see week to week.

Option 1: KAPE, the default for IR

If you are doing incident response and you are on a Windows host, the answer is KAPE with the MFT target. It pulls $MFT, $MFTMirr, $LogFile, $UsnJrnl:$J, $Boot, $Secure:$SDS, and a handful of related files in one pass, preserves the original timestamps on the collected files, and writes a tidy directory tree you can carry to analysis.

kape.exe --tsource C: --target MFT --tdest C:\triage --vss

--vss is the flag people forget. It tells KAPE to also pull $MFT (and the rest of the target) from every Volume Shadow Copy on the source. Older snapshots are independently useful and you should collect them as a matter of course. See Volume Shadow Copy and $MFT for what to do with them.

KAPE handles the locked-file problem by using the raw volume reader from RawCopy.exe under the hood. The collected file is bit-identical to what a forensic image would yield. Use it unless you have a specific reason not to.

Option 2: FTK Imager, the GUI fallback

FTK Imager remains the standard free GUI tool for acquisition. It is what you reach for when KAPE is not on the host and you need to grab $MFT once and walk away. The workflow:

File → Add Evidence Item → Physical Drive (use Logical Drive only if you are working off a remote share or mounted image).
Pick the disk and let it enumerate volumes.
Expand the NTFS volume's root in the tree on the left. $MFT, $MFTMirr, $LogFile, $Volume, $AttrDef, $Bitmap and the rest of the metadata files are visible there even though Explorer hides them.
Right-click $MFT → Export Files. Hash it (SHA-256) immediately.

FTK Imager reads the locked volume by mapping the physical device and parsing NTFS itself. The export is the actual on-disk file, fixup arrays and all.

The same workflow reads .dd, .E01, and .AFF4 images. If you have an offline image, mount it as evidence and use the same export path.

Option 3: fsutil and a raw read, when you cannot install anything

On a hardened host where you cannot drop KAPE or FTK Imager, the built-in fsutil command will tell you where $MFT lives:

fsutil file queryextents C:\$Mft

Output is a list of (Virtual Cluster Number, Logical Cluster Number, length) triples. To turn that into a file you read the raw volume at each LCN and assemble. Powershell with a P/Invoke into CreateFile(\\.\C:, GENERIC_READ) does the job; so does any of the small PowerShell raw-read modules on GitHub. RawCopy.exe from Joakim Schicht (the same code KAPE uses under the hood) is the simplest standalone.

This is a building block, not a final answer. Use it when policy forbids loading other tooling.

What people get wrong

Copying with Copy-Item -Force. Sometimes it succeeds and you get a file. That file is whatever Windows returned from a normal ReadFile call against the open handle, which on most builds is not the real $MFT. Always verify with fsutil file queryextents that the size matches.

Forgetting $MFTMirr and the transaction logs. $MFTMirr is sixteen records of insurance. The transaction logs ($LogFile, plus the per-resource $TxfLog files under $Extend\$RmMetadata) carry the operations that may not have hit $MFT yet at the moment of acquisition. Acquire them together. KAPE does this for free.

Not pulling the USN journal. $UsnJrnl:$J is essential for timeline reconstruction (see pairing the journal with the file table). It rotates, which means waiting two days to come back for it loses evidence. Grab it the first time.

Collecting from a live system without VSS. The live MFT is consistent at the volume level (NTFS is journalled), but if the host is busy you may collect a $MFT and a $UsnJrnl that disagree by tens of seconds because the MFT was read first. Take a VSS snapshot, then read both from the snapshot. The snapshot freezes them.

Trusting the wrong timestamp on the collected file. The "modified" time on the exported $MFT is whatever your collection tool set. Hash the bytes, write the hash and the acquisition time to a separate log, and reference that log everywhere.

A VSS-based acquisition that I actually use

When I am on a live host and I want a clean point-in-time $MFT plus journal plus log, this is the snippet:

vssadmin create shadow /for=C:

Read the Shadow Copy Volume Name from the output, then use that path as the source for whichever tool you prefer:

robocopy "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN" "D:\triage" "$MFT" "$MFTMirr" "$LogFile" "$Extend\$UsnJrnl:$J" /R:1 /W:1

Robocopy can read from a VSS device path because the snapshot is mounted as a separate volume without the live exclusive lock. Hash everything once it lands, delete the snapshot if it is yours to delete (vssadmin delete shadows /shadow={GUID}), and walk away.

This is the cleanest live acquisition I know that does not require installing anything beyond what ships in Windows.

Reading from a disk image

If you already have a .dd or .E01 image you skip the locking entirely. Mount the image read-only (xmount, ewfmount, vshadowmount for VSS-aware images) or use a parser that consumes images directly. $MFT always sits at LCN MftStartLcn from the boot sector at offset 0 of the partition. Sleuth Kit's icat -o <partition_offset> image.dd 0 extracts the file. Inode 0 is always $MFT.

Verification before analysis

Hash the file (SHA-256) immediately after acquisition. Hash it again before parsing. Mismatches happen more often than people admit, usually because of mid-acquisition disk pressure or copy tools that retry partial reads silently.

Then run a structural check. Parse the first ten records, confirm the FILE signature on each, confirm record 0 is $MFT itself with a self-referential $DATA runlist, confirm record 1 is $MFTMirr, confirm record 5 is the root directory with a $INDEX_ROOT attribute. If any of those fail, the acquisition is bad and you need to repeat it. MFTECmd and mft_dump will both throw warnings on a corrupted file; do not suppress them.

Extracting $MFT from a live Windows host without breaking it