kevoreilly
Filtering Processes Before Injection
Issue Description
As mentioned in the issue #2608, when I tried to upload PDFs and MS Office documents, it accidentally creates or executes processes such as explorer.exe or svchost.exe, which will trigger false-positive signatures.
After tracking that issue, I found out that Winword.exe or AcroRd32.exe tried to open the explorer.exe process many times, which will eventually create an injection info for that process and send a message to the analyzer to inject the DLLs inside
As shown above, the process is opened with the desired access of PROCESS_DUP_HANDLE, so I have decided to make a filtering condition to avoid injecting the DLLs into these processes BASED ON PROCESS'S DESIRED ACCESS.
Drawbacks
This approach is working with any 64-bit working processes, but fails with 32-bit processes with an error code of 193 (%1 is not a valid Win32 application.)
Hi para0x0dise, firstly I apologise for not responding to the issue over on the main repo. I had read it and meant to reply, then it just slipped my mind and I completely forgot about it, so sorry about that.
It does look like you have gone down the path I was going to suggest anyway which is great. But I suspect there is a misconception as you mention the use of NtOpenProcess triggering monitor injection, but in fact it doesn't. Looking in Injection.c there is a dedicated function ProcessMessage which triggers monitor injection, and this is invoked by the following functions:
SendNotifyMessageA, SendNotifyMessageW, SetWindowLongA, SetWindowLongPtrA, SetWindowLongW, SetWindowLongPtrW, CreateProcessInternalW, SetWindowsHookExA, SetWindowsHookExW, NtCreateProcess, NtCreateProcessEx, NtCreateUserProcess, RtlCreateUserProcess, CreateProcessWithLogonW, CreateProcessWithTokenW, NtMapViewOfSection, NtWriteVirtualMemory, WriteProcessMemory, NtWow64WriteVirtualMemory64, NtQueueApcThread, NtQueueApcThreadEx, NtCreateThread, NtCreateThreadEx, NtSetContextThread, NtSuspendThread, CreateRemoteThread, RtlCreateUserThread
So for your examples it is definitely worth identifying which of the above apis is responsible for triggering the injection into explorer.
To achieve your goal should be simple. The main drawback in doing this however would be that if ever there were injection from a maldoc into explorer, it would be missed. I'm not sure how improbable or not this might be, but in general it's wise to follow the behaviours only where we can, and avoid blacklists.
I am open to the idea of adding something like this to the blacklist, but firstly I can't actually recreate this myself. When I open a PDF I just get AcroRd32.exe:
So definitely worth looking at the Acroreader install and configuration as this issue would be far better avoided at this level than by blacklisting injection in the monitor.
For Excel, again no explorer injection:
I do see injection into explorer from my Word processes. When I dug into which api it was caused by, the culprit was SendNotifyMessageW:
The code in the hook responsible for triggering the monitor injection is in hook_window.c:
if (hWnd) {
our_GetWindowThreadProcessId(hWnd, &pid);
if (pid != GetCurrentProcessId()) {
DumpSectionViewsForPid(pid);
ProcessMessage(pid, 0);
}
}
If we find that these are the same trigger as you are seeing, and they are seen in all installations/configurations, it would worth considering adding code in the hook itself to filter these unwanted injections as the more specific the filter the better. For example:
diff --git a/hook_window.c b/hook_window.c
index 8bf7b29..b58df82 100644
--- a/hook_window.c
+++ b/hook_window.c
@@ -272,7 +272,7 @@ HOOKDEF(BOOL, WINAPI, SendNotifyMessageA,
get_lasterrors(&lasterror);
if (hWnd) {
our_GetWindowThreadProcessId(hWnd, &pid);
- if (pid != GetCurrentProcessId()) {
+ if (!g_config.office && pid != GetCurrentProcessId()) {
DumpSectionViewsForPid(pid);
ProcessMessage(pid, 0);
}
@@ -299,7 +299,7 @@ HOOKDEF(BOOL, WINAPI, SendNotifyMessageW,
get_lasterrors(&lasterror);
if (hWnd) {
our_GetWindowThreadProcessId(hWnd, &pid);
- if (pid != GetCurrentProcessId()) {
+ if (!g_config.office && pid != GetCurrentProcessId()) {
DumpSectionViewsForPid(pid);
ProcessMessage(pid, 0);
}
This is enough to prevent explorer injections from my Word process. If you would like to test this here is the monitor (assuming your Office is 32-bit!)
Hi @kevoreilly,
First off, apologies for the delay—I’ve been quite busy lately. Thank you very much for the clarification on DLL injection, by the way! I also discovered the reason behind the crash when injecting into a 32-bit process—it was due to a null pointer dereference 😅.
Now, back to the main issue: I found a way to suppress the noise caused by explorer.exe. As shown in the screenshots, apps like Word (or other Microsoft applications) often call NtOpenProcess on explorer.exe, which then uses PostThreadMessageA to send messages (I'm not sure why). This eventually triggers ProcessMessage, leading to DLL injection into explorer.exe.
To handle this, one quick solution is to exclude explorer.exe by name within the hook. However, as you pointed out, that could lead to false negatives, especially if a benign-looking app is attempting malicious injection into Explorer. While I haven't seen such a case in practice, I’ve implemented a more reliable method.
I used a variable named g_config.filter_system_safe_process_pid that stores the last PID opened via NtOpenProcess using specific access masks (typically used by legitimate applications). I then compare this PID with the one used in PostThreadMessageA. I’ve tested this approach against several samples, and it seems to work well.
Feel free to take a look and let me know your thoughts!
Hi para0x0dise, thanks for your reply. Over the years I have learned that when it comes to monitor dev, little details really matter. Here the statement 'apps like Word often call NtOpenProcess on explorer.exe, which then uses PostThreadMessageA'... omits the really relevant detail. It is an api called by Word that triggers the injection in to explorer, so unfortunately explorer calling PostThreadMessage on Word isn't relevant. It in fact highlights that the interesting bit has already happened, as api logging of explorer requires it to first be injected, which is what we're trying to stop!
So going back to what I said in my previous message, there is an api called by Word which acts on a handle to explorer, and which is not NtOpenProcess. It is crucial to make sure we identify this api before even considering a solution. In order to identify the api in my case, which may well be the culprit in yours, I had to laboriously comment each call to ProcessMessage in order to correlate with the injection into explorer captured in the analysis log. You did not mention whether the dll I shared was any help in this regard.
Hi @kevoreilly,
Apologies for not mentioning this earlier — I did test your DLLs (my environment is 64-bit), and I incorporated your condition before rebuilding in 64-bit. Unfortunately, the entire task failed because the DLL caused the application to crash.
if (!g_config.office && pid != GetCurrentProcessId()) {
DumpSectionViewsForPid(pid);
ProcessMessage(pid, 0);
}
NtOpenProcess on explorer.exe, which then uses PostThreadMessageA'... omits the really relevant detail. It is an api called by Word that triggers the injection in to explorer, so unfortunately explorer calling PostThreadMessage on Word isn't relevant.
In my particular case, it's Explorer calling PostThreadMessageA that triggers CAPE to inject DLLs and begin monitoring — I'm not sure why this occurs in my setup, but that’s the behavior I’m seeing.
That doesn't make sense. Explorer calls something that causes injection into explorer?
That doesn't make sense. Explorer calls something that causes injection into explorer?
I'm sure that explorer triggered PostThreadMessageA, but I have no idea why? :)
What is needed is to understand that before any apis from explorer can even be captured, the process must first be monitored, therefore injected. Since the initial process is word or excel, and the discussion is about unwanted injection into explorer, the root cause of this problem is an api called by word or excel that causes a hook in the monitor to call ProcessMessage which sends a message to the analyzer to initiate monitor injection into explorer.
It must be one of the apis I listed for which the hook calls ProcessMessage called by the initial process that we need to establish then deal with.
It is difficult to find this api, therefore in order to do it in the case of my 32-bit Office, I added a debug line to every instance of ProcessMessage in api hooks in capemon. If you need me to provide a 64-bit monitor with these added I will recreate it for you. It is also possible to compile the test code I posted in 64-bit form. I am happy to provide this for you to test also. But the first step has to be to establish which api in the initial process triggers injection into explorer.
Here is the tell-tale output from the analysis log showing the extra logging I added to the hooks that call ProcessMessage just prior to the first appearance of explorer in the log where it is injected:
...
2025-06-26 14:47:30,392 [root] DEBUG: 4028: SendNotifyMessageW: ProcessMessage 1308
2025-06-26 14:47:30,408 [root] DEBUG: 4028: ProcessMessage: Monitoring process 1308
2025-06-26 14:47:30,408 [root] INFO: Announced 64-bit process name: explorer.exe pid: 1308
2025-06-26 14:47:30,408 [lib.api.process] INFO: Monitor config for <Process 1308 explorer.exe>: C:\5b78en0k\dll\1308.ini
2025-06-26 14:47:30,424 [lib.api.process] INFO: 64-bit DLL to inject is C:\5b78en0k\dll\PSbaeGaw.dll, loader C:\5b78en0k\bin\hAUrLOKK.exe
...
I've compiled a 64-bit monitor for you with each ProcessMessage() logged to the analysis log which should allow correlation with first appearance of explorer.exe in that log. This is simply the result of adding lines such as the following to all ProcessMessage() calls:
@@ -301,6 +305,7 @@ HOOKDEF(BOOL, WINAPI, SendNotifyMessageW,
our_GetWindowThreadProcessId(hWnd, &pid);
if (pid != GetCurrentProcessId()) {
DumpSectionViewsForPid(pid);
+ DebugOutput("SendNotifyMessageW: ProcessMessage %d", pid);
ProcessMessage(pid, 0);
}
}
Let me know the result and we'll take it from there. capemon_x64.zip