In the first of this 3-part blog series, we covered the implications of promoting files to “Evil Twins” where they can be created and remain in the system as different entities once case sensitiveness is enabled.
In this 2nd post we try to abuse applications that do not work well with CS changes, abusing years of “normalization” assumptions.
It is worth noting that the impact of this change will vary depending on the target folder.
Out of the box, Windows provides a tool to change CS information by invoking the underlying API NtSetFileInformation with FILE_CASE_SENSITIVE_INFORMATION flags.
This tool contains several checks at user-mode level to restrict the target folder but, as usual, it can be easily bypassed using different path combinations. It is possible to create a tool or invoke the API from PowerShell to remove these checks.
Let us go over the following scenarios:
- Changing ROOT drive CS:
- fsutil restrictions will be bypassed and most of the console will not work unless you specify full paths (mostly due to environment variables broken on case-sensitiveness).
- Combinations to bypass this check include:
- \\?\C:\ (by drive letter with long path)
- \\.\BootPartition\\ (by partition)
- \\?\Volume{3fb4edf7-edf1-4083-84f8-7fbca215bfee}\ (volume id)
- Change “protected folders” CS.
- For some folders is not enough to be Administrator, but to have other type of ACL’s instead.
- TrustedInstaller has the required permissions to do so and… you just need Admin permissions to change the service path:
If you change Windows folder case sensitiveness by using the same technique, Windows will not boot anymore.
These scenarios introduce new unexpected behaviors in the current applications, like for instance:
- There is a folder with CS enabled and two directories with the same name, different case.
- Trying to change CS will fail due to “multiple files/folders with the same name already exists” check.
- Move to recycle bin on one of the folders.
- Change CS of the folder.
- Restore the deleted file.
- The contents of the deleted file overwrite the one originally kept.
Screenshots
Left: Root drive with case sensitive enabled.
Right: Program Files CS changed thanks to Trusted Installer ACL. If an application is not considering the proper case, next time it tries to execute a binary whose name may be normalized (to uppercase) it can spawn a different app.
Watch the video recorded by our expert Cedric Cochin illustrating this technique:
Protection and Detection with McAfee Products
- Products that rely on SysCore will protect C:\ from case sensitive changes
- Endpoint Security Expert Rules
- Active Response:
- Create a custom collector to query Case sensitiveness of important folders.
- Search for fsutil executions (or even History Processes if that collector is part of your Active Response version)
- “Processes where Processes name equals fsutil.exe”
- MVISION EDR:
- Realtime search
- “Processes where Processes name equals fsutil.exe”
- Search for fsutil execution in the historical view
- Realtime search
Artifacts involved:
- NT attributes change
- Fsutil execution
- Trusted Installer service changes
Outcomes for this technique include:
- A ransomware could create C:\Windows\SYSTEM32 and cause a BSOD on next restart
- Change dll being loaded or an event stops application from starting
The post The Twin Journey, Part 2: Evil Twins in a Case In-sensitive Land appeared first on McAfee Blogs.