Listen to this Post
Introduction:
Process injection remains a cornerstone of adversary tradecraft, enabling attackers to execute malicious code within trusted processes. The legitimate Windows utility `mavinject.exe` is often abused to inject DLLs into running processes, but on modern Windows 11 systems, LSASS runs as a Protected Process Light (PPL) by default, blocking even administrator‑level injection attempts. Understanding how PPL changes the detection landscape—and where telemetry gaps appear—is critical for building accurate, context‑aware security monitoring.
Learning Objectives:
- Understand LSASS Protected Process Light (PPL) protection and its impact on process injection techniques
- Learn to use Windows Security auditing and Sysmon to detect injection attempts (successful or failed)
- Analyze process exit codes and module load events to distinguish between real threats and failed attacks
You Should Know
- Testing Process Injection with mavinject.exe on Modern Windows
`mavinject.exe` is a Microsoft utility designed for debugging and application testing, but it has been co‑opted by attackers to inject DLLs into running processes. On a Windows 11 system (with default PPL enabled for LSASS), injection behavior differs dramatically between unprotected and protected processes.
Step‑by‑step guide to reproduce the test:
- Open an elevated PowerShell console (Run as Administrator).
2. Identify target process IDs (PIDs):
Get-Process -Name notepad, lsass | Select-Object Id, Name
(Start Notepad++ or notepad.exe first if not running.)
- Attempt injection into an unprotected process (e.g., Notepad):
mavinject.exe <Notepad_PID> /INJECTRUNNING <path_to_dll>
Example with `vbscript.dll` (exists in System32):
mavinject.exe 1234 /INJECTRUNNING C:\Windows\System32\vbscript.dll
4. Attempt the same against `lsass.exe` (replace with LSASS PID):
mavinject.exe 5678 /INJECTRUNNING C:\Windows\System32\vbscript.dll
Expected results:
- Notepad injection succeeds silently (no console error).
- LSASS injection fails with an access violation.
– `mavinject.exe` provides almost no visible output, forcing reliance on logs.
- Checking LSASS PPL Status and Why It Blocks Injection
PPL (Protected Process Light) is a security mechanism that restricts user‑mode access to process memory, even from administrative accounts. LSASS runs as `PsProtectedSignerWinTcb` level by default on Windows 11.
Commands to verify PPL status:
- Using PowerShell (no extra tools):
Get-Process lsass | Select-Object -ExpandProperty ProtectedProcess
Returns `True` if PPL is active.
- Using Sysinternals Process Explorer (more detailed):
- Run as Administrator → Locate `lsass.exe` → Right‑click → Properties → “Protection” shows “PS Protected Process Light”.
-
Using `fltmc` (checking security policies):
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL
Value `1` = PPL enabled (default on modern Windows).
Why injection fails:
A normal user‑mode process (like mavinject.exe) has a lower protection level than LSASS. The kernel blocks cross‑level memory operations such as `NtMapViewOfSection` and NtWriteVirtualMemory, causing a STATUS_ACCESS_VIOLATION (0xC0000005).
- Enabling Security Event ID 4689 – The Critical Exit Code Artifact
By default, Windows does not log process exit events. Event ID 4689 (Security log) records when a process exits and includes the exit status code. This artifact is invaluable for distinguishing successful injections from failed ones.
Step‑by‑step to enable and query 4689:
- Enable Process Termination auditing via Group Policy or
auditpol:auditpol /set /subcategory:"Process Termination" /success:enable /failure:enable
(Run as Administrator in an elevated command prompt.)
2. Verify the policy is applied:
auditpol /get /subcategory:"Process Termination"
- After performing injection tests, query the Security log for recent 4689 events related to
mavinject.exe:Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4689} | Where-Object {$_.Message -like "mavinject"} | Format-List TimeCreated, Message
4. Examine the Exit Status field:
– `0x0` → Success (e.g., Notepad injection)
– `0xC0000005` → Access violation (LSASS injection failed)
Why this matters:
Without Event ID 4689, an investigator only sees `mavinject.exe` start (Event 4688). A failed injection attempt still creates a process creation event, leading to potential false positives if only process creation is monitored.
- Sysmon Event ID 7 – Image Load Only Occurs on Successful Injection
Sysmon’s Event ID 7 (Image Load) logs when a DLL is loaded into a process. In the LSASS injection test, no Event ID 7 appears because the injection fails before `vbscript.dll` is mapped. The unprotected process (Notepad) generates the event.
Step‑by‑step Sysmon configuration:
1. Install Sysmon (if not already):
sysmon64.exe -accepteula -i
- Use a minimal configuration that logs image loads:
<Sysmon> <EventFiltering> <ImageLoad onmatch="include"> <TargetImage condition="contains">lsass.exe</TargetImage> <TargetImage condition="contains">notepad.exe</TargetImage> </ImageLoad> </EventFiltering> </Sysmon>
Save as `config.xml` and reload:
sysmon64.exe -c config.xml
3. Query Sysmon events:
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; ID=7} | Where-Object {$_.Message -like "vbscript.dll"}
Key detection insight:
The absence of Sysmon Event ID 7 for an LSASS injection attempt does not mean no attempt occurred—it means the attempt failed. Correlating with process exit events (4689) provides the complete picture.
- Hands‑On Lab: Building a Detection Rule for Suspicious mavinject.exe Execution
Create a detection that alerts on any `mavinject.exe` execution but includes context from exit codes and module loads.
Step‑by‑step using PowerShell + Windows Event Log:
1. Collect events:
- Process creation (Event 4688) for `mavinject.exe`
– Process exit (Event 4689) for same process - Sysmon Event ID 7 for `lsass.exe` as target
- Example PowerShell query to correlate a single execution:
$start = Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4688} | Where-Object {$<em>.Properties[bash].Value -like "mavinject.exe"} | Select-Object -First 1 $pid = $start.Properties[bash].Value $exit = Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4689} | Where-Object {$</em>.Properties[bash].Value -eq $pid} if ($exit) { $exitCode = $exit.Properties[bash].Value if ($exitCode -eq "0xC0000005") { Write-Host "FAILED injection attempt on LSASS (access denied) - investigate further" } }
3. For SIEM detection (pseudo‑query):
(EventID=4688 AND CommandLine contains "mavinject.exe" AND TargetImage contains "lsass.exe") AND NOT (EventID=4689 AND ExitStatus=0x0)
This alerts on any `mavinject` targeting LSASS that does not exit successfully (i.e., blocked by PPL). While a failed attempt is less severe, it indicates an active adversary testing defenses.
6. Bypass Awareness: BYOVD and Kernel‑Assisted Attacks
Although PPL blocks normal injection, sophisticated threats use Bring Your Own Vulnerable Driver (BYOVD) to disable kernel callbacks or elevate process protection. Understanding these techniques helps prioritize detections.
Common PPL bypass vectors (theoretical, for detection engineering):
- Loading a vulnerable signed driver to call `SetProcessProtection` with a higher level.
- Exploiting a kernel vulnerability to temporarily remove PPL flag.
- Using the Windows Filtering Platform (WFP) to subvert process protection checks.
Detection hints for bypass attempts:
- Unsigned driver load attempts (Event ID 6 in Sysmon, Event 7045 in System log).
- Processes attempting to open LSASS with `PROCESS_VM_OPERATION` or `PROCESS_VM_WRITE` access from low‑integrity sources.
- Use of tools like `mimikatz` with `!+` command (requires SE_DEBUG_PRIVILEGE and PPL bypass).
- Why Process Creation Events Alone Will Fool You
Relying solely on Event ID 4688 (process created) as a definitive indicator of successful injection leads to false confidence. An attacker can execute `mavinject.exe` against LSASS, the process creation event fires, but the injection fails silently. Meanwhile, a defender might chase a ghost.
Step‑by‑step forensic approach:
- Collect three artifacts for every suspicious process: creation, module loads, exit code.
2. Use timeline analysis:
- 4688 (start) → Wait period → Sysmon 7 (image load) → 4689 (exit)
- If Sysmon 7 missing for target like LSASS, check exit code:
– `0xC0000005` → Access denied → no successful injection.
– `0x0` and Sysmon 7 present → successful injection → escalate investigation. - Automate with a simple script that correlates PID across logs.
Real‑world impact:
In incident response, a failed LSASS injection attempt may still be the prelude to a different technique (e.g., dumping LSASS via `comsvcs.dll` with minidump). Always correlate across telemetry sources.
What Undercode Say:
- Continuously validate and revisit information – Security articles from even a year ago may lack context (e.g., PPL being default on Windows 11). Always test techniques in your own environment.
- Understand system internals – Knowing how PPL blocks memory access transforms your detection approach. Without this knowledge, you would hunt for module load events that never occur.
- Process creation is only the beginning – A start event (4688) does not equal success. Incorporate exit codes (4689) and module load events (Sysmon 7) to build accurate detection logic. Failing to do so leads to high false positives and missed context.
Analysis (~10 lines):
Ahmed’s practical test highlights a dangerous gap in default monitoring: most organizations enable process creation auditing but ignore process exit events. The LSASS PPL change—introduced in Windows 10/11 as a security improvement—renders many traditional injection detection rules obsolete. Attackers will still attempt injection, but defenders who only look for `mavinject.exe` running will generate alerts with no way to prioritize. The solution is simple but underused: enable Security Event 4689 and teach analysts to read exit codes. Furthermore, the lack of console output from `mavinject.exe` means manual investigation requires log forensics. Ahmed’s reminder to “revisit information” is a call to action: threat landscapes shift, and detection engineers must continuously re‑test public research against their own OS versions and patches.
Expected Output:
A successful detection workflow yields a normalized log entry showing a failed LSASS injection:
Timestamp: 2025-02-18 14:32:11 Event ID: 4689 (Security) Process: mavinject.exe (PID 7788) Exit Status: 0xC0000005 (ACCESS_VIOLATION) Target Process: lsass.exe (PID 668) Conclusion: Injection blocked by PPL – no further action on LSASS, but investigate source of mavinject.exe execution.
Prediction:
As Windows continues to harden LSASS and other critical system processes (e.g., with Extended PPL and Hypervisor‑Protected Code Integrity), attackers will shift toward kernel‑based bypasses and abuse of legitimate remote administration tools. Detection engineers must evolve beyond simple process injection monitoring and invest in kernel callback hooking (using tools like Microsoft Defender for Endpoint or custom ETW consumers) to identify PPL bypass attempts. Within two years, most mature SOCs will treat a failed LSASS injection attempt as a high‑severity indicator—not because it succeeded, but because it signals an attacker testing defenses. Automated correlation of process exit codes with parent‑child process trees will become standard in SIEM rules, and frameworks like Sigma will update their injection detections to include exit‑code logic. The era of “alert on any process creation” is ending; context‑aware detection is the new baseline.
▶️ Related Video (68% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Mr Ahmed – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
