Skip to content
T1685.002

Disable or Modify Tools — Disable or Modify Cloud Logs

Defense Impairment Last updated:

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 by removing associated SNS topics, disabling multi-region logging, or disabling settings that validate and/or encrypt log files. 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.

What is T1685.002 Disable or Modify Cloud Logs?

Disable or Modify Cloud Logs (T1685.002) is a sub-technique of Disable or Modify Tools (T1685) in the MITRE ATT&CK framework. It maps to the Defense Impairment tactic — the adversary is trying to break security mechanisms, pipelines, and tooling so defenders can’t see or trust what’s happening.

This page provides production-ready detection logic for Disable or Modify Cloud Logs, covering the data sources and telemetry it touches: Cloud Service: Cloud Service Modification, Application Log: Application Log Content, User Account: User Account Modification. The queries below are rated high severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Defense Impairment
Technique
T1685 Disable or Modify Tools
Sub-technique
T1685.002 Disable or Modify Cloud Log
Canonical reference
https://attack.mitre.org/techniques/T1685/002/
Microsoft Sentinel / Defender
kusto
let CloudTrailTampering = dynamic([
  "StopLogging", "DeleteTrail", "UpdateTrail",
  "PutEventSelectors", "RemoveTargets", "DeleteFlowLogs",
  "DeleteDetector", "DeleteMembers",
  "DisableOrganizationAdminAccount"
]);
let AzureDiagTampering = dynamic([
  "MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE",
  "MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/WRITE",
  "MICROSOFT.SECURITY/SECURITYCONTACTS/DELETE"
]);
let M365AuditTampering = dynamic([
  "Set-MailboxAuditBypassAssociation",
  "Set-AdminAuditLogConfig",
  "Disable-OrganizationCustomization",
  "Set-OrganizationConfig"
]);
union
(
  AuditLogs
  | where TimeGenerated > ago(24h)
  | where OperationName has_any (AzureDiagTampering)
  | project TimeGenerated, OperationName, Identity,
           Result, TargetResources, CorrelationId
),
(
  OfficeActivity
  | where TimeGenerated > ago(24h)
  | where Operation has_any (M365AuditTampering)
  | project TimeGenerated, Operation, UserId,
           ResultStatus, ClientIP, Parameters
),
(
  AWSCloudTrail
  | where TimeGenerated > ago(24h)
  | where EventName has_any (CloudTrailTampering)
  | project TimeGenerated, EventName, UserIdentityArn,
           SourceIpAddress, AWSRegion, ErrorCode,
           RequestParameters
)
| sort by TimeGenerated desc

Detects attempts to disable or modify cloud logging across AWS (CloudTrail/CloudWatch/VPC Flow Logs/GuardDuty), Azure (Diagnostic Settings/Security Center), and Microsoft 365 (Mailbox Audit Bypass/Admin Audit Log). Uses a union across AWSCloudTrail, AuditLogs, and OfficeActivity tables to provide cross-cloud coverage. Identifies key API calls associated with logging disruption such as StopLogging, DeleteTrail, UpdateTrail, DeleteFlowLogs, diagnostic settings deletion, and mailbox audit bypass configuration.

high severity high confidence

Data Sources

Cloud Service: Cloud Service Modification Application Log: Application Log Content User Account: User Account Modification

Required Tables

AWSCloudTrail AuditLogs OfficeActivity

False Positives

  • Cloud administrators legitimately reconfiguring CloudTrail to consolidate trails during an AWS Organization migration or cost optimization exercise
  • Azure DevOps pipelines that programmatically update diagnostic settings as part of infrastructure-as-code deployments (Terraform, Bicep)
  • IT administrators using Set-MailboxAuditBypassAssociation for legitimate service accounts that generate excessive audit noise (e.g., migration tools, backup agents)
  • Security teams temporarily modifying GuardDuty or Security Center settings during a planned penetration test with a signed rules-of-engagement

Sigma rule & cross-platform mapping

The detection logic for Disable or Modify Cloud Logs (T1685.002) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  product: azure

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1 AWS CloudTrail StopLogging Simulation

    Expected signal: CloudTrail event: eventName=StopLogging, eventSource=cloudtrail.amazonaws.com. The event record includes requestParameters.name (trail name) and userIdentity (acting principal). If forwarded to Sentinel, appears in AWSCloudTrail table.

  2. Test 2 AWS GuardDuty DeleteDetector Simulation

    Expected signal: CloudTrail event: eventName=DeleteDetector, eventSource=guardduty.amazonaws.com. The requestParameters include the detectorId. This event will appear in AWSCloudTrail table in Sentinel.

  3. Test 3 M365 Mailbox Audit Bypass via PowerShell

    Expected signal: M365 Unified Audit Log: Operation=Set-MailboxAuditBypassAssociation, with Parameters showing the target mailbox and AuditBypassEnabled=True. Appears in OfficeActivity table in Sentinel.


Response Playbook

Triage

  1. Identify the IAM principal (user/role/service) that made the API call — is this a known admin, automation role, or an unexpected identity? Check the userIdentity.arn and sourceIPAddress fields.
  2. Determine the scope of the change — was a single trail modified or were multiple trails/regions affected? Multi-region or organization-wide changes are higher severity.
  3. Check if the change was preceded by privilege escalation — look for recent AssumeRole, CreateAccessKey, or ConsoleLogin events from the same identity in the last 24 hours.
  4. Verify against change management records — was there an approved change ticket or IaC pipeline run that corresponds to this API call?
  5. Check if logging was restored after the change — a legitimate reconfiguration typically creates a new trail shortly after deleting the old one.
  6. For M365 mailbox audit bypass: identify which mailbox was targeted and whether it belongs to a high-value user (executive, finance, legal).

Containment

  1. Immediately re-enable the disabled logging service (aws cloudtrail start-logging, recreate diagnostic settings, or remove mailbox audit bypass) to restore visibility.
  2. If the acting identity is compromised: revoke active sessions by attaching an inline deny-all policy, delete access keys, and reset console password.
  3. If the source IP is unknown or external: block the IP at the network perimeter (WAF, security group, NSG) and check for other API calls from the same IP.
  4. Enable an SCP (Service Control Policy) or Azure Policy to prevent future CloudTrail/diagnostic settings deletion across the organization.
  5. For M365: re-enable Advanced Auditing on affected mailboxes and check for mailbox rules or delegations added during the audit gap.

Evidence Collection

  1. AWS CloudTrail event history — export the full event record for the tampering API call including requestParameters and responseElements.
  2. AWS Config — check configuration timeline for the CloudTrail resource to see before/after state of the trail configuration.
  3. IAM Access Analyzer — review recent activity for the acting role/user to identify what other actions were taken during and after the logging gap.
  4. Azure Activity Log — for Azure diagnostic settings changes, export the full activity log entry with caller identity and resource details.
  5. M365 Unified Audit Log — search for the Set-MailboxAuditBypassAssociation operation and correlate with any subsequent mailbox access events.
  6. VPC Flow Logs (if still available from other sources) — check for unusual network patterns during the period logging was disabled.

Escalation Criteria

  • ! CloudTrail StopLogging or DeleteTrail on the organization's primary trail — this eliminates visibility across the entire account or organization.
  • ! Multiple logging services disabled in sequence (e.g., CloudTrail stopped, then GuardDuty detector deleted, then VPC Flow Logs removed) — indicates deliberate evidence destruction.
  • ! The acting identity was recently created or had its permissions escalated — suggests a compromised or attacker-created account.
  • ! Mailbox audit bypass set on executive or finance mailboxes — high likelihood of targeted email theft (APT29 TTP).
  • ! Source IP geolocates to a region where the organization has no employees or infrastructure.
  • ! No corresponding change ticket, IaC pipeline run, or administrator confirmation for the modification.

Investigation Guide

Forensic Artifacts

  • > AWS CloudTrail Event History — even if trails are deleted, the last 90 days of management events are available via the CloudTrail Event History console (read-only, cannot be deleted by users).
  • > AWS Config — configuration snapshots and timeline show the state of CloudTrail resources before and after modification.
  • > AWS S3 Access Logs — if the CloudTrail S3 bucket has server access logging enabled, these logs persist independently of CloudTrail configuration.
  • > Azure Activity Log — retained for 90 days in Azure Monitor regardless of diagnostic settings changes (platform-level, not deletable by users).
  • > M365 Unified Audit Log — search for Set-MailboxAuditBypassAssociation and correlate with MailItemsAccessed events.
  • > AWS IAM Credential Report — shows when access keys were last used and from which IP, useful for identifying the compromised credential.

Tuning Guidance

Start by building an allowlist of IAM roles and service principals authorized to modify logging configurations — these are typically limited to cloud platform teams and IaC automation roles (e.g., Terraform, CloudFormation service roles). For AWS, consider implementing an SCP that denies cloudtrail:StopLogging and cloudtrail:DeleteTrail for all principals except a break-glass role. For Azure, use Azure Policy to prevent deletion of diagnostic settings. For M365, restrict Set-MailboxAuditBypassAssociation to a small set of Exchange administrators and alert on any use. Exclude known IaC pipeline source IPs (CI/CD runners) but only by exact IP match, never by CIDR range. If your organization uses multiple AWS accounts, focus highest-severity alerts on the organization management account and security audit accounts where CloudTrail disruption has the greatest impact.


Hunting Queries

Hunt for IAM identities that have performed multiple cloud logging modification actions over a 30-day window. A single identity performing StopLogging followed by DeleteDetector across multiple regions is a strong indicator of deliberate evidence destruction by an adversary with compromised cloud credentials.

Hunting — KQL
kql
AWSCloudTrail
| where TimeGenerated > ago(30d)
| where EventName in ("StopLogging", "DeleteTrail", "UpdateTrail", "PutEventSelectors", "DeleteFlowLogs", "DeleteDetector")
| summarize EventCount=count(), Actions=make_set(EventName), Regions=make_set(AWSRegion) by UserIdentityArn, SourceIpAddress
| where EventCount > 1
| sort by EventCount desc
Hunting — SPL
spl
index=aws sourcetype="aws:cloudtrail" (eventName="StopLogging" OR eventName="DeleteTrail" OR eventName="UpdateTrail" OR eventName="PutEventSelectors" OR eventName="DeleteFlowLogs" OR eventName="DeleteDetector")
| stats count as EventCount, values(eventName) as Actions, values(awsRegion) as Regions by userIdentity.arn, sourceIPAddress
| where EventCount > 1
| sort - EventCount

Hunt for the APT29 pattern: mailbox audit bypass followed by email access on the same mailbox. Correlates Set-MailboxAuditBypassAssociation events with subsequent MailItemsAccessed operations on the targeted mailbox, identifying cases where an adversary disabled auditing before stealing email.

Hunting — KQL
kql
OfficeActivity
| where TimeGenerated > ago(30d)
| where Operation == "Set-MailboxAuditBypassAssociation"
| extend TargetMailbox = tostring(parse_json(Parameters)[0].Value)
| project TimeGenerated, UserId, TargetMailbox, ClientIP, ResultStatus
| join kind=inner (
  OfficeActivity
  | where TimeGenerated > ago(30d)
  | where Operation in ("MailItemsAccessed", "Send", "SendAs", "SendOnBehalf")
  | project MailAccessTime=TimeGenerated, MailboxOwner=UserId, Operation
) on $left.TargetMailbox == $right.MailboxOwner
| where MailAccessTime > TimeGenerated
| sort by TimeGenerated asc
Hunting — SPL
spl
index=o365 sourcetype="o365:management:activity" Operation="Set-MailboxAuditBypassAssociation"
| spath output=TargetMailbox path="Parameters{}.Value"
| table _time, UserId, TargetMailbox, ClientIP, ResultStatus
| join type=inner TargetMailbox [
  search index=o365 sourcetype="o365:management:activity" (Operation="MailItemsAccessed" OR Operation="Send" OR Operation="SendAs")
  | rename UserId as TargetMailbox
  | table _time, TargetMailbox, Operation
]
| sort _time

Hunt for privilege escalation followed by logging disruption within the same 1-hour window. Correlates IAM escalation events (CreateUser, CreateAccessKey, AssumeRole, AttachUserPolicy) with CloudTrail StopLogging or DeleteTrail from the same identity, identifying adversaries who first gain privileges then blind defenders.

Hunting — KQL
kql
AWSCloudTrail
| where TimeGenerated > ago(7d)
| where EventName in ("StopLogging", "DeleteTrail")
| extend TimeBucket = bin(TimeGenerated, 1h)
| join kind=inner (
  AWSCloudTrail
  | where TimeGenerated > ago(7d)
  | where EventName in ("CreateUser", "CreateAccessKey", "AssumeRole", "AttachUserPolicy", "PutUserPolicy")
  | extend TimeBucket = bin(TimeGenerated, 1h)
) on UserIdentityArn, TimeBucket
| project TimeGenerated, EventName, EventName1, UserIdentityArn, SourceIpAddress, AWSRegion
Hunting — SPL
spl
index=aws sourcetype="aws:cloudtrail" (eventName="StopLogging" OR eventName="DeleteTrail")
| bucket _time span=1h
| join type=inner userIdentity.arn, _time [
  search index=aws sourcetype="aws:cloudtrail" (eventName="CreateUser" OR eventName="CreateAccessKey" OR eventName="AssumeRole" OR eventName="AttachUserPolicy")
  | bucket _time span=1h
]
| table _time, eventName, userIdentity.arn, sourceIPAddress, awsRegion

Atomic Red Team Tests

Test 1 AWS CloudTrail StopLogging Simulation
linux

Uses the AWS CLI to stop logging on a CloudTrail trail named 'test-trail'. This simulates the most common adversary action after gaining privileged AWS access — disabling CloudTrail to blind security monitoring. The trail must exist in the account beforehand. This is the technique used by Pacu's detection__disruption module.

Command

bash
aws cloudtrail create-trail --name df00tech-test-trail --s3-bucket-name df00tech-test-bucket --no-is-multi-region-trail 2>/dev/null; aws cloudtrail stop-logging --name df00tech-test-trail

Cleanup

bash
aws cloudtrail start-logging --name df00tech-test-trail; aws cloudtrail delete-trail --name df00tech-test-trail

Expected Telemetry

CloudTrail event: eventName=StopLogging, eventSource=cloudtrail.amazonaws.com. The event record includes requestParameters.name (trail name) and userIdentity (acting principal). If forwarded to Sentinel, appears in AWSCloudTrail table.

Expected Detection

KQL: AWSCloudTrail query matches on EventName 'StopLogging'. SPL: Matched by eventName filter with SeverityScore=3 (highest).

Test 2 AWS GuardDuty DeleteDetector Simulation
linux

Uses the AWS CLI to delete a GuardDuty detector, disabling threat detection for the account/region. Adversaries commonly disable GuardDuty after gaining admin access to prevent detection of subsequent malicious API calls, crypto-mining, and network scanning.

Command

bash
DETECTOR_ID=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text 2>/dev/null); if [ "$DETECTOR_ID" != "None" ] && [ -n "$DETECTOR_ID" ]; then aws guardduty delete-detector --detector-id $DETECTOR_ID; fi

Cleanup

bash
aws guardduty create-detector --enable

Expected Telemetry

CloudTrail event: eventName=DeleteDetector, eventSource=guardduty.amazonaws.com. The requestParameters include the detectorId. This event will appear in AWSCloudTrail table in Sentinel.

Expected Detection

KQL: AWSCloudTrail query matches on EventName 'DeleteDetector'. SPL: Matched by eventName filter with SeverityScore=3.

Test 3 M365 Mailbox Audit Bypass via PowerShell
windows

Uses Exchange Online PowerShell to enable audit bypass on a test mailbox, replicating the APT29 technique of disabling mailbox auditing before stealing email. This command requires Exchange Admin permissions and a connected Exchange Online PowerShell session.

Command

powershell
powershell.exe -Command "Import-Module ExchangeOnlineManagement; Connect-ExchangeOnline -ShowBanner:$false; Set-MailboxAuditBypassAssociation -Identity '[email protected]' -AuditBypassEnabled $true"

Cleanup

powershell
powershell.exe -Command "Set-MailboxAuditBypassAssociation -Identity '[email protected]' -AuditBypassEnabled $false; Disconnect-ExchangeOnline -Confirm:$false"

Expected Telemetry

M365 Unified Audit Log: Operation=Set-MailboxAuditBypassAssociation, with Parameters showing the target mailbox and AuditBypassEnabled=True. Appears in OfficeActivity table in Sentinel.

Expected Detection

KQL: OfficeActivity query matches on Operation 'Set-MailboxAuditBypassAssociation'. SPL: Matched in o365:management:activity sourcetype.

Related Detections