GCP log sink deleted? Detecting defense evasion in logs

TL;DR. An attacker with Owner rights will try to blind you: DeleteSink or UpdateSink on the sink feeding your SIEM, CreateExclusion, UpdateBucket / DeleteBucket on log buckets, DeleteLog, an IAM policy update that removes the Data Access audit config (auditConfigDeltas REMOVE), and Security Command Center notification configs deleted. Every one of these is itself an Admin Activity entry, kept 400 days in a bucket the attacker cannot touch. Look for them first: their timestamp often marks the end of the visible part of the attack.

In MITRE ATT&CK, this is T1562.008, Impair Defenses: Disable or Modify Cloud Logs, and T1070, Indicator Removal when logs are deleted.

What an attacker cannot remove

Start with the good news, because it shapes the investigation. Cloud Logging routes Admin Activity, System Event and Access Transparency logs to the _Required bucket through the _Required sink, which "can't be modified or deleted"; the bucket keeps them 400 days (routing overview, quotas).

So even after a full takeover, the project still holds a record of every configuration change, including the ones that disabled everything else. What the attacker can affect is everything outside _Required: your exports, your Data Access logs, your alerting.

The techniques and their log entries

Two more changes are worth reviewing although they are not strictly logging: v1.compute.firewalls opened to 0.0.0.0/0 (T1562.007), and organization policies relaxed (see SetIamPolicy abuse).

Reading the audit config delta

Data Access logging is configured in the auditConfigs section of the IAM policy (configure Data Access audit logs). Turning it off is therefore a SetIamPolicy call, and the change appears in the policy delta next to the binding deltas:

"policyDelta": {
  "auditConfigDeltas": [
    { "action": "REMOVE", "service": "storage.googleapis.com", "logType": "DATA_READ" }
  ]
}

A REMOVE for allServices or for storage.googleapis.com right before a burst of activity is a strong signal. Adding an exempted member is subtler: the principal stops generating Data Access logs for that service while everyone else continues.

What the timestamp tells you

Defense evasion often comes late in the attack: the attacker does what they came for, then cleans up. In practice:

• Everything before the evasion step is visible everywhere (SIEM, sink bucket, project).
• Everything after is visible only in what the attacker could not change: _Required in the project, and any organization-level aggregated sink they had no rights on.

So after a DeleteSink, do not conclude from the SIEM that activity stopped. Export directly from the project, and from the organization sink if one exists.

Designing logging an attacker cannot switch off

The long-term fix is architectural, and Google describes the building blocks:

• An aggregated sink at the organization or folder level, routing audit logs of every project to a central project that workload owners have no rights on (central log storage).
• A log bucket with a locked retention policy in that project (configure log buckets); locking is irreversible, and a locked bucket cannot be deleted until every entry in it has reached the retention period.
• Data Access logs enabled at the organization level, at least for IAM, Cloud Storage and Secret Manager.
• Alerts on the methodNames in the table above.

What the analyzer flags

When these findings come from the same IP or principal as earlier access findings, the analyzer raises the critical "attack chain" correlation. The checklist then asks to restore the sinks and audit configuration and to add an organization-level sink to a locked bucket.

Legitimate changes

Platform teams do modify sinks and exclusions, typically through Terraform, from CI, during working hours, with a change ticket. An exclusion that drops noisy load-balancer logs is normal; an exclusion that matches protoPayload.authenticationInfo.principalEmail of a single user is not. Read the filter.

Frequently asked questions

Can an attacker delete Google Cloud audit logs?

Not the Admin Activity and System Event logs held in the _Required bucket: its sink cannot be modified or deleted and the bucket keeps them 400 days. An attacker with enough rights can delete sinks that copy logs elsewhere, add exclusions, disable the _Default sink, change log buckets, delete log entries held in the _Default bucket, and turn off Data Access logging.

Is deleting a log sink itself logged?

Yes. google.logging.v2.ConfigServiceV2.DeleteSink is an Admin Activity audit log entry, so the deletion is recorded in the _Required bucket with the caller and IP.

Further reading

• Route log entries (routing overview) — Google Cloud documentation.
• Best practices for Cloud Audit Logs — Google Cloud documentation.
• GCP Data Access logs: off by default and other blind spots.