A service account nobody owned.
And a second key nobody made.

The first question is not “is this malicious.”
It is “what is normal for this account.”

The Worker’s first query was not about the service account. It was about which of the 61 connected sources could say anything about a cloud identity at all. Thirteen could. Four of the places worth looking, Terraform state, source control, CI/CD, and Kubernetes manifests, could not be reached. That was written down before any conclusion depended on it.

The second query looked for the account’s creation event and returned nothing. The Cloud Logging sink keeps 400 days. The account is 1,269 days old. So the first real finding was a boundary: anything claimed about this identity before 2025-08-02 has to come from somewhere other than GCP.

Inside the window, the shape was unmistakable. 1,228 events. 1,191 of them from a single internal address, three operations, always in the 02:00 hour, on 397 of 399 nights. A backup job with a heartbeat.

Then the same query returned 37 events that did not fit any of that.

One row decided the case. On 2026-08-28 at 23:47 UTC, the service account created a new key for itself from a German hosting provider, and the call was authenticated with the production key. That is not an indicator. It is proof that the credential the nightly job has used since 2023 was in somebody else’s hands.

It also created the problem the rest of the investigation is about. The compromised credential and the production credential are the same credential.

Nobody remembering it does not mean it has no owner.

GCP was asked first and had nothing. Owner field empty on all 37 resource records. Labels empty. This is the ordinary condition of most cloud estates and it is exactly why the ticket existed.

One query against four other systems answered it. Not because the query was clever, but because those four systems were reachable in the same breath as the fifth.

Four queries, three systems, and the two questions the ticket could not answer were both closed. The owner left ten months ago and the team that owned it no longer exists. And disabling this account breaks the finance close reconciliation and the executive daily brief, silently, at 02:00, with nobody left to notice.

The change record also handed over the most important lead in the case, and the mesh could not follow it. The key is in a CI variable, on a pipeline, in a system that is not connected. That is recorded as an open question, not resolved with a guess.

The denied calls were worth more than the successful ones.

Thirty-six events on the new key across six days. Dataset enumeration across the project, then table enumeration against four datasets the account had never touched in 399 days. Twenty-four of those calls succeeded. Twelve were denied.

The twelve denials were all against customer_pii_restricted and hr_people_analytics. Zero denials in the preceding 393 days. A scheduled export job does not repeatedly probe datasets it has no permission on. Somebody was mapping what this credential could reach, and least privilege was holding at precisely the two datasets that mattered most.

The one restricted-adjacent dataset the credential could read, finance_close.gl_detail, it read. Six times.

Both source addresses geolocated to AS24940, Hetzner, Germany. No threat-intel records on either. The Worker declined to raise confidence on that and said why: a clean reputation on commodity hosting rented last week carries almost no information. The signal was the deviation from 399 days of baseline, not the address.

Data Access logging was off. So the honest answer is “I don’t know.”

Before writing any conclusion about data movement, the Worker checked what the source could actually see. Cloud Storage had Admin Activity logs and no Data Access logs, which is the GCP default: Data Access audit logs are opt-in per service, and in this project they had been turned on for BigQuery only.

So the nightly write to the export bucket is visible, and any read of that bucket is not. This account has written an export every night for eight days while under third-party control, and whether anything read it cannot be determined, and cannot be determined retroactively.

That is not softened into a low-likelihood judgement anywhere in the report. It is recorded as unanswerable, alongside what would change the answer.

• Open · unanswerable from connected sourcesHow the 2023 key was obtained. The change record puts it in a CI variable on the insights-v2 pipeline. That system is not in the mesh.
• Open · not loggedWhether the export bucket was read. Data Access logging was off for Cloud Storage. Turning it on fixes the future, not the past.
• Open · not connectedWhat else tf-modules/bq-export built. If the module ran more than once, there are sibling accounts in the same condition and nobody has looked.
• Open · outside retention870 days of this account’s life sit before the log window opens. The baseline is strong and it is 399 days long, not 1,269.

Thirteen months of nothing, then ten days.

Contain quietly. In this order, for these reasons.

Step 4 is the one that matters. Leaving a demonstrably compromised credential active for 72 hours has a real downside, taken to preserve visibility and to avoid breaking the finance close. The Worker does not make that call. It assembles the evidence, states the trade in the open, attaches five named tripwires that end the watch immediately, and hands it to the on-call incident lead.

What this case teaches the next cleanup ticket.