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

nldcsc_elastic_rules/rules/cross-platform/multiple_alerts_email_elastic_defend_correlation.toml

@@ -0,0 +1,82 @@
+[metadata]
+creation_date = "2025/11/19"
+maturity = "production"
+updated_date = "2025/11/19"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule correlates any Elastic Defend alert with an email security related alert by target user name. This may indicate
+the successful execution of a phishing attack.
+"""
+from = "now-1h"
+interval = "45m"
+language = "esql"
+license = "Elastic License v2"
+name = "Elastic Defend and Email Alerts Correlation"
+risk_score = 73
+rule_id = "c562a800-cf97-464e-9d6f-84db91e86e10"
+severity = "high"
+tags = [
+    "Use Case: Threat Detection",
+    "Rule Type: Higher-Order Rule",
+    "Resources: Investigation Guide",
+    "Data Source: Elastic Defend",
+    "Domain: Email",
+    "Domain: Endpoint"
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-* metadata _id
+// Email or Elastic Defend alerts where user name is populated
+| where
+  (event.category == "email" and event.kind == "alert" and destination.user.name is not null) or
+  (event.module == "endpoint" and event.dataset == "endpoint.alerts" and user.name is not null)
+
+// extract target user name from email and endpoint alerts
+| eval email_alert_target_user_name = CASE(event.category == "email", destination.user.name, null),
+       elastic_defend_alert_user_name = CASE(event.module == "endpoint" and event.dataset == "endpoint.alerts", user.name, null)
+| eval Esql.target_user_name = COALESCE(email_alert_target_user_name, elastic_defend_alert_user_name)
+| where Esql.target_user_name is not null
+
+// group by Esql.target_user_name
+| stats Esql.alerts_count = COUNT(*),
+        Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
+        Esql.event_module_values = VALUES(event.module),
+        Esql.message_values = VALUES(message),
+        Esql.event_action_values = VALUES(event.action),
+        Esql.process_executable_values = VALUES(process.executable),
+        Esql.host_id_values = VALUES(host.id),
+        Esql.source_user_name = VALUES(source.user.name),
+        Esql.rule_name_values = VALUES(rule.name)
+        by Esql.target_user_name
+// alert when same user is observed in an endpoint and email alert
+| where Esql.event_module_distinct_count >= 2
+| keep Esql.alerts_count, Esql.event_module_values, Esql.host_id_values, Esql.source_user_name, Esql.target_user_name, Esql.message_values, Esql.rule_name_values, Esql.event_action_values
+'''
+note = """## Triage and analysis
+### Investigating Elastic Defend and Email Alerts Correlation
+
+This rule correlates any Elastic Defend alert with an email security related alert by target user name.
+
+### Possible investigation steps
+- Review the alert details to identify the specific host and users involved.
+- Investigate the individual alerts for the target user name and see if they are related.
+- Review all emails received from Esql.source_user_name and if there are other impacted users.
+- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
+- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
+
+### False positive analysis
+- Legitimate email marked as suspicious.
+- Legitimate file or behavior marked as suspicious by Elastic Defend.
+- Unrelated alerts where the target user name is too generic.
+
+### Response and remediation
+- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
+- Conduct a thorough forensic analysis of the host.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
+- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign."""

nldcsc_elastic_rules/rules/cross-platform/multiple_alerts_involving_user.toml

@@ -0,0 +1,82 @@
+[metadata]
+creation_date = "2022/11/16"
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts
+can use this to prioritize triage and response, as these users are more likely to be compromised.
+"""
+false_positives = [
+    """
+    False positives can occur with Generic built-in accounts, such as Administrator, admin, etc. if they are widespread
+    used in your environment. As a best practice, they shouldn't be used in day-to-day tasks, as it prevents the ability
+    to quickly identify and contact the account owner to find out if an alert is a planned activity, regular business
+    activity, or an upcoming incident.
+    """,
+]
+from = "now-24h"
+index = [".alerts-security.*"]
+interval = "1h"
+language = "kuery"
+license = "Elastic License v2"
+name = "Multiple Alerts Involving a User"
+risk_score = 73
+rule_id = "0d160033-fab7-4e72-85a3-3a9d80c8bff7"
+severity = "high"
+tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+signal.rule.name:* and user.name:* and not user.id:("S-1-5-18" or "S-1-5-19" or "S-1-5-20")
+'''
+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 Multiple Alerts Involving a User
+
+In security environments, monitoring user activity is crucial as adversaries often exploit user accounts to gain unauthorized access. Attackers may trigger multiple alerts by performing suspicious actions under a compromised user account. The detection rule identifies such patterns by correlating diverse alerts linked to the same user, excluding known system accounts, thus prioritizing potential threats for analysts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user account involved, focusing on the user.name field to gather initial context about the user.
+- Examine the timeline and sequence of the triggered alerts to understand the pattern of activity associated with the user, noting any unusual or unexpected actions.
+- Cross-reference the user activity with known legitimate activities or scheduled tasks to rule out false positives, ensuring that the actions are not part of normal operations.
+- Investigate the source and destination IP addresses associated with the alerts to identify any suspicious or unauthorized access points.
+- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts.
+- Look into any recent login attempts or authentication failures for the user account to detect potential brute force or credential stuffing attacks.
+- Collaborate with the user or their manager to verify if the activities were authorized or if the account might be compromised.
+
+### False positive analysis
+
+- Alerts triggered by automated system processes or scripts that mimic user behavior can be false positives. To manage these, identify and exclude known benign scripts or processes from the rule.
+- Frequent alerts from users in roles that inherently require access to multiple systems or sensitive data, such as IT administrators, may not indicate compromise. Implement role-based exceptions to reduce noise.
+- Alerts generated by legitimate software updates or maintenance activities can be mistaken for suspicious behavior. Schedule these activities during known maintenance windows and exclude them from the rule during these times.
+- Users involved in testing or development environments may trigger multiple alerts due to their work nature. Create exceptions for these environments to prevent unnecessary alerts.
+- High-volume users, such as those in customer support or sales, may naturally generate more alerts. Monitor these users separately and adjust the rule to focus on unusual patterns rather than volume alone.
+
+### Response and remediation
+
+- Isolate the affected user account immediately to prevent further unauthorized access. Disable the account or change the password to stop any ongoing malicious activity.
+- Conduct a thorough review of the affected user's recent activities and access logs to identify any unauthorized actions or data access. This will help in understanding the scope of the compromise.
+- Remove any malicious software or unauthorized tools that may have been installed on the user's system. Use endpoint detection and response (EDR) tools to scan and clean the system.
+- Restore any altered or deleted data from backups, ensuring that the restored data is free from any malicious modifications.
+- Notify relevant stakeholders, including IT security teams and management, about the incident and the steps being taken to address it. This ensures that everyone is aware and can provide support if needed.
+- Implement additional monitoring on the affected user account and related systems to detect any further suspicious activities. This includes setting up alerts for unusual login attempts or data access patterns.
+- Review and update access controls and permissions for the affected user and similar accounts to prevent future incidents. Ensure that least privilege principles are applied."""
+
+
+
+[rule.threshold]
+field = ["user.name"]
+value = 1
+[[rule.threshold.cardinality]]
+field = "signal.rule.rule_id"
+value = 5
+
+

nldcsc_elastic_rules/rules/cross-platform/multiple_alerts_risky_host_esql.toml

@@ -0,0 +1,105 @@
+[metadata]
+creation_date = "2025/11/19"
+maturity = "production"
+updated_date = "2025/11/19"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are
+triggered and where the accumulated risk score is higher than a defined threshold. Analysts can use this to prioritize
+triage and response, as these hosts are more likely to be compromised.
+"""
+from = "now-8h"
+interval = "1h"
+language = "esql"
+license = "Elastic License v2"
+name = "Alerts in Different ATT&CK Tactics by Host"
+risk_score = 73
+rule_id = "29531d20-0e80-41d4-9ec6-d6b58e4a475c"
+severity = "high"
+tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from .alerts-security.*  metadata _id
+
+// filter for alerts with populated risk score, excluding threat_match rules, deprecated and some other noisy ones.
+| where kibana.alert.risk_score > 0 and
+        kibana.alert.rule.name IS NOT NULL and
+        host.id is not null and event.dataset is not null and
+        kibana.alert.rule.type != "threat_match" and
+        not kibana.alert.rule.name in ("Agent Spoofing - Mismatched Agent ID") and
+        not kibana.alert.rule.name like "Deprecated - *"
+
+// extract unique counts and values by host.id
+| stats Esql.alerts_count = COUNT(*),
+        Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
+        Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
+        Esql.event_module_values = VALUES(event.module),
+        Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name),
+        Esql.threat_tactic_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.threat.tactic.id),
+        Esql.threat_tactic_name_values = VALUES(kibana.alert.rule.threat.tactic.name),
+        Esql.kibana_alert_risk_score_sum = sum(kibana.alert.risk_score),
+        Esql.process_executable_values = VALUES(process.executable),
+        Esql.process_parent_executable_values = VALUES(process.parent.executable),
+        Esql.process_command_line_values = VALUES(process.command_line),
+        Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id
+
+// divide the sum of risk scores by the total number of alerts
+| eval Esql.risk_alerts_count_ratio = Esql.kibana_alert_risk_score_sum/Esql.alerts_count
+
+// filter for risky hosts by risk score and unique count of rules and tactics
+| where Esql.kibana_alert_rule_name_distinct_count >= 5 and Esql.threat_tactic_id_distinct_count >= 3 and Esql.threat_tactic_id_distinct_count >= 3 and Esql.alerts_count <= 500 and Esql.risk_alerts_count_ratio >= 50
+
+// fiels populated in the resulting alert
+| keep host.id,
+       Esql.alerts_count,
+       Esql.kibana_alert_risk_score_sum,
+       Esql.risk_alerts_count_ratio,
+       Esql.kibana_alert_rule_name_distinct_count,
+       Esql.event_module_values,
+       Esql.kibana_alert_rule_name_values,
+       Esql.threat_tactic_name_values,
+       Esql.process_executable_values,
+       Esql.process_parent_executable_values,
+       Esql.process_command_line_values
+'''
+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 Alerts in Different ATT&CK Tactics by Host
+
+The detection rule identifies hosts with alerts across various attack phases, indicating potential compromise. Adversaries exploit system vulnerabilities, moving through different tactics like execution, persistence, and exfiltration. This rule prioritizes hosts with diverse tactic alerts, aiding analysts in focusing on high-risk threats by correlating alert data to detect complex attack patterns.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts.
+- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
+- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
+- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
+- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
+- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
+
+### False positive analysis
+
+- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.
+- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
+- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
+- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
+- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.
+
+### Response and remediation
+
+- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
+- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
+- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign."""
+
+

nldcsc_elastic_rules/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml

@@ -0,0 +1,141 @@
+[metadata]
+creation_date = "2020/12/21"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Adversaries may modify the standard authentication module for persistence via patching the normal authorization process
+or modifying the login configuration to allow unauthorized access or elevate privileges.
+"""
+false_positives = [
+    "Trusted system module updates or allowed Pluggable Authentication Module (PAM) daemon configuration changes.",
+]
+from = "now-9m"
+index = ["auditbeat-*", "logs-endpoint.events.*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Modification of Standard Authentication Module or Configuration"
+references = [
+    "https://github.com/zephrax/linux-pam-backdoor",
+    "https://github.com/eurialo/pambd",
+    "http://0x90909090.blogspot.com/2016/06/creating-backdoor-in-pam-in-5-line-of.html",
+    "https://www.trendmicro.com/en_us/research/19/i/skidmap-linux-malware-uses-rootkit-capabilities-to-hide-cryptocurrency-mining-payload.html",
+]
+risk_score = 47
+rule_id = "93f47b6f-5728-4004-ba00-625083b3dcb0"
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: macOS",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Tactic: Persistence",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.category:file and event.type:change and
+  (file.name:pam_*.so or file.path:(/etc/pam.d/* or /private/etc/pam.d/* or /usr/lib64/security/*)) and
+  process.executable:
+    (* and
+      not
+      (
+        /usr/libexec/packagekitd or
+        /usr/bin/vim or
+        /usr/libexec/xpcproxy or
+        /usr/bin/bsdtar or
+        /usr/local/bin/brew or
+        "/System/Library/PrivateFrameworks/PackageKit.framework/Versions/A/XPCServices/package_script_service.xpc/Contents/MacOS/package_script_service"
+      )
+    ) and
+  not file.path:
+         (
+           /tmp/snap.rootfs_*/pam_*.so or
+           /tmp/newroot/lib/*/pam_*.so or
+           /private/var/folders/*/T/com.apple.fileprovider.ArchiveService/TemporaryItems/*/lib/security/pam_*.so or
+           /tmp/newroot/usr/lib64/security/pam_*.so
+         ) and
+  not process.name:
+         (
+           yum or dnf or rsync or platform-python or authconfig or rpm or pdkg or apk or dnf-automatic or btrfs or
+           dpkg or pam-auth-update or steam or platform-python3.6 or pam-config or microdnf or yum_install or yum-cron or
+           systemd or containerd or pacman
+         )
+'''
+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 Modification of Standard Authentication Module or Configuration
+
+Authentication modules, such as PAM (Pluggable Authentication Modules), are crucial for managing user authentication in Linux and macOS environments. Adversaries may exploit these by altering module files or configurations to gain unauthorized access or escalate privileges. The detection rule identifies suspicious changes to these modules, excluding legitimate processes and paths, to flag potential unauthorized modifications.
+
+### Possible investigation steps
+
+- Review the specific file that triggered the alert by examining the file.name and file.path fields to determine if it is a known authentication module or configuration file.
+- Investigate the process that made the change by analyzing the process.executable field to identify if it is a legitimate process or potentially malicious.
+- Check the process.name field to see if the process is one of the excluded legitimate processes, which might indicate a false positive.
+- Look into recent system changes or updates that might have affected authentication modules, focusing on the time frame around the alert.
+- Correlate the alert with other security events or logs to identify any related suspicious activities or patterns, such as unauthorized access attempts or privilege escalation.
+- Verify the integrity of the affected authentication module or configuration file by comparing it with a known good version or using file integrity monitoring tools.
+
+### False positive analysis
+
+- Package management operations such as updates or installations can trigger false positives. Exclude processes like yum, dnf, rpm, and dpkg from the detection rule to prevent these benign activities from being flagged.
+- System maintenance tasks often involve legitimate changes to authentication modules. Exclude processes like authconfig, pam-auth-update, and pam-config to avoid false alerts during routine maintenance.
+- Development and testing environments may frequently modify authentication modules for testing purposes. Consider excluding paths like /tmp/snap.rootfs_*/pam_*.so and /tmp/newroot/lib/*/pam_*.so to reduce noise from these environments.
+- Backup and synchronization tools such as rsync can cause false positives when they interact with authentication module files. Exclude rsync from the detection rule to prevent these non-threatening activities from being flagged.
+- Containerized environments may have different paths and processes that interact with authentication modules. Exclude processes like containerd and paths like /tmp/newroot/usr/lib64/security/pam_*.so to account for these variations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Conduct a thorough review of the modified authentication module or configuration file to identify unauthorized changes and revert them to their original state using a known good backup.
+- Reset passwords for all user accounts on the affected system, prioritizing accounts with elevated privileges, to mitigate potential credential compromise.
+- Perform a comprehensive scan of the system for additional indicators of compromise, such as unauthorized user accounts or scheduled tasks, and remove any malicious artifacts found.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected.
+- Implement enhanced monitoring on the affected system and similar environments to detect any future unauthorized modifications to authentication modules or configurations.
+- Review and update access controls and authentication policies to strengthen security measures and reduce the risk of similar attacks in the future."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1543"
+name = "Create or Modify System Process"
+reference = "https://attack.mitre.org/techniques/T1543/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1556"
+name = "Modify Authentication Process"
+reference = "https://attack.mitre.org/techniques/T1556/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["host.id", "process.executable", "file.path"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-7d"
+
+

nldcsc_elastic_rules/rules/cross-platform/persistence_shell_profile_modification.toml

@@ -0,0 +1,107 @@
+[metadata]
+creation_date = "2021/01/19"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Both ~/.bash_profile and ~/.bashrc are files containing shell commands that are run when Bash is invoked. These files
+are executed in a user's context, either interactively or non-interactively, when a user logs in so that their
+environment is set correctly. Adversaries may abuse this to establish persistence by executing malicious content
+triggered by a user’s shell.
+"""
+false_positives = ["Changes to the Shell Profile tend to be noisy, a tuning per your environment will be required."]
+from = "now-9m"
+index = ["logs-endpoint.events.*", "auditbeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Bash Shell Profile Modification"
+references = ["https://www.anomali.com/blog/pulling-linux-rabbit-rabbot-malware-out-of-a-hat"]
+risk_score = 47
+rule_id = "e6c1a552-7776-44ad-ae0f-8746cc07773c"
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: macOS",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Persistence",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.category:file and event.type:change and
+  process.name:(* and not (sudo or vim or zsh or env or nano or bash or Terminal or xpcproxy or login or cat or cp or
+  launchctl or java or dnf or tailwatchd or ldconfig or yum or semodule or cpanellogd or dockerd or authselect or chmod or
+  dnf-automatic or git or dpkg or platform-python)) and
+  not process.executable:(/Applications/* or /private/var/folders/* or /usr/local/* or /opt/saltstack/salt/bin/*) and
+  file.path:(/private/etc/rc.local or
+             /etc/rc.local or
+             /home/*/.profile or
+             /home/*/.profile1 or
+             /home/*/.bash_profile or
+             /home/*/.bash_profile1 or
+             /home/*/.bashrc or
+             /Users/*/.bash_profile or
+             /Users/*/.zshenv)
+'''
+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 Bash Shell Profile Modification
+
+Bash shell profiles, such as `.bash_profile` and `.bashrc`, are scripts that configure user environments upon login. Adversaries exploit these by inserting malicious commands to ensure persistence, executing harmful scripts whenever a user initiates a shell session. The detection rule identifies unauthorized modifications by monitoring file changes and filtering out benign processes, focusing on unusual executables and paths to flag potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path that was modified, focusing on paths like /home/*/.bash_profile or /home/*/.bashrc.
+- Examine the process name and executable that triggered the alert to determine if it is an unusual or unauthorized process, as specified in the query.
+- Check the modification timestamp of the affected file to correlate with any known user activity or scheduled tasks.
+- Investigate the contents of the modified Bash shell profile file to identify any suspicious or unexpected commands or scripts.
+- Cross-reference the user account associated with the modified file to determine if the activity aligns with their typical behavior or if the account may be compromised.
+- Look for any related alerts or logs around the same timeframe that might indicate a broader attack or persistence mechanism.
+
+### False positive analysis
+
+- Frequent use of text editors like vim or nano may trigger alerts when users legitimately modify their shell profiles. To mitigate this, consider excluding these processes from the detection rule if they are commonly used in your environment.
+- Automated system updates or configuration management tools like dnf or yum might modify shell profiles as part of their operations. Exclude these processes if they are verified as part of routine maintenance.
+- Development tools such as git or platform-python may alter shell profiles during setup or updates. If these tools are regularly used, add them to the exclusion list to prevent false positives.
+- User-specific applications located in directories like /Applications or /usr/local may be flagged if they modify shell profiles. Verify these applications and exclude their paths if they are trusted and frequently used.
+- Consider excluding specific user directories from monitoring if they are known to contain benign scripts that modify shell profiles, ensuring these exclusions are well-documented and reviewed regularly.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified in the alert that are not part of the allowed list, such as unauthorized executables modifying shell profiles.
+- Restore the modified shell profile files (.bash_profile, .bashrc) from a known good backup to remove any malicious entries.
+- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred.
+- Implement file integrity monitoring on critical shell profile files to detect and alert on future unauthorized changes.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Review and update endpoint protection policies to enhance detection capabilities for similar persistence techniques, leveraging MITRE ATT&CK framework references for T1546."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1546"
+name = "Event Triggered Execution"
+reference = "https://attack.mitre.org/techniques/T1546/"
+[[rule.threat.technique.subtechnique]]
+id = "T1546.004"
+name = "Unix Shell Configuration Modification"
+reference = "https://attack.mitre.org/techniques/T1546/004/"
+
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+