Voidtools Everything Service - DLL hijacking and Potential Abuses (CVE-2020-24567).

20/08/2020: Tamir Vered and Eran Shisel


Cymaera discovered a new vulnerability in voidtools' Everything service for Windows.

Hereafter we describe the vulnerability found in voidtools Everything service. Then, we describe how an attacker could take advantage of this vulnerability to achieve privilege escalation, persistence and possible whitelist bypass by using the technique of implanting an arbitrary unsigned dynamic link library which is executed by a signed service that runs as NT AUTHORITY\SYSTEM.

Everything service

The voidtools Everything application is a fast search utility alternative to the Windows search feature. To achieve it's search speed performence, Everything indexes all fixed NTFS/ReFS volumes [1], which requires administrator privileges.

In order to enable high privileged execution without forcing the user to run Everything as administrator everytime and popup a UAC dialog, Everything has an optional (though default) feature of installing a service which is executed with NT AUTHORITY\SYSTEM privileges on startup.



We initially targeted the Everything service because of the following reasons:

  • It is executed with NT AUTHORITY\SYSTEM privileges, which is a typical target when looking for a privilege escalation vulnerability since it may be very useful for a potential attacker.
  • The installed service has the same executable as the Everything app itself, which may be installed in a low privileged directory.
  • It is signed, which means that malicious code executed on behalf of the service may bypass whitelists that include the Everything executable.

We begin by inspecting the Everything service file system and registry activity and observe the following behaviour on process startup:

As we can see, an unsigned DLL named urlmon.dll is loaded from C:\Windows\System32 after the process attempts to find it in the Everything installation directory first. Implementing our own DLL named urlmon.dll and placing it in Everything's installation directory will allow an attacker to hijack the original DLL.

Proof of Concept

In order to not harm the functionality of the service, we are willing to forward all calls to our "urlmon.dll", to the original urlmon.dll.

After realizing that this dependency is indirect, we look for all of the statically known usages of urlmon.dll by Everything.exe:

We see that the only required function is CopySgtMedium, and compile a DLL which exports a function with the same signature. Our DLL forwards each call to CopySgtMedium to the original urlmon.dll, and additionally, we write the path to the current executable, along with the name of the user to which this process belongs, to a text file in C:\Windows\System32.

and place it in Everything's installation directory:

Now when the Everything service starts, a file named test.txt is created in C:\Windows\System32 with the following content:

C:\Windows\System32\Everything.exe - System

This shows us that our "malicious" code was indeed executed in the context of the Everything service with system privileges.

Potential Implications

Privilege Escalation

By taking advantage of this vulnerability, an attacker authorized to write in the Everything's installation directory, which may be accessible to any low priviledged user, may execute code in NT AUTHORITY\SYSTEM priviliges.

Whitelist Bypass

An attacker taking advantage of this vulnerability may evade whitelisting mechanisms since it allows his elevated code to be executed on behalf of the signed service, which is considered legitimate.


The attacker's code execution is persistent across system reboots, due to the fact that the Everything service is started automatically at system atartup, and the malicious code will be loaded with it, as long as his DLL remains in the installation directory.

Affected Versions

All Everything versions prior to that include the Everything service feature.


16/08/2020: Vulnerability found by Cymaera.

17/08/2020: Vulnerability reported to voidtools.

18/08/2020: Voidtools have confirmed the vulnerability.

18/08/2020: Voidtools have patched and disclosed the vulnerability [2].

20/08/2020: CVE ID was requested by Cymaera.

21/08/2020: CVE-2020-24567 was allocated by Mitre [3].


[1] https://www.voidtools.com/support/everything/indexes/#refs

[2] https://www.voidtools.com/forum/viewtopic.php?p=32509#p32509

[3] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24567