r3xmax/phantomctxActivation Context Hijacking Evasion Tool
PhantomCtx is a tool that automates Activation Context hijacking with the objective of loading an arbitrary DLL into the vast majority of signed executables (e.g. Microsoft, Adobe, Mozilla).
The loader is presented as a modern alternative to traditional DLL Hijacking & Sideloading: unlike conventional approaches, it does not require a vulnerable binary. The technique can be performed as long as the target executable resolves a DLL through its Import Address Table (IAT) or, in the worst case, via LoadLibrary without an absolute path.
C:\PhantomCtx\x64>.\PhantomCtx.exe
+----------------------------------+
| PhantomCtx v1.0 |
+----------------------------------+
Usage:
PhantomCtx.exe -m [MODE] [OPTIONS]
Modes:
-m recon Displays information about the Activation Context DLL redirections
of a running process or one to be spawned.
-m spawn Perform Activation Context Hijacking using an on-disk executable
(preferably a signed binary for OPSEC purposes).
-m runtime Perform Activation Context Hijacking on an already running process.
For a deeper dive into how it works internally and how it evades aggressive EDR solutions, check out the post on my technical blog.
PhantomCtx abuses a legitimate Windows feature present in most processes, called Activation Contexts. According to Microsoft:
Activation contexts are data structures in memory containing information that the system can use to redirect an application to load a particular DLL version, COM object instance, or custom window version...
When the Windows Loader resolves a DLL (via LoadLibrary or the import table), it follows a defined resolution order:
PhantomCtx targets step 3: SxS manifest redirection. Activation Contexts are derived from Side-by-Side (.manifest) files associated with executables, typically embedded in PE binaries. Internally, an Activation Context contains a Table of Contents (ToC) indexing multiple sections, including the DLL redirection section. The Loader typically accesses Activation Contexts through PEB.ActivationContextData.
Research by Kurosh Dabbagh Escalante showed that a malicious Activation Context can be constructed using CreateActCtxW, written into RW memory in a target process, and then activated by overwriting PEB.ActivationContextData to point to the crafted structure.
Once hijacked, the loader resolves DLL redirections defined within the malicious Activation Context, redirecting library resolution to paths controlled by the attacker.
The loader named Eclipse, developed as part of his research, can be found in its official repository.
After multiple tests, Eclipse was detected by aggressive EDRs such as Elastic at the following points:
Potential Suspended Process Code Injection: suspended process creation followed by NtWriteVirtualMemory to copy the AC blob into the remote process.Remote Process Memory Write by Low Reputation Module: NtWriteVirtualMemory without CreateProcess in the call stack and a low-reputation module, needed for overwriting PEB.ActivationContextData.Remote Memory Write to Trusted Target Process: WriteProcessMemory without CreateProcess in the call stack, restricted to system/user-installed binaries.After one day of research looking for alternative approaches to implement in PhantomCtx, I discovered that the memory region of the original Activation Context is a section view mapped during process creation. It is possible to unmap this section view using NtUnmapViewOfSection and then create a new read-only section view backed by our malicious Activation Context, mapping it at the exact same memory address where the original one resided.
As a result, it is no longer necessary for the loader to overwrite the PEB.ActivationContextData pointer. This eliminates the requirement to use NtAllocateVirtualMemory and NtWriteVirtualMemory, bypassing all EDR monitoring rules related to remote process memory writes and injection.
Additionally, to increase detection difficulty, PhantomCtx does not use CreateActCtxW, removing the need to handle .manifest files during the attack. Depending on the selected mode, it can steal the Activation Context from another remote process containing a valid DLL redirection section using NtReadVirtualMemory, reconstruct the DLL redirection entries locally, patch it, and then replace the original.
To compile the tool, it is recommended to use Visual Studio or a compatible compiler.
If using VS, open the x64 Native Tools Command Prompt for VS, navigate to the project root directory and compile it with compile.bat:
C:\PhantomCtx>.\compile.bat
[INFO] Created output directory: x64
[INFO] Compiling PhantomCtx...
main.c
utils.c
recon.c
actctx.c
c_runtime.c
dynamic_resolution.c
process_utils.c
spawn.c
runtime.c
Generating Code...
[SUCCESSFUL] Build successful: x64\PhantomCtx.exe
The tool is designed with a modular architecture to simplify development while providing the operator with a clear, step-based workflow.
Each module serves a specific role within the exploitation workflow.
Please take a moment to review the purpose of each one to fully leverage the tool’s capabilities!!!
The attack can be performed either on a process to be spawned (recommended) or on an already running process. The tool is designed to handle both scenarios.
C:\PhantomCtx\x64>.\PhantomCtx.exe
+----------------------------------+
| PhantomCtx v1.0 |
+----------------------------------+
Usage:
PhantomCtx.exe -m [MODE] [OPTIONS]
Modes:
-m recon Displays information about the Activation Context DLL redirections
of a running process or one to be spawned.
-m spawn Perform Activation Context Hijacking using an on-disk executable
(preferably a signed binary for OPSEC purposes).
-m runtime Perform Activation Context Hijacking on an already running process.
The recon mode focuses on parsing the Activation Context of the target program or running process. It is the first module that should be executed, as it determines which exploitation submodule should be used within the exploitation workflow.
C:\PhantomCtx\x64>.\PhantomCtx.exe -m recon -h