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

nldcsc_elastic_rules/rules/cross-platform/credential_access_forced_authentication_pipes.toml

@@ -0,0 +1,112 @@
+[metadata]
+creation_date = "2024/07/23"
+integration = ["endpoint", "system"]
+maturity = "production"
+updated_date = "2025/02/21"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies a potential forced authentication using related SMB named pipes. Attackers may attempt to force targets to
+authenticate to a host controlled by them to capture hashes or enable relay attacks.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.network-*", "logs-system.security*", "winlogbeat-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Active Directory Forced Authentication from Linux Host - SMB Named Pipes"
+references = [
+    "https://github.com/p0dalirius/windows-coerced-authentication-methods",
+    "https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications",
+    "https://attack.mitre.org/techniques/T1187/",
+]
+risk_score = 47
+rule_id = "c24e9a43-f67e-431d-991b-09cdb83b3c0c"
+setup = """## Setup
+
+This rule uses Elastic Endpoint network events from Linux hosts and system integration events from Domain controllers
+for correlation. Both data sources should be collected from the hosts for this detection to work.
+
+The 'Audit Detailed File Share' audit policy must be configured (Success Failure).
+Steps to implement the logging policy with Advanced Audit Configuration:
+```
+Computer Configuration >
+Policies >
+Windows Settings >
+Security Settings >
+Advanced Audit Policies Configuration >
+Audit Policies >
+Object Access >
+Audit Detailed File Share (Success,Failure)
+```
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Elastic Defend",
+    "Data Source: Active Directory",
+    "Use Case: Active Directory Monitoring",
+    "Data Source: Windows Security Event Logs",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+sequence with maxspan=15s
+[network where host.os.type == "linux" and event.action == "connection_attempted" and destination.port == 445 and not startswith~(string(destination.ip), string(host.ip))] by host.ip, data_stream.namespace
+[file where host.os.type == "windows" and event.code == "5145" and file.name : ("Spoolss", "netdfs", "lsarpc", "lsass", "netlogon", "samr", "efsrpc", "FssagentRpc")] by source.ip, data_stream.namespace
+'''
+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 Active Directory Forced Authentication from Linux Host - SMB Named Pipes
+
+Active Directory (AD) and SMB named pipes facilitate network resource access and inter-process communication. Adversaries exploit these by forcing authentication from a Linux host to capture credentials or perform relay attacks. The detection rule identifies suspicious SMB connection attempts from Linux to Windows hosts, focusing on specific named pipes indicative of forced authentication attempts, thus highlighting potential credential access threats.
+
+### Possible investigation steps
+
+- Review the network logs to identify the Linux host IP address that attempted the SMB connection on port 445 and verify if this activity is expected or authorized.
+- Check the Windows host logs for event code 5145 to determine which named pipes were accessed and assess if these accesses align with normal operations or indicate suspicious activity.
+- Investigate the source IP address from the Windows logs to determine if it matches the Linux host IP and evaluate if this connection is part of a known and legitimate process.
+- Analyze historical data for any previous similar connection attempts from the same Linux host to identify patterns or repeated unauthorized access attempts.
+- Consult with system administrators to confirm if there have been any recent changes or updates in the network configuration that could explain the connection attempts.
+
+### False positive analysis
+
+- Routine administrative tasks from Linux hosts may trigger alerts. Identify and document these tasks to create exceptions for known IP addresses or hostnames involved in regular operations.
+- Automated backup or monitoring systems that connect to Windows hosts using SMB may cause false positives. Review and whitelist these systems by their IP addresses or specific named pipes they access.
+- Development or testing environments where Linux hosts frequently interact with Windows systems can generate alerts. Establish a separate monitoring policy or exclude these environments from the rule to reduce noise.
+- Security tools or scripts that perform network scans or audits might mimic suspicious behavior. Verify these tools and exclude their activities by specifying their source IPs or associated user accounts.
+- Cross-platform file sharing services that use SMB for legitimate purposes may be flagged. Identify these services and adjust the rule to ignore their specific connection patterns or named pipes.
+
+### Response and remediation
+
+- Isolate the affected Linux host from the network to prevent further unauthorized SMB connection attempts and potential credential capture.
+- Conduct a thorough review of the Linux host's network activity logs to identify any unauthorized access or data exfiltration attempts.
+- Reset passwords for any accounts that may have been exposed or compromised during the forced authentication attempt to mitigate the risk of credential misuse.
+- Implement network segmentation to limit SMB traffic between Linux and Windows hosts, reducing the attack surface for similar threats.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional hosts or systems are affected.
+- Deploy enhanced monitoring on the identified named pipes and associated network traffic to detect and respond to future forced authentication attempts promptly.
+- Review and update firewall rules to restrict unnecessary SMB traffic and ensure only authorized systems can communicate over port 445."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1187"
+name = "Forced Authentication"
+reference = "https://attack.mitre.org/techniques/T1187/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/cross-platform/credential_access_trufflehog_execution.toml

@@ -0,0 +1,97 @@
+[metadata]
+creation_date = "2025/09/18"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/11/25"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects the execution of TruffleHog, a tool used to search for high-entropy strings and secrets
+in code repositories, which may indicate an attempt to access credentials. This tool was abused by the Shai-Hulud
+worm to search for credentials in code repositories.
+"""
+false_positives = [
+    """
+    Trufflehog is a legitimate open-source tool used by security professionals and developers to search for sensitive
+    information, such as passwords, API keys, and other secrets, within code repositories. It is commonly employed
+    during security assessments and code reviews to identify potential vulnerabilities.
+    """,
+]
+from = "now-9m"
+index = ["logs-endpoint.events.process-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Credential Access via TruffleHog Execution"
+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 Credential Access via TruffleHog Execution
+
+This rule flags TruffleHog executed to scan the local filesystem with verified JSON results, a direct path to harvesting secrets from source code, configs, and build artifacts. Attackers gain shell access on a developer workstation or CI runner, clone or point to internal repositories, run 'trufflehog --results=verified --json filesystem .' to enumerate valid tokens, and then pivot using the recovered keys to pull private code or authenticate to cloud and CI/CD systems.
+
+### Possible investigation steps
+
+- Review binary path, code signature/hash, parent process chain, initiating user, and host role (developer workstation vs CI runner) to quickly decide if the execution matches an approved secret-scanning job or an ad‑hoc run.
+- Determine the working directory and target path used by the scan to identify which repositories or configuration directories were inspected and whether sensitive files (e.g., .env, deployment keys, build secrets) were in scope.
+- Pivot to same-session activity to spot credential use or exfiltration by correlating subsequent outbound connections to git remotes or cloud/CI APIs and launches of developer CLIs like git, gh, aws, az, gcloud, docker, kubectl, or vault.
+- Look for output artifacts and exfil channels by checking for creation or deletion of JSON reports or archives, clipboard access, or piping of results to curl/wget/netcat and whether those artifacts were emailed or uploaded externally.
+- Cross-check VCS and CI/CD audit logs for this identity and host for unusual pushes, pipeline changes, or new tokens issued shortly after the scan, which may indicate worm-like propagation or credential abuse.
+
+### False positive analysis
+
+- An approved secret-scanning task by a developer or security engineer runs trufflehog with --results=verified --json filesystem to audit local code and configuration, producing benign activity on a development host.
+- An internal automation or scheduled job invokes trufflehog to baseline filesystem secrets for compliance or hygiene checks, leading to expected process-start logs without credential abuse.
+
+### Response and remediation
+
+- Immediately isolate the host or CI runner, terminate the trufflehog process and its parent shell/script, and block egress to git remotes and cloud APIs from that asset.
+- Collect the verified findings from trufflehog output (stdout or JSON file), revoke and rotate any listed secrets (GitHub personal access tokens, AWS access keys, Azure service principal credentials, CI job tokens), and clear credential caches on the host.
+- Remove unauthorized trufflehog binaries/packages, helper scripts, and scheduled tasks; delete report files and scanned working directories (local repo clones, .env/config folders), and purge shell history containing exfil commands like curl/wget/netcat.
+- Restore the workstation or runner from a known-good image if tampering is suspected, re-enroll endpoint protection, reissue required developer or CI credentials with least privilege, and validate normal pulls to internal git and cloud services.
+- Escalate to full incident response if trufflehog ran under a service account, on a build server/CI runner, or if any discovered secret was used to authenticate to external git remotes (e.g., github.com), cloud APIs, or private registries in the same session.
+- Harden by blocking unapproved trufflehog execution via application control, moving approved secret scanning to a locked-down pipeline, enforcing short-lived PATs and key rotation, enabling egress filtering from developer hosts/runners, and deploying fleet-wide detections for "trufflehog --results=verified --json filesystem".
+"""
+references = [
+    "https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise",
+    "https://socket.dev/blog/shai-hulud-strikes-again-v2",
+]
+risk_score = 21
+rule_id = "47595dea-452b-4d37-b82d-6dd691325139"
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "OS: Windows",
+    "OS: macOS",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+process where event.type == "start" and process.name : ("trufflehog.exe", "trufflehog") and
+process.args == "--json" and process.args == "filesystem"
+'''
+
+[[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]]
+id = "T1555"
+name = "Credentials from Password Stores"
+reference = "https://attack.mitre.org/techniques/T1555/"
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"

nldcsc_elastic_rules/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml

@@ -0,0 +1,81 @@
+[metadata]
+creation_date = "2021/07/14"
+maturity = "production"
+updated_date = "2025/11/13"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects events that have a mismatch on the expected event agent ID. The status "agent_id_mismatch/mismatch" occurs when
+the expected agent ID associated with the API key does not match the actual agent ID in an event. This could indicate
+attempts to spoof events in order to masquerade actual activity to evade detection.
+"""
+false_positives = [
+    """
+    This is meant to run only on datasources using Elastic Agent 7.14+ since versions prior to that will be missing the
+    necessary field, resulting in false positives.
+    """,
+]
+from = "now-9m"
+index = ["logs-*", "metrics-*", "traces-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Agent Spoofing - Mismatched Agent ID"
+risk_score = 73
+rule_id = "3115bd2c-0baa-4df0-80ea-45e474b5ef93"
+severity = "high"
+tags = ["Use Case: Threat Detection", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.agent_id_status:agent_id_mismatch and not host.name:agentless-*
+'''
+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 Agent Spoofing - Mismatched Agent ID
+
+In security environments, agent IDs uniquely identify software agents that report events. Adversaries may spoof these IDs to disguise unauthorized activities, evading detection systems. The detection rule identifies discrepancies between expected and actual agent IDs, flagging potential spoofing attempts. By monitoring for mismatches, it helps uncover efforts to masquerade malicious actions as legitimate.
+
+### Possible investigation steps
+
+- Review the event logs to identify the specific events where the agent_id_status is marked as "agent_id_mismatch" or "mismatch" to understand the scope and frequency of the issue.
+- Correlate the mismatched agent IDs with the associated API keys to determine if there are any patterns or commonalities that could indicate a targeted spoofing attempt.
+- Investigate the source IP addresses and user accounts associated with the mismatched events to identify any unauthorized access or suspicious activity.
+- Check for any recent changes or anomalies in the configuration or deployment of agents that could explain the mismatches, such as updates or reassignments.
+- Analyze historical data to determine if similar mismatches have occurred in the past and whether they were resolved or linked to known issues or threats.
+- Consult with the IT or security team to verify if there are any legitimate reasons for the agent ID discrepancies, such as testing or maintenance activities.
+
+### False positive analysis
+
+- Legitimate software updates or patches may temporarily cause agent ID mismatches. Users should verify if the mismatches coincide with scheduled updates and consider excluding these events if confirmed.
+- Network configuration changes, such as IP address reassignments, can lead to mismatches. Ensure that network changes are documented and correlate with the mismatched events before excluding them.
+- Virtual machine snapshots or clones might result in duplicate agent IDs. Users should track virtual machine activities and exclude events from known snapshot or cloning operations.
+- Load balancing or failover processes in high-availability environments can cause agent ID discrepancies. Review the infrastructure setup and exclude events that align with these processes.
+- Testing environments often simulate various agent activities, leading to mismatches. Clearly separate test environments from production in monitoring systems and exclude test-related events.
+
+### Response and remediation
+
+- Immediately isolate the affected systems to prevent further unauthorized access or data exfiltration. This can be done by disconnecting the system from the network or using network segmentation techniques.
+- Conduct a thorough review of the logs and events associated with the mismatched agent ID to identify any unauthorized changes or activities. Focus on the specific events flagged by the detection rule.
+- Revoke and reissue API keys associated with the compromised agent ID to prevent further misuse. Ensure that new keys are distributed securely and only to authorized personnel.
+- Implement additional monitoring on the affected systems and related network segments to detect any further attempts at agent ID spoofing or other suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat actor has compromised other parts of the network.
+- Review and update access controls and authentication mechanisms to ensure that only legitimate agents can report events. Consider implementing multi-factor authentication for added security.
+- Document the incident, including all actions taken, and conduct a post-incident review to identify any gaps in detection or response. Use this information to enhance future threat detection and response capabilities."""
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1036"
+name = "Masquerading"
+reference = "https://attack.mitre.org/techniques/T1036/"
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"

nldcsc_elastic_rules/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml

@@ -0,0 +1,87 @@
+[metadata]
+creation_date = "2021/07/14"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/11/13"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects when multiple hosts are using the same agent ID. This could occur in the event of an agent being taken over and
+used to inject illegitimate documents into an instance as an attempt to spoof events in order to masquerade actual
+activity to evade detection.
+"""
+false_positives = [
+    """
+    This is meant to run only on datasources using Elastic Agent 7.14+ since versions prior to that will be missing the
+    necessary field, resulting in false positives.
+    """,
+]
+from = "now-9m"
+language = "esql"
+license = "Elastic License v2"
+name = "Agent Spoofing - Multiple Hosts Using Same Agent"
+risk_score = 73
+rule_id = "493834ca-f861-414c-8602-150d5505b777"
+severity = "high"
+tags = ["Use Case: Threat Detection", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-endpoint.*  metadata _id
+| where event.agent_id_status is not null 
+| stats Esql.count_distinct_host_ids = count_distinct(host.id), Esql.host_id_values = values(host.id), Esql.user_id_values_user_id = values(user.id) by agent.id
+| where Esql.count_distinct_host_ids >= 2
+| keep Esql.count_distinct_host_ids, Esql.host_id_values, Esql.user_id_values_user_id, agent.id
+'''
+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 Agent Spoofing - Multiple Hosts Using Same Agent
+
+In network environments, agents are deployed on hosts to monitor and report activities. Adversaries may exploit these agents by hijacking their IDs to inject false data, masking malicious actions. The detection rule identifies anomalies where multiple hosts report using the same agent ID, signaling potential spoofing attempts. By focusing on unique agent ID usage, it helps uncover evasion tactics aimed at concealing unauthorized activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific agent ID that is being reported by multiple hosts.
+- Cross-reference the agent ID with the list of known and authorized agents to determine if it has been compromised or misconfigured.
+- Examine the network logs and host activity for each host reporting the same agent ID to identify any unusual or unauthorized activities.
+- Check for any recent changes or updates to the agent software on the affected hosts that could explain the anomaly.
+- Investigate the timeline of events to determine when the agent ID started being used by multiple hosts and correlate this with any known incidents or changes in the network environment.
+- Assess the potential impact of the spoofing attempt on the network's security posture and consider isolating affected hosts if necessary to prevent further malicious activity.
+
+### False positive analysis
+
+- Legitimate load balancing or failover scenarios where multiple hosts are configured to use the same agent ID for redundancy can trigger false positives. Users should identify and document these configurations, then create exceptions in the detection rule to exclude these known non-threatening behaviors.
+- Virtualized environments where snapshots or clones of a host are created might result in multiple instances reporting the same agent ID. Users should ensure that each virtual instance is assigned a unique agent ID or adjust the rule to account for these scenarios.
+- Testing or development environments where agents are intentionally duplicated for testing purposes can also lead to false positives. Users should tag these environments appropriately and modify the rule to exclude events from these tags.
+- In cases where agents are temporarily reassigned to different hosts for maintenance or troubleshooting, users should maintain a log of these activities and adjust the detection rule to ignore these temporary changes.
+
+### Response and remediation
+
+- Isolate affected hosts immediately to prevent further spread of potentially malicious activities across the network.
+- Revoke and reissue new agent IDs for the affected hosts to ensure that compromised IDs are no longer in use.
+- Conduct a thorough forensic analysis on the isolated hosts to identify any unauthorized changes or malicious software that may have been introduced.
+- Review and update access controls and authentication mechanisms for agent deployment to prevent unauthorized access and hijacking of agent IDs.
+- Monitor network traffic and logs closely for any signs of continued spoofing attempts or related suspicious activities.
+- Escalate the incident to the security operations center (SOC) and relevant stakeholders to ensure awareness and coordinated response efforts.
+- Implement enhanced logging and alerting for agent ID anomalies to improve detection of similar threats in the future."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1036"
+name = "Masquerading"
+reference = "https://attack.mitre.org/techniques/T1036/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+
+

nldcsc_elastic_rules/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml

@@ -0,0 +1,99 @@
+[metadata]
+creation_date = "2020/11/03"
+integration = ["endpoint", "windows"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the deletion of WebServer access logs. This may indicate an attempt to evade detection or destroy forensic
+evidence on a system.
+"""
+from = "now-9m"
+index = ["auditbeat-*", "winlogbeat-*", "logs-endpoint.events.*", "logs-windows.sysmon_operational-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "WebServer Access Logs Deleted"
+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 WebServer Access Logs Deleted
+
+Web server access logs are crucial for monitoring and analyzing web traffic, providing insights into user activity and potential security incidents. Adversaries may delete these logs to cover their tracks, hindering forensic investigations. The detection rule identifies log deletions across various operating systems by monitoring specific file paths, signaling potential attempts at evasion or evidence destruction.
+
+### Possible investigation steps
+
+- Review the specific file path where the deletion event was detected to determine which web server's logs were affected, using the file.path field from the alert.
+- Check for any recent access or modification events on the affected web server to identify potential unauthorized access or suspicious activity prior to the log deletion.
+- Investigate user accounts and processes that had access to the deleted log files around the time of the deletion event to identify potential malicious actors or compromised accounts.
+- Correlate the log deletion event with other security alerts or anomalies in the same timeframe to identify patterns or related incidents.
+- Examine backup logs or alternative logging mechanisms, if available, to recover deleted information and assess the impact of the log deletion on forensic capabilities.
+
+### False positive analysis
+
+- Routine log rotation or maintenance scripts may delete old web server logs. To handle this, identify and exclude these scheduled tasks from triggering alerts by specifying their execution times or associated process names.
+- Automated backup processes that move or delete logs after archiving can trigger false positives. Exclude these processes by adding exceptions for the backup software or scripts used.
+- Development or testing environments where logs are frequently cleared to reset the environment can cause alerts. Consider excluding these environments by specifying their IP addresses or hostnames.
+- System administrators manually deleting logs as part of regular maintenance can be mistaken for malicious activity. Implement a policy to log and approve such actions, and exclude these approved activities from detection.
+- Temporary log deletions during server migrations or upgrades might trigger alerts. Document these events and create temporary exceptions during the migration period.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough review of recent user activity and system changes to identify any unauthorized access or modifications that may have led to the log deletion.
+- Restore the deleted web server access logs from backups, if available, to aid in further forensic analysis and investigation.
+- Implement enhanced monitoring on the affected system to detect any further attempts at log deletion or other suspicious activities.
+- Review and tighten access controls and permissions on log files to ensure only authorized personnel can modify or delete them.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Document the incident, including all actions taken, and update incident response plans to improve future detection and response capabilities."""
+risk_score = 47
+rule_id = "665e7a4f-c58e-4fc6-bc83-87a7572670ac"
+setup = """## Setup
+
+If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
+events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
+Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
+`event.ingested` to @timestamp.
+For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "OS: Windows",
+    "OS: macOS",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Data Source: Elastic Defend",
+    "Data Source: Sysmon",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+file where event.type == "deletion" and
+  file.path : ("C:\\inetpub\\logs\\LogFiles\\*.log",
+               "/var/log/apache*/access.log",
+               "/etc/httpd/logs/access_log",
+               "/var/log/httpd/access_log",
+               "/var/www/*/logs/access.log")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1070"
+name = "Indicator Removal"
+reference = "https://attack.mitre.org/techniques/T1070/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml

@@ -0,0 +1,111 @@
+[metadata]
+creation_date = "2020/05/04"
+integration = ["endpoint", "auditd_manager"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Adversaries may attempt to clear or disable the Bash command-line history in an attempt to evade detection or forensic
+investigations.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Tampering of Shell Command-Line History"
+references = ["https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security"]
+risk_score = 47
+rule_id = "7bcbb3ac-e533-41ad-a612-d6c3bf666aba"
+setup = """## Setup
+
+If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
+events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
+Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
+`event.ingested` to @timestamp.
+For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "OS: macOS",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "Data Source: Auditd Manager",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where event.action in ("exec", "exec_event", "executed", "process_started") and event.type == "start" and
+ (
+  ((process.args : ("rm", "echo") or
+    (process.args : "ln" and process.args : "-sf" and process.args : "/dev/null") or
+    (process.args : "truncate" and process.args : "-s0"))
+    and process.args : (".bash_history", "/root/.bash_history", "/home/*/.bash_history","/Users/.bash_history", "/Users/*/.bash_history",
+                        ".zsh_history", "/root/.zsh_history", "/home/*/.zsh_history", "/Users/.zsh_history", "/Users/*/.zsh_history")) or
+  (process.args : "history" and process.args : "-c") or
+  (process.args : "export" and process.args : ("HISTFILE=/dev/null", "HISTFILESIZE=0")) or
+  (process.args : "unset" and process.args : "HISTFILE") or
+  (process.args : "set" and process.args : "history" and process.args : "+o")
+ )
+'''
+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 Tampering of Shell Command-Line History
+
+Shell command-line history is a crucial feature in Unix-like systems, recording user commands for convenience and auditing. Adversaries may manipulate this history to hide their tracks, using commands to delete or redirect history files, clear history buffers, or disable history logging. The detection rule identifies such tampering by monitoring for suspicious command patterns and arguments indicative of history manipulation attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to identify the user account associated with the suspicious command, focusing on the process.args field to determine the specific command and arguments used.
+- Check the process execution timeline to correlate the suspicious activity with other events on the system, such as logins or file modifications, to understand the context of the tampering attempt.
+- Investigate the command history files (.bash_history, .zsh_history) for the affected user accounts to assess the extent of tampering and identify any commands that may have been executed prior to the history manipulation.
+- Examine system logs and audit records for any additional indicators of compromise or related suspicious activities, such as unauthorized access attempts or privilege escalation events.
+- Verify the current configuration of the HISTFILE and HISTFILESIZE environment variables for the affected user accounts to ensure they have not been altered to disable history logging.
+
+### False positive analysis
+
+- System administrators or automated scripts may clear command-line history as part of routine maintenance or privacy measures. To handle this, identify and whitelist known scripts or user accounts that perform these actions regularly.
+- Developers or power users might redirect or unset history files to manage disk space or for personal preference. Consider excluding specific user accounts or directories from monitoring if these actions are verified as non-malicious.
+- Security tools or compliance scripts may execute commands that resemble history tampering to ensure systems are in a desired state. Review and exclude these tools from triggering alerts by adding them to an exception list.
+- Temporary testing environments or sandboxed systems might frequently clear history as part of their reset processes. Exclude these environments from the rule to prevent unnecessary alerts.
+- Users with privacy concerns might intentionally disable history logging. Engage with these users to understand their needs and adjust monitoring policies accordingly, possibly by excluding their sessions from the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further tampering or data exfiltration.
+- Conduct a thorough review of the affected user's recent command history and system logs to identify any unauthorized or suspicious activities that may have occurred prior to the tampering.
+- Restore the tampered history files from a secure backup, if available, to aid in further forensic analysis and ensure continuity of auditing.
+- Re-enable and secure shell history logging by resetting the HISTFILE and HISTFILESIZE environment variables to their default values and ensuring they are not set to null or zero.
+- Implement stricter access controls and monitoring on the affected system to prevent unauthorized users from modifying shell history files in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may have been compromised.
+- Review and update endpoint detection and response (EDR) configurations to enhance monitoring for similar tampering attempts, ensuring alerts are generated for any future suspicious command patterns."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1070"
+name = "Indicator Removal"
+reference = "https://attack.mitre.org/techniques/T1070/"
+[[rule.threat.technique.subtechnique]]
+id = "T1070.003"
+name = "Clear Command History"
+reference = "https://attack.mitre.org/techniques/T1070/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+