Process Termination

Terminating a running application process on a computer system.

How it works

Processes are managed by the operating system kernel. Different operating system kernels manage the creation and termination of processes in a different manner, and expose this functionality via the kernel API.

A running process might be terminated to mitigate its immediate effects if it is exhibiting anomalous, unauthorized, or malicious behavior; such as after detecting anomalous behavior via Administrative Network Activity Analysis, after a failed check from Stack Frame Canary Validation, or after System Call Analysis finds an attempt to execute an unauthorized system call.

Proprietary technology

Security software might use proprietary technology to terminate processes, instead of the system-provided functions. Further research may provide specific detail on such methods used.

System-provided functions

Windows tools

In Windows, ExitProcess() is used to send a signal to a process to request it to exit, and TerminateProcess() is used to force a process to exit.

The taskkill executable available in the cmd shell is used to kill a process, with the /F switch forcing termination as with TerminateProcess(). In PowerShell, Stop-Process is used, which is aliased by default to spps and kill. Processes started in the Windows Subsystem for Linux (WSL) environment may be terminated there with the kill command.

In some cases, existing drivers can also be leveraged to kill processes.

Unix/Linux tools

In Unix-like systems, all process termination requests are handled using signals. The kill function takes the Process ID and signal to send, and is accessible with the kill command. Some shells have a kill builtin function which is separate than the kill binary, which can also kill background jobs in the shell and additionally perform the function faster, and can run from an existing instance of the shell if the process table is full. The signal SIGTERM specifies that the process to terminate may invoke a handler that it has defined instead of terminating, and the signal SIGKILL forces immediate termination.

The related command xkill terminates the connection of a program to the X window server, after which the user process may decide to terminate itself; however, termination is not guaranteed as the process, which could be on the same or different host, could then run in a terminal or reconnect to a different X server on any host. Emacs is such a program that would not terminate itself after its connection to the X server is terminated.

Considerations

Persistence Mechanisms

Terminating a malicious process is not enough to stop an adversary that has already gained persistence in the host via any initial access mechanism, including through that process or another access mechanism.

Terminating Multiple Processes

On most operating systems, process termination operations typically occur independently of each other, without functionality provided to atomically terminate multiple processes. If there are multiple malicious processes which can make system calls to spawn other processes once one of them is closed, user session termination or system restart might be required.

Process Access Permissions

Users must have permissions to kill the process. On Unix-like systems, either root or the process user can kill the process. On Windows systems, process permissions are managed separately via process security tokens.

Process Resource Handles

Terminating Processes with Open Resource Handles

Processes may have open resource handles, which could leave those resources in an undesired state if the process is forced to terminate. As such, most operating systems provide a means to send a signal to a process to inform it to gracefully terminate, and on most of these operating systems, it is the typical first step used to terminate a process.

Signal Traps

As the process may have open resource handles, commonly-used methods of process termination involve sending a signal to the process to terminate. On Windows, the ExitProcess() function is used for this purpose. Process instructions, as well as a third-party DLL can also cause the process to exit. On Linux, the process is sent a signal on the occurrence of various events: when it loses the console, SIGHUP; when termination is requested, SIGTERM. The processor then redirects execution to the function registered to handle the signal.

Therefore, sending a signal to the process to ask it to terminate may not always work.

Avoiding Signal Traps

On Unix-like systems, sending the SIGKILL signal for a process does not send a message to the process or invoke an implementation-defined handler; instead, it immediately does not allow the process to execute any further processor instructions. On Windows TerminateProcess() instead of ExitProcess() performs the equivalent.

Hang on System Call Execution

Even still, as the operating system kernel manages the processes, kernel code may block process signals, including those which cannot be trapped, and does in certain circumstances. Signals are blocked and queued for the duration of the system call when interrupting the system call would result in a kernel invariant being violated, such as when an action results in a malformed data structure; this blocking is common for filesystem requests. Such system calls can hang when a filesystem has gone offline, leading to a long-term uninterruptible sleep, represented in POSIX command ps output as D state. Any malicious system calls or system call handlers are issues of a much larger problem (a kernel-level rootkit) and the system should be redeployed entirely or restored from a backup known to be prior to compromise, and other systems accessible directly and indirectly from that one should also be examined.

A process that is truly hung in a system call may prevent the system from shutting down and leave it in an unresponsive state; a hard power off is required.

To speed up the action of terminating a process in uninterruptible sleep, the process resource accesses (handles) could be analyzed.

On Linux, sync followed by echo 3 > /proc/sys/vm/drop_caches is a safe way to free up some inactive resource handles.

Kernel Processes and Threads

The kernel may not allow kernel processes, which are created via methods other than user-space processes, to be terminated.

Other Code using the Process

Terminating a shared library can lead to unexpected errors; such shared libraries have their own mechanisms for termination.

On Windows, a DLL is unloaded when the reference count of the library reaches 0.

Zombie process

After a process has been terminated, it may still take up an entry in the operating system process table until another event occurs.

Windows

In Windows, a process object is deleted when the last handle to the process is closed.

Linux

In Linux, a process is removed from the process table when it is reaped by its parent process. If the parent terminates, historically the parent has been changed to pid 1; however, in the Linux kernel 3.4 and above, processes can set a different process as the subreaper using the prctl() system call.

Zombie processes and hung processes could be resolved with a restart of the system.

System restart

Finally a system restart might be required to kill a process. Systems which are only accessible via a remote in-band connection may become inaccessible if a process termination operation that is necessary for reboot does not complete.

Subsystems

Processes that are started in a subsystem might not be fully terminated if they are terminated using the command for that subsystem. For example, in the Windows Subsystem for Linux (WSL), processes started and terminated via WSL calls such as with the kill command in Bash may still have an entry in the Windows process table.