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

nldcsc_elastic_rules/rules/linux/discovery_port_scanning_activity_from_compromised_host.toml

@@ -0,0 +1,156 @@
+[metadata]
+creation_date = "2025/03/04"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/09/29"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects potential port scanning activity from a compromised host. Port scanning is a common reconnaissance
+technique used by attackers to identify open ports and services on a target system. A compromised host may exhibit port
+scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable services, or
+prepare for further exploitation. This rule identifies potential port scanning activity by monitoring network connection
+attempts from a single host to a large number of ports within a short time frame. ESQL rules have limited fields
+available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.
+"""
+from = "now-61m"
+interval = "1h"
+language = "esql"
+license = "Elastic License v2"
+name = "Potential Port Scanning Activity from Compromised Host"
+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 Potential Port Scanning Activity from Compromised Host
+
+Port scanning is a reconnaissance method used by attackers to identify open ports and services on a network, often as a precursor to exploitation. In Linux environments, compromised hosts may perform rapid connection attempts to numerous ports, signaling potential scanning activity. The detection rule identifies such behavior by analyzing network logs for a high number of distinct port connections from a single host within a short timeframe, indicating possible malicious intent.
+
+### Possible investigation steps
+
+- Review the network logs to identify the specific host exhibiting the port scanning behavior by examining the destination.ip and process.executable fields.
+- Analyze the @timestamp field to determine the exact time frame of the scanning activity and correlate it with any other suspicious activities or alerts from the same host.
+- Investigate the process.executable field to understand which application or service initiated the connection attempts, and verify if it is a legitimate process or potentially malicious.
+- Check the destination.port field to identify the range and types of ports targeted by the scanning activity, which may provide insights into the attacker's objectives or the services they are interested in.
+- Assess the host's security posture by reviewing recent changes, installed software, and user activity to determine if the host has been compromised or if the scanning is part of legitimate network operations.
+- Consult the original documents and logs for additional context and details that may not be captured in the alert to aid in a comprehensive investigation.
+
+### False positive analysis
+
+- Legitimate network scanning tools used by system administrators for network maintenance or security assessments can trigger this rule. To handle this, identify and whitelist the IP addresses or processes associated with these tools.
+- Automated vulnerability scanners or monitoring systems that perform regular checks on network services may cause false positives. Exclude these systems by creating exceptions for their known IP addresses or process names.
+- High-volume legitimate services that open multiple connections to different ports, such as load balancers or proxy servers, might be flagged. Review and exclude these services by specifying their IP addresses or process executables.
+- Development or testing environments where frequent port scanning is part of routine operations can be mistakenly identified. Implement exceptions for these environments by excluding their specific network segments or host identifiers.
+- Scheduled network discovery tasks that are part of IT operations can mimic port scanning behavior. Document and exclude these tasks by setting up time-based exceptions or identifying their unique process signatures.
+
+### Response and remediation
+
+- Isolate the compromised host from the network immediately to prevent further scanning and potential lateral movement.
+- Terminate any suspicious processes identified by the process.executable field to halt ongoing malicious activities.
+- Conduct a thorough review of the compromised host's system logs and network traffic to identify any unauthorized access or data exfiltration attempts.
+- Patch and update all software and services on the compromised host to close any vulnerabilities that may have been exploited.
+- Change all credentials associated with the compromised host and any potentially affected systems to prevent unauthorized access.
+- Monitor the network for any further signs of scanning activity or other suspicious behavior from other hosts, indicating potential additional compromises.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+"""
+risk_score = 21
+rule_id = "6b341d03-1d63-41ac-841a-2009c86959ca"
+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",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+query = '''
+from logs-endpoint.events.network-*
+| where
+    @timestamp > now() - 1h and
+    host.os.type == "linux" and
+    event.type == "start" and
+    event.action == "connection_attempted" and
+    network.direction  == "egress" and
+    destination.port < 32768 and
+    not (
+      cidr_match(destination.ip, "127.0.0.0/8", "::1", "FE80::/10", "FF00::/8") or
+      process.executable in (
+        "/opt/dbtk/bin/jsvc", "/usr/lib/dotnet/dotnet", "/usr/share/elasticsearch/jdk/bin/java", "/usr/sbin/haproxy",
+        "/usr/bin/java", "/opt/kaspersky/kesl/libexec/kesl", "/usr/bin/dotnet", "/opt/java/openjdk/bin/java"
+      ) or
+      process.executable like "/var/opt/kaspersky/kesl/*kesl" or
+      process.executable like "/usr/lib/jvm/*/java" or
+      process.executable like "/opt/google/chrome*" or
+      process.executable like "/var/lib/docker/*/java" or
+      process.executable like "/usr/lib64/jvm/*/java" or
+      process.executable like "/snap/*" or
+      process.executable like "/home/*/.local/share/JetBrains/*"
+    )
+| keep
+    @timestamp,
+    host.os.type,
+    event.type,
+    event.action,
+    destination.port,
+    process.executable,
+    destination.ip,
+    source.ip,
+    agent.id,
+    host.name
+| stats
+    Esql.event_count = count(),
+    Esql.destination_port_count_distinct = count_distinct(destination.port),
+    Esql.agent_id_count_distinct = count_distinct(agent.id),
+    Esql.host_name_values = values(host.name),
+    Esql.agent_id_values = values(agent.id),
+    Esql.source_ip_values = values(source.ip)
+    by process.executable, destination.ip
+| where
+    Esql.agent_id_count_distinct == 1 and
+    Esql.destination_port_count_distinct > 100
+| sort Esql.event_count asc
+| limit 100
+'''
+
+[[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/"

nldcsc_elastic_rules/rules/linux/discovery_private_key_password_searching_activity.toml

@@ -0,0 +1,114 @@
+[metadata]
+creation_date = "2024/11/04"
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects private key searching activity on Linux systems. Searching for private keys can be an indication of an
+attacker attempting to escalate privileges or exfiltrate sensitive information.
+"""
+from = "now-9m"
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Private Key Searching 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 Private Key Searching Activity
+
+In Linux environments, private keys are crucial for secure communications and authentication. Adversaries may exploit this by searching for private keys to gain unauthorized access or escalate privileges. The detection rule identifies suspicious use of the 'find' command targeting key files in sensitive directories, signaling potential malicious intent. This proactive monitoring helps mitigate risks associated with unauthorized key access.
+
+### Possible investigation steps
+
+- Review the process details to confirm the 'find' command was executed with parameters targeting private key files, as indicated by the command line containing patterns like "*id_dsa*", "*id_rsa*", etc., and directories such as "/home/", "/etc/ssh", or "/root/".
+- Identify the user account associated with the process to determine if the activity aligns with expected behavior for that user or if it suggests potential compromise.
+- Check the process's parent process to understand the context in which the 'find' command was executed, which may provide insights into whether this was part of a legitimate script or an unauthorized action.
+- Investigate any recent login activity or changes in user privileges for the account involved to assess if there has been any unauthorized access or privilege escalation.
+- Examine system logs and other security alerts around the time of the event to identify any correlated suspicious activities or anomalies that might indicate a broader attack campaign.
+
+### False positive analysis
+
+- System administrators or automated scripts may use the 'find' command to locate private keys for legitimate maintenance tasks. To handle this, create exceptions for known administrative accounts or scripts that regularly perform these actions.
+- Backup processes might search for private keys as part of routine data protection activities. Identify and exclude these processes by specifying their unique command-line patterns or process IDs.
+- Security audits or compliance checks often involve scanning for private keys to ensure proper security measures are in place. Exclude these activities by recognizing the specific tools or scripts used during audits.
+- Developers or DevOps teams may search for private keys during application deployment or configuration. Establish a list of trusted users or processes involved in these operations and exclude them from triggering alerts.
+- Automated configuration management tools like Ansible or Puppet might search for keys as part of their operations. Identify these tools and exclude their specific command-line patterns to prevent false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, particularly those involving the 'find' command searching for private keys.
+- Conduct a thorough review of access logs and process execution history to identify any unauthorized access or privilege escalation attempts.
+- Change all potentially compromised private keys and associated credentials, ensuring new keys are securely generated and stored.
+- Implement stricter access controls and permissions on directories containing private keys to limit exposure to unauthorized users.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Enhance monitoring and alerting for similar activities by ensuring that detection rules are tuned to capture variations of the 'find' command targeting sensitive files."""
+risk_score = 21
+rule_id = "627374ab-7080-4e4d-8316-bef1122444af"
+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",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Data Source: Elastic Defend",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
+    "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") and process.name == "find" and
+  process.command_line like ("*id_dsa*", "*id_rsa*", "*id_ed*", "*id_ecdsa*", "*id_xmss*", "*id_dh*") and
+  process.command_line like ("*/home/*", "*/etc/ssh*", "*/root/*", "/")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+

nldcsc_elastic_rules/rules/linux/discovery_proc_maps_read.toml

@@ -0,0 +1,116 @@
+[metadata]
+creation_date = "2024/01/29"
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/04/25"
+
+[rule]
+author = ["Elastic"]
+description = """
+Monitors for /proc/*/maps file reads. The /proc/*/maps file in Linux provides a memory map for a specific process,
+detailing the memory segments, permissions, and what files are mapped to these segments. Attackers may read a process's
+memory map to identify memory addresses for code injection or process hijacking.
+"""
+from = "now-9m"
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Suspicious /proc/maps Discovery"
+references = ["https://github.com/arget13/DDexec"]
+risk_score = 21
+rule_id = "2f95540c-923e-4f57-9dae-de30169c68b9"
+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",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "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") and
+process.name in ("cat", "grep", "tail", "less", "more", "egrep", "fgrep") and process.args like "/proc/*/maps"
+'''
+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 Suspicious /proc/maps Discovery
+
+In Linux environments, the `/proc/*/maps` files provide detailed memory mapping of processes, crucial for system diagnostics. However, adversaries exploit this by reading these files to pinpoint memory addresses for malicious activities like code injection. The detection rule identifies suspicious reads of these files by monitoring specific command executions, such as `cat` or `grep`, initiated from common shell environments, flagging potential reconnaissance attempts.
+
+### Possible investigation steps
+
+- Review the process details, including the process name and arguments, to confirm if the access to /proc/*/maps was initiated by a legitimate user or application. Pay special attention to the process.name and process.args fields.
+- Check the process.entry_leader.name to determine the shell environment from which the command was executed, and assess if this aligns with typical user behavior or known scripts.
+- Investigate the user account associated with the process to determine if there are any signs of compromise or unusual activity, such as recent logins from unfamiliar IP addresses or changes in user permissions.
+- Examine the parent process and any related child processes to understand the broader context of the command execution, looking for any signs of a script or automated task that might have triggered the alert.
+- Correlate this event with other security alerts or logs from the same host or user to identify any patterns or sequences of suspicious activities that could indicate a larger attack or reconnaissance effort.
+
+### False positive analysis
+
+- System diagnostics tools may read /proc/*/maps files as part of routine checks. Identify these tools and create exceptions for their processes to avoid unnecessary alerts.
+- Developers and system administrators might manually inspect /proc/*/maps during debugging or performance tuning. Establish a list of known users and processes that perform these actions regularly and exclude them from triggering the rule.
+- Automated scripts for monitoring or logging purposes could access /proc/*/maps files. Review these scripts and whitelist them if they are verified to be non-malicious.
+- Security software might access these files as part of its scanning operations. Confirm the legitimacy of such software and add it to an exception list to prevent false positives.
+- Consider the context of the process entry leader. If certain shell environments are used predominantly for legitimate administrative tasks, adjust the rule to reduce sensitivity for those specific environments.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious processes identified as reading the `/proc/*/maps` files using commands like `cat` or `grep` from unauthorized shell environments.
+- Conduct a memory analysis on the affected system to identify any injected code or unauthorized modifications in the process memory.
+- Review and audit user accounts and permissions on the affected system to ensure that only authorized users have access to sensitive files and directories.
+- Implement stricter access controls and monitoring on `/proc/*/maps` files to limit exposure and detect unauthorized access attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar suspicious activities in the future."""
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1057"
+name = "Process Discovery"
+reference = "https://attack.mitre.org/techniques/T1057/"
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"

nldcsc_elastic_rules/rules/linux/discovery_process_capabilities.toml

@@ -0,0 +1,114 @@
+[metadata]
+creation_date = "2024/01/09"
+integration = ["endpoint", "crowdstrike"]
+maturity = "production"
+updated_date = "2025/02/04"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies recursive process capability enumeration of the entire filesystem through the getcap command. Malicious users
+may manipulate identified capabilities to gain root privileges.
+"""
+from = "now-9m"
+index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Process Capability Enumeration"
+risk_score = 21
+rule_id = "5c351f54-4187-4ad8-abc8-29b0cfbef8b1"
+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",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "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", "ProcessRollup2") and
+  process.name == "getcap" and process.args == "-r" and process.args == "/" and
+  process.args_count == 3 and user.id != "0"
+'''
+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 Process Capability Enumeration
+
+In Linux environments, the `getcap` command is used to list file capabilities, which define specific privileges for executables. Adversaries may exploit this by recursively scanning the filesystem to identify and manipulate capabilities, potentially escalating privileges. The detection rule identifies suspicious use of `getcap` by monitoring for its execution with specific arguments, especially by non-root users, indicating potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the execution of the `getcap` command with the arguments `-r` and `/`, ensuring the process was initiated by a non-root user (user.id != "0").
+- Identify the user account associated with the process execution to determine if the user has a legitimate reason to perform such actions.
+- Examine the process execution history for the identified user to check for any other suspicious activities or commands executed around the same time.
+- Investigate the system logs for any signs of privilege escalation attempts or unauthorized access following the execution of the `getcap` command.
+- Check for any recent changes to file capabilities on the system that could indicate manipulation by the adversary.
+- Assess the system for any other indicators of compromise or related alerts that might suggest a broader attack campaign.
+
+### False positive analysis
+
+- System administrators or automated scripts may use the getcap command for legitimate auditing purposes. To handle this, create exceptions for known administrative accounts or scripts that regularly perform capability checks.
+- Security tools or monitoring solutions might trigger the rule during routine scans. Identify these tools and exclude their processes from triggering alerts by adding them to an allowlist.
+- Developers or testing environments may execute getcap as part of software testing or development processes. Exclude specific user IDs or groups associated with these environments to prevent unnecessary alerts.
+- Scheduled maintenance tasks might involve capability enumeration. Document and exclude these tasks by specifying the time frames or user accounts involved in the maintenance activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Terminate any unauthorized or suspicious processes associated with the `getcap` command to halt potential privilege escalation activities.
+- Conduct a thorough review of the system's file capabilities using a trusted method to identify any unauthorized changes or suspicious capabilities that may have been set.
+- Revert any unauthorized capability changes to their original state to ensure that no elevated privileges are retained by malicious users.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement monitoring for similar `getcap` command executions across the environment to detect and respond to future attempts promptly.
+- Review and update access controls and user permissions to ensure that only authorized users have the necessary privileges to execute potentially sensitive commands like `getcap`."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1057"
+name = "Process Discovery"
+reference = "https://attack.mitre.org/techniques/T1057/"
+
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+

nldcsc_elastic_rules/rules/linux/discovery_pspy_process_monitoring_detected.toml

@@ -0,0 +1,116 @@
+[metadata]
+creation_date = "2023/07/20"
+integration = ["auditd_manager"]
+maturity = "production"
+updated_date = "2025/01/24"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule leverages auditd to monitor for processes scanning different processes within the /proc directory using the
+openat syscall. This is a strong indication for the usage of the pspy utility. Attackers may leverage the pspy process
+monitoring utility to monitor system processes without requiring root permissions, in order to find potential privilege
+escalation vectors.
+"""
+from = "now-9m"
+index = ["logs-auditd_manager.auditd-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Pspy Process Monitoring Detected"
+references = ["https://github.com/DominicBreuker/pspy"]
+risk_score = 21
+rule_id = "bdb04043-f0e3-4efa-bdee-7d9d13fa9edc"
+setup = """## Setup
+
+This rule requires data coming in from Auditd Manager.
+
+### Auditd Manager Integration Setup
+The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.
+Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system.
+
+#### The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux System:
+- Go to the Kibana home page and click “Add integrations”.
+- In the query bar, search for “Auditd Manager” and select the integration to see more details about it.
+- Click “Add Auditd Manager”.
+- Configure the integration name and optionally add a description.
+- Review optional and advanced settings accordingly.
+- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
+- Click “Save and Continue”.
+- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).
+
+#### Rule Specific Setup Note
+Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.
+However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.
+- For this detection rule the following additional audit rules are required to be added to the integration:
+  -- "-w /proc/ -p r -k audit_proc"
+"""
+severity = "low"
+tags = [
+    "Data Source: Auditd Manager",
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Resources: Investigation Guide",
+]
+type = "eql"
+query = '''
+sequence by process.pid, host.id with maxspan=5s
+  [file where host.os.type == "linux" and auditd.data.syscall == "openat" and file.path == "/proc" and
+   auditd.data.a0 : ("ffffffffffffff9c", "ffffff9c") and auditd.data.a2 : ("80000", "88000") and
+   not process.name in ("agentbeat", "packetbeat")
+  ] with runs=10
+'''
+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 Potential Pspy Process Monitoring Detected
+
+Auditd is a Linux auditing system that tracks system calls, providing insights into process activities. Adversaries exploit tools like pspy to monitor processes via the /proc directory, seeking privilege escalation opportunities without root access. The detection rule identifies suspicious openat syscalls targeting /proc, excluding benign processes, to flag potential misuse of pspy for process discovery.
+
+### Possible investigation steps
+
+- Review the process details associated with the alert, focusing on the process.pid and process.name fields to identify the process attempting to access the /proc directory.
+- Investigate the host.id to determine if this activity is isolated to a single host or part of a broader pattern across multiple systems.
+- Examine the process tree and parent processes of the flagged process to understand how it was initiated and if it is part of a legitimate workflow or potentially malicious activity.
+- Check for any recent changes or installations on the host that might explain the presence of a tool like pspy, such as new software installations or updates.
+- Correlate the timing of the alert with any other suspicious activities or alerts on the same host to identify potential lateral movement or privilege escalation attempts.
+- Verify if the process name is a known benign process that might have been mistakenly excluded from the query, ensuring that the exclusion list is up-to-date and accurate.
+
+### False positive analysis
+
+- Frequent scanning by legitimate monitoring tools can trigger the rule. Identify and whitelist these tools by adding their process names to the exclusion list.
+- System management scripts that regularly access the /proc directory may cause false positives. Review these scripts and exclude their process names if they are verified as non-threatening.
+- Automated backup or security software that interacts with the /proc directory might be flagged. Confirm their legitimacy and add them to the exception list to prevent unnecessary alerts.
+- Custom applications developed in-house that require access to the /proc directory for performance monitoring should be reviewed and excluded if they are deemed safe.
+- Regularly update the exclusion list to reflect changes in legitimate software and tools used within the organization to minimize false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious processes identified as using the pspy utility to halt further unauthorized process monitoring.
+- Conduct a thorough review of the affected system's /proc directory access logs to identify any other unauthorized access attempts or anomalies.
+- Reset credentials and review permissions for any accounts that may have been compromised or used in the attack to prevent further unauthorized access.
+- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited for privilege escalation.
+- Enhance monitoring and logging on the affected host to detect any future attempts to access the /proc directory using similar methods.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected."""
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1057"
+name = "Process Discovery"
+reference = "https://attack.mitre.org/techniques/T1057/"
+
+[[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/"