Potential Disabling of AppArmor

This rule monitors for potential attempts to disable AppArmor. AppArmor is a Linux security module that enforces fine-grained access control policies to restrict the actions and resources that specific applications and processes can access. Adversaries may disable security tools to avoid possible detection of their tools and activities.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2023/08/28"
  3integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
  4maturity = "production"
  5min_stack_version = "8.13.0"
  6min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
  7updated_date = "2025/01/15"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule monitors for potential attempts to disable AppArmor. AppArmor is a Linux security module that enforces
 13fine-grained access control policies to restrict the actions and resources that specific applications and processes can
 14access. Adversaries may disable security tools to avoid possible detection of their tools and activities.
 15"""
 16from = "now-9m"
 17index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 18language = "eql"
 19license = "Elastic License v2"
 20name = "Potential Disabling of AppArmor"
 21risk_score = 21
 22rule_id = "fac52c69-2646-4e79-89c0-fd7653461010"
 23setup = """## Setup
 24
 25This rule requires data coming in from Elastic Defend.
 26
 27### Elastic Defend Integration Setup
 28Elastic 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.
 29
 30#### Prerequisite Requirements:
 31- Fleet is required for Elastic Defend.
 32- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 33
 34#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 35- Go to the Kibana home page and click "Add integrations".
 36- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 37- Click "Add Elastic Defend".
 38- Configure the integration name and optionally add a description.
 39- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 40- 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).
 41- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 42- 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.
 43For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 44- Click "Save and Continue".
 45- 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.
 46For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 47"""
 48severity = "low"
 49tags = [
 50    "Domain: Endpoint",
 51    "OS: Linux",
 52    "Use Case: Threat Detection",
 53    "Tactic: Defense Evasion",
 54    "Data Source: Elastic Defend",
 55    "Data Source: Elastic Endgame",
 56    "Data Source: Auditd Manager",
 57    "Data Source: Crowdstrike",
 58    "Data Source: SentinelOne",
 59    "Resources: Investigation Guide",
 60]
 61timestamp_override = "event.ingested"
 62type = "eql"
 63query = '''
 64process where host.os.type == "linux" and event.type == "start" and
 65 event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
 66 (
 67  (process.name == "systemctl" and process.args in ("stop", "disable", "kill") and process.args in ("apparmor", "apparmor.service")) or
 68  (process.name == "service" and process.args == "apparmor" and process.args == "stop") or
 69  (process.name == "chkconfig" and process.args == "apparmor" and process.args == "off") or
 70  (process.name == "ln" and process.args : "/etc/apparmor.d/*" and process.args == "/etc/apparmor.d/disable/")
 71)
 72'''
 73note = """## Triage and analysis
 74
 75> **Disclaimer**:
 76> 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.
 77
 78### Investigating Potential Disabling of AppArmor
 79
 80AppArmor is a Linux security module that enforces strict access controls, limiting what applications can do. Adversaries may attempt to disable AppArmor to evade detection and freely execute malicious activities. The detection rule identifies suspicious processes attempting to stop or disable AppArmor services, such as using commands like `systemctl` or `service` with specific arguments, indicating potential tampering with security defenses.
 81
 82### Possible investigation steps
 83
 84- Review the process details to confirm the command used, focusing on the process name and arguments, such as "systemctl", "service", "chkconfig", or "ln" with arguments related to AppArmor.
 85- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
 86- Investigate the host's recent activity logs to identify any other suspicious behavior or anomalies around the time the alert was triggered.
 87- Examine the system's AppArmor status to verify if it has been disabled or tampered with, and assess any potential impact on system security.
 88- Correlate this event with other alerts or logs from the same host or user to identify patterns or a broader attack campaign.
 89- Consult threat intelligence sources to determine if there are known adversaries or malware that commonly attempt to disable AppArmor in similar ways.
 90
 91### False positive analysis
 92
 93- Routine system maintenance activities may trigger this rule, such as administrators stopping AppArmor for legitimate updates or configuration changes. To manage this, create exceptions for known maintenance windows or specific administrator accounts.
 94- Automated scripts or configuration management tools like Ansible or Puppet might stop or disable AppArmor as part of their deployment processes. Identify these scripts and whitelist their execution paths or associated user accounts.
 95- Testing environments where security modules are frequently enabled and disabled for testing purposes can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific hosts.
 96- Some legitimate software installations may require temporarily disabling AppArmor. Monitor installation logs and correlate them with the rule triggers to identify and exclude these benign activities.
 97- In environments where AppArmor is not actively used or managed, the rule may trigger on default system actions. Evaluate the necessity of monitoring AppArmor in such environments and adjust the rule scope accordingly.
 98
 99### Response and remediation
100
101- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary.
102- Terminate any suspicious processes identified by the detection rule, specifically those attempting to disable AppArmor, to halt any ongoing malicious activities.
103- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or related malicious activities.
104- Restore AppArmor to its intended operational state by re-enabling the service and ensuring all security policies are correctly applied.
105- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
106- Implement enhanced monitoring on the affected system and similar environments to detect any future attempts to disable AppArmor or other security controls.
107- Review and update access controls and permissions to ensure that only authorized personnel can modify security settings, reducing the risk of similar incidents."""
108
109[[rule.threat]]
110framework = "MITRE ATT&CK"
111
112[[rule.threat.technique]]
113id = "T1562"
114name = "Impair Defenses"
115reference = "https://attack.mitre.org/techniques/T1562/"
116
117[[rule.threat.technique.subtechnique]]
118id = "T1562.001"
119name = "Disable or Modify Tools"
120reference = "https://attack.mitre.org/techniques/T1562/001/"
121
122[rule.threat.tactic]
123id = "TA0005"
124name = "Defense Evasion"
125reference = "https://attack.mitre.org/tactics/TA0005/"
...
toml

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.

AppArmor is a Linux security module that enforces strict access controls, limiting what applications can do. Adversaries may attempt to disable AppArmor to evade detection and freely execute malicious activities. The detection rule identifies suspicious processes attempting to stop or disable AppArmor services, such as using commands like systemctl or service with specific arguments, indicating potential tampering with security defenses.

  • Review the process details to confirm the command used, focusing on the process name and arguments, such as "systemctl", "service", "chkconfig", or "ln" with arguments related to AppArmor.
  • Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
  • Investigate the host's recent activity logs to identify any other suspicious behavior or anomalies around the time the alert was triggered.
  • Examine the system's AppArmor status to verify if it has been disabled or tampered with, and assess any potential impact on system security.
  • Correlate this event with other alerts or logs from the same host or user to identify patterns or a broader attack campaign.
  • Consult threat intelligence sources to determine if there are known adversaries or malware that commonly attempt to disable AppArmor in similar ways.
  • Routine system maintenance activities may trigger this rule, such as administrators stopping AppArmor for legitimate updates or configuration changes. To manage this, create exceptions for known maintenance windows or specific administrator accounts.
  • Automated scripts or configuration management tools like Ansible or Puppet might stop or disable AppArmor as part of their deployment processes. Identify these scripts and whitelist their execution paths or associated user accounts.
  • Testing environments where security modules are frequently enabled and disabled for testing purposes can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific hosts.
  • Some legitimate software installations may require temporarily disabling AppArmor. Monitor installation logs and correlate them with the rule triggers to identify and exclude these benign activities.
  • In environments where AppArmor is not actively used or managed, the rule may trigger on default system actions. Evaluate the necessity of monitoring AppArmor in such environments and adjust the rule scope accordingly.
  • Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary.
  • Terminate any suspicious processes identified by the detection rule, specifically those attempting to disable AppArmor, to halt any ongoing malicious activities.
  • Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or related malicious activities.
  • Restore AppArmor to its intended operational state by re-enabling the service and ensuring all security policies are correctly applied.
  • Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
  • Implement enhanced monitoring on the affected system and similar environments to detect any future attempts to disable AppArmor or other security controls.
  • Review and update access controls and permissions to ensure that only authorized personnel can modify security settings, reducing the risk of similar incidents.

Related rules

to-top