This post outlines the finding and analysis of CVE-2025-59284, a libarchive vulnerability in Windows abusing hardlinks to leak NetNTLMv2 hash upon any file opening or archive extraction. Initial Idea During some research we stumbled upon the Windows feature of file- and folder-links. A feature we knew existed but didnt really dig into yet. From doing pentests on linux based systems we were aware that this could potentially be misused or exploited if wrongly configured by Microsoft, so this caught our curiosity. Different link-types in Windows Windows generally incorporates 3 major link types: Symlinks Junctions Hardlinks There are also 2 additional forms of links, but they wont be covered here: 32bit UAC file virtualization Bindlinks Reparse points are metadata attached to a file or directory ( reparse tag + reparse data ) that causes name resolutions to “replay” with the new metadata inputs. If a caller tries to open C:\A\B\C the filesystem tries to resolve its components. When it hits a FILE_ATTRIBUTE_REPARSE_POINT entry it will look at its reparse tag . When there exists a handler for said tag, the opening to that path is “reparsed” and the handler provides a “replacement path” and path resolution starts using that replacement. Symlinks are filesystem object whose MFT entry includes a reparse point with tag IO_REPARSE_TAG_SYMLINK = 0xA000000C . This link object can be created either as a directory or a file (and even registry keys), allowing symbolic links to either point to and be treated as a file or directory. Symbolic links can also point to a UNC Path allowing access to remote objects. However the creation of Symbolic links ( CreateSymbolicLink ) only works with elevated privileges or if developer mode is enabled! Junctions is a directory reparse point using the mount point tag IO_REPARSE_TAG_MOUNT_POINT = 0xA0000003 . Conceptionally Junctions are similair as volume mount points and can only be created on folders. They can be created from low privileged users, but they can not be pointed to a UNC path upon creation. Hardlinks are not reparse points and do not trigger pathname substitution. On Windows at the NTFS filesystem level each file has a single Identity ( file record / file ID ). A hardlink adds another directory entry pointing to that same file record, and the target file’s metadata hardlink count gets increased. They only work on NTFS and only for files. You can create them from low privileges, however since the file ACL’s are inherited, you need to have write-privileges over the target file pointing to. Also hardlinks can’t point to a UNC path on creation and must reference something on the same filesytem Volume. Understanding all low-level details can be difficult and was not necessary for finding this bug. On the very low level you can play with those objects and create unexpected results. See James Forshaw’s symbolic-testing-tools and his blogs for more. For understanding how we found the bug and why it works it is enough to remember this table: Link type reparse point? points to only with special privileges can point to UNC Symlink yes File or Folder or registry entry yes yes Junction yes Folder only no no Hardlink no File only no no How to deliver them? Since all link types needs to be recognized and therfore be baked into the filesystem in some form or the other you cant deliver them purely as a file ( even though there is the .symlink file for symlinks on Windows, but we didnt have much success yet playing with them). The most easy way to deliver them would be trough .vhd(x) files, but since you need to hold high privileges or be in developer mode to mount those, we didnt spend time bothering with that. Therefore the best option left for us were container files. Why this sounded promising without us knowing if any container file existed to hold or create them? Because there has to be a way for users to propagate links between systems and backups. Also creating links on linux and deliver them packed to Windows machines was probably something Microsoft and other vendors already thought of. We needed something that obeys NTFS file structures or links and decided to look into .iso files first. But this didnt yield any results, so we were left with archive files. To our advantage, Windows 11 added support for more archive formats by implementing a merge of the libarchive project . Which link to choose? On first glance symbolic links looked the most promising. They have the most features and can point to UNC paths which is always something that can easily be abused to leak NetNTLMv2 hashes. Even though they need admin privileges to be created, we had high hopes that Windows or libarchive is doing some file operations on the target before trying to create them. (e.g some form of “is target resolvable/existing” checks, leading to a CreateFile call and then to hashleak). Unfortunately this wasn’t the case and was in fact something other people already looked into as discussed in here . Playi...