Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0062: Detection Strategy for Disable or Modify Linux Audit System Log

DET0062 matters because it points defenders at attempts to disable or alter Linux Audit logging, a defense-impairment behavior that can remove the evidence...

EnterpriseDET0062Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0062 matters because it points defenders at attempts to disable or alter Linux Audit logging, a defense-impairment behavior that can remove the evidence needed to investigate incidents. For leaders, the practical issue is not just whether auditd exists, but whether the organization can prove that Linux security logs remain enabled, protected, collected, and reviewed during an intrusion.

Executive priority

Prioritize this as an assurance and resilience question for Linux-dependent services: can security and operations teams detect when audit logging is weakened before incident evidence is lost? This affects incident response readiness, compliance evidence, SOC visibility, and confidence in investigations involving Linux systems. The ATT&CK object itself is sparse, so priority should be based on the organization’s dependence on Linux workloads and the criticality of systems where Linux Audit provides security-relevant evidence.

Technical view

This detection strategy detects T1685.004, Disable or Modify Linux Audit System Log, under defense impairment on Linux. SOC and detection engineering teams should validate monitoring around the Linux Audit system, commonly auditd, including service state, audit rule integrity, configuration changes, log generation, and interruptions in expected audit event flow. Because MITRE provides no official detection text for DET0062, local detection logic should be built from environment baselines and validated against authorized administrative activity.

Likely telemetry

  • Linux Audit/auditd events and rule state
  • auditd service status and start/stop/restart events
  • Linux system logs that record service management or audit subsystem errors
  • File integrity or change records for audit configuration and rule files
  • Endpoint process telemetry for administrative commands affecting audit services or configuration

Detection direction

  • Alert on suspicious or unauthorized changes to Linux Audit service state, audit rules, or audit configuration on systems where auditd is expected to run.
  • Correlate audit changes with identity, host criticality, maintenance windows, and change-management records to reduce false positives from legitimate administration.
  • Look for negative signals as well as positive events: sudden loss of expected audit telemetry from a Linux host can be material even when no explicit disable event is collected.
  • Validate whether detection still works if local logs are modified or stop forwarding, since the related behavior is specifically about impairing evidence sources.
  • Use the relationship to T1685.004 as the main analytic anchor; DET0062 has no supplied tactics, platforms, description, or detection text of its own.

Mitigation priorities

  • Define which Linux systems must run Linux Audit and what minimum audit rules are required for security and compliance evidence.
  • Restrict and review privileged access capable of changing auditd, audit rules, or audit configuration.
  • Centralize audit logs so local tampering or service disruption is more visible to the SOC.
  • Monitor audit configuration integrity and service health, especially on business-critical Linux hosts.
  • Exercise incident response procedures for cases where audit logs are missing, disabled, or unreliable.
Analyst notes and limits

The strongest value of this object is relationship-driven: it maps a detection strategy to a Linux defense-impairment technique involving the Linux Audit system. Treat this as a prompt to test whether Linux audit logging is both operational and tamper-aware, not as a complete MITRE-authored analytic.

The supplied ATT&CK detection strategy has no official description, no official detection content, no tactics, and no platforms listed directly on the object. Linux platform and defense-impairment context come from the relationship to T1685.004. Local system roles, logging architecture, privileged-access model, and change-control data are required to turn this into production detection logic.

Official MITRE ATT&CK definition

Detection Strategy for Disable or Modify Linux Audit System Log

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Techniques used

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1685.004 Disable or Modify Linux Audit System Log Sub-technique This object detects Disable or Modify Linux Audit System Log.
Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
45a1393af6595462...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 45a1393af659…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0062
    Open source URL
Source and licensing

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.