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

T1685.002: Disable or Modify Cloud Log

An adversary may disable or modify cloud logging capabilities and integrations to limit what data is collected on their activities and avoid detection. Cloud environments allow for collection and analysis of audit and application logs that provide insight into what activities a user does within the environment. If an adversary has sufficient permissions, they can disable or modify logging to avoid detection of their activities.

For example, in AWS an adversary may disable CloudWatch/CloudTrail integrations prior to conducting further malicious activity. They may alternatively tamper with logging functionality, for example, by removing any associated SNS topics, disabling multi-region logging, or disabling settings that validate and/or encrypt log files.[1][2] In Office 365, an adversary may disable logging on mail collection activities for specific users by using the Set-MailboxAuditBypassAssociation cmdlet, by disabling M365 Advanced Auditing for the user, or by downgrading the user’s license from an Enterprise E5 to an Enterprise E3 license.[3]

EnterpriseT1685.002Sub-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 cloud logs are often the evidence trail for identity misuse, SaaS activity, and infrastructure changes. If an attacker with sufficient permissions can disable or weaken those logs, the organization may lose the ability to detect follow-on activity, reconstruct an incident, or prove control effectiveness during an audit.

Executive priority

Treat cloud logging control as a resilience and governance issue, not only a SOC issue. Leaders should ask who can change logging in IaaS, SaaS, identity provider, and office suite environments; whether those changes are independently monitored; and whether incident responders would still have usable evidence if native logging were degraded. This should influence IAM privilege reviews, cloud security budgets, audit evidence collection, and incident response readiness.

Technical view

This is a defense-impairment sub-technique under Disable or Modify Tools affecting IaaS, SaaS, Identity Provider, and Office Suite platforms. ATT&CK gives examples such as disabling AWS CloudTrail/CloudWatch integrations, changing trail settings such as multi-region logging, validation, encryption, or SNS associations, and modifying Microsoft 365 mailbox auditing or audit-related licensing. SOC and IR teams should validate monitoring for administrative changes to cloud audit configurations, mailbox audit bypass settings, audit feature enablement, and privilege changes that allow those actions. Relationship context notes DET0289 as a detection strategy, M1018 User Account Management as a mitigation, APT29 as a group associated with use of this behavior, and Pacu as software associated with this behavior in IaaS.

Likely telemetry

  • Cloud audit log configuration change events from IaaS platforms
  • SaaS and office suite administrative audit events
  • Identity provider administrative and privilege assignment logs
  • Events showing enablement, disablement, or modification of audit policies, mailbox auditing, or audit bypass settings
  • Cloud trail or logging service configuration records, including region coverage, validation, encryption, and notification integrations

Detection direction

  • Validate alerting on changes to cloud logging configuration, especially disablement, scope reduction, encryption or validation changes, and removal of notification integrations.
  • Monitor for administrative changes that reduce audit visibility for specific users or mailboxes, including audit bypass or audit feature changes where supported by the platform.
  • Correlate logging changes with identity context: actor, role, recent privilege changes, source location, and subsequent high-risk activity.
  • Tune for authorized maintenance and licensing changes to reduce false positives, but require change-ticket or approval context for events that reduce audit coverage.
  • Test whether detection still works if the primary cloud log source is degraded; common blind spots include overreliance on the same logs an attacker may be able to disable.

Mitigation priorities

  • Enforce least privilege for accounts and roles that can modify cloud, SaaS, identity provider, and office suite logging settings, consistent with M1018 User Account Management.
  • Separate duties so routine administrators cannot silently reduce audit coverage without additional approval or monitoring.
  • Maintain an inventory of required logging settings and periodically compare current configuration against that baseline.
  • Preserve audit evidence in locations or integrations that are harder for the same administrator path to alter.
  • Include cloud log impairment scenarios in incident response playbooks and access reviews.
Analyst notes and limits

The ATT&CK object provides strong cloud and SaaS examples but no official detection text. The most useful local validation is whether logging control changes are both restricted and monitored independently. The revoked-by relationship indicates this object replaces T1562.008 in the newer ATT&CK structure.

This take is based only on the supplied ATT&CK fields, references, and relationships. It does not establish current activity, customer exposure, or guaranteed detectability. Exact event names and control options vary by cloud, SaaS, identity provider, and office suite implementation.

Official MITRE ATT&CK definition

Disable or Modify Cloud Log

An adversary may disable or modify cloud logging capabilities and integrations to limit what data is collected on their activities and avoid detection. Cloud environments allow for collection and analysis of audit and application logs that provide insight into what activities a user does within the environment. If an adversary has sufficient permissions, they can disable or modify logging to avoid detection of their activities.

For example, in AWS an adversary may disable CloudWatch/CloudTrail integrations prior to conducting further malicious activity. They may alternatively tamper with logging functionality, for example, by removing any associated SNS topics, disabling multi-region logging, or disabling settings that validate and/or encrypt log files.[1][2] In Office 365, an adversary may disable logging on mail collection activities for specific users by using the Set-MailboxAuditBypassAssociation cmdlet, by disabling M365 Advanced Auditing for the user, or by downgrading the user’s license from an Enterprise E5 to an Enterprise E3 license.[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 T1685 Disable or Modify Tools This object subtechnique of Disable or Modify Tools.
Enterprise T1562.008 Disable or Modify Cloud Logs Sub-technique Disable or Modify Cloud Logs revoked by this object.
Associated objects

Groups, software, and campaigns

Group Enterprise

G0016: APT29

APT29 is threat group that has been attributed to Russia's Foreign Intelligence Service (SVR).[1][2] They have operated since at least 2008, often targeting government networks in Europe and NATO member countries, research institutes, and think tanks. APT29 reportedly compromised the Democratic National Committee starting in the summer of 2015.[3][4][5][6]

In April 2021, the US and UK governments attributed the SolarWinds Compromise to the SVR; public statements included citations to APT29, Cozy Bear, and The Dukes.[7][8] Industry reporting also referred to the actors involved in this campaign as UNC2452, NOBELIUM, StellarParticle, Dark Halo, and SolarStorm.[9][10][11][12][13][14]

Tool Enterprise

S1091: Pacu

Pacu is an open-source AWS exploitation framework. The tool is written in Python and publicly available on GitHub.[1]

IaaS
Relationship explorer

All related ATT&CK context

subtechnique of · Technique T1685: Disable or Modify Tools Enterprise uses · Tool S1091: Pacu Enterprise revoked by · Technique T1562.008: Disable or Modify Cloud Logs Enterprise mitigates · Mitigation M1018: User Account Management Enterprise detects · Detection Strategy DET0289: Detection Strategy for Disable or Modify Cloud Log Enterprise uses · Group G0016: APT29 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.

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

    AWS. (n.d.). update-trail. Retrieved April 15, 2026.

    Open source URL
  2. [2]
    Pacu Detection Disruption Module

    Rhino Security Labs. (2021, April 29). Pacu Detection Disruption Module. Retrieved August 4, 2023.

    Open source URL
  3. [3]
    Dark Reading

    Kelly Sheridan. (2021, August 5). Retrieved April 15, 2026.

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