Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
28 detections
Filters
Last updated
All Time
Detection languages
11
11
3
1
1
Contributors
7
5
3
2
2
Categories
18
14
7
6
3
Platforms
18
7
7
2
1
Products / Services
17
7
4
3
2
MITRE Techniques
18,110
15,627
12,575
8,387
6,212
IDS Classtypes
1
IDS Protocols
1
Detects the creation or modification of Kubernetes RoleBindings or ClusterRoleBindings that grant highly privileged roles (e.g., cluster-admin or wildcard permissions) to a subject. The detection includes behavioral analysis to identify ServiceAccount usage from unusual source IP addresses within a short timeframe, which may indicate account compromise and unauthorized privilege escalation.
Detects the creation or modification of Kubernetes RoleBindings or ClusterRoleBindings that grant highly privileged roles (e.g., cluster-admin or wildcard permissions) to a subject. The detection includes behavioral analysis to identify ServiceAccount usage from unusual source IP addresses within a short timeframe, which may indicate account compromise and unauthorized privilege escalation.
Detects creation of Kubernetes role bindings for elevated cluster access
Detects the creation or modification of Kubernetes ClusterRoles, ClusterRoleBindings, and RoleBindings, which can be used for privilege escalation within a Kubernetes cluster. The rule specifically flags activities related to 'cluster-admin' roles as critical and other administrative roles as high severity.
This rule detects the creation of a cluster role binding in a Kubernetes environment, specifically looking for HTTP POST requests to the Kubernetes API server's rbac.authorization.k8s.io endpoint for 'rolebindings'. This activity can indicate an attempt to establish persistence within the cluster by granting specific permissions to an identity.
Detects suspicious Kubernetes Role-Based Access Control (RBAC) changes that grant elevated privileges, such as 'cluster-admin' roles, wildcard permissions for verbs, resources, or API groups, or direct access to secrets or service accounts. This rule monitors 'create', 'update', and 'patch' operations on roles, clusterroles, rolebindings, and clusterrolebindings within Kubernetes audit logs.
This rule detects the creation, patching, or updating of Kubernetes ClusterRoleBindings, RoleBindings, or Roles within the 'prod', 'production', or 'default' namespaces. It specifically excludes actions performed by the 'system:clusterrole-aggregation-controller' to reduce noise from legitimate system operations. This activity can indicate an attempt to manipulate access controls within the Kubernetes cluster, potentially for privilege escalation or persistence.
Detects activity where there are role bindings and high-risk actions (verbs) applied.
This could be indicative of Privilege Escalation.
This could be indicative of Privilege Escalation.
This rule detects a multi-stage attack chain starting with a high-confidence phishing email, followed by a risky sign-in from the recipient, and culminating in sensitive actions within Azure, specifically targeting IAM role assignments, storage account key access, or AKS cluster modifications. The detection correlates these events within a defined time window to identify potential compromise of cloud resources originating from a successful phishing attack.
Detects when a modification (create, update, replace, delete, or patch) action is taken that affects mutating or validating webhook configurations in Kubernetes. Adversaries can abuse these configurations to achieve persistence, exfiltrate credentials, or escalate privileges within the cluster.
This rule identifies when an admission controller is executed in Azure Kubernetes. Admission controllers intercept and potentially modify requests to the Kubernetes API server. Adversaries can leverage admission webhooks (MutatingAdmissionWebhook or ValidatingAdmissionWebhook) for persistence, such as injecting malicious containers into pods or intercepting API requests to steal credentials and sensitive information.
This rule detects the creation of Kubernetes pods by non-system service accounts within namespaces that start with 'kube'. This could indicate an attempt to establish persistence or escalate privileges within the Kubernetes cluster by creating malicious pods in critical system namespaces.
KQL Query from file: CVE-2024-7971 Patch Prioritization
KQL Query from file: Hunting IngressNightmare (CVSS 9.8)
Detects the creation or modification of an Active Directory forest trust where the CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION (0x00000800) flag is set in TdoAttributes. This includes cases where it's set alone (0x800) or in combination with the FOREST_TRANSITIVE flag (0x808), both indicative of the AORTA attack. For more comprehensive detection, consider backend-specific bitwise checks on TdoAttributes to ensure the 0x800 bit is set, regardless of other flags.
Detects the creation or modification of an Active Directory forest trust with only the CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION (0x00000800) flag set in TdoAttributes. This indicates the AORTA attack where TGT delegation is enabled without the trust also being marked as transitive. This complements the detection for the 0x808 value.
Detects the creation of a new Active Directory forest trust with both FOREST_TRANSITIVE (0x00000008) and CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION (0x00000800) flags set, indicative of the AORTA attack. This rule specifically checks for the TdoAttributes value 0x808, which represents the exact combination of these two flags. Attackers might set additional flags, which would result in a different TdoAttributes value, potentially leading to false negatives. Consider implementing backend-specific bitwise checks if your SIEM supports them for more comprehensive detection.
'This query look for Service Principal accounts that are no longer used where a user has added or updated credentials for them before logging in with the Service Principal.
Threat actors may look to re-activate dormant accounts and use them for access in the hope that changes to such dormant accounts may go un-noticed.'
Threat actors may look to re-activate dormant accounts and use them for access in the hope that changes to such dormant accounts may go un-noticed.'
Author: alex verboon @alexverboon.
Blogpost: https://www.verboon.info/2020/09/hunting-for-local-group-membership-changes.
Blogpost: https://www.verboon.info/2020/09/hunting-for-local-group-membership-changes.
'Detects a privileged role being added to a Service Principal.
Ensure that any assignment to a Service Principal is valid and appropriate - Service Principals should not be assigned to very highly privileged roles such as Global Admin.
Ref: https://docs.microsoft.com/azure/active-directory/fundamentals/security-operations-privileged-accounts#changes-to-privileged-accounts'
Ensure that any assignment to a Service Principal is valid and appropriate - Service Principals should not be assigned to very highly privileged roles such as Global Admin.
Ref: https://docs.microsoft.com/azure/active-directory/fundamentals/security-operations-privileged-accounts#changes-to-privileged-accounts'
Intent:
- Use MTP capability to look for insider threat potential risk indicators
- Indicators would then serve as the building block for insider threat risk modeling in subsequent tools
Definition of Insider Threat:
"The potential for an individual who has or had authorized access to an organization's assets to use their access, either maliciously or unintentionally, to act in a way that could negatively affect the organization."
This collection of queries describes the different indicators that could be used to model and look for patterns suggesting an increased risk of an individual becoming a potential insider threat.
Note: no single indicator should be used as a lone determinant of insider threat activity, but should be part of an overall program to understand the increased risk to your organization's critical assets. This in turn is used to feed an investigation by a formal insider threat program to look at the context associated with the whole person to understand the implication of a set of indicators.
- Use MTP capability to look for insider threat potential risk indicators
- Indicators would then serve as the building block for insider threat risk modeling in subsequent tools
Definition of Insider Threat:
"The potential for an individual who has or had authorized access to an organization's assets to use their access, either maliciously or unintentionally, to act in a way that could negatively affect the organization."
This collection of queries describes the different indicators that could be used to model and look for patterns suggesting an increased risk of an individual becoming a potential insider threat.
Note: no single indicator should be used as a lone determinant of insider threat activity, but should be part of an overall program to understand the increased risk to your organization's critical assets. This in turn is used to feed an investigation by a formal insider threat program to look at the context associated with the whole person to understand the implication of a set of indicators.
Page 1 of 2