4

When I run CheckDisk on a Windows 8 Consumer Preview volume, I get:

> chkdsk /v S:
The type of the file system is NTFS.
Volume label is Windows 8.

WARNING!  F parameter not specified.
Running CHKDSK in read-only mode.

CHKDSK is verifying files (stage 1 of 3)...
  91392 file records processed.
File verification completed.
  28 large file records processed.
  0 bad file records processed.
  20224 EA records processed.                 <------------------ huh??

Why are there so many extended attributes on the volume? I thought no one used EAs anymore...


Edit:

As an example, the file \Windows\CSC\v2.0.6 has an extended attribute that contains the string

Ԡ 1X C8A05BC0-3FA8-49E9-8148-61EE14A67687.CSC.DATABASE P X Չ: Չ: ˌΦ]cᑡPcďŠ 4 C8A05BC0-3FA8-49E9-8148-61EE14A67687.CSC.DATABASEEX1 P X _, N0t 08 C8A05BC0-3FA8-49E9-8148-61EE14A67687.CSC.EPOCHEA 8 ͌Φ]cᑡPcďŠ }

which (thanks to an answer below) seems to be related to client-side caching of offline files.

However, it seems like most other EAs are different -- e.g. the file

\Program Files\WindowsApps  
    \Microsoft.BingFinance_1.0.1022.0_x64__8wekyb3d8bbwe\pages\ETF\js\ETF.js

and most other files contains (mostly) the string $KERNEL.PURGE.APPXFICACHE, which doesn't seem to be related. What might this be for?

3 Answers 3

4

Extended attributes ARE used in Windows, including by the kernel, which uses them to track various security restrictions and enforce them.

See https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/kernel-extended-attributes

Notably the USN journal of NTFS will be able to safely track changes made to files, so that filesystem snapshots or recovery of the filesystem after an unexpected brutal shutdown (caused by power loss, overheat, or BSOD and reboots) are reliable. These are short secured records added in small EA streams (generally stored themselves within the MFT record without allocating any additional extent, unless the MFT record is too small to fit all streams, in which case they will be inserted in separate NTFS extents allocated for "non-resident" attributes that don't fit in the fixed-size MFT record which is generally small and about 1KB, but where some file attributes will ALWAYS be fitted, including basic attributes, and the special attribute containing the map of allocated extents for streams that exceed the capacity, such as the default "$DATA" stream for regular file contents, or indexes for directories; which stream will fit in the MFT record depend on the size of MFT record, which may be tuned when formatting the MFT volume, but which is generally 1KB, i.e. smaller than regular "clusters" used to allocate space for extents)

Some extended attributes managed by the kernel are:

  • "$KERNEL.PURGE.ESBCACHE": apparently this is used by "Branch Cache" to facilitate the deployment and system updates on remotely managed hosts, allowing domains to enforce their own policies (rather than the default local policies or policies defined by default by Microsoft in Windows).

  • "$KERNEL.PURGE.SEC.FILEHASH": it contains a strong file hash (and the hashing algorithm used) of the file contents: this allows filesystem recovery to detect content corruption.

  • "$KERNEL.PURGE.SEC.CODEINTEGRITY": this small EA contains the code integrity policy flags

  • "$KERNEL.SMARTLOCKER.ORIGINCLAIM": it securely tracks the application that created the file (i.e. the path of its installer or MSI package containing reference signatures)

  • "$CI.CATALOGHINT": this contains the name of a secure *.cat file in Windows catalogs for the package containing a source for that file. Tools like "SFC /SCANNOW" or "DISM /Online Cleanup-Image ScanHealth" can inspect them, and with the help of the previous EAs, it will be be able to securely identify the original package containing the file from which it was installed (if necessary, Windows Update will be able to find, download and reinstall a copy of these packages).

  • DO NOT CONFUSE the last two EAs, with the "Zone.Identifier" that IE (or other web browsers for Windows) are adding on files you download from the web, or that un-archivers are adding to files you extract from a downloaded ZIP or cabinet file (or other archive formats), by copying it from the "Zone-Identifier" of the archive/cabinet file itself: these are not EAs, they are stored as "Alternate Data Streams" (ADS's) which are attributes of type "$DATA" (like the regular content of the file, except that this $DATA has a non-empty name, where as the regular content of the file has an empty name); as well, these ADS only exist if they are stored in NTFS or compatible file systems, and they are NOT checked by the kernel, but by the user interface (mainly in the file Explorer) and not always preserved when copied elsewhere (e.g. when moving such tagged files into a ZIP file). These ADS's are very weak, they are not as strong as EAs or other signatures systems (like external secure catalogs, or Authenticode signatures inside executable files, or some medias formats allowing similar signatures inside the regular content of the file; to secure the system, the kernel does not need and uses these legacy ADS, it uses Authenticode, and secure catalogs otherwise, e.g. in the Drivers database or in Windows catalogs like WinSxS). Alternate data streams are deprecated, but still used in web browsers only for that purpose, just as an hint for users, but they do not resist basic operations that users may still do, including bypassing the alert that Explorer would show them (but not always, as they are frequently not preserved). As well, web browsers may not necessarily append these "Zone.identifier" ADS, if the downloaded files use a stronger signature mechanism, or if they are downloaded by a specialized service in the background (such as Windows Update itself which uses securely signed catalogs).

Depending on tools and OS features that you use, or with some drivers, you may have other EAs defined. Many security tools and antimalware add their own EAs to various files or directories (also helping these tools to scan changes more efficiently).

If you use the Microsoft Store, or AppX deployment tools on Windows, there will also be additional EAs for setting the virtual environnement on which they will run (e.g. global settings per machine, or per domain or per user or per online "identity" depending on the remote service you'll use or with which third party you'll communicate, copy-on-write or full duplication, delayed writes or sync'ed writes, sharing options or policies, granted licences and usage rights, trackers for subscription/payment options on online services; some apps also use them also just like tracking cookies on web pages and will then store personal identifiers or preferences specific to some file contents or apps, and will be able to sync them with online personal profiles, so that you can use these apps offline, at least for a given period of time...).

If you use some cloud services (not jsut those from Microsoft), they can also sync a local copy for files you use locally the most, while allowing files to be archived online or synchronized to other devices).

Generally EAs are very small (about 100 bytes or so for most of them). Any file in NTFS/ReFS (and other supported filesystems) can have many EAs attached to them for many different applications. The way these EAs are individually encoded is application-dependant. EAs have their own names (like regular files in visible directories, and like ADS streams), except that these names are not intended to be read by humans; so these names are "technical" and not using Unicode. Some EA name prefixes are reserved by Microsoft on Windows filesystems.

Whever these EAs will be resident of not in the MFT (of NTFS or ReFS filesystems) depend on how many are present for a given file. IF they don't fit in the MFT record, NTFS will allocate some extents to locate them elsewhere on the volume. The list of EAs defined for a file are one of its streams, just like the standard attributes, or security attributes (ACLs) or the regular content, or additional streams (such as the stream that tracks that a file was downloaded from the net and may be unsafe, it may track its web domain or IP of origin, and if that domain was accessed with a secure protocol like HTTPS: this allows Windows to display authorization popups for the User, or ask for user elevation permission; ZIP/CAB files have such stream, added by web browsers and safe downloaders; and zip extracting tools will also propagate that stream on each extracted file if it may be executable or have side effects, including HTML files, fonts, Javascripts, media files, or office documents, that will be opened by default in safe mode by applications using them and that will alert the user that some embedded components like scripts or fonts may be unsafe) It is true that some EAs were designed to provide compatibility with OS/2 or MacOS (only these EAs are deprecated), but there are still other systems added and using them. And new security systems (including in Windows itself in its kernel or in its services and features) constantly add new ones.

EAs are a key feature of NTFS (and ReFS). They also exist in other non-Windows filesystems (including Ext4 on Linux); for some filesystems that don't have native support for them, they may be stored in a separate subdirectory or in files with special names. EAs are normally not displayed in directory contents (for filesystems that implement them) and do not count in the regular file-sizes, so they can be added/removed easily without altering the regular content; they also allow different applications, services or OSes to interoperate with the same files by safely associating their own metadata. So they are safe extensions of existing filesystems (most of the time applications don't have to care about them, the OS or its services will manage them, most often for security reasons and inspection)

EAs are definitely not deprecated. In fact there are much more frequently used today, and have many variants created by the many security solutions developed (if you look at Windows 11, it uses more of them; if you are using Azure services, or join an AD domain, there will be additional EAs, if you use various security tools, not just those from Microsoft, they will add their own, some apps also use them to store DRM right trackers on your purchased medias, along with the decryption keys if needed, plus securely signed counters of devices on which they were authorized, you need to logon to the services to update these signatures or remove a device and its authorizations; EAs have plenty of possible uses, not just for security, but as well for optimizing performances by including processing hints and traces or statistics specific to a given usage; they can also be used to track backups and replications/mirrorings, better than the single legacy "ARCHIVE" bit; EAs have their own distinctive names and are creating a sort of "parallel" filesystem, except that they are generally optional and just the appropriate files or directories needing them will get those EAs). The interest of placing EAs in the core NTFS/ReFS filesystem structure (i.e. resident in MFT records, or their extension in a non-resident special attribute used as a container for more attributes not fitting in the MFT record) is that their placement is ideal rather than using a separate store elsewhere on volumes (this would be slower, especially when working with network filesystems or hard disks and disk arrays, due to access time: EAs can be retrieved very fast at the same time as basic file attributes are loaded; and they are easier to add/remove dynamically)

3
  • Just a note, I asked this question in 2012 specifically about Windows 8, whereas my searching suggests the EAs you're citing as examples might actually be from Windows 10 and 11? It would be great if you could at least list what $KERNEL.PURGE.APPXFICACHE (which I cited in my question) does, since otherwise your answer (as good content as it may otherwise be) seems to be about a different OS than I had actually asked about!
    – user541686
    Aug 9, 2022 at 8:26
  • I first replied to your initial question and your incorrect statement that EAs are no longer used. You added $KERNEL.PURGE.APPXFICACHE in a further edit. But this is one of the EAs that the kernel may need to add (and there are more). Yes it is related to the introduction of kernel-supported "containers" for running AppX applications safely (i.e. properly isolating them, possibly with additional "shims" restricting them, or adding some additional rights that normally are restricted in Windows containers). There are more EAs in Windows 8.1/10/11 and other editions: Pro/Enterprise/Server...
    – verdy_p
    Aug 20, 2022 at 16:41
  • As well there are specific EAs for specific domains your PC or your user account is joined to, in order to securely enforce their domain policies. If you use other non-AD domains, their connection service may add their own (some of them supported directly by the kernel, others by system services, or user services like backup/recovery or synchronization services that you've subscribed to, or for search engine indexers, or if you use other filesystems running on top of NTFS for correct emulation and performance).
    – verdy_p
    Aug 20, 2022 at 16:47
3

Based on the EA name "CSC.DATABASE", one might guess it is related to client-side caching. That would also explain why there are so many of them, since each cached file probably has them to identify them with the server.

Also, I don't think EAs are particularly seldom used at all. I know for sure that they are used, for instance, by IE to identify a file as having been "downloaded from the web" (which makes Windows Explorer ask before running the file and such things).

9
  • 1
    +1 for the client-side caching, I'll take a look to see if that's also the case for other files. However: note that EAs (extended attributes) are not the same as ADSs (alternate data streams)! The latter is used by IE to store the attachment zone information that you mentioned, but EAs, as far as I know, were only for compatibility with other OSes (OS/2?) -- people don't use them much, AFAIK.
    – user541686
    Mar 4, 2012 at 8:05
  • 1
    No, "downloaded from web" is not stored in an EA, it is stored in a named stream (of type $DATA); you an even see them and edit them in Notepad. It can have arbitrary content even if it is usually very small (and so it is a most often resident in the MFT record and does not allocate extra space, unless there are too many attributes, in which case it may fit in extents allocated for extra attributes not fitting in the MFT record, usually limited to 1KB, including the first attribute for BASIC_ATTRIBUTES). EAs can then frequently be non-resident, like data streams of files > than ~600 bytes.
    – verdy_p
    Aug 12, 2022 at 18:01
  • the only streams in the MFT that MUST be resident in the MFT record are the BASIC _ATTRIBUTES and the attributes storing the root table of allocated extents. File names, $DATA content streams, alternate named $DATA streams (ADS) may be non-resident, by allocating a special stream for extending the size of attributes that don't fit the MFT record. ADS are rarely used they frequently don't survive when files are copied/moved to other volumes that don't support extra attributes (e.g. FAT32), they will be silently dropped.
    – verdy_p
    Aug 12, 2022 at 18:08
  • On the opposite, moving files to other volumes that don't support EA will be signaled, as they are frequently used for serious security purposes. The "downladed from the web" ADS is just a weak indicator, used by the File Explorer to show you an alert if you open them with it, they are not applying any restriction, they can be bypassed by any user. They are added to files by web browsers or other download tools when they download these files (from untrusted sources).
    – verdy_p
    Aug 12, 2022 at 18:11
  • EAs offer much more facilities than basic ADS: they are structured, have subtypes in addition to unique names (and you cannot name them freely like ADS). There can exist a lot of distinct EAs for the asme file, created by many apps, tools or services. It's not easy to drop them (but it's trivial to drop any ADS from files without any additional administrative privileges, so ADS are not used for system files).
    – verdy_p
    Aug 12, 2022 at 18:15
0

This site points to CodeIntegrity aka Windows Defender Application Control as the source of the ESBCache & CatalogHint attributes. https://www.exploit-db.com/exploits/43162

I believe that to be more accurate than the reference to Branchcache and SFC /SCANNOW. These might use that data as well, although I haven't been able to prove that conclusively.

This post explains what the majority of the EA's are. TL;DR ESBCache & CatalogHint make up the biggest amount of data. https://posts.specterops.io/host-based-threat-modeling-indicator-design-a9dbbb53d5ea

1
  • 1
    Wow, interesting. Isn't this a security hole (different from the one linked)? Anyone can mount an NTFS drive (just plug in a USB...), so if a Kernel EA is used to cache the signature validation info, then someone can just mess with the disk on a different machine before plugging it in, right? I wonder what information they actually cache in an EA...
    – user541686
    Aug 22, 2022 at 15:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .