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

nldcsc_elastic_rules/rules/linux/discovery_kubeconfig_file_discovery.toml

@@ -0,0 +1,141 @@
+[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. This rule detects process discovery executions that involve
+kubeconfig files, particularly those executed from common shell environments or world-writeable
+directories.
+"""
+from = "now-9m"
+index = [
+    "logs-endpoint.events.process*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Kubeconfig File Discovery"
+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 Discovery
+
+Kubeconfig files are essential in Kubernetes, storing credentials and configurations for cluster access. Adversaries may target these files to gain unauthorized access or move laterally within clusters. The detection rule identifies suspicious processes interacting with kubeconfig files, especially from common shell environments or risky directories, flagging potential misuse by excluding benign commands like 'stat' or 'md5sum'.
+
+### Possible investigation steps
+
+- Review the process details to identify the parent process name and executable path, focusing on those originating from common shell environments or risky directories like /tmp, /var/tmp, or /dev/shm.
+- Examine the process arguments to determine if they include references to sensitive kubeconfig files such as admin.conf, kubelet.conf, or any files within /etc/kubernetes or ~/.kube directories.
+- Check the working directory of the process to see if it aligns with known Kubernetes configuration paths like /etc/kubernetes or ~/.kube, which may indicate an attempt to access or modify kubeconfig files.
+- Investigate the user account associated with the process to assess whether it has legitimate access to Kubernetes configurations or if it might be compromised.
+- Correlate the event with other recent activities from the same user or IP address to identify any patterns of suspicious behavior or potential lateral movement within the cluster.
+- Review any related alerts or logs for the same host or container to gather additional context on the system's state and any other potential indicators of compromise.
+
+### False positive analysis
+
+- Processes like 'stat' and 'md5sum' are excluded from detection as they are commonly used for legitimate file checks. Ensure these exclusions are correctly configured to prevent unnecessary alerts.
+- Scripts located in user directories such as '/home/*/.kube' may trigger alerts if they interact with kubeconfig files. Consider adding exceptions for known scripts or users that regularly access these files for legitimate purposes.
+- Processes originating from world-writeable directories like '/tmp' or '/var/tmp' can be flagged. Review these alerts to identify routine operations and whitelist specific processes or directories that are part of regular maintenance tasks.
+- Alerts triggered by processes with names matching patterns like '*.sh' may include legitimate scripts. Evaluate these scripts and exclude them if they are part of standard operations or administrative tasks.
+- Regular administrative tasks involving kubeconfig files in directories like '/etc/kubernetes' may be flagged. Implement exceptions for known administrative processes to reduce false positives while maintaining security oversight.
+
+### Response and remediation
+
+- Immediately isolate the affected system to prevent further unauthorized access to the Kubernetes cluster.
+- Revoke any compromised credentials associated with the kubeconfig files and issue new credentials to authorized users.
+- Conduct a thorough review of recent access logs and audit trails for the Kubernetes cluster to identify any unauthorized access or lateral movement attempts.
+- Restore any modified or deleted kubeconfig files from a secure backup to ensure the integrity of the cluster configuration.
+- Implement stricter access controls and permissions for directories containing kubeconfig files, ensuring only authorized personnel have access.
+- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems are affected.
+- Enhance monitoring and alerting for suspicious activities related to kubeconfig files, leveraging the MITRE ATT&CK framework to identify potential discovery tactics.
+"""
+references = [
+    "https://kubernetes-threat-matrix.redguard.ch/initial-access/kubeconfig-file/",
+    "https://kubenomicon.com/Initial_access/Kubeconfig_file.html",
+    ]
+risk_score = 21
+rule_id = "9a6f5d74-c7e7-4a8b-945e-462c102daee4"
+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 = "low"
+tags = [
+    "Domain: Endpoint",
+    "Domain: Container",
+    "Domain: Kubernetes",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
+  process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or
+  (
+    process.parent.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", "/home/*") or
+    process.parent.name like (".*", "*.sh")
+  )
+) and
+(
+  (
+    process.working_directory like ("/etc/kubernetes", "/root/.kube", "/home/*/.kube") and
+    process.args in ("kubeconfig", "admin.conf", "super-admin.conf", "kubelet.conf", "controller-manager.conf", "scheduler.conf")
+  ) or
+  process.args like (
+    "/etc/kubernetes/admin.conf",
+    "/etc/kubernetes/super-admin.conf",
+    "/etc/kubernetes/kubelet.conf",
+    "/etc/kubernetes/controller-manager.conf",
+    "/etc/kubernetes/scheduler.conf",
+    "/home/*/.kube/config",
+    "/root/.kube/config",
+    "/var/lib/*/kubeconfig"
+  )
+) and not process.name in ("stat", "md5sum", "dirname")
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1613"
+name = "Container and Resource Discovery"
+reference = "https://attack.mitre.org/techniques/T1613/"
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"

nldcsc_elastic_rules/rules/linux/discovery_kubectl_permission_discovery.toml

@@ -0,0 +1,117 @@
+[metadata]
+creation_date = "2025/06/17"
+integration = ["endpoint", "crowdstrike"]
+maturity = "production"
+updated_date = "2025/10/17"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects the use of the "kubectl auth --can-i" command, which is used to check permissions in Kubernetes clusters.
+Attackers may use this command to enumerate permissions and discover potential misconfigurations in the cluster, allowing
+them to gain unauthorized access or escalate privileges.
+"""
+from = "now-9m"
+index = [
+  "logs-endpoint.events.process*",
+  "logs-crowdstrike.fdr*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Kubectl Permission Discovery"
+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 Kubectl Permission Discovery
+
+Kubectl is a command-line tool for interacting with Kubernetes clusters, allowing users to manage applications and resources. Adversaries may exploit the "kubectl auth can-i" command to probe for permission misconfigurations, potentially leading to unauthorized access or privilege escalation. The detection rule identifies this activity by monitoring specific command executions on Linux systems, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the use of the "kubectl auth can-i" command, focusing on the process name "kubectl" and arguments "auth" and "can-i".
+- Identify the user account associated with the execution of the command to determine if it aligns with expected administrative activity or if it indicates potential unauthorized access.
+- Check the timing and frequency of the command execution to assess whether it corresponds with routine operations or suggests suspicious behavior.
+- Investigate the source IP address or hostname from which the command was executed to verify if it originates from a known and trusted environment.
+- Examine related logs and events around the time of the alert to identify any subsequent actions that might indicate privilege escalation or unauthorized access attempts.
+- Cross-reference the alert with any recent changes or incidents in the Kubernetes cluster to determine if the command execution is part of a broader security concern.
+
+### False positive analysis
+
+- Routine administrative checks by authorized personnel can trigger the rule. To manage this, create exceptions for specific user accounts or roles that regularly perform these checks as part of their job duties.
+- Automated scripts or monitoring tools that verify permissions as part of their normal operation may cause false positives. Identify these scripts and whitelist their execution paths or associated service accounts.
+- Development and testing environments where developers frequently check permissions might lead to alerts. Consider excluding these environments from the rule or adjusting the risk score for these specific contexts.
+- Scheduled audits or compliance checks that involve permission verification can be mistaken for malicious activity. Document these activities and set up time-based exceptions to prevent unnecessary alerts during known audit periods.
+
+### Response and remediation
+
+- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or privilege escalation.
+- Revoke any suspicious or unauthorized credentials or tokens identified during the investigation to prevent further misuse.
+- Conduct a thorough review of the Kubernetes Role-Based Access Control (RBAC) configurations to identify and rectify any permission misconfigurations.
+- Implement stricter access controls and least privilege principles for Kubernetes users and service accounts to minimize the risk of unauthorized access.
+- Monitor for any additional suspicious activity or anomalies in the cluster, focusing on access patterns and command executions.
+- Escalate the incident to the security operations team for further analysis and to determine if additional clusters or systems are affected.
+- Update detection and monitoring systems to enhance visibility and alerting for similar permission discovery attempts in the future.
+"""
+references = [
+    "https://kubernetes.io/docs/reference/kubectl/generated/kubectl_auth/kubectl_auth_can-i/",
+    ]
+risk_score = 21
+rule_id = "1600f9e2-5be6-4742-8593-1ba50cd94069"
+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 = "low"
+tags = [
+  "Domain: Endpoint",
+  "Domain: Container",
+  "Domain: Kubernetes",
+  "OS: Linux",
+  "Use Case: Threat Detection",
+  "Tactic: Discovery",
+  "Data Source: Elastic Defend",
+  "Resources: Investigation Guide",
+  "Data Source: Crowdstrike",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and
+process.name == "kubectl" and process.args == "auth" and process.args == "can-i"
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1613"
+name = "Container and Resource Discovery"
+reference = "https://attack.mitre.org/techniques/T1613/"
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"

nldcsc_elastic_rules/rules/linux/discovery_linux_hping_activity.toml

@@ -0,0 +1,141 @@
+[metadata]
+creation_date = "2020/02/18"
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Hping ran on a Linux host. Hping is a FOSS command-line packet analyzer and has the ability to construct network packets
+for a wide variety of network security testing applications, including scanning and firewall auditing.
+"""
+false_positives = [
+    """
+    Normal use of hping is uncommon apart from security testing and research. Use by non-security engineers is very
+    uncommon.
+    """,
+]
+from = "now-9m"
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Hping Process Activity"
+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 Hping Process Activity
+
+Hping is a versatile command-line tool used for crafting and analyzing network packets, often employed in network security testing. Adversaries may exploit Hping to perform reconnaissance, such as scanning networks or probing firewalls, to gather system information. The detection rule identifies Hping's execution on Linux systems by monitoring specific process start events, helping to flag potential misuse indicative of discovery tactics.
+
+### Possible investigation steps
+
+- Review the process start event details to confirm the execution of Hping, focusing on the process.name field to ensure it matches "hping", "hping2", or "hping3".
+- Identify the user account associated with the Hping process by examining the user context in the event data to determine if the activity aligns with expected behavior for that user.
+- Analyze the command line arguments used with the Hping process to understand the intent of the execution, such as specific network targets or options that indicate scanning or probing activities.
+- Check the timing and frequency of the Hping process execution to assess whether it aligns with routine network testing schedules or if it appears anomalous.
+- Investigate the source and destination IP addresses involved in the Hping activity to identify potential targets and assess whether they are internal or external to the organization.
+- Correlate the Hping activity with other security events or alerts from the same host or network segment to identify any related suspicious activities or patterns.
+- Consult with the system owner or network security team to verify if the Hping activity was authorized as part of legitimate security testing or if it requires further investigation.
+
+### False positive analysis
+
+- Routine network testing by IT teams may trigger the rule when using Hping for legitimate purposes. To manage this, create exceptions for known IP addresses or user accounts involved in regular network audits.
+- Automated scripts or cron jobs that utilize Hping for monitoring network performance can lead to false positives. Identify these scripts and exclude their execution paths or associated user accounts from the detection rule.
+- Security training exercises or penetration testing activities might involve Hping usage. Coordinate with security teams to whitelist these activities by specifying time windows or specific user roles.
+- Development or testing environments where Hping is used for application testing can cause alerts. Exclude these environments by filtering based on hostnames or network segments associated with non-production systems.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential lateral movement by the adversary.
+- Terminate any active Hping processes on the affected host to stop ongoing packet crafting or network probing activities.
+- Conduct a thorough review of network logs and firewall configurations to identify any unauthorized access or anomalies that may have been exploited using Hping.
+- Perform a comprehensive scan of the affected system for additional indicators of compromise, such as unauthorized user accounts or unexpected changes to system files.
+- Reset credentials and review access permissions for accounts on the affected host to ensure no unauthorized access persists.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Update detection and monitoring systems to enhance visibility and alerting for similar reconnaissance activities, ensuring rapid response to future threats."""
+references = ["https://en.wikipedia.org/wiki/Hping"]
+risk_score = 47
+rule_id = "90169566-2260-4824-b8e4-8615c3b4ed52"
+setup = """## Setup
+
+This rule requires data coming in from one of the following integrations:
+- Elastic Defend
+- Auditbeat
+
+### 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).
+
+### Auditbeat Setup
+Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.
+
+#### The following steps should be executed in order to add the Auditbeat on a 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/auditbeat/current/setup-repositories.html).
+- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
+- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
+- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and
+ event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+ process.name in ("hping", "hping2", "hping3")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1082"
+name = "System Information Discovery"
+reference = "https://attack.mitre.org/techniques/T1082/"
+
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+

nldcsc_elastic_rules/rules/linux/discovery_linux_nping_activity.toml

@@ -0,0 +1,141 @@
+[metadata]
+creation_date = "2020/02/18"
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Nping ran on a Linux host. Nping is part of the Nmap tool suite and has the ability to construct raw packets for a wide
+variety of security testing applications, including denial of service testing.
+"""
+false_positives = [
+    """
+    Some normal use of this command may originate from security engineers and network or server administrators, but this
+    is usually not routine or unannounced. Use of `Nping` by non-engineers or ordinary users is uncommon.
+    """,
+]
+from = "now-9m"
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Nping Process Activity"
+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 Nping Process Activity
+
+Nping, a component of the Nmap suite, is used for crafting raw packets, aiding in network diagnostics and security testing. Adversaries may exploit Nping to perform network reconnaissance or denial-of-service attacks by sending crafted packets to probe network services. The detection rule identifies Nping's execution on Linux systems by monitoring process start events, helping to flag potential misuse for malicious network discovery activities.
+
+### Possible investigation steps
+
+- Review the process start event details to confirm the execution of Nping, focusing on the process name field to ensure it matches "nping".
+- Identify the user account associated with the Nping process execution to determine if it aligns with expected or authorized usage patterns.
+- Examine the command line arguments used with Nping to understand the intent of the execution, such as specific network targets or packet types.
+- Check the timing and frequency of the Nping execution to assess if it correlates with any known maintenance windows or unusual activity patterns.
+- Investigate network logs or traffic data to identify any unusual or unauthorized network scanning or probing activities originating from the host where Nping was executed.
+- Correlate the Nping activity with other security alerts or logs from the same host to identify potential indicators of compromise or broader attack patterns.
+
+### False positive analysis
+
+- Routine network diagnostics by IT teams using Nping for legitimate purposes can trigger alerts. To manage this, create exceptions for specific user accounts or IP addresses known to perform regular network testing.
+- Automated scripts or monitoring tools that incorporate Nping for network health checks may cause false positives. Identify these scripts and whitelist their execution paths or associated processes.
+- Security assessments or penetration tests conducted by authorized personnel might involve Nping usage. Coordinate with security teams to schedule these activities and temporarily adjust detection rules or add exceptions for the duration of the tests.
+- Development or testing environments where Nping is used for application testing can generate alerts. Exclude these environments from monitoring or adjust the rule to ignore specific hostnames or network segments.
+- Training sessions or workshops that include Nping demonstrations can lead to false positives. Notify the security team in advance and apply temporary exceptions for the event duration.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential denial-of-service attacks.
+- Terminate the Nping process on the affected host to stop any ongoing malicious activity.
+- Conduct a thorough review of recent network traffic logs from the affected host to identify any unusual or unauthorized network service discovery attempts.
+- Check for any unauthorized changes or installations on the affected host that may indicate further compromise or persistence mechanisms.
+- Update and apply network security policies to restrict the use of network diagnostic tools like Nping to authorized personnel only.
+- Escalate the incident to the security operations team for further investigation and to determine if the activity is part of a larger attack campaign.
+- Enhance monitoring and alerting for similar activities across the network by ensuring that detection rules are in place for unauthorized use of network diagnostic tools."""
+references = ["https://en.wikipedia.org/wiki/Nmap"]
+risk_score = 47
+rule_id = "0d69150b-96f8-467c-a86d-a67a3378ce77"
+setup = """## Setup
+
+This rule requires data coming in from one of the following integrations:
+- Elastic Defend
+- Auditbeat
+
+### 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).
+
+### Auditbeat Setup
+Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.
+
+#### The following steps should be executed in order to add the Auditbeat on a 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/auditbeat/current/setup-repositories.html).
+- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
+- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
+- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and
+ event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+ process.name == "nping"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1046"
+name = "Network Service Discovery"
+reference = "https://attack.mitre.org/techniques/T1046/"
+
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+