T1218.013: Mavinject
Adversaries may abuse mavinject.exe to proxy execution of malicious code. Mavinject.exe is the Microsoft Application Virtualization Injector, a Windows utility that can inject code into external processes as part of Microsoft Application Virtualization (App-V).[1]
Adversaries may abuse mavinject.exe to inject malicious DLLs into running processes (i.e. Dynamic-link Library Injection), allowing for arbitrary code execution (ex. C:\Windows\system32\mavinject.exe PID /INJECTRUNNING PATH_DLL).[2][3] Since mavinject.exe may be digitally signed by Microsoft, proxying execution via this method may evade detection by security products because the execution is masked under a legitimate process.
In addition to Dynamic-link Library Injection, Mavinject.exe can also be abused to perform import descriptor injection via its /HMODULE command-line parameter (ex. mavinject.exe PID /HMODULE=BASE_ADDRESS PATH_DLL ORDINAL_NUMBER). This command would inject an import table entry consisting of the specified DLL into the module at the given base address.[4]
Analyst context for executives and security teams
Mavinject is a Windows signed utility associated with Microsoft App-V that can be abused to run attacker-controlled DLL code inside another process. The business issue is not that mavinject.exe is inherently malicious; it is that trusted Windows binaries can blur the line between normal administration and stealthy execution. Leaders should treat this as a test of whether endpoint controls, SOC workflows, and application-control policy can distinguish legitimate App-V activity from suspicious code injection.
Executive priority
Prioritize this where Windows endpoints or servers allow broad execution of native signed binaries without context-aware monitoring. This technique is relevant to resilience and audit readiness because it can undermine simple allowlisting based only on Microsoft signatures. Risk owners should ask whether App-V/mavinject is actually required, whether unauthorized DLL execution is prevented, and whether incident responders can quickly prove which process injected what DLL into which target process.
Technical view
For SOC and IR teams, validate coverage on Windows for mavinject.exe process starts, command-line arguments associated with DLL or import descriptor injection such as /INJECTRUNNING and /HMODULE, the target process identifier, and the referenced DLL path. Because this is a sub-technique of System Binary Proxy Execution and relates to Dynamic-link Library Injection behavior, detections should not rely only on the binary being unsigned or unknown. The supplied relationship indicates detection strategy DET0433 is relevant, and mitigations M1038 Execution Prevention and M1042 Disable or Remove Feature or Program should guide control validation.
Likely telemetry
- Windows process creation events including full command line, parent process, user, image path, and hash/signature metadata for mavinject.exe
- DLL/module load telemetry showing the injected or referenced DLL path and loading process
- EDR telemetry for cross-process activity, process injection, handle access, or code execution in another process where available
- Application control or execution prevention logs showing allowed or blocked mavinject.exe and DLL execution
- Asset/software inventory indicating whether Microsoft App-V and mavinject.exe are expected on the host
Detection direction
- Baseline legitimate App-V or administrative use before treating all mavinject.exe execution as malicious; false positives are possible in environments that use App-V.
- Alert on mavinject.exe with injection-related parameters, unusual parent processes, non-standard DLL paths, user-writable locations, or execution on systems where App-V is not expected.
- Do not suppress events solely because mavinject.exe is Microsoft-signed; the ATT&CK behavior specifically relies on trusted binary proxy execution.
- Correlate process creation with DLL load and target process telemetry to reduce noise and improve incident confidence.
- Use the mapped detection strategy DET0433 as a validation reference, but confirm that local logging actually captures command line and module/injection evidence.
Mitigation priorities
- First determine whether App-V/mavinject.exe is required; if not, reduce attack surface by disabling or removing unnecessary features consistent with M1042.
- Where the utility is required, enforce execution prevention and application control consistent with M1038 so only authorized code and approved DLL locations are allowed.
- Harden policy beyond publisher trust alone; signed Microsoft binary execution should still be constrained by path, role, use case, and command context where possible.
- Maintain evidence for compliance and readiness reviews: approved use cases, application-control policy, exceptions, and alert/response procedures for mavinject.exe abuse.
Analyst notes and limits
ATT&CK also maps TONESHELL software to use of this technique, which can help threat intelligence teams enrich analytic hypotheses. That relationship should not be interpreted as proof of current activity in any specific environment. The practical value is to validate whether signed-binary proxy execution and DLL injection are observable and controllable on Windows assets.
The official ATT&CK object does not provide a detection section, so detection guidance here is derived from the official description and supplied relationships, especially DET0433, M1038, M1042, and the parent technique T1218. Local App-V usage, endpoint logging depth, and application-control design are required to assess actual exposure or coverage.
Mavinject
Adversaries may abuse mavinject.exe to proxy execution of malicious code. Mavinject.exe is the Microsoft Application Virtualization Injector, a Windows utility that can inject code into external processes as part of Microsoft Application Virtualization (App-V).[1]
Adversaries may abuse mavinject.exe to inject malicious DLLs into running processes (i.e. Dynamic-link Library Injection), allowing for arbitrary code execution (ex. C:\Windows\system32\mavinject.exe PID /INJECTRUNNING PATH_DLL).[2][3] Since mavinject.exe may be digitally signed by Microsoft, proxying execution via this method may evade detection by security products because the execution is masked under a legitimate process.
In addition to Dynamic-link Library Injection, Mavinject.exe can also be abused to perform import descriptor injection via its /HMODULE command-line parameter (ex. mavinject.exe PID /HMODULE=BASE_ADDRESS PATH_DLL ORDINAL_NUMBER). This command would inject an import table entry consisting of the specified DLL into the module at the given base address.[4]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1218 | System Binary Proxy Execution | This object subtechnique of System Binary Proxy Execution. |
Groups, software, and campaigns
S1239: TONESHELL
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 3.0 | Current bundle | 0803a729a6c8… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
LOLBAS Mavinject
LOLBAS. (n.d.). Mavinject.exe. Retrieved September 22, 2021.
Open source URL -
[2]
ATT Lazarus TTP Evolution
Fernando Martinez. (2021, July 6). Lazarus campaign TTPs and evolution. Retrieved September 22, 2021.
Open source URL -
[3]
Reaqta Mavinject
Reaqta. (2017, December 16). From False Positive to True Positive: the story of Mavinject.exe, the Microsoft Injector. Retrieved September 22, 2021.
Open source URL -
[4]
Mavinject Functionality Deconstructed
Matt Graeber. (2018, May 29). mavinject.exe Functionality Deconstructed. Retrieved September 22, 2021.
Open source URL -
[5]
mitre-attack T1218.013Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.