This will (hopefully) be a short story about a bug I found some time ago while auditing a .NET service from an OEM. It should be interesting as I have yet to find a description of how to exploit a similar condition.
Our service was running as
SYSTEM and needed to periodically
execute some other utilities as part of its workflow. Before running these
auxiliary tools, it would check if the executable was properly signed by the
vendor. Something like this:
public void CallAgent()
string ExeFile = "C:\\Program Files\\Vendor\\Util.exe";
if (!new Signtool().VerifyExe(ExeFile))
// Execute Agent here
This is where it gets interesting. Of course we can’t
control anything at that
Program Files location, but what is that
internal class Signtool
private const string SignToolPath = "C:\\Windows\\Temp\\signtool.exe";
private void ExtractSignTool()
byte signtool = QuatService.Resource1.signtool;
using (FileStream fileStream = new FileStream("C:\\Windows\\Temp\\signtool.exe", FileMode.Create))
fileStream.Write(signtool, 0, signtool.Length);
private void DeleteSignTool()
private bool Verify(string arg)
Process process = new Process();
process.StartInfo.UseShellExecute = false;
process.StartInfo.RedirectStandardOutput = true;
process.StartInfo.FileName = "C:\\Windows\\Temp\\signtool.exe";
process.StartInfo.Arguments = arg;
return process.ExitCode == 0 || process.ExitCode == 2;
public bool VerifyExe(string ExeFile)
return this.Verify("verify /pa \"" + ExeFile + "\"");
The code simply extracts a signature verification tool that it has embedded in
C:\Windows\Temp as part of its resources, executes it to verify the target executable, and then deletes the tool as if nothing ever happened.
Did you catch the bug? The issue is in the
FileMode.Create flag that gets passed as part of the FileStream call used to write the file.
What is object squatting?
I first read about squatting attacks
in “The Art of Software Security Assessment” (which I highly recommend by the
way). Essentially, squatting is an attack where you create an object before the
legitimate application does. You can then manipulate the object and affect the
normal behavior of the application.
If an application is not careful and attempts to
create a named object (such as Mutex, an Event, a Semaphore, etc.) in the
global namespace, it might open an existing object instead, because another
application could have already created an object with the exact same name. In
this case, the Create method will succeed (https://docs.microsoft.com/en-us/windows/win32/sync/object-names):
This same method can be used for file
squatting: the application acts as if it has created a file when it has
actually opened an existing file.
There are two conditions necessary
for this to be exploitable:
dwCreationDispositionparameter of the
CreateFilefunction must be set incorrectly, leading the application to open an
existing file instead of creating a new one. An incorrect setting is any
- The location where the file is being created must
be writeable by potentially malicious users.
So in C/C++ code, if you see a call
CREATE_ALWAYS, it should raise a flag:
In .NET code,
At this point, we have a confirmed file
- The service is not using
- The location
C:\Windows\Tempis writable by authenticated
We also have a race condition
because there is a time window between when
signtool.exe is extracted and when
it is executed.
Therefore, we can exploit this
vulnerability by leveraging Hardlinks and OpLocks:
The steps would be the following:
a directory such as
a file named dummy.txt inside the directory.
payload.exeinside the directory.
the Hardlink in
C:\Windows\Temp\Signtool.exeto point to
an OpLock on dummy.txt.
the OpLock triggers, recreate the Hardlink to point to payload.exe (we can do
this because the file is ours and the ACL hasn’t changed).
Not so fast! If we check the
behavior of the vulnerable “QuatService” with ProcMon, we see there are
actually five calls to
CreateFile instead of just three:
CreateFile is used by
FileStream to write the signtool to disk. The second, third, and fourth calls
are all part of the inner workings of
CreateProcess. The final
called with delete access in order to erase the file.
At a practical level, because of
the short time window, the two additional
CreateFile calls from
could interfere with our goal. I found that the best settings for reliable,
reproducible results were:
- Use a second OpLock on dummy.txt after the first
one is hit.
- Call Sleep(1) to skip the third CreateFile
(second one from CreateProcess).
- Attempt to create the Hardlink to payload.exe in
a loop. This is necessary because the Hardlink creation could fail due to the
fact the service could still hold the handle from the third CreateFile.
Here is the code for a functional exploit for the vulnerability (tested on Windows 10 19041 and 18363):
Video demo of the exploit working:
The vulnerable service is included
in the same GitHub project in case you want to play with it. If you come up
with a better approach to increase the reliability of the exploit, please send
me a message.
As already discussed, to avoid this
situation there are two options:
CREATE_NEW / FileMode.CreateNewand
handle the potential error caused by an existing file.
to a protected filesystem location.
What about the path redirection
- The Hardlink mitigation doesn’t apply here because we’re creating a link to our own file.
SYSTEM %TEMP%change is not implemented yet. Even though this mitigation will definitely fix the vulnerability, it is worth noting that there will be still room for squatting other directories:
- The Art of Software Security Assessment
- Keeping Windows Secure (David Weston): https://msrnd-cdn-stor.azureedge.net/bluehat/bluehatil/2019/assets/doc/Keeping%20Windows%20Secure.pdf
More on Object Squatting mitigations: