AppArmor Policy Violation Detected

 1[metadata]
 2creation_date = "2026/03/20"
 3integration = ["auditd_manager"]
 4maturity = "production"
 5updated_date = "2026/03/20"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10Identifies events where the AppArmor security module blocked or restricted an operation due to a policy violation.
11AppArmor enforces mandatory access control policies that limit how processes interact with system resources such as
12files, network sockets, and capabilities. When a process attempts an action that is not permitted by the active
13profile, the kernel generates a policy violation event. While these events can occur during normal operation or
14misconfiguration, they may also indicate attempted privilege escalation, restricted file access, or malicious
15activity being prevented by the system's security policy.
16"""
17from = "now-9m"
18index = [
19    "logs-auditd_manager.auditd-*",
20    "auditbeat-*",
21]
22language = "eql"
23license = "Elastic License v2"
24name = "AppArmor Policy Violation Detected"
25note = """## Triage and analysis
26
27> **Disclaimer**:
28> 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.
29
30### Investigating AppArmor Policy Violation Detected
31
32This alert shows that AppArmor blocked or limited a Linux process because it tried to act outside its assigned security profile, which can reveal privilege escalation, restricted file access, or defense-evasion activity being stopped by the kernel. An attacker who gains code execution in a web-facing service might try to read `/etc/shadow`, spawn a shell from the confined process, or touch protected sockets, causing this violation when AppArmor contains the behavior.
33
34### Possible investigation steps
35
36- Determine which AppArmor profile produced the denial and what resource or capability was blocked, then judge whether the attempted action matches the application's expected behavior or suggests shell execution, credential access, or unusual network activity.
37- Build a short timeline around the event for the affected workload to identify preceding parent-child process chains, interactive sessions, failed access attempts, new persistence artifacts, or outbound connections that indicate exploitation rather than misconfiguration.
38- Review recent software deployments, package updates, profile changes, and administrator actions on the host to verify whether the violation began after a legitimate change that may require profile tuning or rollback.
39- If the denied behavior is unexpected or repeated, validate the integrity and reputation of the involved binary or script against known-good versions from the environment and inspect its execution context for signs of tampering or abuse.
40- For violations that align with malicious behavior, preserve relevant audit and system logs, contain the host or impacted service as needed, remove any confirmed malicious artifacts, and retain or harden the AppArmor policy that successfully blocked the action.
41
42### False positive analysis
43
44- A legitimate application or package update may change binaries, file paths, or socket usage without a matching AppArmor profile update, so verify the alert timing against recent host software changes and confirm the denied path or capability is part of the application's documented normal operation.
45- An administrator-initiated maintenance task or service restart can trigger a confined process to access temporary files, logs, or helper executables outside its usual profile, so review the parent process, command line, and user context to confirm it aligns with expected maintenance activity on the host.
46
47### Response and remediation
48
49- Isolate the affected Linux host or container from the network, stop the compromised service or process that triggered the AppArmor denial, and disable any abused user or service account to prevent additional attacker execution.
50- Remove attacker footholds by deleting unauthorized systemd units, cron jobs, startup scripts, SSH `authorized_keys` additions, dropped web shells, or replaced binaries linked to the confined process, then terminate any related child shells or reverse-connection tools.
51- Restore the workload to a known-good state by rebuilding the host or redeploying the service from a trusted image, reinstalling affected packages, validating critical files such as `/etc/passwd`, `/etc/shadow`, and application binaries against baseline hashes, and rotating any credentials the process may have reached.
52- Escalate to incident response immediately if the denial came from an internet-facing service, involved attempts to spawn a shell or read protected files, showed tampering with `/etc/apparmor.d/`, or appeared on multiple hosts, because these are strong indicators of active exploitation or wider compromise.
53- Harden the environment by keeping AppArmor in enforce mode, restoring any modified profiles, patching the vulnerable application or package the attacker abused, removing unnecessary interpreter access and write permissions for the service, and adding detections for the same blocked shell, file, or socket behaviors across similar systems."""
54references = [
55    "https://cdn2.qualys.com/advisory/2026/03/10/crack-armor.txt",
56    "https://blog.qualys.com/vulnerabilities-threat-research/2026/03/12/crackarmor-critical-apparmor-flaws-enable-local-privilege-escalation-to-root",
57]
58risk_score = 21
59rule_id = "02137bc2-5cc2-4f7f-a8e4-c52dc239aa69"
60setup = """## Setup
61
62This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system.

 1`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.
 2
 3For this detection rule no additional audit rules are required to be added to the integration.
 4
 5Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
 6"""
 7severity = "low"
 8tags = [
 9    "Domain: Endpoint",
10    "OS: Linux",
11    "Use Case: Threat Detection",
12    "Tactic: Defense Evasion",
13    "Data Source: Auditd Manager",
14    "Resources: Investigation Guide",
15]
16timestamp_override = "event.ingested"
17type = "eql"
18query = '''
19file where host.os.type == "linux" and event.type == "change" and event.action == "violated-apparmor-policy"
20'''
21
22[[rule.threat]]
23framework = "MITRE ATT&CK"
24
25[[rule.threat.technique]]
26id = "T1562"
27name = "Impair Defenses"
28reference = "https://attack.mitre.org/techniques/T1562/"
29
30[[rule.threat.technique.subtechnique]]
31id = "T1562.001"
32name = "Disable or Modify Tools"
33reference = "https://attack.mitre.org/techniques/T1562/001/"
34
35[rule.threat.tactic]
36id = "TA0005"
37name = "Defense Evasion"
38reference = "https://attack.mitre.org/tactics/TA0005/"