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.
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.
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.
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
kill. Processes started in the Windows Subsystem for Linux (WSL) environment may be terminated there with the
In some cases, existing drivers can also be leveraged to kill processes.
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.
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.
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.
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.
After a process has been terminated, it may still take up an entry in the operating system process table until another event occurs.
In Windows, a process object is deleted when the last handle to the process is closed.
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.
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.
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.
The following references were used to develop the Process Termination knowledge-base article.
(Note: the consideration of references does not imply specific functionality exists in an offering.)