AN0523: Analytic 0523
Monitors tampering with audit logs, volumes, or mounted storage often used for side-channel logging (e.g., /var/log inside containers) post-compromise.
Analyst context for executives and security teams
This analytic matters because container intrusions can become much harder to investigate if an attacker tampers with audit logs, container volumes, or mounted storage such as paths used for side-channel logging. For leaders, the practical issue is not just detection of one action; it is whether the organization can preserve reliable evidence after a container compromise and make timely incident decisions.
Executive priority
Prioritize this as an incident-readiness and operational-resilience control for containerized environments. Security leaders should ask whether container logging is protected from workload-level tampering, whether SOC teams can see changes to mounted log paths and volumes, and whether incident responders have trustworthy evidence if a container is suspected to be compromised. This is also relevant to compliance evidence where log integrity and retention are required.
Technical view
AN0523 applies to Containers and focuses on monitoring tampering with audit logs, volumes, or mounted storage used for side-channel logging, including examples such as /var/log inside containers. Because no official detection logic is supplied, SOC and detection engineering teams should validate whether their container telemetry can show suspicious modification, deletion, truncation, permission change, remounting, or unexpected write activity affecting log and audit storage locations. IR teams should treat gaps in these signals as evidence-integrity risk during container compromise investigations.
Likely telemetry
- Container runtime events related to volume mounts and filesystem activity
- Container file integrity or filesystem monitoring for log and audit paths
- Host-level audit telemetry for mounted storage used by containers
- Kubernetes or container orchestration events involving volumes, mounts, and workload changes where applicable to the environment
- Centralized log pipeline health, gaps, truncation, or unexpected source silence indicators
Detection direction
- Confirm which container log and audit paths are monitored, especially mounted storage and side-channel logging locations such as /var/log inside containers.
- Tune for high-risk changes to log files, audit artifacts, permissions, ownership, mount state, or volume contents rather than ordinary application log rotation alone.
- Correlate possible log or volume tampering with other signs of container compromise when local telemetry allows, since the ATT&CK object provides no tactic, relationship, or detection logic context.
- Review false positives from legitimate log rotation, deployment activity, maintenance jobs, and storage lifecycle processes.
- Identify blind spots where logs are writable by the workload, stored only inside ephemeral containers, or not forwarded before local tampering could occur.
Mitigation priorities
- Centralize and forward container logs quickly so evidence is not dependent only on writable in-container storage.
- Restrict workload permissions to log, audit, and mounted storage paths to the minimum required for normal operation.
- Use immutable or append-only logging patterns where feasible for audit-relevant records.
- Monitor and control volume mount configuration changes through container platform governance and change management.
- Include container log-integrity checks in incident response playbooks and compliance evidence reviews.
Analyst notes and limits
The supplied object is a detection analytic, not a technique, and it has no supplied tactic, relationships, aliases, or official detection logic. The strongest defensible takeaway is evidence preservation and tamper visibility in container environments after compromise. Local architecture determines whether the most important evidence comes from the container runtime, host auditing, orchestration layer, or centralized logging pipeline.
This take is limited to the official ATT&CK fields provided for AN0523. No active exploitation, adversary attribution, impact level, specific detection query, or guaranteed coverage is stated because those details were not supplied.
Analytic 0523
Monitors tampering with audit logs, volumes, or mounted storage often used for side-channel logging (e.g., /var/log inside containers) post-compromise.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | c4a0bb515dd6… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0523Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.