Mark-of-the-Web: the rules changed, the tools didn’t

There are many CVE IDs assigned for various issues resulting in missing or improper Mark-of-the-Web (MOTW) propagation when extracting files from archives (#1, #2, #3, #4, #5, #6, and so on).

Some of these issues are disputed using the same template (inserted by MITRE):

  • Mark-of-the-Web propagation can increase risk via security-warning habituation – in other words, users are tired of such warnings;
  • the intended control sphere for file-origin metadata (e.g., HostUrl in Zone.Identifier) may be narrower than that for reading the file’s content – simply propagating the “Zone.Identifier” alternative data stream isn’t enough to adhere a possible security policy, although I haven’t seen any real-world examples of this not being enough, security policies (not to be confused with hunting rules) aren’t bound to fields other than “ZoneId”.

Microsoft treats MOTW in their software as a defense-in-depth feature which isn’t serviceable. Although bypasses observed in-the-wild get CVE IDs (e.g., CVE-2024-38217).

As a result, I’m not sure if MOTW is a security boundary, but here is another big issue…

Continue reading “Mark-of-the-Web: the rules changed, the tools didn’t”

Deceptive NTFS short file names

Are you aware of DLL hijacking? If yes, let’s suppose there is a program that executes the following line of code:

LoadLibrary('riched32.dll');

Its executable has the following name: “i_use_riched32.exe” (just as an example).

Now, take a look at the following contents of a directory containing this executable, the screenshots were taken of three tools: Explorer, FTK Imager Lite, The Sleuth Kit (each one points to the same directory).

svl-explorer
Explorer

svl-ftki
FTK Imager Lite

svl-tsk
The Sleuth Kit

Is the “riched32.dll” library hijacked for the “i_use_riched32.exe” executable? Let’s assume that no attempts to hijack the library have been made outside of the directory shown above.

Continue reading “Deceptive NTFS short file names”