Cloud Token Theft: Identity Under Siege

Before you can separate the attacker's token-replay sessions from normal activity, you need a reliable signal for what a clean, successful interactive logon looks like in the Windows security log. Examine marcus.aurelius's early sign-ins on corp-wks-8821 from the period before any cloud enumeration began, and determine the numeric Windows event identifier that records a successful logon. Every malicious sign-in later in this intrusion produces the same identifier, so pinning it down now is what lets you triage the rest.

With a trustworthy logon signal established, start walking the intrusion forward from the workstation into the cloud estate. Azure network telemetry flagged an unusual inbound connection reaching the production application server srv-app-prod-01 that does not match its normal traffic profile. Examine the cloud NSG flow event for that connection and identify the internal source IP that originated the pivot, so you can confirm which foothold the attacker is operating from.

Having confirmed the attacker's foothold, look for how they escalated. The Azure AD sign-in logs show a successful authentication on the emergency break-glass admin account against production infrastructure — an account that should almost never be used. This is not an external-C2 lead: the sign-in came from inside the environment. Examine the relevant SIEM / Azure AD sign-in record and identify the internal source address the break-glass login originated from.

From the compromised foothold, the attacker turned their attention to the container platform. Process monitoring on the Kubernetes node k8s-node-primary-01 recorded a command-line tool reaching out to the cluster's API server — activity that does not match the node's normal control-plane processes. Review the SIEM process and network-connection events for that host and determine which executable the attacker used to interact with the orchestration layer.

With cluster access and a foothold confirmed, the attacker began harvesting cloud identity data. An AzureHound Microsoft Graph enumeration run by the dev_ops_automation service account redirected its results to a local staging file so it could be exfiltrated later. Working from the process-creation and file-creation telemetry on corp-wks-8821, recover the full output path the attacker wrote that enumeration data to.

Days after the AzureHound harvest, endpoint telemetry flagged the attacker — operating as marcus.aurelius — dumping sensitive Kubernetes cluster material to disk on corp-wks-8821. The contents were written to a local temporary directory ahead of exfiltration. Find the file-creation telemetry for this event and recover the full path the attacker staged the cluster secrets to.

Continuing the harvest, the attacker mapped the cloud estate with AzureHound on corp-wks-8821 and went hunting for application credentials that would unlock the srv-app-prod-01 server. Endpoint telemetry then caught a small configuration file — the kind that typically holds a web app's secrets and environment variables — being copied off the app server and staged in a local Temp directory. Examine the file-creation telemetry and identify the exact artifact the attacker staged.

Everything so far points to one outcome: the attacker staged cloud identity data, cluster secrets, and application credentials for removal. The final question for the incident report is whether the perimeter stopped them. After the Goblob enumeration tool ran on the compromised workstation corp-wks-8821 (10.0.1.134), outbound connections were observed heading to an external destination. Inspect the firewall record for that egress and report the verdict the perimeter applied to it.