Turning the lights off first: GCP log sink and audit-config tampering
An attacker deletes the SIEM export sink and disables Data Access logs before the real work. The tampering itself is recorded in always-on Admin Activity logs.
A smart attacker turns the lights off before doing the real work. In GCP that means deleting your export sink and disabling Data Access audit logs. The question is how you ever know what happened in the dark.
How the attack works
An attacker who has impersonated a service account with logging admin rights moves to blind detection first. They delete the aggregated log sink that exported audit logs to the SIEM, then run SetIamPolicy to remove DATA_READ and DATA_WRITE logging on key services via the IAM audit config. Subsequent reads and admin actions are no longer captured, and they act quietly in that dark window. Crucially, the DeleteSink and the audit-config change are themselves recorded in Admin Activity logs, which are always on and cannot be disabled. In ATT&CK terms this is T1562, Impair Defenses, paired with T1070, Indicator Removal.
Why it works
Ordinary identities could change logging configuration, and Data Access logging is not retroactive. Once it is off, the reads it would have recorded are simply never written, which is exactly the deception the attacker is engineering.
How to fix it
Recreating the sink is not enough, because the identity still holds the rights to delete it again. Revoke its logging admin role and impersonation rights, restore the sink and audit config from policy-as-code, and enforce that config so a silent re-disable is blocked or reverted. For the root cause, lock logging-admin and audit-config changes behind break-glass with approval, manage sinks and audit config as enforced policy-as-code, and turn the always-on DeleteSink and auditConfig events into high-priority alerts. Reconstruct the dark window from those always-on Admin Activity logs plus durable downstream artifacts, and remember that absence of Data Access logs is not absence of access: reason from the maximum exposure the identity could reach.
Practice it
We built this as a GraphLattice Range scenario so responders can rehearse detecting log tampering from the always-on admin trail and hunting the blinded window.