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

nldcsc_elastic_rules/rules/linux/credential_access_ssh_password_grabbing_via_strace.toml

@@ -0,0 +1,100 @@
+[metadata]
+creation_date = "2025/11/10"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/11/24"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects potential SSH password grabbing via the use of strace on sshd processes. Attackers may use strace to capture
+sensitive information, such as passwords, by tracing system calls made by the sshd process. This rule looks for a sequence
+of events where an sshd process ends followed closely by the start of a strace process. This may be indicative of an attacker
+attempting to capture SSH credentials.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential SSH Password Grabbing via strace"
+note = """
+## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Potential SSH Password Grabbing via strace
+
+This detection flags a suspicious sequence where an sshd process stops and a strace process starts seconds later, indicating attempted snooping of SSH authentication. Capturing syscall activity around login exposes passwords and session secrets, enabling credential theft and lateral movement. Attackers kill sshd, then relaunch or attach with strace, logging read/write and open calls from PAM or keyboard-interactive flows to a file such as /tmp/sshd.trace.
+
+### Possible investigation steps
+
+- Pull the strace command-line, full path, parent chain, invoking user, and working directory to confirm whether it attached to sshd and whether output was directed to a file.
+- Correlate systemd/journald and audit logs around the same seconds for sshd stop/start, kill signals, coredumps, or admin actions to distinguish debugging from credential capture.
+- Identify and preserve any strace output or redirected logs (common in /tmp or home directories) and scan for PAM interactions or TTY reads containing password prompts.
+- Check ptrace feasibility by verifying UID relationships, CAP_SYS_PTRACE, SELinux/AppArmor policies, and ptrace_scope to assess whether sshd could be traced.
+- Pivot on the same user and host for adjacent activity such as restarting sshd, running ltrace/gdb/perf, modifying PAM or sshd_config, and creating trace files to gauge intent.
+
+### False positive analysis
+
+- An administrator intentionally stops sshd and immediately launches strace to troubleshoot a configuration change or startup problem, tracing a controlled test run rather than attempting to capture credentials.
+- A normal sshd session process ends while strace is started to debug an unrelated application, producing a near-simultaneous end/start sequence even though strace is not attached to sshd or capturing authentication input.
+
+### Response and remediation
+
+- Immediately kill active strace processes targeting sshd (e.g., strace -p PID or strace -f /usr/sbin/sshd with -o /tmp/sshd.trace), isolate the host from the network, and restart the sshd service to restore a clean state.
+- Preserve forensic copies, then remove artifacts such as trace outputs like /tmp/sshd.trace or ~/sshd.strace.log, purge unauthorized strace wrappers or cron entries, and revert changes in /etc/ssh/sshd_config and /etc/pam.d/*.
+- Force credential hygiene by expiring passwords for users who logged in during the suspected window, rotating SSH host keys in /etc/ssh/ (ssh_host_*), revoking recently added ~/.ssh/authorized_keys entries, and terminating lingering sshd child sessions and SSH agents in /tmp or /run.
+- Escalate to incident response if strace was executed as root or via sudo against /usr/sbin/sshd, if CAP_SYS_PTRACE or ptrace_scope=0 was present, if trace files contain password strings or PAM conversation data, or if similar behavior appears on more than one host.
+- Harden by setting /proc/sys/kernel/yama/ptrace_scope to 1 or 2, enforcing SELinux/AppArmor policies that block ptrace to sshd, disabling PasswordAuthentication or requiring MFA in /etc/ssh/sshd_config, and adding auditd rules to alert on ptrace attaches to /usr/sbin/sshd.
+
+"""
+references = [
+    "https://github.com/braindead-sec/ssh-grabber",
+    "https://dfir.ch/posts/strace/",
+]
+risk_score = 47
+rule_id = "9eaa3fb1-3f70-48ed-bb0e-d7ae4d3c8f28"
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Persistence",
+    "Tactic: Credential Access",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+sequence by host.id with maxspan=3s
+  [process where host.os.type == "linux" and event.type == "end" and process.name == "sshd"]
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "strace"]
+'''
+
+[[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.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1554"
+name = "Compromise Host Software Binary"
+reference = "https://attack.mitre.org/techniques/T1554/"
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"

nldcsc_elastic_rules/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml

@@ -0,0 +1,212 @@
+[metadata]
+creation_date = "2024/08/22"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/09/29"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule identifies potentially malicious processes attempting to access the cloud service provider's instance metadata
+service (IMDS) API endpoint, which can be used to retrieve sensitive instance-specific information such as instance ID,
+public IP address, and even temporary security credentials if role's are assumed by that instance. The rule monitors for
+various tools and scripts like curl, wget, python, and perl that might be used to interact with the metadata API.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Unusual Instance Metadata Service (IMDS) API Request"
+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 Unusual Instance Metadata Service (IMDS) API Request
+
+The Instance Metadata Service (IMDS) API provides essential instance-specific data, including configuration details and temporary credentials, to applications running on cloud instances. Adversaries exploit this by using scripts or tools to access sensitive data, potentially leading to unauthorized access. The detection rule identifies suspicious access attempts by monitoring specific processes and network activities, excluding known legitimate paths, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the process details such as process.name and process.command_line to identify the tool or script used to access the IMDS API and determine if it aligns with known malicious behavior.
+- Examine the process.executable and process.working_directory fields to verify if the execution path is unusual or suspicious, especially if it originates from directories like /tmp/* or /var/tmp/*.
+- Check the process.parent.entity_id and process.parent.executable to understand the parent process and its legitimacy, which might provide context on how the suspicious process was initiated.
+- Investigate the network event details, particularly the destination.ip field, to confirm if there was an attempted connection to the IMDS API endpoint at 169.254.169.254.
+- Correlate the host.id with other security events or logs to identify any additional suspicious activities or patterns on the same host that might indicate a broader compromise.
+- Assess the risk score and severity to prioritize the investigation and determine if immediate action is required to mitigate potential threats.
+
+### False positive analysis
+
+- Security and monitoring tools like Rapid7, Nessus, and Amazon SSM Agent may trigger false positives due to their legitimate access to the IMDS API. Users can exclude these by adding their working directories to the exception list.
+- Automated scripts or processes running from known directories such as /opt/rumble/bin or /usr/share/ec2-instance-connect may also cause false positives. Exclude these directories or specific executables from the rule to prevent unnecessary alerts.
+- System maintenance or configuration scripts that access the IMDS API for legitimate purposes might be flagged. Identify these scripts and add their paths or parent executables to the exclusion list to reduce noise.
+- Regular network monitoring tools that attempt connections to the IMDS IP address for health checks or status updates can be excluded by specifying their process names or executable paths in the exception criteria.
+
+### Response and remediation
+
+- Immediately isolate the affected instance from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified in the alert that are attempting to access the IMDS API, especially those using tools like curl, wget, or python.
+- Revoke any temporary credentials that may have been exposed or accessed through the IMDS API to prevent unauthorized use.
+- Conduct a thorough review of the instance's security groups and IAM roles to ensure that only necessary permissions are granted and that there are no overly permissive policies.
+- Escalate the incident to the security operations team for further investigation and to determine if additional instances or resources are affected.
+- Implement network monitoring to detect and alert on any future attempts to access the IMDS API from unauthorized processes or locations.
+- Review and update the instance's security configurations and apply any necessary patches or updates to mitigate vulnerabilities that could be exploited in similar attacks."""
+references = [
+    "https://hackingthe.cloud/aws/general-knowledge/intro_metadata_service/",
+    "https://www.wiz.io/blog/imds-anomaly-hunting-zero-day",
+]
+risk_score = 47
+rule_id = "ecc0cd54-608e-11ef-ab6d-f661ea17fbce"
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "Domain: Cloud",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Tactic: Discovery",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+type = "eql"
+
+query = '''
+sequence by host.id, process.parent.entity_id with maxspan=3s
+[
+    process
+    where host.os.type == "linux"
+        and event.type == "start"
+        and event.action == "exec"
+        and process.parent.executable != null
+
+        // common tooling / suspicious names (keep broad)
+        and (
+            process.name : (
+                "curl", "wget", "python*", "perl*", "php*", "ruby*", "lua*", "telnet", "pwsh",
+                "openssl", "nc", "ncat", "netcat", "awk", "gawk", "mawk", "nawk", "socat", "node",
+                "bash", "sh"
+            )
+            or
+            // suspicious execution locations (dropped binaries / temp execution)
+            process.executable : (
+                "./*", "/tmp/*", "/var/tmp/*", "/var/www/*", "/dev/shm/*", "/etc/init.d/*", "/etc/rc*.d/*",
+                "/etc/cron*", "/etc/update-motd.d/*", "/boot/*", "/srv/*", "/run/*", "/etc/rc.local"
+            )
+            or
+            // threat-relevant IMDS / metadata endpoints (inclusion list)
+            process.command_line : (
+                "*169.254.169.254/latest/api/token*",
+                "*169.254.169.254/latest/meta-data/iam/security-credentials*",
+                "*169.254.169.254/latest/meta-data/local-ipv4*",
+                "*169.254.169.254/latest/meta-data/local-hostname*",
+                "*169.254.169.254/latest/meta-data/public-ipv4*",
+                "*169.254.169.254/latest/user-data*",
+                "*169.254.169.254/latest/dynamic/instance-identity/document*",
+                "*169.254.169.254/latest/meta-data/instance-id*",
+                "*169.254.169.254/latest/meta-data/public-keys*",
+                "*computeMetadata/v1/instance/service-accounts/*/token*",
+                "*/metadata/identity/oauth2/token*",
+                "*169.254.169.254/opc/v*/instance*",
+                "*169.254.169.254/opc/v*/vnics*"
+            )
+        )
+
+        // global working-dir / executable / parent exclusions for known benign agents
+        and not process.working_directory : (
+            "/opt/rapid7*",
+            "/opt/nessus*",
+            "/snap/amazon-ssm-agent*",
+            "/var/snap/amazon-ssm-agent/*",
+            "/var/log/amazon/ssm/*",
+            "/srv/snp/docker/overlay2*",
+            "/opt/nessus_agent/var/nessus/*"
+        )
+
+        and not process.executable : (
+            "/opt/rumble/bin/rumble-agent*",
+            "/opt/aws/inspector/bin/inspectorssmplugin",
+            "/snap/oracle-cloud-agent/*",
+            "/lusr/libexec/oracle-cloud-agent/*"
+        )
+
+        and not process.parent.executable : (
+            "/usr/bin/setup-policy-routes",
+            "/usr/share/ec2-instance-connect/*",
+            "/var/lib/amazon/ssm/*",
+            "/etc/update-motd.d/30-banner",
+            "/usr/sbin/dhclient-script",
+            "/usr/local/bin/uwsgi",
+            "/usr/lib/skylight/al-extras",
+            "/usr/bin/cloud-init",
+            "/usr/sbin/waagent",
+            "/usr/bin/google_osconfig_agent",
+            "/usr/bin/docker",
+            "/usr/bin/containerd-shim",
+            "/usr/bin/runc"
+        )
+
+        and not process.entry_leader.executable : (
+            "/usr/local/qualys/cloud-agent/bin/qualys-cloud-agent",
+            "/opt/Elastic/Agent/data/elastic-agent-*/elastic-agent",
+            "/opt/nessus_agent/sbin/nessus-service"
+        )
+
+        // carve-out: safe /usr/bin/curl usage (suppress noisy, legitimate agent patterns)
+        and not (
+            process.executable == "/usr/bin/curl"
+            and (
+                // AWS IMDSv2 token PUT that includes ttl header
+                (process.command_line : "*-X PUT*169.254.169.254/latest/api/token*" and process.command_line : "*X-aws-ec2-metadata-token-ttl-seconds*")
+                or
+                // Any IMDSv2 GET that includes token header for any /latest/* path
+                process.command_line : "*-H X-aws-ec2-metadata-token:*169.254.169.254/latest/*"
+                or
+                // Common amazon tooling UA
+                process.command_line : "*-A amazon-ec2-net-utils/*"
+                or
+                // Azure metadata legitimate header
+                process.command_line : "*-H Metadata:true*169.254.169.254/metadata/*"
+                or
+                // Oracle IMDS legitimate header
+                process.command_line : "*-H Authorization:*Oracle*169.254.169.254/opc/*"
+            )
+        )
+]
+[
+    network where host.os.type == "linux"
+        and event.action == "connection_attempted"
+        and destination.ip == "169.254.169.254"
+]
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1552"
+name = "Unsecured Credentials"
+reference = "https://attack.mitre.org/techniques/T1552/"
+[[rule.threat.technique.subtechnique]]
+id = "T1552.005"
+name = "Cloud Instance Metadata API"
+reference = "https://attack.mitre.org/techniques/T1552/005/"
+
+
+
+[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 = "T1580"
+name = "Cloud Infrastructure Discovery"
+reference = "https://attack.mitre.org/techniques/T1580/"
+
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+

nldcsc_elastic_rules/rules/linux/defense_evasion_acl_modification_via_setfacl.toml

@@ -0,0 +1,105 @@
+[metadata]
+creation_date = "2024/08/23"
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = "This rule detects Linux Access Control List (ACL) modification via the setfacl command.\n"
+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 = "Access Control List Modification via setfacl"
+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 Access Control List Modification via setfacl
+
+Access Control Lists (ACLs) in Linux enhance file permission management by allowing more granular access control. The `setfacl` command modifies these ACLs, potentially altering who can access or modify files. Adversaries may exploit `setfacl` to stealthily change permissions, evading detection and maintaining persistence. The detection rule identifies suspicious `setfacl` executions, excluding benign patterns, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of the setfacl command, focusing on the process.name and event.type fields to ensure the alert is valid.
+- Examine the process.command_line to understand the specific ACL modifications attempted and identify any unusual or unauthorized changes.
+- Investigate the user account associated with the process execution to determine if the action aligns with their typical behavior or role.
+- Check the process's parent process to identify how the setfacl command was initiated and assess if it was part of a legitimate workflow or a potential compromise.
+- Correlate the event with other security logs or alerts from the same host to identify any related suspicious activities or patterns that might indicate a broader attack.
+
+### False positive analysis
+
+- Routine system maintenance tasks may trigger the rule if they involve legitimate use of setfacl. To manage this, identify and document regular maintenance scripts or processes that use setfacl and create exceptions for these specific command lines.
+- Backup operations that restore ACLs using setfacl can be mistaken for suspicious activity. Exclude these by adding exceptions for command lines that match known backup procedures, such as those using the --restore option.
+- Automated log management tools might use setfacl to manage permissions on log directories like /var/log/journal/. To prevent false positives, exclude these specific directory paths from triggering the rule.
+- Custom applications or services that require dynamic permission changes using setfacl could be flagged. Review these applications and, if deemed safe, add their specific command patterns to the exception list to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or changes.
+- Review the process execution logs to identify any unauthorized users or processes that executed the `setfacl` command.
+- Revert any unauthorized ACL changes by restoring the original file permissions from a known good backup or configuration.
+- Conduct a thorough scan of the system for any additional signs of compromise, such as unauthorized user accounts or unexpected processes.
+- Update and patch the system to address any vulnerabilities that may have been exploited to gain access.
+- Implement stricter access controls and monitoring on critical systems to detect and prevent unauthorized ACL modifications in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected."""
+references = [
+    "https://www.uptycs.com/blog/threat-research-report-team/evasive-techniques-used-by-malicious-linux-shell-scripts",
+]
+risk_score = 21
+rule_id = "999565a2-fc52-4d72-91e4-ba6712c0377e"
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "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 == "setfacl" and not (
+  process.command_line == "/bin/setfacl --restore=-" or
+  process.args == "/var/log/journal/" or
+  process.parent.name in ("stats.pl", "perl", "find") or
+  process.parent.command_line like~ "/bin/sh -c *ansible*"
+)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1222"
+name = "File and Directory Permissions Modification"
+reference = "https://attack.mitre.org/techniques/T1222/"
+[[rule.threat.technique.subtechnique]]
+id = "T1222.002"
+name = "Linux and Mac File and Directory Permissions Modification"
+reference = "https://attack.mitre.org/techniques/T1222/002/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml

@@ -0,0 +1,127 @@
+[metadata]
+creation_date = "2024/08/28"
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Adversaries may attempt to disable the Auditd service to evade detection. Auditd is a Linux service that provides system
+auditing and logging. Disabling the Auditd service can prevent the system from logging important security events, which
+can be used to detect malicious activity.
+"""
+from = "now-9m"
+index = [
+    "logs-endpoint.events.process*",
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Attempt to Disable Auditd Service"
+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 Attempt to Disable Auditd Service
+
+Auditd is a critical Linux service responsible for system auditing and logging, capturing security-relevant events. Adversaries may target this service to evade detection by disabling it, thus preventing the logging of their activities. The detection rule identifies suspicious processes attempting to stop or disable Auditd, such as using commands like `service stop` or `systemctl disable`, signaling potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the process details to identify the user account associated with the suspicious command execution, focusing on the process fields such as process.name and process.args.
+- Check the system logs for any preceding or subsequent suspicious activities around the time of the alert, particularly looking for other defense evasion tactics or unauthorized access attempts.
+- Investigate the command history of the user identified to determine if there are any other unauthorized or suspicious commands executed.
+- Verify the current status of the Auditd service on the affected host to ensure it is running and properly configured.
+- Correlate the alert with any other security events or alerts from the same host or user to identify potential patterns or broader attack campaigns.
+
+### False positive analysis
+
+- System administrators may intentionally stop or disable the Auditd service during maintenance or troubleshooting. To handle this, create exceptions for known maintenance windows or specific administrator accounts.
+- Automated scripts or configuration management tools might stop or disable Auditd as part of routine system updates or deployments. Identify these scripts and whitelist their activities to prevent false alerts.
+- Some Linux distributions or custom setups might have alternative methods for managing services that could trigger this rule. Review and adjust the detection criteria to align with the specific service management practices of your environment.
+- In environments where Auditd is not used or is replaced by another logging service, the rule might trigger unnecessarily. Consider disabling the rule or adjusting its scope in such cases.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary.
+- Terminate any suspicious processes identified in the alert that are attempting to disable the Auditd service to stop the adversary's actions.
+- Re-enable and restart the Auditd service on the affected system to ensure that auditing and logging are resumed, capturing any further suspicious activities.
+- Conduct a thorough review of the system logs and audit records to identify any unauthorized changes or additional indicators of compromise that may have occurred prior to the alert.
+- Apply any necessary security patches or updates to the affected system to address vulnerabilities that may have been exploited by the adversary.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.
+- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts to disable critical security services."""
+risk_score = 21
+rule_id = "6a058ed6-4e9f-49f3-8f8e-f32165ae7ebf"
+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: Defense Evasion",
+    "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 == "service" and process.args == "stop") or
+  (process.name == "chkconfig" and process.args == "off") or
+  (process.name == "systemctl" and process.args in ("disable", "stop", "kill"))
+) and
+process.args in ("auditd", "auditd.service") and 
+not process.parent.name == "auditd.prerm"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.001"
+name = "Disable or Modify Tools"
+reference = "https://attack.mitre.org/techniques/T1562/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+