nldcsc-elastic-rules 0.0.8__py3-none-any.whl

nldcsc_elastic_rules/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml

@@ -0,0 +1,129 @@
+[metadata]
+creation_date = "2022/07/11"
+integration = ["kubernetes"]
+maturity = "production"
+updated_date = "2025/06/18"
+
+[rule]
+author = ["Elastic"]
+description = """
+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.
+"""
+false_positives = [
+    """
+    An administrator may need to attach a hostPath volume for a legitimate reason. This alert should be investigated for
+    legitimacy by determining if the kuberenetes.audit.requestObject.spec.volumes.hostPath.path triggered is one needed
+    by its target container/pod. For example, when the fleet managed elastic agent is deployed as a daemonset it creates
+    several hostPath volume mounts, some of which are sensitive host directories like /proc, /etc/kubernetes, and
+    /var/log. Add exceptions for trusted container images using the query field
+    "kubernetes.audit.requestObject.spec.container.image"
+    """,
+]
+index = ["logs-kubernetes.audit_logs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Kubernetes Pod created with a Sensitive hostPath Volume"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Kubernetes Pod created with a Sensitive hostPath Volume
+
+Kubernetes allows containers to access host filesystems via hostPath volumes, which can be crucial for certain applications. However, if a container is compromised, adversaries can exploit these mounts to access sensitive host data or escalate privileges. The detection rule identifies when pods are created or modified with hostPath volumes pointing to critical directories, signaling potential misuse or security risks.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value "kubernetes.audit_logs".
+- Examine the kubernetes.audit.requestObject.spec.volumes.hostPath.path field to determine which sensitive hostPath was mounted and assess the potential risk associated with that specific path.
+- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the legitimacy of the authorization decision.
+- Investigate the kubernetes.audit.requestObject.spec.containers.image field to identify the container image used, ensuring it is not a known or suspected malicious image, and cross-reference with any known vulnerabilities or security advisories.
+- Analyze the context of the pod creation or modification by reviewing the kubernetes.audit.verb field to understand whether the action was a create, update, or patch operation, and correlate this with recent changes or deployments in the environment.
+- Assess the potential impact on the cluster by identifying other pods or services that might be affected by the compromised pod, especially those with elevated privileges or access to sensitive data.
+
+### False positive analysis
+
+- Development environments often use hostPath volumes for testing purposes, which can trigger this rule. To manage this, create exceptions for specific namespaces or labels associated with development workloads.
+- Monitoring tools or agents may require access to certain host paths for legitimate reasons. Identify these tools and exclude their specific container images from the rule, similar to the exclusion of the elastic-agent image.
+- Backup or logging applications might need access to host directories to perform their functions. Review these applications and consider excluding their specific hostPath configurations if they are deemed non-threatening.
+- Some system maintenance tasks might temporarily use hostPath volumes. Document these tasks and schedule them during known maintenance windows, then create temporary exceptions during these periods.
+- Custom scripts or automation tools that interact with Kubernetes may inadvertently trigger this rule. Audit these scripts and tools, and if they are safe, exclude their specific actions or paths from the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected pod to prevent further access to sensitive host data. This can be done by cordoning the node or deleting the pod if necessary.
+- Review and revoke any credentials or tokens that may have been exposed through the compromised pod to prevent unauthorized access to other resources.
+- Conduct a thorough analysis of the container image and application code to identify any vulnerabilities or malicious code that may have led to the compromise.
+- Patch or update the container image and application code to address any identified vulnerabilities, and redeploy the application with the updated image.
+- Implement network policies to restrict pod-to-pod and pod-to-node communication, limiting the potential impact of a compromised pod.
+- Enhance monitoring and logging for Kubernetes audit logs to ensure timely detection of similar threats in the future, focusing on unauthorized access attempts and privilege escalation activities.
+- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions.
+
+## Setup
+
+The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216",
+    "https://kubernetes.io/docs/concepts/storage/volumes/#hostpath",
+]
+risk_score = 47
+rule_id = "2abda169-416b-4bb3-9a6b-f8d239fd78ba"
+severity = "medium"
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset : "kubernetes.audit_logs"
+  and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
+  and kubernetes.audit.objectRef.resource:"pods"
+  and kubernetes.audit.verb:("create" or "update" or "patch")
+  and kubernetes.audit.requestObject.spec.volumes.hostPath.path:
+  ("/" or
+  "/proc" or
+  "/root" or
+  "/var" or
+  "/var/run" or
+  "/var/run/docker.sock" or
+  "/var/run/crio/crio.sock" or
+  "/var/run/cri-dockerd.sock" or
+  "/var/lib/kubelet" or
+  "/var/lib/kubelet/pki" or
+  "/var/lib/docker/overlay2" or
+  "/etc" or
+  "/etc/kubernetes" or
+  "/etc/kubernetes/manifests" or
+  "/etc/kubernetes/pki" or
+  "/home/admin")
+  and not kubernetes.audit.requestObject.spec.containers.image: ("docker.elastic.co/beats/elastic-agent:8.4.0")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1611"
+name = "Escape to Host"
+reference = "https://attack.mitre.org/techniques/T1611/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1610"
+name = "Deploy Container"
+reference = "https://attack.mitre.org/techniques/T1610/"
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

nldcsc_elastic_rules/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml

@@ -0,0 +1,111 @@
+[metadata]
+creation_date = "2022/07/05"
+integration = ["kubernetes"]
+maturity = "production"
+updated_date = "2025/06/18"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects when a user creates a pod/container running in privileged mode. A highly privileged container has
+access to the node's resources and breaks the isolation between containers. If compromised, an attacker can use the
+privileged container to gain access to the underlying host. Gaining access to the host may provide the adversary with
+the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the
+environment, or setting up a command and control channel on the host.
+"""
+false_positives = [
+    """
+    By default a container is not allowed to access any devices on the host, but a "privileged" container is given
+    access to all devices on the host. This allows the container nearly all the same access as processes running on the
+    host. An administrator may want to run a privileged container to use operating system administrative capabilities
+    such as manipulating the network stack or accessing hardware devices from within the cluster. Add exceptions for
+    trusted container images using the query field "kubernetes.audit.requestObject.spec.container.image"
+    """,
+]
+index = ["logs-kubernetes.audit_logs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Kubernetes Privileged Pod Created"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Kubernetes Privileged Pod Created
+
+Kubernetes allows for the creation of privileged pods, which can access the host's resources, breaking container isolation. Adversaries may exploit this to escalate privileges, access sensitive data, or establish persistence. The detection rule identifies such events by monitoring audit logs for pod creation with privileged settings, excluding known safe images, to flag potential security threats.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to identify the user or service account responsible for creating the privileged pod by examining the `kubernetes.audit.annotations.authorization_k8s_io/decision` and `kubernetes.audit.verb:create` fields.
+- Investigate the context of the privileged pod creation by checking the `kubernetes.audit.requestObject.spec.containers.image` field to determine if the image used is known or potentially malicious.
+- Assess the necessity and legitimacy of the privileged pod by consulting with the relevant development or operations teams to understand if there was a valid reason for its creation.
+- Examine the `kubernetes.audit.objectRef.resource:pods` field to identify the specific pod and its associated namespace, and verify if it aligns with expected deployment patterns or environments.
+- Check for any subsequent suspicious activities or anomalies in the Kubernetes environment that may indicate further exploitation attempts, such as lateral movement or data exfiltration, following the creation of the privileged pod.
+
+### False positive analysis
+
+- Known safe images like "docker.elastic.co/beats/elastic-agent:8.4.0" are already excluded from triggering alerts. Ensure that any additional internal or third-party images that are verified as safe are added to the exclusion list to prevent unnecessary alerts.
+- Development and testing environments often use privileged pods for legitimate purposes. Consider creating separate rules or exceptions for these environments to avoid false positives while maintaining security in production.
+- Automated deployment tools or scripts might create privileged pods as part of their normal operation. Review these tools and, if they are deemed safe, add their specific actions or images to the exclusion list.
+- Regularly review and update the exclusion list to reflect changes in your environment, such as new safe images or changes in deployment practices, to maintain an accurate detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected node to prevent further exploitation and lateral movement within the cluster. This can be done by cordoning and draining the node to stop new pods from being scheduled and to safely evict existing pods.
+- Terminate the privileged pod to stop any ongoing malicious activity. Ensure that the termination is logged for further analysis.
+- Conduct a thorough review of the audit logs to identify any unauthorized access or actions taken by the privileged pod. Focus on any attempts to access sensitive data or escalate privileges.
+- Reset credentials and access tokens that may have been exposed or compromised due to the privileged pod's access to the host's resources.
+- Patch and update the Kubernetes environment and any affected nodes to address vulnerabilities that may have been exploited to create the privileged pod.
+- Implement network segmentation and firewall rules to limit the communication capabilities of pods, especially those with elevated privileges, to reduce the risk of lateral movement.
+- Escalate the incident to the security operations team for a comprehensive investigation and to assess the need for further security measures or incident response actions.
+
+## Setup
+
+The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF",
+    "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/",
+]
+risk_score = 47
+rule_id = "c7908cac-337a-4f38-b50d-5eeb78bdb531"
+severity = "medium"
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset : "kubernetes.audit_logs"
+  and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
+  and kubernetes.audit.objectRef.resource:pods
+  and kubernetes.audit.verb:create
+  and kubernetes.audit.requestObject.spec.containers.securityContext.privileged:true
+  and not kubernetes.audit.requestObject.spec.containers.image: ("docker.elastic.co/beats/elastic-agent:8.4.0")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1611"
+name = "Escape to Host"
+reference = "https://attack.mitre.org/techniques/T1611/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1610"
+name = "Deploy Container"
+reference = "https://attack.mitre.org/techniques/T1610/"
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

nldcsc_elastic_rules/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml

@@ -0,0 +1,103 @@
+[metadata]
+creation_date = "2022/09/13"
+integration = ["kubernetes"]
+maturity = "production"
+updated_date = "2025/06/18"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system
+namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in
+the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate
+adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system
+namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate
+privileges and gain complete cluster control.
+"""
+false_positives = [
+    """
+    Controller service accounts aren't normally assigned to running pods, this is abnormal behavior with very few
+    legitimate use-cases and should result in very few false positives.
+    """,
+]
+index = ["logs-kubernetes.audit_logs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Kubernetes Suspicious Assignment of Controller Service Account"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Kubernetes Suspicious Assignment of Controller Service Account
+
+Kubernetes uses service accounts to manage pod permissions, with controller service accounts in the kube-system namespace having elevated privileges. Adversaries may exploit this by assigning these accounts to pods, gaining admin-level access. The detection rule identifies such suspicious assignments by monitoring audit logs for pod creation events in the kube-system namespace with controller service accounts, flagging potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the presence of a "create" event for a pod in the "kube-system" namespace with a service account name containing "controller".
+- Identify the source of the request by examining the user or service account that initiated the pod creation event in the audit logs.
+- Check the history of the involved service account to determine if it has been used in any other suspicious activities or unauthorized access attempts.
+- Investigate the pod's configuration and associated resources to understand its purpose and whether it aligns with expected operations within the cluster.
+- Assess the potential impact by evaluating the permissions and roles associated with the controller service account assigned to the pod.
+- Review recent changes or deployments in the "kube-system" namespace to identify any unauthorized modifications or anomalies.
+
+### False positive analysis
+
+- Routine maintenance tasks in the kube-system namespace may involve creating or modifying pods with elevated service accounts. Review the context of such actions to determine if they are part of scheduled maintenance or updates.
+- Automated deployment tools might temporarily assign controller service accounts to pods for configuration purposes. Verify if these actions align with known deployment processes and consider excluding these specific tools from triggering alerts.
+- Legitimate testing or debugging activities by cluster administrators could involve using controller service accounts. Ensure these activities are documented and consider creating exceptions for known testing environments.
+- Some monitoring or logging solutions might require elevated permissions and could inadvertently trigger this rule. Validate the necessity of these permissions and whitelist these solutions if they are deemed non-threatening.
+- Regularly review and update the list of known benign service account assignments to ensure that only unexpected or unauthorized assignments are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected pod by cordoning the node it is running on to prevent further scheduling of pods and drain the node if necessary to stop the pod from executing.
+- Revoke the service account token associated with the suspicious pod to prevent further unauthorized access or actions using the compromised credentials.
+- Conduct a thorough review of recent changes in the kube-system namespace to identify unauthorized modifications or deployments, focusing on the creation and modification of pods and service accounts.
+- Reset credentials and rotate keys for any service accounts that may have been compromised to ensure that any stolen credentials are rendered useless.
+- Implement network policies to restrict pod-to-pod communication within the kube-system namespace, limiting the potential lateral movement of an attacker.
+- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems have been affected.
+- Enhance monitoring and alerting for similar activities by ensuring audit logs are comprehensive and that alerts are configured to detect unauthorized service account assignments promptly.
+
+## Setup
+
+The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms",
+]
+risk_score = 47
+rule_id = "63c05204-339a-11ed-a261-0242ac120002"
+severity = "medium"
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset : "kubernetes.audit_logs"
+  and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
+  and kubernetes.audit.verb : "create"
+  and kubernetes.audit.objectRef.resource : "pods"
+  and kubernetes.audit.objectRef.namespace : "kube-system"
+  and kubernetes.audit.requestObject.spec.serviceAccountName:*controller
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+[[rule.threat.technique.subtechnique]]
+id = "T1078.001"
+name = "Default Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml

@@ -0,0 +1,102 @@
+[metadata]
+creation_date = "2023/10/12"
+integration = ["lmd", "endpoint"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+anomaly_threshold = 70
+author = ["Elastic"]
+description = """
+A machine learning job has detected unusually high number of process arguments in an RDP session. Executing
+sophisticated attacks such as lateral movement can involve the use of complex commands, obfuscation mechanisms,
+redirection and piping, which in turn increases the number of arguments in a command.
+"""
+from = "now-12h"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = "lmd_high_mean_rdp_process_args"
+name = "High Mean of Process Arguments in an RDP Session"
+references = [
+    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
+    "https://docs.elastic.co/en/integrations/lmd",
+    "https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration",
+    "https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security",
+]
+risk_score = 21
+rule_id = "36c48a0c-c63a-4cbc-aee1-8cac87db31a9"
+setup = """## Setup
+
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
+
+### Lateral Movement Detection Setup
+The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+#### Prerequisite Requirements:
+- Fleet is required for Lateral Movement Detection.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+- Windows RDP process events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) integration.
+- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+
+#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration:
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+"""
+severity = "low"
+tags = [
+    "Use Case: Lateral Movement Detection",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating High Mean of Process Arguments in an RDP Session
+
+Remote Desktop Protocol (RDP) facilitates remote access to systems, often targeted by adversaries for lateral movement. Attackers may exploit RDP by executing complex commands with numerous arguments to obfuscate their actions. The detection rule leverages machine learning to identify anomalies in process arguments, flagging potential misuse indicative of sophisticated attacks.
+
+### Possible investigation steps
+
+- Review the specific RDP session details, including the source and destination IP addresses, to identify any unusual or unauthorized access patterns.
+- Analyze the process arguments flagged by the machine learning model to determine if they include known malicious commands or patterns indicative of obfuscation or redirection.
+- Check the user account associated with the RDP session for any signs of compromise, such as recent password changes or login attempts from unusual locations.
+- Correlate the alert with other security events or logs, such as firewall logs or intrusion detection system alerts, to identify any related suspicious activities or lateral movement attempts.
+- Investigate the historical behavior of the involved systems and users to determine if the high number of process arguments is an anomaly or part of a regular pattern.
+
+### False positive analysis
+
+- Routine administrative tasks may generate a high number of process arguments, such as batch scripts or automated maintenance operations. Users can create exceptions for known scripts or processes that are regularly executed by trusted administrators.
+- Software updates or installations often involve complex commands with multiple arguments. To mitigate false positives, users should whitelist update processes from trusted vendors.
+- Monitoring and management tools that perform extensive logging or diagnostics can trigger this rule. Users should identify and exclude these tools if they are verified as non-threatening.
+- Custom applications or scripts developed in-house may use numerous arguments for configuration purposes. Users should document and exclude these applications if they are part of normal business operations.
+- Scheduled tasks that run during off-hours might appear suspicious due to their complexity. Users can adjust the rule to ignore these tasks if they are part of a regular, approved schedule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
+- Terminate any suspicious RDP sessions and associated processes that exhibit high numbers of arguments to halt ongoing malicious activities.
+- Conduct a thorough review of the affected system's event logs and process execution history to identify any unauthorized access or changes made during the RDP session.
+- Reset credentials for any accounts that were accessed during the suspicious RDP session to prevent unauthorized access using compromised credentials.
+- Apply security patches and updates to the affected system and any other systems within the network to mitigate vulnerabilities that could be exploited for similar attacks.
+- Enhance monitoring and logging for RDP sessions across the network to detect and respond to similar anomalies more quickly in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised."""
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1210"
+name = "Exploitation of Remote Services"
+reference = "https://attack.mitre.org/techniques/T1210/"
+
+
+[rule.threat.tactic]
+id = "TA0008"
+name = "Lateral Movement"
+reference = "https://attack.mitre.org/tactics/TA0008/"
+

nldcsc_elastic_rules/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml

@@ -0,0 +1,103 @@
+[metadata]
+creation_date = "2023/10/12"
+integration = ["lmd", "endpoint"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+anomaly_threshold = 70
+author = ["Elastic"]
+description = """
+A machine learning job has detected unusually high mean of RDP session duration. Long RDP sessions can be used to evade
+detection mechanisms via session persistence, and might be used to perform tasks such as lateral movement, that might
+require uninterrupted access to a compromised machine.
+"""
+from = "now-12h"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = "lmd_high_mean_rdp_session_duration"
+name = "High Mean of RDP Session Duration"
+references = [
+    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
+    "https://docs.elastic.co/en/integrations/lmd",
+    "https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration",
+    "https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security",
+]
+risk_score = 21
+rule_id = "a74c60cb-70ee-4629-a127-608ead14ebf1"
+setup = """## Setup
+
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
+
+### Lateral Movement Detection Setup
+The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+#### Prerequisite Requirements:
+- Fleet is required for Lateral Movement Detection.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+- Windows RDP process events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) integration.
+- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+
+#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration:
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+"""
+severity = "low"
+tags = [
+    "Use Case: Lateral Movement Detection",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating High Mean of RDP Session Duration
+
+Remote Desktop Protocol (RDP) enables remote access to systems, facilitating administrative tasks. However, adversaries exploit prolonged RDP sessions to maintain persistent access, potentially conducting lateral movements undetected. The 'High Mean of RDP Session Duration' detection rule leverages machine learning to identify anomalies in session lengths, flagging potential misuse indicative of malicious activity.
+
+### Possible investigation steps
+
+- Review the specific RDP session details, including the start and end times, to understand the duration and identify any patterns or anomalies in session lengths.
+- Correlate the flagged RDP session with user activity logs to determine if the session aligns with expected user behavior or if it deviates from normal patterns.
+- Check for any concurrent or subsequent suspicious activities, such as file transfers or command executions, that might indicate lateral movement or data exfiltration.
+- Investigate the source and destination IP addresses involved in the RDP session to identify if they are known, trusted, or associated with any previous security incidents.
+- Analyze the user account involved in the RDP session for any signs of compromise, such as recent password changes, failed login attempts, or unusual access patterns.
+- Review any recent changes in the network or system configurations that might have affected RDP session durations or security settings.
+
+### False positive analysis
+
+- Extended RDP sessions for legitimate administrative tasks can trigger false positives. To manage this, identify and whitelist IP addresses or user accounts associated with routine administrative activities.
+- Scheduled maintenance or software updates often require prolonged RDP sessions. Exclude these activities by setting time-based exceptions during known maintenance windows.
+- Remote support sessions from trusted third-party vendors may appear as anomalies. Create exceptions for these vendors by verifying their IP addresses and adding them to an allowlist.
+- Training sessions or demonstrations using RDP can result in longer session durations. Document and exclude these events by correlating them with scheduled training times and user accounts involved.
+- Automated scripts or processes that maintain RDP sessions for monitoring purposes can be mistaken for threats. Identify these scripts and exclude their associated user accounts or machine names from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious or unauthorized RDP sessions to cut off potential adversary access.
+- Conduct a thorough review of user accounts and permissions on the affected system to identify and disable any compromised accounts.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Restore the system from a known good backup if any unauthorized changes or malware are detected.
+- Monitor network traffic and logs for any signs of further exploitation attempts or related suspicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation."""
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1210"
+name = "Exploitation of Remote Services"
+reference = "https://attack.mitre.org/techniques/T1210/"
+
+
+[rule.threat.tactic]
+id = "TA0008"
+name = "Lateral Movement"
+reference = "https://attack.mitre.org/tactics/TA0008/"
+