Contribution
This post adds original detection content: a three-part cloud audit pattern for log tampering that starts with identity use, watches the logging plane, and then checks whether data access follows the visibility gap. Unit 42 explains how attackers can stop, delete, poison or redirect cloud logging. Microsoft shows why that matters in a real cloud breach: once an identity is compromised, legitimate control-plane features can carry the attack all the way to secrets and storage. The synthesis here is the join between those two ideas: do not alert on log changes as isolated admin events, alert on log changes as the bridge between valid-account access and data theft.
The pattern
Unit 42's June 2026 research puts a useful label on a cloud behaviour defenders often treat as a configuration problem. Cloud logging is not only a record of the incident after the fact. It is a target. If an attacker can change CloudTrail, Google Cloud Logging, log buckets, sinks, keys or destinations, they can blind the systems that would otherwise reconstruct the attack.
The research describes two attacker goals. The first is defence impairment: stop the logs, delete the storage destination, remove the router, break encryption dependencies or poison records so that investigation becomes harder. The second is attacker visibility: route a copy of logs to infrastructure the attacker controls, so they can watch the victim environment while they decide what to touch next. Both goals sit on the same control plane as ordinary administration, which is why a single event name is not enough.
The easy AWS example is cloudtrail:StopLogging, but the broader pattern is wider. A trail can be deleted. A destination bucket can be emptied or removed. A logging encryption key can be disabled or controlled in a way that prevents delivery. In Google Cloud, a sink can be disabled, a filter can be narrowed until it drops useful events, a log bucket can be marked for deletion, or a destination can be changed. Microsoft 365 and Azure add their own variants: mailbox audit bypass, audit downgrades, diagnostic setting changes, and changes to where platform logs are exported.
Microsoft's Storm-2949 write-up gives the other half of the problem. That incident began with compromised identities and social engineering around password reset and MFA flows, then moved into cloud and SaaS data access. The actor did not need malware for the cloud part of the chain. They used legitimate management features across Microsoft Entra ID, Microsoft 365 and Azure: publishing profiles, Key Vault access changes, SQL firewall changes, Storage account keys, VM extensions and cloud data access. That is the right mental model for log tampering too. A compromised identity can use ordinary administration to create an extraordinary blind spot.
Treat those two source sets together and a better research question appears. The most important signal is not only "CloudTrail stopped" or "a sink changed". It is "who had to authenticate first, what did they inspect, what did they do to logging, and what data action happened after visibility weakened?" Most detections stop at the logging event. A stronger hunt treats the logging event as the hinge in a chain.
Why it matters to cloud defenders
Cloud defenders care because the blast radius is larger than the logging service itself. Cloud audit logs feed SIEM rules, case timelines, data-loss alerts, compliance evidence, detection coverage reports and post-incident root-cause work. If those logs are weakened at the wrong moment, every downstream control becomes less reliable.
That is especially true in environments where the same privileged identity family can touch both production data and the telemetry pipeline. A platform administrator might have rights to tune diagnostic settings, rotate keys and read storage. A break-glass role might have rights to repair logging in an outage. A CI identity might be able to update infrastructure-as-code that manages both an application account and its log exports. Those privileges are not always wrong, but they need a different detection shape from routine console activity.
A13E's audience should also care because this is a cloud-control-plane problem, not a purely endpoint problem. Endpoint tools may never see the decision to stop a trail or redirect a sink. Network tools may only see normal API calls to AWS, Azure or Google Cloud endpoints. The authoritative trace is in CloudTrail management events, Azure Activity and diagnostic setting records, Microsoft 365 audit records, Entra sign-in and audit logs, Google Cloud Admin Activity logs, Google Cloud Logging activity, and the storage or key-management logs that surround them.
There is a timing issue too. A logging change is often an early action, not a closing action. An attacker who plans to steal data has a reason to reduce visibility before the large read or export. A defender who waits for the data event has already lost the best chance to contain the chain cleanly. The useful alert fires when a newly risky identity touches the logging plane, then escalates if data access follows.
The hard part is false positives. Administrators do stop, delete and rebuild logging resources during migrations, outages and cost-control work. Security teams change sink filters and destinations when onboarding a new SIEM. Cloud platform teams rotate keys and adjust bucket retention. A detection that treats every logging change as an emergency will train analysts to ignore it. A detection that joins identity context, change context and follow-on data access has a better chance.
ATT&CK mapping
The central technique is T1685.002, Disable or Modify Cloud Log. ATT&CK v19 moved this behaviour into the Defense Impairment tactic, which fits the cloud reality better than treating it as a footnote under generic impairment. The technique covers disabling or modifying cloud logging, audit and monitoring capabilities so the attacker can reduce what defenders collect about their activity.
That is the hinge, not the whole chain. The entry in many real cases is T1078.004, Valid Accounts: Cloud Accounts. Storm-2949 is a clean example of why. The first useful defender signal is not a binary exploit. It is a legitimate identity behaving outside its normal boundary after social engineering or credential theft. In AWS that may be a role session or IAM user suddenly changing logging. In Azure it may be a privileged user, service principal or managed identity changing diagnostic settings after an unusual sign-in. In Google Cloud it may be a service account changing sinks or buckets from a source it has not used before.
The payoff is often T1530, Data from Cloud Storage, or a related SaaS data-access technique kept in prose when the exact ATT&CK page is not part of the current library set. Microsoft's case moved through cloud secrets and storage access after identity compromise. Unit 42's scenarios describe log changes that can precede exfiltration or leave defenders unable to prove it. Mapping the payoff matters because log tampering without a following data action may be a risky admin change. Log tampering followed by storage reads, Key Vault access, BigQuery export jobs, SharePoint downloads or database firewall changes is an incident until proven otherwise.
There is also a visibility branch. If a sink or destination is changed to copy logs elsewhere, the attacker is not only hiding. They may be watching. That behaviour still sits under T1685.002 for the logging modification, but the defensive question changes: what external account, bucket, project, subscription, workspace or tenant now receives records about the victim environment? The modified logging path becomes a reconnaissance aid.
This end-to-end mapping keeps the post honest. T1685.002 is the research spine. T1078.004 explains how the actor obtains the right to touch logging. T1530 explains why a logging blind spot is often followed by data access. Listing only the logging technique would miss the entry and the outcome; listing every possible cloud-data technique would turn the article into a taxonomy dump. Three techniques are enough for the chain the sources support.
Detection guidance
Build the hunt around sequence and ownership. Start with every successful change to cloud logging configuration, then add identity and data context around it. A practical window is 30 minutes before the logging change and 90 minutes after it, widened for environments where automated deployment jobs run slowly.
For AWS, begin with CloudTrail management events where eventSource is cloudtrail.amazonaws.com, logs.amazonaws.com, s3.amazonaws.com, kms.amazonaws.com or related monitoring services. High-signal event names include StopLogging, DeleteTrail, UpdateTrail, PutEventSelectors, PutInsightSelectors, changes that remove multi-region coverage, S3 bucket deletion or policy changes on log buckets, KMS key disablement affecting trail delivery, and EventBridge or CloudWatch changes that remove forwarding. Splunk's public StopLogging analytic is a useful narrow starting point because it keys on successful StopLogging where the user agent is not the AWS console. Use that as one detector, not the whole programme.
For Google Cloud, look at Admin Activity logs for logging.sinks.update, sink deletion, bucket deletion state changes, destination changes, filter changes that drop high-value services, and permission changes on log destinations. Watch for changes to log buckets, log views and the storage buckets that receive exported records. A filter that suddenly excludes cloudaudit.googleapis.com/activity, data_access records or a production project should be treated as a visibility-impacting change, even if logs still flow somewhere.
For Azure and Microsoft 365, cover Azure Activity events for diagnostic setting creation, deletion and update, Event Hub or Log Analytics destination changes, storage destination changes, and management-group or subscription policy changes that affect audit export. Join those to Entra audit and sign-in logs. In Microsoft 365, watch for audit bypass or audit-retention changes on mailboxes and users with high-value data access. The exact event names vary by tenant configuration, so the first implementation should inventory current audit and diagnostic-setting records before writing hard filters.
Now add the chain logic. For the same actor, role, service principal, source IP, device, user agent or session, ask four questions.
First: was the identity newly risky? Examples include first use from a new ASN or country, MFA not used where it normally is, new device registration, fresh role assignment, consent grant, password reset, privileged role activation, or first use of an automation identity outside its known runner.
Second: did the identity inspect the environment before the logging change? Look for role, policy, bucket, project, subscription, diagnostic setting, sink, Key Vault, Storage and database discovery. A logging change that follows discovery is more suspicious than a logging change issued by a known deployment job with no surrounding exploration.
Third: did the logging change reduce defender visibility or copy it somewhere new? Classify the change. Stop, delete, narrow, disable, redirect, weaken retention, weaken encryption, remove validation, change destination, change filter. Store the before and after values in the alert so the analyst does not have to rebuild them from raw JSON.
Fourth: did sensitive data access follow? In AWS, check S3 object reads, Secrets Manager reads, snapshot export and unusual STS chaining. In Azure, check Key Vault secret access, Storage reads, SQL firewall and query activity, App Service publishing profile retrieval, and Graph or SharePoint downloads. In Google Cloud, check BigQuery jobs, Cloud Storage reads, Secret Manager access and service-account token generation. The strongest alert is not the logging event alone. It is a newly risky identity, followed by logging impairment, followed by data access.
False-positive tuning should be strict but narrow. Suppress known infrastructure-as-code pipelines by role, source network, repository, change window and expected event names. Do not suppress the same role globally. If a Terraform job normally updates diagnostic settings but never reads Key Vault secrets, a diagnostic change plus Key Vault read should still fire. If a security engineer stops a non-production trail during a ticketed migration, suppress that ticketed trail and time window, not every future StopLogging event from the person.
Add a second class of alert for attacker visibility. Trigger when a sink, trail, diagnostic setting or export destination points to a new account, bucket, project, subscription, workspace, Event Hub, storage account or external principal. Then check whether that destination is owned by the organisation, whether it is in the approved log-archive account, and whether its policy allows external readers. Many teams only check whether logging is on. They also need to check where the logs go.
What to do now
First, inventory the logging plane. List every CloudTrail trail, CloudWatch or EventBridge forwarder, S3 log bucket, KMS key used for log delivery, Azure diagnostic setting, Log Analytics workspace, Event Hub export, Google Cloud sink, log bucket, log view and export destination. Mark the owner, expected writer, expected destination and whether the destination is immutable or locked.
Second, write the first detector as a change-and-context rule. Start with T1685.002 logging changes, then join the actor to sign-in and privilege context, then join forward to storage, secrets and database access. Keep the output readable: actor, source, old logging state, new logging state, destination, preceding identity risk, following data access, and known change ticket if one exists.
Third, move high-value logs away from ordinary production administration. Use separate log-archive accounts or projects, object lock or retention locks where available, restricted key administration, and alerts on destination changes. The point is not to make logging impossible to change. The point is to make a production identity unable to both steal the data and erase the witness.
Finally, rehearse a response. When the alert fires, preserve the last good logs, snapshot the current logging configuration, restore delivery if it was stopped, revoke the suspicious credential, and check whether the same actor touched data stores after the blind spot began. The attacker may have changed the lights, but they still had to reach for the switch.