What do you do when you’ve found an arbitrary file delete as ? Probably just sigh and call it a DoS. Well, no more. In this article, we’ll show you some great techniques for getting much more out of your arbitrary file deletes, arbitrary folder deletes, and other seemingly low-impact filesystem-based exploit primitives.NT AUTHORITY\SYSTEM

The Trouble with Arbitrary File Deletes

When you consider how to leverage an arbitrary file delete on Windows, two great obstacles present themselves:

1. Most critical Windows OS files are locked down with DACLs that prevent modification even by . Instead, most OS files are owned by , and only that account has permission to modify them. (Exercise for the reader: Find the critical Windows OS files that can still be deleted or overwritten by !)SYSTEMTrustedInstallerSYSTEM
2. Even if you find a file that you can delete as , it needs to be something that causes a “fail-open” (degradation of security) if deleted.SYSTEM

A third problem that can arise is that some critical system files are inaccessible at all times due to sharing violations.

Experience shows that finding a file to delete that meets all the above criteria is very hard. When looking in the usual places, which would be within , or , we’re not aware of anything that fits the bill. There is some prior work that involves exploiting antivirus and other products, but this is dependent on vulnerable behavior in those products.C:\WindowsC:\Program FilesC:\Program Data

The Solution is Found Elsewhere: Windows Installer

In March of 2021, we received a vulnerability report from researcher Abdelhamid Naceri (halov). The vulnerability he reported was an arbitrary file delete in the User Profile service, running as . Remarkably, his submission also included a technique to parlay this file delete into an escalation of privilege (EoP), resulting in a command prompt running as . The EoP works by deleting a file, but not in any of the locations you would usually think of.SYSTEMSYSTEM

To understand the route to privilege escalation, we need to explain a bit about the operation of the Windows Installer service. The following explanation is simplified somewhat.

The Windows Installer service is responsible for performing installations of applications. An application author supplies an file, which is a database defining the changes that must be made to install the application: folders to be created, files to be copied, registry keys to be modified, custom actions to be executed, and so forth..msi

To ensure that system integrity is maintained when an installation cannot be completed, and to make it possible to revert an installation cleanly, the Windows Installer service enforces transactionality. Each time it makes a change to the system, Windows Installer makes a record of the change, and each time it overwrites an existing file on the system with a newer version from the package being installed, it retains a copy of the older version. In case the install needs to be rolled back, these records allow the Windows Installer service to restore the system to its original state. In the simplest scenario, the location for these records is a folder named .C:\Config.Msi

During an installation, the Windows Installer service creates a folder named and populates it with rollback information. Whenever the install process makes a change to the system, Windows Installer records the change in a file of type (rollback script) within . Additionally, whenever the install overwrites an older version of some file with a newer version, Windows Installer will place a copy of the original file within . This type of a file will be given the (rollback file) extension. In case an incomplete install needs to be rolled back, the service will read the and files and use them to revert the system to the state that existed before the install.C:\Config.Msi.rbsC:\Config.MsiC:\Config.Msi.rbf.rbs.rbf

This mechanism must be protected against tampering. If a malicious user were able to alter the and/or files before they are read, arbitrary changes to the state of the system could occur during rollback. Therefore, Windows Installer sets a strong DACL on and the enclosed files..rbs.rbfC:\Config.Msi

Here is where an opening arises, though: What if an attacker has an arbitrary folder delete vulnerability? They can use it to completely remove immediately after Windows Installer creates it. The attacker can then recreate with a weak DACL (note that ordinary users are allowed to create folders at the root of ). Once Windows Installer creates its rollback files within , the attacker will be able to replace with a fraudulent version that contains attacker-specified and files. Then, upon rollback, Windows Installer will make arbitrary changes to the system, as specified in the malicious rollback scripts.C:\Config.MsiC:\Config.MsiC:\C:\Config.MsiC:\Config.Msi.rbs.rbf

Note that the only required exploit primitive here is the ability to delete an empty folder. Moving or renaming the folder works equally well.

From Arbitrary Folder Delete/Move/Rename to SYSTEM EoP

In conjunction with this article, we are releasing source code for Abdelhamid Naceri’s privilege escalation technique. This exploit has wide applicability in cases where you have a primitive for deleting, moving, or renaming an arbitrary empty folder in the context of or an administrator. The exploit should be built in the Release configuration for either x64 or x86 to match the architecture of the target system. Upon running the exploit, it will prompt you to initiate a delete of . You can do this by triggering an arbitrary folder delete vulnerability, or, for testing purposes, you can simply run from an elevated command prompt. Upon a successful run, the exploit will drop a file to . You can then get a command prompt by starting the On-Screen Keyboard and then switching to the Secure Desktop, for example by pressing Ctrl-Alt-Delete.SYSTEMC:\Config.Msirmdir C:\Config.MsiC:\Program Files\Common Files\microsoft shared\ink\HID.DLLSYSTEMosk.exe

The exploit contains an file. The main thing that’s special about this is that it contains two custom actions: one that produces a short delay, and a second that throws an error. When the Windows Installer service tries to install this , the installation will halt midway and rollback. By the time the rollback begins, the exploit will have replaced the contents of with a malicious and . The contains the bits of the malicious HID.DLL, and the instructs Windows Installer to “restore” it to our desired location ()..msi.msi.msiC:\Config.Msi.rbs.rbf.rbf.rbsC:\Program Files\Common Files\microsoft shared\ink\

The full mechanism of the EoP exploit is as follows:

1. The EoP creates a dummy and sets an oplock.C:\Config.Msi
2. The attacker triggers the folder delete vulnerability to delete (or move elsewhere) in the context of (or admin). Due to the oplock, the process is forced to wait.C:\Config.MsiC:\Config.MsiSYSTEMSYSTEM
3. Within the EoP, the oplock callback is invoked. The following several steps take place within the callback.
4. The EoP moves the dummy elsewhere. This is done so that the oplock remains in place and the vulnerable process is forced to continue waiting, while the filesystem location becomes available for other purposes (see further).C:\Config.MsiC:\Config.Msi
5. The EoP spawns a new thread that invokes the Windows Installer service to install the , with UI disabled..msi
6. The callback thread of the EoP continues and begins polling for the existence of . For reasons that are not clear to me, Windows Installer will create , use it briefly for a temp file, delete it, and then create it a second time to use for rollback scripts. The callback thread polls to wait for each of these actions to take place.C:\Config.MsiC:\Config.MsiC:\Config.Msi
7. As soon as the EoP detects that Windows Installer has created for the second time, the callback thread exits, releasing the oplock. This allows the vulnerable process to proceed and delete (or move, or rename) the created by Windows Installer.C:\Config.MsiC:\Config.Msi
8. The EoP main thread resumes. It repeatedly attempts to create with a weak DACL. As soon as the vulnerable process deletes (or moves, or renames) , the EoP’s create operation succeeds.C:\Config.MsiC:\Config.Msi
9. The EoP watches the contents of and waits for Windows Installer to create an file there.C:\Config.Msi.rbs
10. The EoP repeatedly attempts to move elsewhere. As soon as Windows Installer closes its handle to the , the move succeeds, and the EoP proceeds.C:\Config.Msi.rbs
11. The EoP creates one final time. Within it, it places a malicious file having the same name as the original . Together with the , it writes a malicious .C:\Config.Msi.rbs.rbs.rbs.rbf
12. After the delay and the error action specified in the , Windows Installer performs a rollback. It consumes the malicious and , dropping the DLL..msi.rbs.rbf

Note that at step 7, there is a race condition that sometimes causes problems. If the vulnerable process does not immediately awaken and delete , the window of opportunity may be lost because Windows Installer will soon open a handle to and begin writing an there. At that point, deleting will no longer work, because it is not an empty folder. To avoid this, it is recommended to run the EoP on a system with a minimum of 4 processor cores. A quiet system, where not much other activity is taking place, is probably ideal. If you do experience a failure, it will be necessary to retry the EoP and trigger the vulnerability a second time.C:\Config.MsiC:\Config.Msi.rbsC:\Config.Msi

From Arbitrary File Delete to SYSTEM EoP

The technique described above assumes a primitive that deletes an arbitrary empty folder. Often, though, one has a file delete primitive as opposed to a folder delete primitive. That was the case with Abdelhamid Naceri’s User Profile bug. To achieve EoP in this case, his exploit used one additional trick, which we will now explain.SYSTEM

In NTFS, the metadata (index data) associated with a folder is stored in an alternate data stream on that folder. If the folder is named , then the index data is found in a stream referred to as . Some implementation details can be found here. For our purposes, though, what we need to know is this: deleting the stream of a folder effectively deletes the folder from the filesystem, and a stream name, such as , can be passed to APIs that expect the name of a file, including .C:\MyFolderC:\MyFolder::$INDEX_ALLOCATION::$INDEX_ALLOCATIONC:\MyFolder::$INDEX_ALLOCATIONDeleteFileW

So, if you are able to get a process running as or admin to pass an arbitrary string to , then you can use it not only as a file delete primitive but also as a folder delete primitive. From there, you can get a EoP using the exploit technique discussed above. In our case, the string you want to pass is .SYSTEMDeleteFileWSYSTEMC:\Config.Msi::$INDEX_ALLOCATION

Be advised that success depends on the particular code present in the vulnerable process. If the vulnerable process simply calls /, you should be fine. In other cases, though, the privileged process performs other associated actions, such as checking the attributes of the specified file. This is why you cannot test this scenario from the command prompt by running .DeleteFileADeleteFileWdel C:\Config.Msi::$INDEX_ALLOCATION

From Folder Contents Delete to SYSTEM EoP

Leveling up once more, let us suppose that the vulnerable process does not allow us to specify an arbitrary folder or file to be deleted, but we can get it to delete the contents of an arbitrary folder, or alternatively, to recursively delete files from an attacker-writable folder. Can this also be used for EoP? Researcher Abdelhamid Naceri demonstrated this as well, in a subsequent submission in July 2021. In this submission he detailed a vulnerability in the scheduled task, running as . This task iterates over the contents of a temp folder and deletes each file it finds there. His technique was as follows:SYSTEMSilentCleanupSYSTEM

1. Create a subfolder, .temp\folder1
2. Create a file, .temp\folder1\file1.txt
3. Set an oplock on .temp\folder1\file1.txt
4. Wait for the vulnerable process to enumerate the contents of and try to delete the file it finds there. This will trigger the oplock.temp\folder1file1.txt
5. When the oplock triggers, perform the following in the callback:[出自:jiwo.org]
   a. Move elsewhere, so that is empty and can be deleted. We move as opposed to just deleting it because deleting it would require us to first release the oplock. This way, we maintain the oplock so that the vulnerable process continues to wait, while we perform the next step.
   b. Recreate as a junction to the ‘\RPC Control\RPC Control\file1.txtC:\Config.Msi::$INDEX_ALLOCATION`.file1.txttemp\folder1file1.txttemp\folder1folder of the object namespace. c. Create a symlink atpointing to
6. When the callback completes, the oplock is released and the vulnerable process continues execution. The delete of becomes a delete of .file1.txtC:\Config.Msi

Readers may recognize the symlink technique involving from James Forshaw’s symboliclink-testing-tools. Note, though, that it’s not sufficient to set up the junction from to and then let the arbitrary file delete vulnerability do its thing. That’s because is not an enumerable file system location, so the vulnerable process would not be able to find via enumeration. Instead, we must start off by creating as a bona fide file, allowing the vulnerable process to find it through enumeration. Only afterward, just as the vulnerable process attempts to open the file for deletion, we turn into a junction pointing into the object namespace.\RPC Controltemp\folder1\RPC Control\RPC Control\RPC Control\file1.txttemp\folder1\file1.txttemp\folder1

For working exploit code, see project . Note that the built-in malware detection in Windows will flag this process and shut it down. I recommend adding a “Process” exclusion for .FolderContentsDeleteToFolderDeleteFolderContentsDeleteToFolderDelete.exe

You can chain these two exploits together. To begin, run and wait for it to prompt you to trigger privileged deletion of . Then, run . It will prompt you to trigger privileged deletion of the contents of . If necessary for your exploit primitive, you can customize this location using the command-line switch. For testing purposes, you can simulate the privileged folder contents deletion primitive by running from an elevated command prompt. will turn this into a delete of , and this will enable to drop the . Finally, open the On-Screen Keyboard and hit Ctrl-Alt-Delete for your shell.FolderOrFileDeleteToSystemConfig.MsiFolderContentsDeleteToFolderDelete /target C:\Config.MsiC:\test1/initialdel /q C:\test1\*FolderContentsDeleteToFolderDeleteC:\Config.MsiFolderOrFileDeleteToSystemHID.DLLSYSTEM

From Arbitrary Folder Create to Permanent DoS

Before closing, we’d like to share one more technique we learned from this same researcher. Suppose you have an exploit primitive for creating an arbitrary folder as or admin. Unless the folder is created with a weak DACL, it doesn’t sound like this would be something that could have any security impact at all. Surprisingly, though, it does: it can be used for a powerful denial of service. The trick is to create a folder such as this one:SYSTEM

      C:\Windows\System32\cng.sys

Normally there is no file or folder by that name. If an attacker name squats on that filesystem location with an extraneous file or even an empty folder, the Windows boot process is disrupted. The exact mechanism is a bit of a mystery. It would appear that Windows attempts to load the kernel module from the improper location and fails, and there is no retry logic that allows it to continue and locate the proper driver. The result is a complete inability to boot the system. Other drivers can be used as well for the same effect.cng.sys

Depending on the vulnerability at hand, this DoS exploit could even be a remote DoS, as nothing is required besides the ability to drop a single folder or file.

Conclusion

The techniques we’ve presented here show how some rather weak exploit primitives can be used for great effect. We have learned that:

• An arbitrary folder delete/move/rename (even of an empty folder), as or admin, can be used to escalate to SYSTEM.
• An arbitrary file delete, as or admin, can usually be used to escalate to .
• A delete of contents of an arbitrary folder, as or admin, can be used to escalate to .
• A recursive delete, as or admin, of contents of a fixed but attacker-writable folder (such as a temp folder), can be used to escalate to .
• An arbitrary folder create, as or admin, can be used for a permanent system denial-of-service.
• An arbitrary file delete or overwrite, as or admin, even if there is no control of contents, can be used for a permanent system denial-of-service.SYSTEMSYSTEMSYSTEMSYSTEMSYSTEMSYSTEMSYSTEMSYSTEMSYSTEM