sample 634d066fd4f9a8b201a3ddf346e880be unable to be terminate on windows 7 x64

[Kwansy98]

Describe what you noticed and did

sample 634d066fd4f9a8b201a3ddf346e880be is a netwire family malware which is using DebugActiveProcess to debug a subprocess svchost.exe. While debug established, in Windows 7, sample itself can not be terminated by TerminateProcess nor sandboxie interface, including qtGUI's "terminate all process" button and sbiedll!SbieDll_KillAll. The only way i found to terminate the sample it is to use TerminateThread to kill all of its threads.
This is not a sandboxie bug, but it might be better if sandboxie ended the process properly :)
https://www.virustotal.com/gui/file/ebcda4a079c878809ffda53ec1f48fde31a6aff4901dbbd15c5b75f6edcb6f81

How often did you encounter it so far?

No response

Affected program

634d066fd4f9a8b201a3ddf346e880be

Download link

hxxp://43.138.13.175/file/634d066fd4f9a8b201a3ddf346e880be

Where is the program located?

The program is installed both inside and outside the sandbox.

Expected behavior

This is not a sandboxie bug, but it might be better if sandboxie ended the process properly :)

What is your Windows edition and version?

Windows 7 x64 7601

In which Windows account you have this problem?

Not relevant to my request.

Please mention any installed security software

no

What version of Sandboxie are you running?

all version has this problem

Is it a new installation of Sandboxie?

I recently did a new clean installation.

Is it a regression?

No response

In which sandbox type you have this problem?

In a standard isolation sandbox (yellow sandbox icon).

Can you reproduce this problem on a new empty sandbox?

I can confirm it also on a new empty sandbox.

Did you previously enable some security policy settings outside Sandboxie?

No response

Crash dump

No response

Trace log

No response

Sandboxie.ini configuration

No response

[DavidXanatos]

can this be reproduced on windows 10?

[diversenok]

The behavior you describe is by design and has little to do with Sandboxie. Debugging is inherently synchronous and grants the debugger the ability to postpone certain system activities regarding the target process (such as its termination). Before the system can fully terminate the target, the debugger needs to reply to the corresponding debug event. Until it happens, the target process will be stuck in a partially-terminated state.

Sandboxie can mitigate this issue the same way System Informer does - by forcing detach on termination. NtTerminateProcess has a special code DBG_TERMINATE_PROCESS that forcibly clears the associated debug object and immediately terminates the process. It works even after initiated termination, so you can call NtTerminateProcess twice - the first time to set the custom exit code, the second with DBG_TERMINATE_PROCESS to guarantee debugger detach.

You can also reproduce this behavior by using SuspendTool from my repository about suspending techniques. Select an option that suspends/freezes the process via a debug object and then terminate the target via Task Manager. The process will get stuck in the same partially-teminated state until you either detach it or close the debugging session.

[Kwansy98]

can this be reproduced on windows 10?

No, currently it only appears in Windows 7, but I have not tested older versions.

[DavidXanatos]

I think in this case the best fix would be to simply always set DBG_TERMINATE_PROCESS right away, a simple fix for a fringe problem.