Actions
Overview of manual response actions that can be executed in the UI, including killing a process or killing a pod.
Last updated
Overview of manual response actions that can be executed in the UI, including killing a process or killing a pod.
Last updated
© SPYDERBAT, Inc., All Rights Reserved
The Spyderbat platform features include a powerful response capability: the option to kill processes on Linux machines or pods within Kubernetes clusters directly through the UI. This feature empowers security teams to take immediate action during an investigation, stopping active threats as soon as they are identified.
Whether dealing with malicious processes on a machine or a compromised pod within a Kubernetes cluster, users can mitigate the threat swiftly and efficiently.
This capability ensures real-time responsiveness by terminating the identified threat within seconds. The action is recorded in an audit log for accountability and compliance purposes.
Killing a process or pod requires specific permissions for the logged in user. By default these permissions are preset for the following Spyderbat Roles:
Admin
Power User
Roles for users can be assigned or modiefied in the Admin section, Organization management. For more details, see User and role management overview
The process starts with an investigation, which can be the result of pivoting from a high scoring trace, or a security redflag, drilling down from a dashboard card, or just from the output of the search results to find specific proccess or kubernetes resources of interest.
Once you have identified the process of interest in the Investigation section of the UI, you can take action.
In this example, we identified a netcat server running on port 9000
The kill action can be taken either at the bottom of the graph view, or within the process details view. You can opt to kill the process, or, if the process is running in a container from a Kubernetes cluster, to kill the entire pod.
After selecting the "Kill Process" action, a confirmation dialog will appear, prompting you to provide a reason for the action. This reason will be recorded in the audit log for accountability and future reference. Input a clear and concise reason for the kill action, for example "Terminating malicious process" or "Shutting down compromised pod."
To prevent accidental terminations, Spyderbat requires confirmation before executing the kill action. After entering your reason, click 'YES, KILL PROCESS' to proceed with the process termination.
The process for killing a pod is exactly the same, just select Kill Pod and follow the confirmation prompt.
Once confirmed, Spyderbat will automatically terminate the process or pod within seconds. A popup at the bottom-page will provide confirmation.
After a process is killed, its icon will be updated to reflect it is now defunct, and the process details will contain action audit log information
Every kill action, including the reason for the termination and user details, is recorded in Spyderbat’s comprehensive audit log. You can review this log to track all interventions taken during an investigation.
You can find a full log of all actions taken in your account by navigating to the Reports, Action Log section
In the actions log you will find what type of action was taken, the action status, when it was created, the action result code, who took the action, the reason provided and what process or pod was impacted.
You can filter for specific actions you are looking for by clicking on "Filters", and adjust the columns view by clicking on "Columns".
After the kill action, you should continue to identify root-cause of the unexpected behavior you chose to terminate.
It is possible another process is still active that could respawn the same type of process you just killed, so reviewing processes again would be a great idea.
Similarly, if you chose to kill the pod, be mindful a new pod might be automatically created by the cluster, exhibiting the same threat you tried to eliminate. Confirm that the behavior you want to see addressed is not introduced by a higher-up kubernetes resource manager, such as a deployment or statefulset that was compromised.
