Listen to this Post
Introduction:
Privilege escalation to the TrustedInstaller account has long been a coveted goal for red teamers and penetration testers, offering SYSTEM-level access with even higher integrity. Traditional methods rely on starting the TrustedInstaller service directly via the Service Control Manager (SCM), an action that is heavily monitored by EDR solutions and almost guarantees immediate detection. A new, stealthier approach has emerged, leveraging the Deployment Image Servicing and Management (DISM) API to trigger TrustedInstaller.exe as a benign side effect of a health check, allowing for thread impersonation without ever touching the SCM.
Learning Objectives:
- Understand the mechanics of triggering TrustedInstaller.exe through DISM API calls rather than SCM.
- Learn how to implement this technique as a Beacon Object File (BOF) for in-memory execution.
- Identify detection opportunities and mitigation strategies for this novel privilege escalation vector.
You Should Know:
1. The Mechanics of the DISM-Based Trigger
The core of this technique lies in abusing the servicing stack operations performed by DISM. When `DismCheckImageHealth` is called, it loads `dismapi.dll` and initiates a series of operations to verify the integrity of the Windows image. As part of this process, the servicing stack, which operates under the context of TrustedInstaller.exe, is invoked. The application initiating the API call does not need to have high privileges to request this check; it merely needs to invoke the API correctly. Once `TrustedInstaller.exe` is spawned, the attacker’s process can then use Windows APIs to open a thread handle to the newly created service process and perform thread impersonation, effectively inheriting its token.
This method bypasses the Service Control Manager entirely. The SCM is responsible for starting services, logging these starts, and enforcing permissions. By avoiding `sc start` or StartServiceW, the attacker evades a telemetry point that is almost universally monitored. The process appears as a legitimate application (like DISM) performing a standard system health check, while the spawning of `TrustedInstaller.exe` appears as a normal background operation of the servicing stack.
To compile the BOF:
The provided GitHub repository likely contains C code that leverages the Dism API. Compilation requires the Windows SDK and a BOF toolchain like `make` with a `Makefile` tailored for BOFs.
Example compilation (assuming a standard BOF setup) make -f Makefile
The output will be a `.o` file (e.g., trusted_installer_bof.o) that can be loaded into a C2 framework like Cobalt Strike.
2. Command Execution and Impersonation Flow
Once the BOF is loaded and executed, it performs a series of internal steps. The goal is to obtain a handle to the `TrustedInstaller` process, duplicate its token, and then impersonate it to execute commands with high integrity. This flow is critical for red team operations where stealth is paramount.
Step‑by‑step guide:
- Load and execute the BOF: Within your C2 agent (e.g., Beacon), execute the BOF using the appropriate command, such as
bof-trusted-installer. - API Call: The BOF calls `DismCheckImageHealth` via
dismapi.dll. This initiates the servicing stack. - Process Creation: `TrustedInstaller.exe` starts as a child process of the servicing stack, not of your agent.
- Handle Acquisition: The BOF enumerates processes and uses `OpenProcess` to obtain a handle to `TrustedInstaller.exe` with `PROCESS_QUERY_INFORMATION` and `PROCESS_DUP_HANDLE` rights.
- Token Duplication: Using `OpenProcessToken` and
DuplicateTokenEx, the BOF creates a primary token from the `TrustedInstaller` process. - Impersonation: The BOF uses `ImpersonateLoggedOnUser` or `CreateProcessAsUser` with the duplicated token to spawn a new command shell or run a payload with TrustedInstaller privileges.
3. BOF Implementation and In-Memory Execution
Beacon Object Files are designed for stealth. They execute in the memory of the beacon process without writing a new executable to disk. This is a significant advantage over traditional privilege escalation tools that drop executables. The BOF code is written in C and must be position-independent.
Key code snippet concepts:
The BOF would include a function like `go` that is exported. Inside, it would:
– Dynamically resolve the addresses of `LoadLibraryA` and `GetProcAddress` to avoid imports.
– Load `dismapi.dll` and resolve the address of DismCheckImageHealth.
– Call `DismCheckImageHealth` with appropriate parameters.
– Wait for the TrustedInstaller process to appear.
– Execute the token stealing and impersonation logic.
// Pseudo-code within BOF
void go(char args, int len) {
HMODULE hDism = LoadLibraryA("dismapi.dll");
if (hDism) {
DismCheckImageHealthFunc pDismCheck = (DismCheckImageHealthFunc)GetProcAddress(hDism, "DismCheckImageHealth");
if (pDismCheck) {
pDismCheck(/.../);
// Wait for TrustedInstaller.exe
Sleep(2000);
// Find PID and impersonate
// ...
}
}
}
4. Detection and Mitigation Strategies
For defenders, this technique represents a challenge because it abuses legitimate system functions. The use of `dismapi.dll` by an unexpected process is a strong indicator. Many applications do not legitimately call DismCheckImageHealth. Monitoring for processes that load `dismapi.dll` and subsequently perform token manipulation can yield high-fidelity alerts.
Detection commands:
- Monitor for dismapi.dll loads:
PowerShell command to check for unusual processes loading dismapi.dll Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; ID=7} | Where-Object { $_.Message -like "dismapi.dll" } - Monitor for Token Impersonation:
Use Sysmon Event ID 10 (ProcessAccess) to detect `OpenProcess` calls with `PROCESS_DUP_HANDLE` or `PROCESS_QUERY_INFORMATION` on `TrustedInstaller.exe` by non-system processes. - Mitigation: Consider enabling Windows Defender Application Control (WDAC) or AppLocker to restrict which executables can load
dismapi.dll. Additionally, rigorous EDR rules that detect unusual call stacks leading to `TrustedInstaller.exe` spawning can be effective.
5. Operational Security Considerations
While this technique avoids SCM, it is not entirely invisible. It still creates a `TrustedInstaller.exe` process, which under normal circumstances should only be active during Windows servicing tasks. An active `TrustedInstaller.exe` on a system that is not installing updates is suspicious. Furthermore, the act of thread impersonation to launch a command shell or reverse shell will still generate process creation events.
Windows commands to monitor:
– `tasklist /fi “imagename eq TrustedInstaller.exe”` – Check for active instances.
– `wmic process where name=”TrustedInstaller.exe” get parentprocessid` – Identify the parent process; if it’s not `svchost.exe` or a servicing stack process, investigate.
– `netstat -anob` – Check for unexpected outbound connections from processes running as TrustedInstaller.
Red teamers using this technique should pair it with other evasion tactics, such as using named pipes for command execution instead of spawning new processes, and ensuring that the BOF cleans up handles and any artifacts left in memory.
What Undercode Say:
- Stealth Through Legitimacy: By leveraging a standard Windows API call that is part of normal system maintenance, this technique achieves privilege escalation with a significantly lower detection footprint than SCM-based methods.
- BOF Advantage: The use of Beacon Object Files for this technique highlights the shift towards in-memory, fileless attack tooling that bypasses traditional antivirus and leaves minimal forensic artifacts.
- Detection Gap: Defenders must now expand their monitoring to include process lineage and API call patterns for components like DISM, which were previously considered benign.
Prediction:
This technique represents a broader trend where attackers are moving away from high-level service management APIs toward low-level, component-specific APIs to achieve privileged operations. As EDRs mature to detect this pattern, we can expect a cat-and-mouse game involving other Windows servicing and management APIs (like CBS or WMI) being abused in similar ways. The future of privilege escalation will increasingly rely on understanding and weaponizing the nuanced behaviors of legitimate system components, making traditional process-based monitoring insufficient and driving the need for behavioral analysis and call stack telemetry.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Meowmycks For – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
