D3-PT
Definition
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 <a href="https://d3fend.mitre.org/technique/d3f:AdministrativeNetworkActivityAnalysis" rdf:about="https://d3fend.mitre.org/ontologies/d3fend.owl#AdministrativeNetworkActivityAnalysis">Administrative Network Activity Analysis</a>, after a failed check from <a href="https://d3fend.mitre.org/technique/d3f:StackFrameCanaryVerification" rdf:about="https://d3fend.mitre.org/ontologies/d3fend.owl#StackFrameCanaryValidation">Stack Frame Canary Validation</a>, or after <a href="https://d3fend.mitre.org/technique/d3f:SystemCallAnalysis" rdf:about="https://d3fend.mitre.org/ontologies/d3fend.owl#SystemCallAnalysis">System Call Analysis</a> 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.
Artifact Relationships
This defensive technique relates to specific digital artifacts.