From False Positive to True Positive: the story of Mavinject.exe, the Microsoft Injector

Mavinject is a legitimate Windows component that can be used, and abused, to perform arbitrary code injections inside any running process. As this is a common component on Windows, it can be leveraged to perform living-off-the-land attacks.

From False Positive to True Positive

One of our customers recently reported of a potential false positive pocked up by our engines. As part of the maintenance process we went on to investigate the event, to better understand why that particular operation was marked as malicious by the algorithms:

Mavinject Incident Behavioral-Tree
Behavioral-Tree of Mavinject32.exe Cross-Process Operation in Excel.exe

After further analysis we dismissed the event as a false positive but we were still puzzled by the cause of the trigger and the reason why a legitimate component would perform such an operation on Excel.exe.

Mavinject Incident Events
Mavinject32.exe Events

In terms of timeline mavinject32.exe performed a code injection inside excel.exe just to terminate immediately after that. This raised some concerns on the engines that flagged the operation as potentially malicious and started tracking the endpoint’s behavior. Below are the details of the offending process:

Mavinject Process-Details
Mavinject32.exe Process-Details

It’s clear now that mavinject32.exe is a legitimate Microsoft component. The commandline is interesting too, as from a preliminary analysis the arguments appeared to be as follows:

mavinject32.exe <PID> <PATH DLL>

12232 is in fact the PID of the excel.exe instance running on the endpoint an the path corresponded to that of the DLL injected during the “incident”. The name “mav-inject” should have been quite revealing already 😉, at this point we had the suspect that it could be used (and abused) to inject arbitrary malicious DLLs inside any other process.

As a first step we tried to understand whether Mavinject was a common component or not; we found it on different endpoints at the following location:

"C:\Program Files\Common Files\microsoft shared\ClickToRun\MavInject32.exe"

Additionally the executable could be found in other two directories: System32 and SysWOW64.

The file description reveals what the component is:

FileDescription:  Microsoft Application Virtualization Injector

The application is part of the Microsoft Application Virtualization (App-V). The analysis of the executable lead us to the following interesting parameter:


Prior Work

Before we start to dig inside the abusing part, let’s give credit where credit is due. At the time of writing we haven’t found any prior work related to abusing mavinject, the only reference we could find is the following tweet from @hexacorn:


Using Mavinject…

After gathering more information from different customers, we identified a common use-case:


The executable that is ran with this command-line looks for the following registry key:


whose corresponding values are:

ValueName: Modules - ValueData: C:\Windows\System32\AppVEntSubsystems32.dll
ValueName: Modules64 - ValueData: C:\Windows\System32\AppVEntSubsystems64.dll

Depending on the target process architecture (32 or 64 bit), it injects one of the DLLs.

Abusing Mavinject…

After further analysis it became clear that the same exact mechanism can be abused in the following way to inject a dll inside an arbitrary running process:


Here is a practical example:

Soon after we wrote about the “feature”, the infosec community responded quickly with several researchers combining the findings with well-known red-team/exploitation frameworks:

Another interesting experiment was that of injecting a DLL inside the commonly used Sysmon 😉 :


Other than what we described above and as pointed out by other researchers , besides the injection this attack can be used as a “living off the land” technique as it is offers a very convenient function via a totally legit and trusted application. This is likely to raise less alerts than performing the same action using an external or unrecognized component.

The Defense

ReaQta-Hive, as we have just learned, detects and protects from this attack out of the box. Our customers can pull-up all the operations performed by mavinject directly from the Hunting page if additional analysis of the events is required.

If instead you’re using an application whitelisting framework, configure it to forbid the loading of foreign modules.


Dynamic behavioral analysis is powerful as it shows strength in detecting behaviors that would be quickly overlooked by a human analyst (as we initially did!), as the models learn from the infrastructure they acquire a visibility over the operations that is hard to match with manual analysis. Anomalous behaviors should be investigated before they become the root of more important issues, in this case a false positive led to the discovery of more serious issues that attackers can easily abuse while maintaining a low profile. Such “vulnerabilities” are trivial to exploit, while offering several up-sides to the attackers, so gaining visibility on the infrastructure is an essential step toward a better overall security.