prod-gcp-audit · sample

SetIamPolicy appears 847 times in this sample window versus 3–4/day in the scenario history. One service account granted Owner access to 12 fictional projects between 02:00–03:15 UTC. This pattern warrants verification as a possible privilege-escalation sequence; it does not establish compromise.

This example source IP is first-seen in the available 30-day scenario context. All 23 API calls from it succeeded. That combination warrants source-system and identity verification; Flare has not independently established the IP reputation or credential owner.

PERMISSION_DENIED errors reached 340 in 15 minutes, 98× the scenario’s daily average of 3.5. Dense access failures followed by permission changes can fit a scanning hypothesis, but the sequence requires source-system verification.

The available 30-day scenario context contains only read-only storage operations for this service account. SetIamPolicy and CreateServiceAccountKey are first-seen actions in that context and should be verified with the identity owner before treating them as unauthorized.

A service account key was created for pipeline-sa minutes after the first SetIamPolicy calls. If unauthorized, a long-lived key could preserve access, so verify its creator and intended use before following the organization’s containment procedure.

The disaster-recovery backup project received 34 API calls in this window, unusually high for a project that typically sees 0–2 calls/day. Combined with the escalation activity in the main project, this may indicate lateral movement.