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:
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.
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:
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"
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:
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:
— Adam (@Hexacorn) September 14, 2016
After gathering more information from different customers, we identified a common use-case:
mavinject <PID> /INJECTRUNNING
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.
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:
MavInject.exe <PID> /INJECTRUNNING <PATH DLL>
Here is a practical example:
Using MavInject32.exe (Microsoft Corp Signed) to load any dll in a running process.
> "C:Program FilesCommon Filesmicrosoft sharedClickToRunMavInject32.exe" <PID> /INJECTRUNNING <PATH DLL>
— Giuseppe `N3mes1s` (@gN3mes1s) December 14, 2017
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:
— P-A Braeken (@pabraeken) December 14, 2017
Another interesting experiment was that of injecting a DLL inside the commonly used Sysmon 😉 :
— Casey Smith (@subTee) December 15, 2017
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.
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.
Our engineers have found a way to inject a DLL inside any process using mavinject (Microsoft Application Virtualization Injector, signed by Microsoft), below happens during the attack from the perspective of ReaQta-Hive. Original tweet: https://t.co/NHUco6NN6A pic.twitter.com/2XxOzhw333
— ReaQta (@ReaQta) December 15, 2017
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.