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

T1685.004: Disable or Modify Linux Audit System Log

Adversaries may disable or modify the Linux Audit system to hide malicious activity and avoid detection. Linux admins use the Linux Audit system to track security-relevant information on a system. The Linux Audit system operates at the kernel-level and maintains event logs on application and system activity such as process, network, file, and login events based on pre-configured rules.

Often referred to as `auditd`, this is the name of the daemon used to write events to disk and is governed by the parameters set in the `audit.conf` configuration file. Two primary ways to configure the log generation rules are through the command line `auditctl` utility and the file `/etc/audit/audit.rules`, containing a sequence of `auditctl` commands loaded at boot time.[1][2]

With root privileges, adversaries may be able to ensure their activity is not logged through disabling the Audit system service, editing the configuration/rule files, or by hooking the Audit system library functions. Using the command line, adversaries can disable the Audit system service through killing processes associated with `auditd` daemon or use `systemctl` to stop the Audit service. Adversaries can also hook Audit system functions to disable logging or modify the rules contained in the `/etc/audit/audit.rules` or `audit.conf` files to ignore malicious activity.[3]

EnterpriseT1685.004Sub-techniqueObject v1.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

This technique matters because Linux audit logging is often the evidence layer used to reconstruct privileged activity, authentication events, process execution, file changes, and network-relevant behavior on Linux systems. If an adversary with root privileges disables auditd, changes audit rules, or interferes with audit-related functions, the organization may lose the very records needed for incident response, compliance evidence, and confidence in containment decisions.

Executive priority

Treat this as a visibility and trust issue for Linux operations. Leaders should ask whether critical Linux servers have monitored audit configurations, whether privileged users can change audit settings without review, and whether incident responders would notice audit logging gaps quickly. The business risk is not just missing an alert; it is losing defensible evidence during an investigation or audit.

Technical view

For SOC, detection engineering, and IR teams, validate monitoring around the Linux Audit system on Linux platforms. ATT&CK identifies auditd, auditctl, /etc/audit/audit.rules, and audit.conf as key areas. Coverage should include service stoppage or process termination for auditd, command-line or boot-time audit rule changes, configuration edits, and evidence of tampering with audit-related libraries or functions. This is a sub-technique of Disable or Modify Tools under defense impairment, so triage should consider it a potential precursor to broader log evasion.

Likely telemetry

  • auditd service state and process lifecycle events
  • systemctl or service-management activity affecting the Audit service
  • process execution involving auditctl and commands that stop or kill auditd-related processes
  • file modification monitoring for /etc/audit/audit.rules and audit.conf
  • audit rule load or configuration-change evidence at boot and runtime

Detection direction

  • Because the official ATT&CK detection field is not provided, validate local detections against the related DET0062 strategy if available in your content set rather than assuming coverage.
  • Alert on auditd being stopped, killed, disabled, or unexpectedly absent on Linux systems where it is expected to run.
  • Monitor changes to audit.conf and /etc/audit/audit.rules, including rule removals or changes that reduce logging for sensitive activity.
  • Correlate audit configuration changes with privileged logins and administrative change windows to reduce false positives while preserving escalation paths for unapproved changes.
  • Look for gaps or sudden drops in expected audit event volume; absence of expected audit events can be as important as the presence of a suspicious command.

Mitigation priorities

  • Prioritize User Account Management: restrict who can obtain root-level privileges or modify audit configuration, and review privileged account lifecycle and access paths.
  • Prioritize Audit: maintain approved audit rules, review audit configurations systematically, and verify that audit logging is functioning on Linux systems where required.
  • Establish change-control expectations for auditd service state and audit rule updates so authorized administration can be distinguished from suspicious impairment.
  • During hardening and compliance reviews, test whether audit rules load as expected at boot and whether defenders receive evidence when auditd or its configuration changes.
  • For critical Linux systems, make audit integrity part of IR readiness: responders should know what audit evidence should exist and what a missing or modified audit trail implies.
Analyst notes and limits

This object is Linux-specific and focused on defense impairment by disabling or modifying the Linux Audit system. The relationship context includes mitigations for User Account Management and Audit, a detection-strategy relationship, a revoked predecessor technique, the parent Disable or Modify Tools technique, and software context showing Ebury uses this behavior. That software relationship supports awareness but should not be treated as proof of current activity in any environment.

The official ATT&CK detection text is not provided, and the related DET0062 detection strategy details were not supplied. This take therefore provides validation direction rather than claiming a specific detection analytic. Local baselines, audit policies, privileged-access models, and Linux distribution practices are required to determine what is abnormal.

Official MITRE ATT&CK definition

Disable or Modify Linux Audit System Log

Adversaries may disable or modify the Linux Audit system to hide malicious activity and avoid detection. Linux admins use the Linux Audit system to track security-relevant information on a system. The Linux Audit system operates at the kernel-level and maintains event logs on application and system activity such as process, network, file, and login events based on pre-configured rules.

Often referred to as `auditd`, this is the name of the daemon used to write events to disk and is governed by the parameters set in the `audit.conf` configuration file. Two primary ways to configure the log generation rules are through the command line `auditctl` utility and the file `/etc/audit/audit.rules`, containing a sequence of `auditctl` commands loaded at boot time.[1][2]

With root privileges, adversaries may be able to ensure their activity is not logged through disabling the Audit system service, editing the configuration/rule files, or by hooking the Audit system library functions. Using the command line, adversaries can disable the Audit system service through killing processes associated with `auditd` daemon or use `systemctl` to stop the Audit service. Adversaries can also hook Audit system functions to disable logging or modify the rules contained in the `/etc/audit/audit.rules` or `audit.conf` files to ignore malicious activity.[3]

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

Related techniques

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.

2 rows
Domain ID Name Relationship / procedure
Enterprise T1562.012 Disable or Modify Linux Audit System Sub-technique Disable or Modify Linux Audit System revoked by this object.
Enterprise T1685 Disable or Modify Tools This object subtechnique of Disable or Modify Tools.
Associated objects

Groups, software, and campaigns

Malware Enterprise

S0377: Ebury

Ebury is an OpenSSH backdoor and credential stealer targeting Linux servers and container hosts developed by Windigo. Ebury is primarily installed through modifying shared libraries (`.so` files) executed by the legitimate OpenSSH program. First seen in 2009, Ebury has been used to maintain a botnet of servers, deploy additional malware, and steal cryptocurrency wallets, credentials, and credit card details.[1][2][3][4]

Linux
Relationship explorer

All related ATT&CK context

detects · Detection Strategy DET0062: Detection Strategy for Disable or Modify Linux Audit System Log Enterprise mitigates · Mitigation M1018: User Account Management Enterprise uses · Malware S0377: Ebury Enterprise mitigates · Mitigation M1047: Audit Enterprise revoked by · Technique T1562.012: Disable or Modify Linux Audit System Enterprise subtechnique of · Technique T1685: Disable or Modify Tools Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1018: User Account Management

User Account Management involves implementing and enforcing policies for the lifecycle of user accounts, including creation, modification, and deactivation. Proper account management reduces the attack surface by limiting unauthorized access, managing account privileges, and ensuring accounts are used according to organizational policies. This mitigation can be implemented through the following measures:

Enforcing the Principle of Least Privilege

- Implementation: Assign users only the minimum permissions required to perform their job functions. Regularly audit accounts to ensure no excess permissions are granted. - Use Case: Reduces the risk of privilege escalation by ensuring accounts cannot perform unauthorized actions.

Implementing Strong Password Policies

- Implementation: Enforce password complexity requirements (e.g., length, character types). Require password expiration every 90 days and disallow password reuse. - Use Case: Prevents adversaries from gaining unauthorized access through password guessing or brute force attacks.

Managing Dormant and Orphaned Accounts

- Implementation: Implement automated workflows to disable accounts after a set period of inactivity (e.g., 30 days). Remove orphaned accounts (e.g., accounts without an assigned owner) during regular account audits. - Use Case: Eliminates dormant accounts that could be exploited by attackers.

Account Lockout Policies

- Implementation: Configure account lockout thresholds (e.g., lock accounts after five failed login attempts). Set lockout durations to a minimum of 15 minutes. - Use Case: Mitigates automated attack techniques that rely on repeated login attempts.

Multi-Factor Authentication (MFA) for High-Risk Accounts

- Implementation: Require MFA for all administrative accounts and high-risk users. Use MFA mechanisms like hardware tokens, authenticator apps, or biometrics. - Use Case: Prevents unauthorized access, even if credentials are stolen.

Restricting Interactive Logins

- Implementation: Restrict interactive logins for privileged accounts to specific secure systems or management consoles. Use group policies to enforce logon restrictions. - Use Case: Protects sensitive accounts from misuse or exploitation.

*Tools for Implementation*

Built-in Tools:

- Microsoft Active Directory (AD): Centralized account management and RBAC enforcement. - Group Policy Object (GPO): Enforce password policies, logon restrictions, and account lockout policies.

Identity and Access Management (IAM) Tools:

- Okta: Centralized user provisioning, MFA, and SSO integration. - Microsoft Azure Active Directory: Provides advanced account lifecycle management, role-based access, and conditional access policies.

Privileged Account Management (PAM): - CyberArk, BeyondTrust, Thycotic: Manage and monitor privileged account usage, enforce session recording, and JIT access.

Mitigation Enterprise

M1047: Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements. The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures.

Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.This mitigation can be implemented through the following measures:

System Audit:

- Use Case: Regularly assess system configurations to ensure compliance with organizational security policies. - Implementation: Use tools to scan for deviations from established benchmarks.

Permission Audits:

- Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation. - Implementation: Run access reviews to identify users or groups with excessive permissions.

Software Audits:

- Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector. - Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.

Configuration Audits:

- Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA). - Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.

Network Audits:

- Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections. - Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.

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
c9ef56ddaac81798...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle c9ef56ddaac8…
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.

Open mirrored raw JSON Open MITRE-hosted copy
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]
    IzyKnows auditd threat detection 2022

    IzySec. (2022, January 26). Linux auditd for Threat Detection. Retrieved September 29, 2023.

    Open source URL
  2. [2]
    Red Hat Linux Disable or Mod

    Red Hat. (n.d.). Retrieved April 15, 2026.

    Open source URL
  3. [3]
    ESET Ebury Feb 2014

    M.Léveillé, M.. (2014, February 21). An In-depth Analysis of Linux/Ebury. Retrieved April 19, 2019.

    Open source URL
  4. [4]
    mitre-attack T1685.004
    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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use