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

nldcsc_elastic_rules/rules/linux/credential_access_gdb_init_process_hooking.toml

@@ -0,0 +1,124 @@
+[metadata]
+creation_date = "2023/08/30"
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule monitors for the potential memory dump of the init process (PID 1) through gdb. Attackers may leverage memory
+dumping techniques to attempt secret extraction from privileged processes. Tools that display this behavior include
+"truffleproc" and "bash-memory-dump". This behavior should not happen by default, and should be investigated thoroughly.
+"""
+from = "now-9m"
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Linux init (PID 1) Secret Dump via GDB"
+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 Linux init (PID 1) Secret Dump via GDB
+
+In Linux, the init process (PID 1) is the first process started by the kernel and is responsible for initializing the system. Adversaries may exploit debugging tools like GDB to dump memory from this process, potentially extracting sensitive information. The detection rule identifies suspicious GDB executions targeting PID 1, flagging unauthorized memory access attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "gdb" and the process arguments include "--pid" or "-p" with a target of PID "1".
+- Check the user account associated with the gdb process execution to determine if it is authorized to perform debugging tasks on the system.
+- Investigate the parent process of the gdb execution to understand how it was initiated and whether it was part of a legitimate workflow or script.
+- Examine system logs around the time of the alert to identify any other suspicious activities or related events that might indicate a broader attack.
+- Assess the system for any unauthorized changes or anomalies, such as new user accounts, modified configurations, or unexpected network connections.
+- If possible, capture and analyze memory dumps or other forensic artifacts to identify any sensitive information that may have been accessed or exfiltrated.
+
+### False positive analysis
+
+- System administrators or developers may use GDB for legitimate debugging purposes on the init process. To handle this, create exceptions for known maintenance windows or specific user accounts that are authorized to perform such actions.
+- Automated scripts or monitoring tools might inadvertently trigger this rule if they include GDB commands targeting PID 1 for health checks. Review and adjust these scripts to avoid unnecessary memory access or exclude them from the rule if they are verified as safe.
+- Security tools or forensic analysis software might use GDB as part of their operations. Identify these tools and whitelist their processes to prevent false positives while ensuring they are from trusted sources.
+- Training or testing environments may simulate attacks or debugging scenarios involving GDB and PID 1. Exclude these environments from the rule to avoid noise, ensuring they are isolated from production systems.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the suspicious gdb process targeting PID 1 to stop any ongoing memory dumping activity.
+- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized access attempts or related suspicious activities.
+- Change all credentials and secrets that may have been exposed or accessed during the memory dump, focusing on those used by the init process and other privileged accounts.
+- Implement stricter access controls and monitoring for debugging tools like gdb, ensuring only authorized personnel can execute such tools on critical systems.
+- Escalate the incident to the security operations team for a comprehensive investigation and to determine if further forensic analysis is required.
+- Update and enhance detection rules and monitoring systems to better identify and alert on similar unauthorized memory access attempts in the future."""
+references = ["https://github.com/controlplaneio/truffleproc", "https://github.com/hajzer/bash-memory-dump"]
+risk_score = 47
+rule_id = "d4ff2f53-c802-4d2e-9fb9-9ecc08356c3f"
+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",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "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 == "gdb" and process.args in ("--pid", "-p") and process.args == "1"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1003"
+name = "OS Credential Dumping"
+reference = "https://attack.mitre.org/techniques/T1003/"
+[[rule.threat.technique.subtechnique]]
+id = "T1003.007"
+name = "Proc Filesystem"
+reference = "https://attack.mitre.org/techniques/T1003/007/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/linux/credential_access_gdb_process_hooking.toml

@@ -0,0 +1,105 @@
+[metadata]
+creation_date = "2023/08/30"
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule monitors for potential memory dumping through gdb. Attackers may leverage memory dumping techniques to attempt
+secret extraction from privileged processes. Tools that display this behavior include "truffleproc" and
+"bash-memory-dump". This behavior should not happen by default, and should be investigated thoroughly.
+"""
+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 = "Linux Process Hooking via GDB"
+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 Linux Process Hooking via GDB
+
+GDB, the GNU Debugger, is a powerful tool used for debugging applications by inspecting their memory and execution flow. Adversaries can exploit GDB to attach to running processes, potentially extracting sensitive information like credentials. The detection rule identifies suspicious use of GDB by monitoring process initiation with specific arguments, flagging potential unauthorized memory access attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of GDB by checking if the process name is "gdb" and the arguments include "--pid" or "-p".
+- Identify the target process that GDB is attempting to attach to by examining the process arguments and cross-referencing the process ID.
+- Investigate the user account under which the GDB process is running to determine if it is authorized to perform debugging tasks on the target process.
+- Check the system logs and audit logs for any unusual activity or prior attempts to access sensitive processes or data around the time the GDB process was initiated.
+- Correlate the event with other security alerts or anomalies in the environment to assess if this is part of a broader attack pattern or isolated incident.
+- Evaluate the necessity and legitimacy of the GDB usage in the context of the system's normal operations and the user's role.
+- If unauthorized access is suspected, consider isolating the affected system and conducting a deeper forensic analysis to prevent potential data exfiltration.
+
+### False positive analysis
+
+- Development and debugging activities may trigger the rule when developers use GDB for legitimate purposes. To manage this, create exceptions for specific user accounts or development environments where GDB usage is expected.
+- Automated scripts or maintenance tasks that utilize GDB for process inspection can also cause false positives. Identify these scripts and exclude their execution paths or associated user accounts from the rule.
+- Security tools or monitoring solutions that use GDB for legitimate process analysis might be flagged. Verify these tools and whitelist their processes or execution contexts to prevent unnecessary alerts.
+- Training or educational environments where GDB is used for learning purposes can lead to false positives. Consider excluding these environments or specific user groups from the rule to avoid interference with educational activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the GDB process if it is confirmed to be unauthorized, using process management tools to stop the process safely.
+- Conduct a memory dump analysis of the affected system to identify any potential data leakage or extraction of sensitive information.
+- Review system logs and audit trails to identify any additional unauthorized access attempts or related suspicious activities.
+- Change credentials for any accounts that may have been exposed or accessed during the incident to prevent unauthorized use.
+- Implement stricter access controls and monitoring for systems that handle sensitive information to prevent similar incidents.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
+references = ["https://github.com/controlplaneio/truffleproc", "https://github.com/hajzer/bash-memory-dump"]
+risk_score = 21
+rule_id = "66c058f3-99f4-4d18-952b-43348f2577a0"
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "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 == "gdb" and process.args in ("--pid", "-p") and
+/* Covered by d4ff2f53-c802-4d2e-9fb9-9ecc08356c3f */
+process.args != "1"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1003"
+name = "OS Credential Dumping"
+reference = "https://attack.mitre.org/techniques/T1003/"
+[[rule.threat.technique.subtechnique]]
+id = "T1003.007"
+name = "Proc Filesystem"
+reference = "https://attack.mitre.org/techniques/T1003/007/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/linux/credential_access_gh_auth_via_nodejs.toml

@@ -0,0 +1,97 @@
+[metadata]
+creation_date = "2025/09/18"
+integration = ["endpoint", "crowdstrike"]
+maturity = "production"
+updated_date = "2025/10/17"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects when the Node.js runtime spawns a shell to execute the GitHub CLI (gh) command to retrieve
+a GitHub authentication token. The GitHub CLI is a command-line tool that allows users to interact with
+GitHub from the terminal. The "gh auth token" command is used to retrieve an authentication token for
+GitHub, which can be used to authenticate API requests and perform actions on behalf of the user. Adversaries
+may use this technique to access GitHub repositories and potentially exfiltrate sensitive information or
+perform malicious actions. This activity was observed in the wild as part of the Shai-Hulud worm.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*", "logs-crowdstrike.fdr*"]
+language = "eql"
+license = "Elastic License v2"
+name = "GitHub Authentication Token Access via Node.js"
+references = ["https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise"]
+risk_score = 47
+rule_id = "e5d69377-f8cf-4e8f-8328-690822cd012a"
+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",
+  "OS: Linux",
+  "Use Case: Threat Detection",
+  "Tactic: Credential Access",
+  "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.parent.name == "node" and
+process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "gh auth token"
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1552"
+name = "Unsecured Credentials"
+reference = "https://attack.mitre.org/techniques/T1552/"
+
+[[rule.threat.technique]]
+id = "T1528"
+name = "Steal Application Access Token"
+reference = "https://attack.mitre.org/techniques/T1528/"
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+
+[[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/credential_access_kubernetes_service_account_secret_access.toml

@@ -0,0 +1,144 @@
+[metadata]
+creation_date = "2025/06/17"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/07/07"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects when a process accesses Kubernetes service account secrets. Kubernetes service
+account secrets are files that contain sensitive information used by applications running in Kubernetes
+clusters to authenticate and authorize access to the cluster. These secrets are typically mounted into
+pods at runtime, allowing applications to access them securely. Unauthorized access to these secrets
+can lead to privilege escalation, lateral movement and unauthorized actions within the cluster.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Kubernetes Service Account Secret Access"
+note = """ ## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Kubernetes Service Account Secret Access
+
+Kubernetes service account secrets are crucial for authenticating applications within clusters, providing access to necessary resources. Adversaries may exploit these secrets to escalate privileges or move laterally within the cluster. The detection rule identifies unauthorized access by monitoring processes that interact with secret file paths or specific secret files, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the process command line and working directory to confirm if the access to the service account secrets was expected or authorized. Check for any known applications or scripts that should have access to these paths.
+- Investigate the user or service account under which the process was executed to determine if it has legitimate reasons to access the Kubernetes service account secrets.
+- Examine the process arguments, specifically looking for access to files like "ca.crt", "token", and "namespace", to understand the nature of the access and whether it aligns with normal operations.
+- Check the history of the process and any associated processes to identify if there are any patterns of unauthorized access or if this is an isolated incident.
+- Correlate the event with other logs or alerts from the same host or cluster to identify any signs of privilege escalation or lateral movement attempts.
+- Assess the risk score and severity in the context of the environment to prioritize the investigation and response actions accordingly.
+
+### False positive analysis
+
+- Routine access by system processes or monitoring tools can trigger false positives. Identify these processes and create exceptions to prevent unnecessary alerts.
+- Automated scripts or applications that regularly access service account secrets for legitimate purposes may be flagged. Review these scripts and whitelist them if they are verified as non-threatening.
+- Development and testing environments often have processes accessing service account secrets as part of normal operations. Exclude these environments from the rule or adjust the rule's scope to focus on production environments.
+- Frequent access by container orchestration tools or agents that manage Kubernetes clusters can be mistaken for unauthorized access. Ensure these tools are recognized and excluded from triggering alerts.
+- Scheduled jobs or cron tasks that interact with service account secrets for maintenance or updates might be flagged. Validate these tasks and add them to an exception list if they are part of regular operations.
+
+### Response and remediation
+
+- Immediately isolate the affected pod or container to prevent further unauthorized access or lateral movement within the cluster.
+- Revoke and rotate the compromised service account credentials to prevent further misuse. Ensure that new credentials are securely distributed and stored.
+- Conduct a thorough review of access logs to identify any unauthorized actions or data access that occurred using the compromised credentials.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the cluster and associated resources.
+- Implement network segmentation and access controls to limit the exposure of sensitive secrets and reduce the risk of unauthorized access in the future.
+- Enhance monitoring and alerting for unusual access patterns to Kubernetes service account secrets to detect similar threats promptly.
+- Review and update Kubernetes security policies to enforce least privilege access and ensure that service accounts have only the necessary permissions for their intended functions.
+"""
+risk_score = 47
+rule_id = "ce73954b-a0a4-4f05-b67b-294c500dac77"
+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: Credential Access",
+    "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.command_line like (
+    "*/run/secrets/kubernetes.io/serviceaccount*",
+    "*/var/run/secrets/kubernetes.io/serviceaccount*",
+    "*/secrets/kubernetes.io/serviceaccount*"
+  ) or (
+    process.working_directory like (
+      "/run/secrets/kubernetes.io/serviceaccount",
+      "/var/run/secrets/kubernetes.io/serviceaccount",
+      "/secrets/kubernetes.io/serviceaccount"
+    ) and
+    process.args in ("ca.crt", "token", "namespace")
+  )
+)
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1552"
+name = "Unsecured Credentials"
+reference = "https://attack.mitre.org/techniques/T1552/"
+
+[[rule.threat.technique]]
+id = "T1528"
+name = "Steal Application Access Token"
+reference = "https://attack.mitre.org/techniques/T1528/"
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+
+[[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/credential_access_manual_memory_dumping.toml

@@ -0,0 +1,128 @@
+[metadata]
+creation_date = "2025/04/25"
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/07/07"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule monitors for manual memory dumping via the proc filesystem. The proc filesystem in Linux provides a virtual filesystem
+that contains information about system processes and their memory mappings. Attackers may use this technique to dump the memory
+of a process, potentially extracting sensitive information such as credentials or encryption keys.
+"""
+from = "now-9m"
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Manual Memory Dumping via Proc Filesystem"
+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 Manual Memory Dumping via Proc Filesystem
+
+The proc filesystem in Linux is a virtual interface providing detailed insights into system processes and their memory. Adversaries exploit this by manually dumping memory from processes to extract sensitive data like credentials. The detection rule identifies suspicious activities by monitoring process executions that access memory files within the proc directory, flagging potential credential access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and command line that triggered the rule, focusing on processes like "cat", "grep", "tail", "less", "more", "egrep", or "fgrep" accessing "/proc/*/mem".
+- Examine the process execution context, including the parent process and user account associated with the suspicious activity, to determine if the activity is expected or potentially malicious.
+- Check the system logs and historical data for any previous occurrences of similar activities involving the same process names and command lines to assess if this is part of a pattern or anomaly.
+- Investigate the user account's recent activities and permissions to determine if there are any signs of compromise or unauthorized access that could explain the memory dumping attempt.
+- Analyze network traffic and connections from the host to identify any potential data exfiltration attempts or communications with known malicious IP addresses or domains.
+- If necessary, isolate the affected system to prevent further potential data leakage and conduct a deeper forensic analysis to uncover any additional indicators of compromise.
+
+### False positive analysis
+
+- System administrators or automated scripts may legitimately access the proc filesystem for monitoring or debugging purposes. To handle this, identify and whitelist known scripts or administrative tools that frequently access memory files.
+- Security tools or monitoring solutions might access the proc filesystem as part of their regular operations. Review and exclude these processes from the rule to prevent unnecessary alerts.
+- Developers or testers might use commands like cat or grep on proc files during application debugging. Establish a list of approved users or groups who are allowed to perform these actions and exclude their activities from triggering alerts.
+- Backup or system maintenance processes could involve accessing proc files. Document these processes and create exceptions for them to avoid false positives.
+- Regular system health checks might involve accessing memory files. Identify these checks and configure the rule to ignore them by specifying the associated process names or command patterns.
+
+### Response and remediation
+
+- Immediately isolate the affected system to prevent further unauthorized access or data exfiltration. Disconnect the network connection and disable remote access capabilities.
+- Terminate any suspicious processes identified by the detection rule, specifically those accessing memory files within the proc directory using commands like "cat", "grep", "tail", "less", "more", "egrep", or "fgrep".
+- Conduct a memory analysis on the isolated system to identify any extracted sensitive data, such as credentials or encryption keys, and assess the extent of the compromise.
+- Change all potentially compromised credentials and encryption keys immediately, prioritizing those associated with critical systems and services.
+- Review and enhance system logging and monitoring configurations to ensure comprehensive visibility into process activities, particularly those involving the proc filesystem.
+- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to determine if the threat is part of a larger attack campaign.
+- Implement additional security controls, such as restricting access to the proc filesystem and employing application whitelisting, to prevent unauthorized memory dumping activities in the future.
+"""
+risk_score = 21
+rule_id = "6505e02e-28dd-41cd-b18f-64e649caa4e2"
+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: Credential Access",
+    "Use Case: Vulnerability",
+    "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Data Source: Crowdstrike",
+    "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 in ("cat", "grep", "tail", "less", "more", "egrep", "fgrep") and process.command_line like "/proc/*/mem"
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1003"
+name = "OS Credential Dumping"
+reference = "https://attack.mitre.org/techniques/T1003/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1003.007"
+name = "Proc Filesystem"
+reference = "https://attack.mitre.org/techniques/T1003/007/"
+
+[[rule.threat.technique]]
+id = "T1212"
+name = "Exploitation for Credential Access"
+reference = "https://attack.mitre.org/techniques/T1212/"
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"