This rule monitors for the creation of an EKS cluster. Impact A creation of a new EKS cluster should be verified. Mitigation Inspect the user who created the EKS Cluster and verify if this was an authorized action. Further investigate and revert changes if not. Note- This alert works on cloudtrail logs MITRE Tactic: TA0001 MITRE Technique: T1578

This rule detects if an EKS cluster was deleted. Impact An unauthorized change or deletion of an EKS could indicate malicious activity. Mitigation Investigate the deletion of EKS cluster, if the activity wasn't authorized, revert changes and further investigate the user that made the changes for any other malicious activity. Note- This alert works on cloudtrail logs MITRE Tactic: TA0005 MITRE Technique: T1610

This rule detects if an EKS Cluster was created/modified with public access. Impact AWS EKS with public access is vulnerable to multiple types of attacks and therefore not advised. Mitigation Inspect the user who created the EKS Cluster and verify if this was an authorized action. Further investigate and revert changes if not. Note- This alert works on cloudtrail logs. MITRE Tactic: TA0001 MITRE Technique: T1578

Service account tokens are used mainly by applications to call the Kubernetes API from within the cluster. Impact If the serviceaccount token is used from an anomalous IP, this could mean that an attacker has compromised the serviceaccount token of a privileged application and is trying to use it to access resources within the cluster. Mitigation It should be validated if this was a genuine call from outside. Note- All the service accounts which are expected to be used from public domain should be whitelisted to reduce the false positives. MITRE Tactic: TA0006 MITRE Technique: T1555

This alert triggers when there are multiple occurrences of unhealthy pod. If a pod is in the unhealthy state, it indicates that Kubernetes has detected a problem on the pod. Impact - Denial of Service (DoS) Vulnerability: Attackers could intentionally exhaust CPU or memory resources in pods, triggering a denial of service against critical services or applications. - Resource Exhaustion Attacks: Malicious actors might target pods with resource-intensive requests, depleting available resources and causing disruptions across the system. Mitigation Identify which non-Kubernetes processes are running on the node. If there are any, shut them down or reduce them to a minimum to conserve resources. Run a malware scan—there may be hidden malicious processes taking up system resources MITRE Tactic: TA0040 MITRE Technique : T1496

This alert triggers when there are multiple Node Not Ready. If a node is in the NodeReady state, it indicates that the kubelet is installed on the node, but Kubernetes has detected a problem on the node that prevents it from running pods. Impact When a node shuts down or crashes, it enters the NotReady state, meaning it cannot be used to run pods. All stateful pods running on the node then become unavailable. Mitigation Identify which non-Kubernetes processes are running on the node. If there are any, shut them down or reduce them to a minimum to conserve resources. Run a malware scan—there may be hidden malicious processes taking up system resources MITRE Tactic: TA0040 MITRE Technique : T1496

This alert triggers when there are multiple warnings for insufficient CPU/Memory in a node. If a node is in the NodeReady state, it indicates that the kubelet is installed on the node, but Kubernetes has detected a problem on the node that prevents it from running pods. Impact - Denial of Service (DoS) Vulnerability: Attackers could intentionally exhaust CPU or memory resources in pods, triggering a denial of service against critical services or applications. - Resource Exhaustion Attacks: Malicious actors might target pods with resource-intensive requests, depleting available resources and causing disruptions across the system. Mitigation - Apply rate limiting and throttling mechanisms to mitigate the impact of sudden resource-intensive requests, preventing potential DoS attacks. - Isolate critical services or applications into separate pods or namespaces to contain resource impacts and minimize the blast radius of potential attacks. MITRE Tactic: TA0040 MITRE Technique : T1496

This rule detects suspicious operations performed by the service account like unauthorized request . This is highly unusual behaviour for non-human identities likes service accounts. Impact An attacker may have gained access to credentials/tokens and he is further exploring what operations he is able tom perform and elevating his permissions. Mitigation Any unknown behaviours by service account should be investigated to check its legitimacy MITRE Tactic : TA0003 MITRE Technique : T1098

This detection identifies attempts to link a controller service account to an active or new pod operating within the kube-system namespace. Typically, the controllers operating alongside the API Server rely on admin-level service accounts located within the kube-system namespace. Impact The uncommon assignment of controller service accounts to active pods may signal malicious activity within the cluster. If an intruder gains the ability to create or modify pods or their controllers in the kube-system namespace, they could allocate an admin-level service account to a pod. This could be exploited to wield its potent token, escalating privileges and securing complete control over the cluster. Mitigation It's unusual for controller service accounts to be linked with active pods, indicating atypical behavior with minimal valid use-cases. Therefore, such instances should yield very few false positives and should be flagged for scrutiny. MITRE Tactic: TA0004 MITRE Technique: T1078

The alert detects whenever the - user agent is access_matrix which is a access review tool. Any occurrences of this would signify an access review tool is being used called Rakkess. - RequestURI field within an audit log contains the command being executed,This can be used to identify when a command shell is being used and may indicate further suspicious behaviour if unauthorized. Impact When the use is unexpected this may be indicative of an attacker performing post compromise actions. Mitigation These activities should be validated internally to check if authorized or not. MITRE Tactic: TA0004 MITRE Technique: T1078

This alert detects when a user creates a authentication token via token request API. It is good to verify the IP, user and agent and expiration time for the token. Impact The attacker can create service accounts to maintain the persistance after the attack for longer duration. Mitigation Take appropriate action once the alert triggers like validate the token creation, delete the token and check the environment for any other unauthorized activity. MITRE Tactic :TA0003 MITRE Technique : T1098

This rule monitors if a user attempt pod exec and got failed. Impact A user should not to exec into a pod.If a users exec into a pod it allows them to execute any process(which is not already running) in container. The attacker can get access to the pod by exec the bash and can access some sensitive info like secrets. Mitigation Validate if the user should be execing into a running container. MITRE Tactic: TA0002 MITRE Technique: T1204

This alert detects when a user updates/deleted multiple configmaps across multiple namespaces. Impact If an attacker manages to modify or delete configmaps the corresponding workload would never get spun up and causes Denial of Service Attack. Mitigation The changes should be verified immediately and if the unauthorized changes seen then all the changes should be revert back and all other activities should be checked for the user to minimize the impact. MITRE Tactic: TA0040 MITRE Technique: T1499

This rule detects when a new user ( compared to last 7 days data )is trying to get the network map of cluster using policy listing. Impact If there are multiple such instances, it could mean that an attacker has managed to compromise a legitimate user's credentials and is trying to get network information within the cluster. Mitigation This should be validated internally with the user if that is the expected behaviour of the user. MITRE Tactic: TA0007 MITRE Technique: T1016

This alert detects when an authentication req is received from an expired token. Impact There is a possibility that the token was compromised and the attacker is using that token to gain access to kubernets environment or it can be a case of bruteforce attack. Mitigation The request should be validated if it is a geniune request then you might consider renewing the token or if the req are unknown to you then the activities should be validated in the EKS environment for any unknown queries/changes in past days. MITRE Tactics: TA0006 MITRE Techniques:T1110

Detect when a delete action is performed in Kube-System namespace. Kube-system is the namespace for objects and service accounts with high-level privileges within Kubernetes. Kubernetes itself owns this namespace, which specifically contains vital components like kube-dns, kube-proxy, kubernetes-dashboard, and more. Messing around in this namespace can damage the Kubernetes system. Impact Attackers may want to delete the default name space is in an attempt to avoid detection of their activity in the cluster. Mitigation It should be validated with the user if it is manually deleted. MITRE Tactic: TA0005 MITRE Technique: T1070

This rule monitors if a user has been attached to a pod. A user should not be to attached to a pod. Impact Attaching to a pod allows a user to attach to any process in a running container which may give an attacker access to sensitive data. Mitigation Determine if the user should be attaching to a running container. MITRE Tactic: TA0003 MITRE Technique: T1078

Detect when a delete action is performed on the Node. If a pod in a Kubernetes cluster is deleted by an unauthorized person, it represents a critical security breach and potential disruption to the cluster's operations. This action could stem from a compromised account, inadequate access controls, or an attacker exploiting vulnerabilities, leading to the deletion of pods without proper authorization. Impact 1. Service Disruption: Deleting pods disrupts services and applications running on those pods. This disruption can cause downtime, affect user experience, and interrupt critical processes or workflows. 2. Data Loss: Depending on the application architecture, deleting pods might result in the loss of data stored locally within the pod. This loss can impact the application's functionality or lead to data inconsistencies. 3. Security Compromise: The unauthorized deletion indicates a security breach. It may be part of a larger attack strategy, exposing vulnerabilities in access controls and potentially allowing attackers to gain further unauthorized access or manipulate other resources within the cluster. Mitigation In case of unauthorized pod deletion, the deleted pods need to be restored promptly. Additionally, a thorough examination of the cluster environment should be conducted to scrutinize any other alterations made by the user involved. MITRE Tactic: TA0040 MITRE Technique: T1485

This rule tracks any attempt to create or modify a pod connected to the host PID namespace. By utilizing HostPID, a pod gains access to all processes running on the host, potentially enabling an attacker to perform malicious actions. MITRE Tactic: TA0004 MITRE Technique: T1611

This rule monitors for an attempt to creation or modification of a service as type NodePort. Impact The NodePort service enables external exposure of labeled pods to the internet by creating an open port on every worker node in the relevant cluster. Incoming external traffic on this open port is routed to the specific pod through the associated service. However, if configured by a malicious user, this NodePort setup could intercept traffic from other pods or nodes, circumventing firewalls and other network security measures designed for cluster load balancers. This configuration establishes a direct communication channel between the cluster and external networks, potentially facilitating malicious activities and significantly expanding the cluster's attack surface. Mitigation Assess whether the pod requires NodePort service MITRE Tactic: TA0003 MITRE Technique: T1133

This rule flags API server responses where errors are marked as "Forbidden," signaling that an authenticated user tried an action they aren't explicitly permitted to execute. Impact Patterns of multiple denied actions from a user could indicate potential malicious behavior or unauthorized access attempts, requiring closer investigation. Mitigation Further investigation is required to validate the legitimacy of user actions that have been denied due to insufficient permissions. MITRE Tactic: TA0001,TA0007 MITRE Technique: T1078

This rule watches for instances where a service account or node tries to list its permissions using the selfsubjectaccessreview or selfsubjectrulesreview APIs.Such behaviour is uncommon for non-human identities like service accounts and nodes. Impact It suggests a potential breach where an attacker might have obtained credentials or tokens. This action could indicate an attempt to identify available privileges, potentially to enable further movement or execution within the cluster. Mitigation Any unknown behaviours by service account should be investigated to check its legitimacy MITRE Tactic: TA0007 MITRE Technique: T1613

This rule detects when a Kubernetes user is assigned to the cluster-admin role. Impact This grants the referenced user with full administrator permissions over all the Kubernetes cluster. Mitigation Check if the Kubernetes user should have received administrative privileges within the cluster. MITRE Tactic: TA0004 MITRE Technique: T1548

This rule monitors when any action is permitted with status_code:[100 TO 299]) for an unauthenticated user. The /healthz and /livez endpoint is commonly accessed unauthenticated hence excluded in the query filter. Impact Unauthorized access to resources serves as a clear indication of a compromise within the system. Any instance of accessing resources without proper authorization signifies a potential breach or compromise in the security of the system or network. Mitigation Check all the HTTP paths accessed by the user and it should be validated if these paths should be allowed to access by unauthorised user Check for other sensitive endpoints accessed from same source IP. MITRE Tactic: TA0001 MITRE Technique: T1190

This rule monitors if a user has been exec into a pod. Impact A user should not to exec into a pod.If a users exec into a pod it allows him to execute any process(which is not already running) in container. The attacker can get access to the pod by exec the bash and can access some sensitive info like secrets. Mitigation Validate if the user should be execing into a running container. MITRE Tactic: TA0002 MITRE Technique: T1204

This rule monitors for an attempt of creation or modification of a pod attached to the host network. HostNetwork allows a pod to use the node network namespace. It gives the pod access to any service running on localhost of the host. An attacker could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies applied to its given namespace. MITRE Tactic: TA0004 MITRE Technique: T1611

This monitoring rule detects any attempts to create or modify a pod using the host's IPC namespace. Impact This access allows pods to use the host's inter-process communication (IPC) mechanisms, potentially exposing data accessible to any other pod using the same host IPC namespace. If any process in a pod or on the host utilizes these IPC mechanisms (like shared memory, semaphore arrays, message queues, etc.), an attacker could potentially read from or write to those same mechanisms, posing a security risk. Mitigation This alert should be investigated for legitimacy by determining if the pod is require access to hostIPC namespace MITRE Tactic: TA0004 MITRE Technique: T1611

This detection identifies instances where a pod is generated utilizing a sensitive volume known as hostPath. This volume type enables the mounting of critical files or directories from the node onto the container. Impact If the container becomes compromised, this mount could be exploited by an attacker to gain entry to the node. This situation allows the attacker various pathways to escalate privileges, such as accessing data from other containers and reaching tokens belonging to more privileged pods within the system. Mitigation This alert should be investigated for legitimacy by determining if the hostpath triggered is one needed by its target container/pod. MITRE Tactic: TA0004 MITRE Technique: T1611

This rule monitors and alerts in every 5 minutes for more than usual 4XX error code received with a threshold of 10 which might be an indication of brute force attack. Impact Service Disruption: Continual receipt of 40XX errors can disrupt services relying on Kubernetes, leading to downtime or impaired functionality. Degraded Performance: The accumulation of these errors might impact the overall performance of the Kubernetes cluster, causing delays or unresponsiveness in handling requests. Mitigation 1. Investigate the logs and error messages to pinpoint the specific requests causing the 4XX errors. 2. Enforce rate limiting for incoming requests to prevent excessive requests or potential abuse, which could lead to malformed requests and subsequent 4XX errors. MITRE Tactic: TA0006 MITRE Technique: T1110

This rule monitors for creation of a pod/container running in privileged mode. Impact A container with extensive privileges can access the node's resources, compromising the isolation between containers. If this container is breached, attackers can exploit it to reach the underlying host. Access to the host offers adversaries opportunities to carry out further objectives, like establishing long-term presence, moving through the environment, or creating a command and control channel on the host. Mitigation Assess whether the pod requires privileged access. MITRE Tactic: TA0002 MITRE Technique: T1609

This rule monitors for an attempt to creation or modification of 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. MITRE Tactic: TA0003 MITRE Technique: T1133

This alert identifies the attempts to discover the secrets with cluster for lateral movements. Impact If the user is trying to get the secrets and he is not authorized to view is probably account compromise case. Mitigation The activity should be validated to check if the user is expected to view the secrets in the vault which they are looking for. MITRE Tactic : TA0008 MITRE Technique : T1021

This alert detects when a user deletes kubernetes "event" resources that are generally never deleted by users. A technique generally employed by attackers is to delete kubernetes resource type - "events". This ensures that these events do not show up on the Administrator's or the Security team's radar in case the attackers are creating resources within the cluster. Impact Deleting the events is the technique used by attacker to avoid the detection of any malicious activity. Mitigation Ideally the log events should bot be deleted hence the activity should be verified and further investigation should be done incase of unauthorized deletion of events is detected MITRE Tactic : TA0005 MITRE Technique: T1562

This alert detects when a user tried to create cronjob but got forbid response. There should ideally be minimal number of forbids for creating "cronjobs" assuming the user have admin access to the namespace in the cluster. Impact An anomalous number of forbids for cronjob creation could indicate that an attacker is trying to gain a persistent foothold in the cluster Mitigation The activity should be verified if this was a genuine requirement by the user or the user account is compromised and the attacker was trying to create persistence using cronjob and should be investigated further MITRE Tactic:TA0003 MITRE Technique: T1053

This alert detects the scanning activity on pods by unauthorized user. Impact Unauthorized attempts to access pods pose a serious risk, as any user or attacker gaining entry could cause harm or compromise security Mitigation In the case of unauthorized or external users attempting to access pods, take immediate action to investigate and block such attempts. This may involve isolating the user account, revoking access privileges, and implementing additional security measures to prevent further unauthorized access. MITRE Tactic: TA0043 MITRE Technique: T1595

This rule detects if an activity for system namespace is observed from public IP Impact Accessing system namespaces within your Kubernetes environment without proper authorization can pose significant risks and potential harm to the system's integrity and security. Mitigation The activity should be validated with the user. MITRE Tactic- TA0001 MITRE Technique: T1190

This flow alert detects when there are multiple failed operations from a IP followed by cluster admin access assigned to a user. Impact It is possible an attacker trying to scan the kubernetes infra and then he got in to the system and then did privilege escalation to get the cluster admin access. Mitigation This activity should be validated and investigated further. MITRE Tactic: TA0004 MITRE Technique: T1078

This rule detects when a service account is accessed from public IP and then some unauthorized and other critical operations are attempted. . This is highly unusual behavior for non-human identities likes service accounts. Impact An attacker may have gained access to credentials/tokens and they are further exploring what operations they are able to perform and elevating their permissions. Mitigation Any unknown behaviours by service account should be investigated to check its legitimacy MITRE Tactic : TA0003 MITRE Technique : T1098