{
	"id": "9c2a6715-09de-46ca-9dad-257f991a488d",
	"created_at": "2026-04-06T00:11:06.412364Z",
	"updated_at": "2026-04-10T13:13:02.093822Z",
	"deleted_at": null,
	"sha1_hash": "27f32a923cb028de97293aec945245780d7e34be",
	"title": "NTFS File Attributes",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 131033,
	"plain_text": "NTFS File Attributes\r\nBy kexugit\r\nArchived: 2026-04-05 18:26:14 UTC\r\nIt is time once again to delve into the fascinating world of NTFS! So far I’ve outlined how files become more\r\ncomplex as they grow, the different metafiles found in the MFT, and then the different parts of Windows storage\r\nthat results in the infamous 2TB size limitation.\r\nToday I want to list out most the different attribute types that a file can have. Think of these as the building blocks\r\nfor the file itself. No file will have every attribute type. In fact most just have a few.\r\n$STANDARD_INFORMATION – General information about the file. Creationtime, LastModificationTime,\r\nLastChangeTime, and LastAccessTime are all stored here.\r\nNOTE: Even if the updates to LastAccessTime are disabled, the old time will still be stored here.\r\nFileAttributes are also stored here. Do not confuse FileAttributes with the file’s attribute types. FileAttributes are\r\njust flags and can mark the file as being...\r\nRead-only Archive\r\nHidden Compressed\r\nSystem Encrypted\r\nThere are more flags but these are the really common ones.\r\nimage\r\nSo when you make changes to the file in this part of the UI, you are actually changing the FileAttributes flag of\r\nthe $STANDARD_INFORMATION attribute type.\r\nAlso, this attribute holds a SecurityID. Do not confuse this with a security descriptor. Those are stored elsewhere.\r\nThe SecurityID is used to help locate the correct security descriptor for the file in question.\r\n$ATTRIBUTE_LIST – This attribute type keeps a list of all of the file’s attribute types. But it only exists if at\r\nleast ONE of the attribute types is nonresident. So if you have a file with five attribute types and one is\r\nnonresident, an $ATTRIBUTE_LIST will be added to the file.\r\nTo get a good visual of how the $ATTRIBUTE_LIST is used, refer to my blog on file growth.\r\nhttps://blogs.technet.microsoft.com/askcore/2010/08/25/ntfs-file-attributes/\r\nPage 1 of 5\n\nhttps://blogs.technet.com/askcore/archive/2009/10/16/the-four-stages-of-ntfs-file-growth.aspx\r\nBut basically, the $ATTRIBUTE_LIST will tell you at what FRS (file record segment) you will find each of the\r\nfile’s attribute types. For attribute types that are resident, it will just point back to its own FRS.\r\n$FILE_NAME - This is where we store the file name. No, really. In addition there are also fields for\r\nCreationtime, LastModificationTime, LastChangeTime, and LastAccessTime. These are not updated as often as\r\ntheir counterparts in the $STANDARD_INFORMATION attribute type.\r\nThis is also where we keep track of what directory the file belongs to. So if the parent directory incorrectly\r\nremoves the still active file from its index, running CHKDSK will have enough information about where the file\r\nshould live to be able to recover this ‘orphaned file’.\r\n$VOLUME_VERSION – This attribute type contains volume information, or at least it used to. It hasn’t been\r\nused in a very long time. It only existed in early versions of Windows NT. I’m only including it in the list to be\r\ncomplete.\r\n$OBJECT_ID – This is an attribute that holds an ID. This ID is used by the Distributed Link Tracking Service.\r\nAn example of how it is used would be found in shortcuts. Make a shortcut on your desktop that points to a file.\r\nThen move that file. The shortcut will still function because it is using a way to tack the source file other than just\r\nthe path and file name.\r\nNot all files will have an $OBJECT_ID attribute. In fact, it isn’t until an actual ID is to be assigned that the\r\nattribute is added to the file.\r\nFor more information about the Distributed Link Tracking Service please use the following MSDN link.\r\nhttps://msdn.microsoft.com/en-us/library/aa363997%28VS.85%29.aspx\r\n$SECURITY_DESCRIPTOR – This is where security information for the file used to be stored. In newer\r\nversions of NTFS, Microsoft moved to storing all security information in a single file called $SECURE. One of\r\nthe main benefits of this was that files that had the same security on them didn’t need to store that information in\r\neach individual file.\r\nhttps://blogs.technet.microsoft.com/askcore/2010/08/25/ntfs-file-attributes/\r\nPage 2 of 5\n\n$VOLUME_NAME – This attribute exists in only one file in each NTFS volume...the $Volume file. This is one\r\nof the metafiles I listed in my blog NTFS Metafiles.\r\nhttps://blogs.technet.com/askcore/archive/2009/12/30/ntfs-metafiles.aspx\r\nIt is in this file, in this attribute that the name or ‘label’ of the file is found.\r\nMy volume is here is called Dave. The default name of a volume is New Volume.\r\n$VOLUME_INFORMATION – Also only found in the $Volume metafile, this attribute contains version\r\ninformation for NTFS and a field for volume flags such at the ‘dirty bit’.\r\n$DATA – When we think of a file, we typically just think of the data that is in it. The $DATA attribute is where\r\nthat data is located. This attribute is normally only found in files...not directories.\r\n$INDEX_ROOT – A directory will have an index that contains information about the files associated with that\r\ndirectory. If there are only a few index entries, they will all be found in the $INDEX_ROOT attribute. Once there\r\nare too many entries, they are moved to an $INDEX_ALLOCATION attribute. These index entries form a ‘b-tree’.\r\nThe layout of indexes is somewhat complex and I will probably do a separate blog for them. For this list, I’m\r\ntrying to keep it simple.\r\n$INDEX_ALLOCATION – See $INDEX_ROOT\r\n$BITMAP – The $BITMAP attribute is also part of the index structure. It keeps track of what parts of the index\r\nare allocated and which are free to be reused. It also provides a similar function to the $MFT file.\r\nhttps://blogs.technet.microsoft.com/askcore/2010/08/25/ntfs-file-attributes/\r\nPage 3 of 5\n\nDo not confuse this attribute with the $BITMAP metafile.\r\n$SYMBOLIC_LINK – Symbolic links, reparse points and hard links are commonly misunderstood. The\r\n$SYMBOLIC_LINK attribute is currently not in use. The MKLINK utility allows you to create symbolic links but\r\nit does so by creating a $REPARSE_POINT attribute.\r\n$REPARSE_POINT – This attribute is used when a symbolic link or mount point is created. There will be a\r\nReparseTag in the attribute that tells us what type of reparse point is being used.\r\nThere are other attribute types but for the most part they are obscure or obsolete. This list covers the ones people\r\nare likely to care about.\r\nRobert Mitchell\r\nSenior Support Escalation Engineer\r\nMicrosoft Enterprise Platforms Support\r\n“Demystifying NTFS as much as I’m allowed”\r\nAnonymous\r\nJanuary 01, 2003\r\nSorry to leave this comment so long without an answer.  I can see what you are trying to do, but it would\r\nbe better accomplished by creating an alternate data stream (ADS) and storing your information there.  It\r\nwouldn't affect the primary data stream (unnamed data stream) and it would follow the file.  An ADS\r\nwould actually exist in a separate data attribute.  \r\nAnonymous\r\nSeptember 28, 2011\r\nRobert, this is a good post!How extensible are NTFS attributes? Hypothetical example; To give developers\r\na way of marking files and folders as migrateable (defined as non-machine specific, non-cache, non-temp\r\nuser data), could a new entry be added to $STANDARD_INFORMATION to allow for this? Would this be\r\na huge undertaking re compatibility and other issues, or fairly simple to implement? I'm thinking in terms\r\nof backup tools like Robocopy.\r\nAnonymous\r\nOctober 31, 2013\r\nIt says under the $BITMAP attribute section \"Do not confuse this attribute with the $BITMAP metafile\". It\r\nshould actually read \"Do not confuse this attribute with the $Bitmap metafile\" since metafile are given as\r\nlowercase to distinguish them from attributes! It would avoid confusion if everyone stuck to this\r\nconvention.\r\nAnonymous\r\nOctober 18, 2014\r\nI am having problems with 3 USB external drives. My .jpg files are changed into folders and it is\r\nimpossible to open o delete them.\r\nAnonymous\r\nDecember 19, 2015\r\ni use windows 10 but i am facing nfts local disk c (access denied) problem\r\nhttps://blogs.technet.microsoft.com/askcore/2010/08/25/ntfs-file-attributes/\r\nPage 4 of 5\n\nSource: https://blogs.technet.microsoft.com/askcore/2010/08/25/ntfs-file-attributes/\r\nhttps://blogs.technet.microsoft.com/askcore/2010/08/25/ntfs-file-attributes/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blogs.technet.microsoft.com/askcore/2010/08/25/ntfs-file-attributes/"
	],
	"report_names": [
		"ntfs-file-attributes"
	],
	"threat_actors": [],
	"ts_created_at": 1775434266,
	"ts_updated_at": 1775826782,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/27f32a923cb028de97293aec945245780d7e34be.pdf",
		"text": "https://archive.orkl.eu/27f32a923cb028de97293aec945245780d7e34be.txt",
		"img": "https://archive.orkl.eu/27f32a923cb028de97293aec945245780d7e34be.jpg"
	}
}