Filtering Processes Before Injection

[para0x0dise]

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.)

[gemini-code-assist]

Summary of Changes

Hello @para0x0dise, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request aims to significantly reduce false positives in the analysis environment by implementing a sophisticated filtering mechanism for DLL injection. It prevents injection into system processes that are opened with non-malicious access rights, thereby improving the accuracy of analysis results, particularly for document-based malware.

Highlights

• Injection Filtering Logic: Introduced a new filtering mechanism to prevent DLL injection into benign system processes (e.g., explorer.exe, svchost.exe) that are opened with only legitimate access rights. This addresses false positives during analysis of documents that might spawn such processes.
• Process Access Rights Tracking: Modified the InjectionInfo structure and OpenProcessHandler to store and utilize the DesiredAccess flags used when a process handle is opened. This allows the new filtering logic to make informed decisions about whether to proceed with injection.
• New Configuration Option: Added a new configuration option, filter_system_injection, which controls whether this new filtering logic is active. This option is enabled by default to immediately reduce false positives.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

The pull request effectively introduces a new filtering mechanism to prevent false-positive DLL injections into system processes. The changes correctly propagate the DesiredAccess flags through the OpenProcessHandler and InjectionInfo structure, allowing the ProcessMessage function to make informed decisions based on the access rights used to open a process. The definitions of MALICIOUS_FLAGS and LEGITIMATE_FLAGS are appropriate for distinguishing between benign and potentially malicious process access patterns. The implementation is clean, well-commented, and integrates seamlessly with the existing configuration system, enabling the feature by default to enhance the accuracy of threat detection.

[kevoreilly]

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!)

capemon.zip