Cloud logs are the first thing a competent intruder checks and, if they have the permissions, the first thing they turn off. Unlike an on-host EDR kill, disabling CloudTrail or deleting an Azure diagnostic setting doesn’t require a driver exploit or admin rights on an endpoint — it just requires an IAM policy that was scoped too loosely. MITRE tracks this under T1562.008, Impair Defenses: Disable or Modify Cloud Logs, and it shows up early in cloud intrusions precisely because it’s cheap and it buys the rest of the operation cover.

The technique is not subtle once you’re looking for it. The problem is that most organizations aren’t looking, because the events that indicate tampering are rare, low-volume management-plane calls buried in an ocean of routine API activity. That rarity is exactly what makes them high-fidelity detections — a StopLogging call has essentially no legitimate high-frequency use case in a mature environment.

What Attackers Actually Do

AWS. CloudTrail is API-driven, so disabling it is a single call. Adversary tooling (including reconnaissance frameworks like Pacu) will enumerate active trails via DescribeTrails/GetTrailStatus before touching them. The actual impairment shows up as StopLogging (halts delivery entirely), DeleteTrail (removes the trail object), or UpdateTrail (narrows scope — disabling multi-region logging, turning off log file validation, or redirecting delivery to an attacker-controlled S3 bucket). GuardDuty tampering is a close cousin: CreateIPSet/UpdateIPSet calls can whitelist attacker infrastructure out of alerting.

Azure. The platform Activity Log itself can’t be turned off, but the diagnostic settings that export it (and resource-level logs) to a Log Analytics workspace, storage account, or Event Hub can be deleted or reconfigured. The operation name to watch is MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE, with .../WRITE covering scope changes such as dropping specific log categories.

GCP. Admin Activity audit logs can’t be disabled, but Data Access logs can be excluded via IAM policy, and log sinks that route logs to SIEM/export destinations can be modified or deleted through google.logging.v2.ConfigServiceV2.UpdateSink and .DeleteSink.

Detection: AWS CloudTrail Logging Disabled

title: AWS CloudTrail Logging Stopped or Deleted
id: 7a91c3de-5f28-4b9a-8e6d-1c4f9a2b7d3e
status: experimental
description: Detects CloudTrail StopLogging, DeleteTrail, or UpdateTrail calls that reduce or eliminate log coverage, consistent with T1562.008.
references:
  - https://attack.mitre.org/techniques/T1562/008/
author: SOC Analyst Hub
date: 2026/08/21
tags:
  - attack.defense_evasion
  - attack.t1562.008
logsource:
  product: aws
  service: cloudtrail
detection:
  selection_stop:
    eventSource: cloudtrail.amazonaws.com
    eventName:
      - StopLogging
      - DeleteTrail
  selection_update:
    eventSource: cloudtrail.amazonaws.com
    eventName: UpdateTrail
    requestParameters|contains:
      - '"IsMultiRegionTrail":false'
      - '"EnableLogFileValidation":false'
  condition: selection_stop or selection_update
falsepositives:
  - Deliberate trail decommission during account offboarding, tracked via change management
  - Terraform/CloudFormation drift correction runs
level: critical

KQL for Microsoft Sentinel (ingesting AWSCloudTrail):

AWSCloudTrail
| where TimeGenerated > ago(7d)
| where EventSource == "cloudtrail.amazonaws.com"
| where EventName in ("StopLogging", "DeleteTrail", "UpdateTrail")
| where EventName != "UpdateTrail" or RequestParameters has_any ("IsMultiRegionTrail\":false", "EnableLogFileValidation\":false")
| project TimeGenerated, EventName, UserIdentityArn, SourceIpAddress, AWSRegion, RequestParameters
| order by TimeGenerated desc

Detection: Azure Diagnostic Settings Deleted or Scoped Down

AzureActivity
| where TimeGenerated > ago(7d)
| where OperationNameValue in~ (
    "MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE",
    "MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/WRITE")
| where ActivityStatusValue == "Success"
| project TimeGenerated, OperationNameValue, Caller, CallerIpAddress, ResourceId, SubscriptionId
| order by TimeGenerated desc

Pair this with a baseline: diagnostic setting deletions are infrequent enough in most tenants that a single hit outside a known change window warrants a ticket. Correlate the Caller identity against recent sign-in risk and privilege-escalation activity (new role assignments, PIM elevation) in the preceding hour — tampering with logging is rarely an isolated action.

Detection: GCP Audit Log Sink Modified or Deleted

title: GCP Logging Sink Deleted or Updated
id: 2d5e8f14-9c3a-4b7d-a1f6-6e2c8b4d0f9a
status: experimental
description: Detects deletion or modification of GCP log sinks that route Admin Activity or Data Access logs to external destinations.
author: SOC Analyst Hub
date: 2026/08/21
tags:
  - attack.defense_evasion
  - attack.t1562.008
logsource:
  product: gcp
  service: gcp.audit
detection:
  selection:
    protoPayload.methodName:
      - google.logging.v2.ConfigServiceV2.DeleteSink
      - google.logging.v2.ConfigServiceV2.UpdateSink
  condition: selection
falsepositives:
  - Planned sink migrations during log pipeline changes
level: high

Hunt Notes

  • Treat these events as tripwires, not just alerts — build a standing hunt query that runs weekly even if the alert is silent, since a well-resourced actor with valid credentials may operate under your detection threshold for tuning purposes.
  • Cross-reference the identity performing the tampering against recently created or modified IAM roles/service principals. Log-disabling is frequently the second or third action after privilege escalation, not the first.
  • If logging was disabled for any window, treat that window as a blind spot requiring compensating evidence — VPC flow logs, EDR telemetry on any touched hosts, and billing/usage anomalies can partially reconstruct activity that CloudTrail or Activity Log missed.
  • Multi-cloud environments should alert on any of these three regardless of which cloud is “primary” — actors pivoting through federated identity often hit whichever provider has the weaker logging guardrails.