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

nldcsc_elastic_rules/rules/linux/initial_access_apache_struts_cve_2023_50164_exploitation_to_webshell.toml

@@ -0,0 +1,144 @@
+[metadata]
+creation_date = "2025/11/19"
+integration = ["endpoint", "network_traffic"]
+maturity = "production"
+updated_date = "2025/11/19"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies successful exploitation of CVE-2023-50164, a critical path traversal vulnerability in Apache Struts 2 file
+upload functionality. This high-fidelity rule detects a specific attack sequence where a malicious multipart/form-data
+POST request with WebKitFormBoundary is made to a Struts .action upload endpoint, immediately followed by the creation
+of a JSP web shell file by a Java process in Tomcat's webapps directories. This correlated activity indicates active
+exploitation resulting in remote code execution capability through unauthorized file upload and web shell deployment.
+"""
+false_positives = [
+    """
+    False positives are expected to be very rare due to the specific nature of this rule. Legitimate application
+    deployments typically do not involve multipart form uploads to .action endpoints followed immediately by JSP file
+    creation in webapps directories. However, custom deployment scripts or automated testing tools that simulate file
+    uploads could potentially trigger this alert. Review the source IP, user agent, uploaded file content, timing, and
+    deployment schedules to validate if the activity is authorized. Standard package manager operations are already
+    excluded from detection.
+    """,
+]
+from = "now-9m"
+index = ["logs-endpoint.events.*", "logs-network_traffic.*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Webshell Deployed via Apache Struts CVE-2023-50164 Exploitation"
+note = """## Triage and analysis
+
+### Investigating Potential Webshell Deployed via Apache Struts CVE-2023-50164 Exploitation
+
+CVE-2023-50164 is a critical path traversal vulnerability in Apache Struts 2 that allows attackers to manipulate file upload parameters and write malicious files to arbitrary locations on the web server. This vulnerability affects the file upload feature and enables attackers to bypass security controls, upload JSP-based web shells, and achieve remote code execution. This detection rule identifies the complete attack chain by correlating suspicious file upload requests to Struts endpoints with the subsequent creation of JSP files in web-accessible directories, indicating successful exploitation.
+
+### Possible investigation steps
+
+- Review the source IP address of the HTTP POST request to determine if it originates from a known malicious source, VPN/proxy service, or unexpected geographic location that does not align with legitimate application usage patterns.
+- Examine the complete HTTP request details including headers, user agent string, and the full request body content to identify indicators of exploit code, path traversal attempts, or malicious payloads embedded in the multipart form data.
+- Investigate the created JSP file by examining its contents, file name, creation timestamp, and file permissions to determine if it contains web shell code, command execution capabilities, or other malicious functionality.
+- Check for any subsequent process execution, network connections, or file system activities originating from the Java process after the JSP file creation, which may indicate that the web shell has been accessed and used by the attacker.
+- Review web server access logs for requests to the newly created JSP file path to identify if the attacker has attempted to access or execute the web shell, and capture any command execution or data exfiltration attempts.
+- Examine the affected Struts application logs and Tomcat catalina logs for additional context about the file upload request, error messages, or anomalous behavior that occurred during the exploitation attempt.
+- Identify the version of Apache Struts 2 running on the affected server to confirm if it is vulnerable to CVE-2023-50164 (versions prior to 2.5.33 or 6.3.0.2 are affected).
+- Search for additional suspicious file creations, modifications, or deletions in the webapps directories that may indicate the attacker attempted multiple exploitation attempts or deployed additional persistence mechanisms.
+
+### False positive analysis
+
+- Legitimate application deployments using multipart form uploads to Struts endpoints followed by JSP file creation are uncommon but possible in custom deployment workflows. Review the source IP, user identity, and timing against known deployment schedules and authorized deployment systems.
+- Automated testing frameworks or security scanning tools that test file upload functionality may trigger this rule if they upload files to Struts endpoints. Identify and exclude known security testing tools or authorized penetration testing activities based on source IP or user agent patterns.
+- Development or staging environments where developers frequently test file upload features may generate alerts. Consider creating exceptions for non-production environments or restricting the rule to production systems only.
+- CI/CD pipelines that deploy applications via multipart form uploads could potentially match this pattern, though this is rare. Review the deployment process and create exceptions for known automated deployment systems if necessary.
+
+### Response and remediation
+
+- Immediately isolate the affected web server from the network to prevent further exploitation, lateral movement, or data exfiltration by the attacker.
+- Identify and delete the malicious JSP web shell file from the web server, ensuring you preserve a copy for forensic analysis and evidence collection.
+- Terminate any active web shell sessions by restarting the Java application server process and reviewing all active network connections for suspicious activity.
+- Review web server access logs to identify all IP addresses that accessed the web shell and block those IP addresses at the network perimeter to prevent re-exploitation.
+- Conduct a comprehensive scan of the affected server for additional web shells, backdoors, persistence mechanisms, or signs of lateral movement to other systems in the environment.
+- Patch the Apache Struts 2 installation to version 2.5.33, 6.3.0.2, or higher to remediate the CVE-2023-50164 vulnerability and prevent future exploitation attempts.
+- Review and harden file upload configurations in Struts applications, implement strict input validation, restrict file upload locations, and consider implementing web application firewall (WAF) rules to detect and block path traversal attempts.
+- Reset credentials for any accounts or services running on the compromised server, as the attacker may have captured sensitive information or credentials through the web shell.
+- Escalate the incident to the security operations center (SOC) and incident response team for comprehensive investigation, threat hunting, and to determine if additional systems were compromised.
+- Conduct a post-incident review to identify gaps in detection, response, and vulnerability management processes, and implement improvements to prevent similar incidents in the future.
+"""
+references = [
+    "https://nvd.nist.gov/vuln/detail/CVE-2023-50164",
+    "https://www.trendmicro.com/en_us/research/23/l/decoding-cve-2023-50164--unveiling-the-apache-struts-file-upload.html",
+    "https://github.com/snyk-labs/CVE-2023-50164-POC",
+]
+risk_score = 73
+rule_id = "7f3e8b9a-2c4d-5e6f-8a1b-9c2d3e4f5a6b"
+setup = """## Setup
+
+This rule requires data coming in from both Elastic Defend (for file events) and Network Packet Capture integrations (for HTTP traffic analysis).
+
+### Network Packet Capture Integration Setup
+
+**IMPORTANT**: This rule requires HTTP request body capture to be enabled in order to detect the multipart/form-data content containing WebKitFormBoundary indicators. The network traffic integration must be configured to capture HTTP request bodies for POST requests with `multipart/form-data` content type.
+"""
+severity = "high"
+tags = [
+    "Domain: Endpoint",
+    "Domain: Web",
+    "Domain: Network",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Initial Access",
+    "Tactic: Persistence",
+    "Data Source: Elastic Defend",
+    "Data Source: Network Traffic",
+    "Resources: Investigation Guide",
+]
+type = "eql"
+
+query = '''
+sequence by agent.id with maxspan=10s
+  [network where data_stream.dataset == "network_traffic.http" and
+      http.request.method == "POST" and
+      http.request.body.content like "*WebKitFormBoundary*" and
+      url.path like~ "*upload*.action"]
+  [file where event.dataset == "endpoint.events.file" and
+      host.os.type == "linux" and
+      event.action == "creation" and
+      process.name == "java" and
+      file.extension == "jsp" and
+      file.path like "*/webapps/*" and
+      not file.path like "*/WEB-INF/*" and
+      not file.path like "*/META-INF/*" and
+      not process.parent.name in ("apk", "apt", "apt-get", "dpkg", "yum", "rpm", "dnf", "systemd", "init")]
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1190"
+name = "Exploit Public-Facing Application"
+reference = "https://attack.mitre.org/techniques/T1190/"
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1505"
+name = "Server Software Component"
+reference = "https://attack.mitre.org/techniques/T1505/"
+[[rule.threat.technique.subtechnique]]
+id = "T1505.003"
+name = "Web Shell"
+reference = "https://attack.mitre.org/techniques/T1505/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+

nldcsc_elastic_rules/rules/linux/initial_access_first_time_public_key_authentication.toml

@@ -0,0 +1,118 @@
+[metadata]
+creation_date = "2025/02/21"
+integration = ["system"]
+maturity = "production"
+updated_date = "2025/09/09"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule leverages the new_terms rule type to detect successful SSH authentications via a public
+key that has not been seen in the last 10 days. Public key authentication is a secure method for
+authenticating users to a server. Monitoring unusual public key authentication events can help
+detect unauthorized access attempts or suspicious activity on the system.
+"""
+false_positives = [
+    """
+    This rule may trigger in cases where a user has routine work patterns that result in infrequent authentications.
+    """,
+]
+from = "now-9m"
+index = ["logs-system.auth-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Successful SSH Authentication from Unusual SSH Public Key"
+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 Successful SSH Authentication from Unusual SSH Public Key
+
+SSH public key authentication is a secure method for accessing Linux systems, relying on cryptographic keys rather than passwords. Adversaries may exploit this by using stolen or unauthorized keys to gain access. The detection rule identifies successful logins using new public keys, unseen in the past 10 days, signaling potential unauthorized access attempts. This helps in early detection of suspicious activities, aligning with threat tactics like Initial Access.
+
+### Possible investigation steps
+
+- Review the specific SSH login event details, focusing on the event.category, event.action, and event.outcome fields to confirm the successful authentication via public key.
+- Identify the source IP address and user account associated with the login event to determine if they are known or expected.
+- Check the system.auth.ssh.method field to ensure the authentication method was indeed public key and not another method.
+- Investigate the history of the public key used for authentication by searching logs for any previous occurrences or related activities within the last 10 days.
+- Correlate the event with other security logs or alerts from the same host or user to identify any patterns or additional suspicious activities.
+- Assess the risk by considering the context of the login, such as the time of access, the location of the source IP, and any recent changes in user behavior or system configurations.
+- If unauthorized access is suspected, initiate incident response procedures, including revoking the public key, notifying affected parties, and conducting a thorough security review of the system.
+
+### False positive analysis
+
+- Frequent logins from known automation scripts or services using rotating SSH keys can trigger false positives. To manage this, identify these services and add their public keys to an exception list.
+- Developers or system administrators who regularly update their SSH keys for security reasons may cause alerts. Maintain a record of authorized personnel and their key update schedules to exclude these events.
+- Temporary access granted to third-party vendors or contractors might appear as unusual activity. Ensure that any temporary access is documented and keys are added to an exception list during the access period.
+- Test environments where SSH keys are frequently generated and used for various testing purposes can lead to false positives. Implement a separate monitoring policy for test environments to reduce noise in production alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Revoke the unauthorized SSH public key from the system's authorized_keys file to block further access using that key.
+- Conduct a thorough review of recent login activities and system logs to identify any additional unauthorized access or suspicious activities that may have occurred.
+- Change passwords and regenerate SSH keys for all legitimate users on the affected system to ensure no compromised credentials remain in use.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring on the affected system and related network segments to detect any further suspicious activities or attempts to regain access.
+- Review and update access control policies and SSH key management practices to prevent similar incidents in the future, ensuring that only authorized keys are allowed and regularly audited.
+"""
+risk_score = 21
+rule_id = "267dace3-a4de-4c94-a7b5-dd6c0f5482e5"
+setup = """## Setup
+
+This rule requires data coming in from one of the following integrations:
+- Filebeat
+
+### Filebeat Setup
+Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing.
+
+#### The following steps should be executed in order to add the Filebeat for the Linux System:
+- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
+- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html).
+- To run Filebeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html).
+- To run Filebeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html).
+- For quick start information for Filebeat refer to the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html).
+- For complete Setup and Run Filebeat information refer to the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html).
+
+#### Rule Specific Setup Note
+- This rule requires the Filebeat System Module to be enabled.
+- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions.
+- To run the system module of Filebeat on Linux follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html).
+"""
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Initial Access",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+query = '''
+event.category:authentication and host.os.type:linux and event.action:ssh_login and event.outcome:success and system.auth.ssh.method:publickey
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["system.auth.ssh.signature"]
+
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-10d"

nldcsc_elastic_rules/rules/linux/initial_access_successful_ssh_authentication_by_unusual_ip.toml

@@ -0,0 +1,111 @@
+[metadata]
+creation_date = "2025/02/21"
+integration = ["system"]
+maturity = "production"
+updated_date = "2025/04/07"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule leverages the new_terms rule type to detect successful SSH authentications by an IP-
+address that has not been authenticated in the last 10 days. This behavior may indicate an
+attacker attempting to gain access to the system using a valid account.
+"""
+from = "now-9m"
+index = ["logs-system.auth-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Successful SSH Authentication from Unusual IP Address"
+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 Successful SSH Authentication from Unusual IP Address
+
+Secure Shell (SSH) is a protocol used to securely access and manage Linux systems. Adversaries may exploit SSH by using stolen credentials to gain unauthorized access. The detection rule identifies successful logins from IPs not seen in the past 10 days, flagging potential intrusions. This approach helps in spotting unusual access patterns that could indicate compromised accounts.
+
+### Possible investigation steps
+
+- Review the IP address flagged in the alert to determine its geolocation and assess if it aligns with expected access patterns for the user account involved.
+- Check historical authentication logs for the user account to identify any other unusual or unauthorized access attempts, focusing on the event.category:authentication and event.action:ssh_login fields.
+- Investigate the user account's recent activity on the system to identify any suspicious commands or actions executed post-authentication.
+- Correlate the flagged IP address with known threat intelligence sources to determine if it is associated with any malicious activity or previously reported incidents.
+- Contact the user associated with the account to verify if they recognize the login attempt and if they have recently accessed the system from a new location or device.
+
+### False positive analysis
+
+- New employee or contractor access from a previously unseen IP address may trigger the rule. Regularly update the list of known IP addresses for new users to prevent unnecessary alerts.
+- Remote workers or employees traveling may log in from different IP addresses. Implement a process to whitelist IP ranges associated with common travel destinations or VPNs used by the organization.
+- Automated scripts or services that occasionally run from different IPs can cause false positives. Identify and document these services, then create exceptions for their known IP addresses.
+- Cloud-based infrastructure changes, such as new instances or containers, might authenticate from new IPs. Maintain an updated inventory of cloud resources and their expected IP ranges to adjust the rule accordingly.
+- Third-party vendors accessing systems for maintenance or support might use different IPs. Establish a protocol for temporary exceptions for vendor IPs during their access periods.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Verify the legitimacy of the login by contacting the account owner to confirm whether the access was authorized. If unauthorized, proceed with further steps.
+- Change the password of the compromised account and any other accounts that may have been accessed using the same credentials.
+- Review and analyze the system logs for any additional suspicious activity or changes made during the unauthorized access period.
+- Escalate the incident to the security operations team for a thorough investigation and to determine if further systems are affected.
+- Implement IP whitelisting or geofencing to restrict SSH access to known and trusted IP addresses only.
+- Update and enhance monitoring rules to detect similar unauthorized access attempts in the future, ensuring that alerts are promptly reviewed and acted upon.
+"""
+risk_score = 21
+rule_id = "5c495612-9992-49a7-afe3-0f647671fb60"
+setup = """## Setup
+
+This rule requires data coming in from one of the following integrations:
+- Filebeat
+
+### Filebeat Setup
+Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing.
+
+#### The following steps should be executed in order to add the Filebeat for the Linux System:
+- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
+- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html).
+- To run Filebeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html).
+- To run Filebeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html).
+- For quick start information for Filebeat refer to the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html).
+- For complete Setup and Run Filebeat information refer to the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html).
+
+#### Rule Specific Setup Note
+- This rule requires the Filebeat System Module to be enabled.
+- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions.
+- To run the system module of Filebeat on Linux follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html).
+"""
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Initial Access",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+query = '''
+event.category:authentication and host.os.type:linux and event.action:ssh_login and event.outcome:success
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["related.ip"]
+
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-10d"

nldcsc_elastic_rules/rules/linux/initial_access_successful_ssh_authentication_by_unusual_user.toml

@@ -0,0 +1,95 @@
+[metadata]
+creation_date = "2025/02/21"
+integration = ["system"]
+maturity = "production"
+updated_date = "2025/04/07"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule leverages the new_terms rule type to detect successful SSH authentications by a user
+who has not been authenticated in the last 10 days. This behavior may indicate an attacker
+attempting to gain access to the system using a valid account.
+"""
+false_positives = [
+    """
+    This rule may trigger in cases where a user has routine work patterns that result in infrequent authentications.
+    """,
+]
+from = "now-9m"
+index = ["logs-system.auth-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Successful SSH Authentication from Unusual User"
+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 Successful SSH Authentication from Unusual User
+
+SSH (Secure Shell) is a protocol used to securely access and manage Linux systems. Adversaries may exploit valid user accounts to gain unauthorized access, bypassing traditional security measures. The detection rule identifies unusual SSH logins by flagging users who haven't logged in for over 10 days, indicating potential misuse of credentials. This proactive approach helps in early detection of unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the specific user account involved in the alert to determine if the login is expected or authorized, considering the user's typical login patterns and responsibilities.
+- Check the source IP address of the SSH login to see if it is recognized or associated with previous legitimate access, or if it appears unusual or suspicious.
+- Analyze the timing of the login event to see if it coincides with any known maintenance windows or scheduled activities that could explain the access.
+- Investigate any recent changes to the user's account, such as password resets or modifications to permissions, that could indicate potential compromise.
+- Correlate the SSH login event with other logs or alerts from the same timeframe to identify any additional suspicious activities or patterns that could suggest a broader security incident.
+
+### False positive analysis
+
+- Users returning from extended leave or vacation may trigger the rule. To manage this, create exceptions for users with known absence periods.
+- System administrators or service accounts that log in infrequently for maintenance tasks can be excluded by identifying and documenting these accounts.
+- Automated scripts or processes that authenticate sporadically might be flagged. Review and whitelist these processes if they are legitimate and necessary for operations.
+- Temporary contractors or consultants with limited access periods may cause alerts. Ensure their access is documented and create exceptions for their accounts during their engagement period.
+- Accounts used for testing or development purposes that are not regularly active can be excluded by maintaining a list of such accounts and updating it as needed.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Terminate the active SSH session associated with the unusual login to cut off the attacker's access.
+- Reset the password for the compromised user account and any other accounts that may have been accessed using the same credentials.
+- Conduct a thorough review of the affected system's logs and configurations to identify any unauthorized changes or additional compromised accounts.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been affected.
+- Implement multi-factor authentication (MFA) for SSH access to enhance security and prevent similar unauthorized access attempts in the future.
+- Update and enhance monitoring rules to detect similar unusual login patterns, ensuring early detection of potential threats.
+"""
+risk_score = 21
+rule_id = "5b8d7b94-23c6-4e3f-baed-3a4d0da4f19d"
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Initial Access",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+query = '''
+event.category:authentication and host.os.type:linux and event.action:ssh_login and event.outcome:success
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["related.user"]
+
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-10d"

nldcsc_elastic_rules/rules/linux/lateral_movement_kubeconfig_file_activity.toml

@@ -0,0 +1,155 @@
+[metadata]
+creation_date = "2025/06/17"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/07/07"
+
+[rule]
+author = ["Elastic"]
+description = """
+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.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.file*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Kubeconfig File Creation or Modification"
+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 Kubeconfig File Creation or Modification
+Kubeconfig files are essential in Kubernetes environments, storing configurations for cluster access and management. Adversaries may target these files to gain unauthorized access or move laterally within clusters. The detection rule identifies suspicious creation or modification of kubeconfig files, excluding legitimate processes like kubeadm and minikube, to flag potential threats and mitigate risks associated with unauthorized access.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path involved in the creation or modification event, focusing on paths like "/root/.kube/config" or "/etc/kubernetes/admin.conf".
+- Examine the process responsible for the file creation or modification, ensuring it is not one of the excluded legitimate processes such as "kubeadm", "kubelet", "vcluster", or "minikube".
+- Check the user account associated with the process to determine if it has legitimate access to modify kubeconfig files and assess if the activity aligns with typical user behavior.
+- Investigate the timing of the event to see if it coincides with any scheduled maintenance or deployment activities that could explain the modification.
+- Look for any related alerts or logs that might indicate lateral movement or unauthorized access attempts within the Kubernetes cluster.
+- Assess the network activity from the host where the modification occurred to identify any suspicious connections or data transfers that could suggest unauthorized access or exfiltration.
+
+### False positive analysis
+
+- Legitimate administrative tools like kubeadm, kubelet, vcluster, and minikube may create or modify kubeconfig files as part of normal operations. Ensure these processes are excluded from triggering alerts by maintaining the exclusion list in the detection rule.
+- Automated scripts or configuration management tools that use sed to modify kubeconfig files might be flagged. Consider adding specific script names or paths to the exclusion list if they are verified as non-threatening.
+- User-initiated changes to kubeconfig files for legitimate access or configuration updates can trigger alerts. Implement a process to verify and document such changes, allowing for quick exclusion of known user actions.
+- Regular updates or maintenance activities that involve kubeconfig file modifications should be documented and excluded from detection. Coordinate with the operations team to identify and whitelist these activities.
+- Development environments where frequent kubeconfig changes occur, such as in testing or staging, may generate false positives. Establish a separate monitoring policy for these environments to reduce noise while maintaining security oversight.
+
+### Response and remediation
+
+- Immediately isolate the affected system to prevent further unauthorized access or lateral movement within the Kubernetes cluster.
+- Revoke any potentially compromised credentials associated with the kubeconfig files and issue new credentials to ensure secure access.
+- Conduct a thorough review of recent access logs and audit trails to identify any unauthorized access or suspicious activity related to the kubeconfig files.
+- Restore the kubeconfig files from a known good backup to ensure the integrity of the configuration and access settings.
+- Implement additional monitoring and alerting for any future modifications to kubeconfig files, focusing on processes not typically involved in legitimate changes.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader Kubernetes environment.
+- Review and update Kubernetes access policies to ensure they align with best practices for security and least privilege, reducing the risk of unauthorized access.
+"""
+references = [
+    "https://kubernetes-threat-matrix.redguard.ch/initial-access/kubeconfig-file/",
+    "https://kubenomicon.com/Initial_access/Kubeconfig_file.html",
+    ]
+risk_score = 47
+rule_id = "b11116fd-023c-4718-aeb8-fa9d283fc53b"
+setup = """## Setup
+
+This rule requires data coming in from Elastic Defend.
+
+### Elastic Defend Integration Setup
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+#### Prerequisite Requirements:
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+
+#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+
+For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "Domain: Container",
+    "Domain: Kubernetes",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Lateral Movement",
+    "Tactic: Defense Evasion",
+    "Tactic: Initial Access",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+file where host.os.type == "linux" and event.type != "deletion" and file.path like (
+  "/root/.kube/config",
+  "/home/*/.kube/config",
+  "/etc/kubernetes/admin.conf",
+  "/etc/kubernetes/super-admin.conf",
+  "/etc/kubernetes/kubelet.conf",
+  "/etc/kubernetes/controller-manager.conf",
+  "/etc/kubernetes/scheduler.conf",
+  "/var/lib/*/kubeconfig"
+) and not (
+  process.name in ("kubeadm", "kubelet", "vcluster", "minikube") or
+  (process.name == "sed" and file.Ext.original.name like "sed*")
+)
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1550"
+name = "Use Alternate Authentication Material"
+reference = "https://attack.mitre.org/techniques/T1550/"
+
+[rule.threat.tactic]
+id = "TA0008"
+name = "Lateral Movement"
+reference = "https://attack.mitre.org/tactics/TA0008/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1550"
+name = "Use Alternate Authentication Material"
+reference = "https://attack.mitre.org/techniques/T1550/"
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"