Detecting Disable or Modify Cloud Log (MITRE ATT&CK T1685.002)

Disable or Modify Cloud Log (T1685.002) is a sub-technique of Disable or Modify Tools. Adversaries turn off or change cloud logging and integrations to limit what is recorded about their activity. MITRE lists the Defense Impairment tactic and the IaaS, SaaS, Identity Provider and Office Suite platforms.

How attackers use it

Cloud platforms collect audit and application logs that show what each user does. If an adversary has sufficient permissions, they can switch that logging off or change it.

MITRE gives two sets of examples.

AWS. An adversary may disable CloudWatch or CloudTrail integrations before further malicious activity. They may also tamper with logging by removing associated SNS topics, disabling multi-region logging, or turning off settings that validate or encrypt log files.

Office 365. An adversary may turn off logging on mail collection activity for specific users with the Set-MailboxAuditBypassAssociation cmdlet, disable Microsoft 365 Advanced Auditing for a user, or downgrade the user's license from Enterprise E5 to Enterprise E3.

Documented uses include an actor that disabled Purview Audit on targeted accounts before stealing email from Microsoft 365 tenants, and a framework that can disable or restrict AWS logging such as CloudTrail and VPC flow logs.

How to detect it

MITRE's detection strategy splits by service type:

• IaaS. Cloud API events that stop, delete or modify logging in a way that removes audit visibility, such as StopLogging, DeleteTrail or UpdateSink, correlated with privileged user activity.
• Identity and sign-in logs. Policy or configuration changes that remove logging coverage for critical accounts.
• Mailbox and tenant audit. Disabling mailbox or tenant-level audit logging, for example through Set-MailboxAuditBypassAssociation or a license downgrade. The defender's view is a sudden absence of mailbox activity logging for monitored users.
• Other SaaS. API calls or admin console changes that stop event exports or logging integrations in tools such as Slack, Zoom or Salesforce.

Note the pattern of the problem: the cloud log is the record of the very change that disables it. Send these particular events to a second, separate place that the same administrators cannot edit.

How to reduce the risk

MITRE lists one mitigation, User Account Management: configure the default account policy to enable logging, and limit which users can change logging policies.

Practical steps that go with it:

• Keep one trail or log destination in an account that workload administrators cannot reach.
• Turn on log file validation where the platform offers it.
• Alert on every change to a logging setting, with no exceptions.
• Review who holds permission to stop or alter logging, and remove it from anyone who does not need it.
• Check licensing: a downgrade should not silently reduce audit coverage.

Check your own environment

Read-only checks, with the AWS CLI:

aws cloudtrail describe-trails
aws cloudtrail get-trail-status --name YOUR_TRAIL_NAME

Then ask:

• Is every trail multi-region, and is log file validation on?
• Is CloudTrail actually logging, with a recent latest delivery time?
• For Microsoft 365, is mailbox auditing on for all users, and who holds rights to change it?
• Do you alert when logging stops?
• Is a copy of the logs stored where administrators cannot delete it?

Quick check

Sources

• MITRE ATT&CK, Disable or Modify Cloud Log (T1685.002): https://attack.mitre.org/techniques/T1685/002