EXPLORE DETECTIONS
Kirbi File Creation
Identifies the creation of .kirbi files. The creation of this kind of file is an indicator of an attacker running Kerberos ticket dump utilities, such as Mimikatz, and precedes attacks such as Pass-The-Ticket (PTT), which allows the attacker to impersonate users using Kerberos tickets.
KRBTGT Delegation Backdoor
Identifies the modification of the msDS-AllowedToDelegateTo attribute to KRBTGT. Attackers can use this technique to maintain persistence to the domain by having the ability to request tickets for the KRBTGT service.
Kubeconfig File Creation or Modification
The kubeconfig file is a critical component in Kubernetes environments, containing configuration details for accessing and managing Kubernetes clusters. Attackers may attempt to get access to, create or modify kubeconfig files to gain unauthorized initial access to Kubernetes clusters or move laterally within the cluster.
Kubeconfig File Discovery
The kubeconfig file is a critical component in Kubernetes environments, containing configuration details for accessing and managing Kubernetes clusters. Attackers may attempt to get access to, create, or modify kubeconfig files to gain unauthorized initial access to Kubernetes clusters or move laterally within the cluster. This rule detects process discovery executions that involve kubeconfig files, particularly those executed from common shell environments or world-writeable directories.
Kubectl Apply Pod from URL
This rule detects the execution of the "kubectl apply" command with a URL argument. This command is often used to apply configurations or deploy resources in a Kubernetes cluster. Attackers may use this command to deploy malicious pods or modify existing ones, potentially leading to unauthorized access or data exfiltration.
Kubectl Network Configuration Modification
This rule detects potential kubectl network configuration modification activity by monitoring for process events where the kubectl command is executed with arguments that suggest an attempt to modify network configurations in Kubernetes. This could indicate an adversary trying to manipulate network settings for malicious purposes, such as establishing unauthorized access or exfiltrating data.
Kubectl Permission Discovery
This rule detects the use of the "kubectl auth --can-i" command, which is used to check permissions in Kubernetes clusters. Attackers may use this command to enumerate permissions and discover potential misconfigurations in the cluster, allowing them to gain unauthorized access or escalate privileges.
Kubectl Secrets Enumeration Across All Namespaces
This rule detects the use of the "kubectl get secrets --all-namespaces" command, which enumerates secret resources across the entire Kubernetes cluster. Attackers may use this command to identify accessible secrets in multiple namespaces, aiding credential discovery, privilege escalation, or lateral movement.
Kubelet Certificate File Access Detected via Defend for Containers
This rule detects the access of the Kubelet certificate file inside a container. The Kubelet certificate file is used to authenticate the container to the Kubernetes API server, and may be used by an adversary to gain access to the Kubernetes API server or other resources within the cluster. These files are a common target for adversaries to gain access to the cluster. There is a current limitation in the defend for containers file sensor that prevents file open events from being logged for file open events without write intent.
Kubelet Pod Discovery Detected via Defend for Containers
This rule detects the use of built-in utilities to discover running pods on a Kubernetes cluster. The utilities used are du, nice, find, locate, and ls. These utilities are commonly used to discover running pods on a Kubernetes cluster. The "/var/lib/kubelet/pods" directory is the default location for Kubelet pod information.
Kubernetes Anonymous Request Authorized by Unusual User Agent
This rule detects when an unauthenticated user request is authorized within the cluster via an unusual user agent. Attackers may attempt to use anonymous accounts to gain initial access to the cluster or to avoid attribution of their activities within the cluster. This rule excludes the /healthz, /livez, /version and /.well-known/oauth-authorization-server endpoints which are commonly accessed anonymously.
Kubernetes Anonymous User Create/Update/Patch Pods Request
This rule detects attempts to create, update, or patch pods by an anonymous user. An anonymous user is a user that is not authenticated or authorized to access the Kubernetes API server. Creating, updating, or patching pods is a common activity for attackers to gain access to the cluster and execute commands.
Kubernetes Cluster-Admin Role Binding Created
This rule detects the creation of a RoleBinding or ClusterRoleBinding that grants the cluster-admin ClusterRole, which provides unrestricted access to all Kubernetes resources and represents a high-risk privilege escalation or misconfiguration.
Kubernetes Container Created with Excessive Linux Capabilities
This rule detects a container deployed with one or more dangerously permissive Linux capabilities. An attacker with the ability to deploy a container with added capabilities could use this for further execution, lateral movement, or privilege escalation within a cluster. The capabilities detected in this rule have been used in container escapes to the host machine.
Kubernetes Creation of a RoleBinding Referencing a ServiceAccount
This rule detects the creation of RoleBindings or ClusterRoleBindings that reference a ServiceAccount, which may indicate privilege delegation or potential RBAC misconfiguration leading to elevated access.
Kubernetes Creation or Modification of Sensitive Role
Detects the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs (e.g., bind, escalate, impersonate), which may enable privilege escalation or unauthorized access within the cluster.
Kubernetes Denied Service Account Request via Unusual User Agent
This rule detects when a service account makes an unauthorized request for resources from the API server via an unusual user agent. Service accounts follow a very predictable pattern of behavior. A service account should never send an unauthorized request to the API server. This behavior is likely an indicator of compromise or of a problem within the cluster. An adversary may have gained access to credentials/tokens and this could be an attempt to access or create resources to facilitate further movement or execution within the cluster.
Kubernetes Direct API Request via Curl or Wget
This rule monitors for the execution of curl or wget commands that directly access Kubernetes API endpoints, which may indicate an attempt to interact with Kubernetes resources in a potentially unauthorized manner. This technique is often used by adversaries to gather information about the Kubernetes environment, such as secrets, config maps, and other sensitive data, without using the official Kubernetes client tools such as "kubectl".
Kubernetes Events Deleted
This rule detects the deletion of Kubernetes events, which can indicate an attempt to cover up malicious activity or misconfigurations. Adversaries may delete events to remove traces of their actions, making it harder for defenders to investigate and respond to incidents.
Kubernetes Exposed Service Created With Type NodePort
This rule detects an attempt to create or modify a service as type NodePort. The NodePort service allows a user to externally expose a set of labeled pods to the internet. This creates an open port on every worker node in the cluster that has a pod for that service. When external traffic is received on that open port, it directs it to the specific pod through the service representing it. A malicious user can configure a service as type Nodeport in order to intercept traffic from other pods or nodes, bypassing firewalls and other network security measures configured for load balancers within a cluster. This creates a direct method of communication between the cluster and the outside world, which could be used for more malicious behavior and certainly widens the attack surface of your cluster.
Kubernetes Forbidden Creation Request
This rule detects attempts to create resources in Kubernetes clusters that are forbidden by the authorization policy. It specifically looks for creation requests that are denied with a "forbid" decision, indicating that the user or service account does not have the necessary permissions to perform the action. This activity is commonly associated with adversaries attempting to create resources in a Kubernetes environment without proper authorization, which can lead to unauthorized access, manipulation of cluster resources, lateral movement and/or privilege escalation.
Kubernetes Forbidden Request from Unusual User Agent
This rule detects when a forbidden request is made from an unusual user agent in a Kubernetes environment. Adversary tooling may use non-standard or unexpected user agents to interact with the Kubernetes API, which can indicate an attempt to evade detection or blend in with legitimate traffic. In combination with a forbidden request, this behavior can suggest an adversary is attempting to exploit vulnerabilities or misconfigurations in the Kubernetes cluster.
Kubernetes Pod Created with a Sensitive hostPath Volume
This rule detects when a pod is created with a sensitive volume of type hostPath. A hostPath volume type mounts a sensitive file or folder from the node to the container. If the container gets compromised, the attacker can use this mount for gaining access to the node. There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including reading data from other containers, and accessing tokens of more privileged pods.
Kubernetes Pod Created With HostIPC
This rule detects an attempt to create or modify a pod using the host IPC namespace. This gives access to data used by any pod that also use the hosts IPC namespace. If any process on the host or any processes in a pod uses the hosts inter-process communication mechanisms (shared memory, semaphore arrays, message queues, etc.), an attacker can read/write to those same mechanisms. They may look for files in /dev/shm or use ipcs to check for any IPC facilities being used.