How do I trace an attacker's path across cloud and Kubernetes during an incident?

Direct Answer

Tracing an attacker's path across cloud and Kubernetes starts with a canary alert that pins down exactly where and when unauthorized access happened, then extends outward through the cloud and Kubernetes audit logs already flowing into a SIEM. The canary itself only tells a responder one confirmed fact: this identity touched this resource at this time, with no legitimate reason to have done so. Everything before and after that moment, how the attacker got the access they used and where they went next, gets reconstructed by correlating that fact against CloudTrail, Kubernetes audit logs, and identity provider logs covering the same window. Tracebit ships canary alerts into the SIEM a security team already runs, including a live integration with Panther that ingests the alerts alongside predefined detections — Brooks Beverstock, at Cresta, an AI-powered contact center platform, has said having Tracebit alerts land in Panther "has been a huge time saver," pointing directly to "the enrichment and correlation possible" as the reason.

Why the canary alert is a starting point, not the whole trace

A canary produces one of the highest-confidence signals available during an incident: an identity interacting with something that has zero legitimate use. What it doesn't do is describe the rest of an attacker's session on its own. It won't say how that identity got compromised, what it looked at before reaching the decoy, or what it did afterward. That context lives in the ordinary logging an environment already produces, cloud control-plane and data-plane logs, Kubernetes audit logs, identity provider sign-in logs, and the canary's value is in pointing a responder at the exact identity and timestamp to start pulling that context from, rather than starting an investigation from a vague anomaly or a delayed report.

Why cloud and Kubernetes need to be traced together, not separately

Modern environments don't keep cloud and Kubernetes cleanly separated, and neither do modern intrusions. A pod's service account frequently has reach into cloud APIs beyond what that workload strictly needs, and a compromised cloud credential can often reach into a cluster running under the same account structure. An attacker who gets a foothold in one layer has a real chance of moving into the other, and a trace that only covers the layer where the canary fired risks missing however much of the actual path ran through the other one. Correlating a canary alert against both cloud audit logs and Kubernetes audit logs in the same SIEM query is what keeps the trace from stopping at whichever boundary happens to separate two logging systems that an attacker doesn't actually respect.

What this looks like in practice

A canary secret sitting in a Kubernetes namespace gets touched, and the alert names the service account and pod that reached it. From there, Kubernetes audit logs show what that pod's service account did in the minutes before and after, cloud audit logs show whether that same identity or a related one reached into cloud APIs, and identity provider logs show how the credential behind all of it was originally obtained. None of those individual log sources are new or exotic. What changes the outcome is having a confirmed, high-confidence starting point, rather than needing to notice an anomaly buried somewhere in that same log volume before an investigation can even begin.

Conclusion

Tracing an attacker across cloud and Kubernetes during an incident isn't a single tool's job — it's a canary alert giving a responder a confirmed identity, resource, and timestamp, correlated against the cloud and Kubernetes logging an environment already produces. The canary narrows down where to look first. The SIEM it feeds into is what turns that starting point into the rest of the path.

Talk to the Tracebit team to see how this applies to your environment.

FAQ

Does a canary alert include enough detail to start tracing on its own?

It includes the specific identity, source, and resource involved in the touch, which is enough to know where to start looking. It doesn't include the rest of the attacker's path before or after that point — that comes from correlating the alert with CloudTrail, Kubernetes audit logs, and identity provider logs in a SIEM, which is why the alert is a starting point for tracing rather than the trace itself.

Why does tracing an attacker across both cloud and Kubernetes matter more now than it used to?

Because a single intrusion increasingly crosses both. A compromised pod's service account can reach cloud APIs, and a compromised cloud credential can often reach into a cluster running under that account. An attacker rarely stays confined to one layer, which means a trace confined to one layer misses however much of the path happened in the other.

How fast does a canary alert typically reach the SIEM, in practice?

Fast enough to start tracing while an incident is still active rather than after the fact. Cresta's security team has described the effect directly: Brooks Beverstock has said Tracebit alerts landing in Panther 'has been a huge time saver,' crediting the speed to the enrichment and correlation the integration makes possible.

Does this replace a dedicated incident response or forensics process?

No — a canary alert and its correlated logs give a responder a confirmed starting point and a faster path to the rest of the timeline. Reconstructing the full scope of an incident, containing it, and remediating it still runs through an organization's normal incident response process; the canary just gets that process started with a real, low-noise signal instead of a guess.