One Exposed AWS Access Key Expanded into Multi-Account Compromise in 72 Hours

1 Once the first key appeared, responders were no longer following one path; they were watching new attack waves start from every credential

In one observed second, four different access keys belonging to four AWS accounts were used from the same source IP and with the same user agent. That single cluster is where this investigation becomes visible as a race rather than a conventional sequence. One identity had already become several, several accounts were active together, and a responder looking only at the first key would have been reading history while other branches continued to move.

To understand how the four lanes formed, the story has to rewind to an Internet-facing application. Sygnia's detailed investigation, dated June 29, 2026, states that a weakness in that application exposed a long-lived AWS access key. The actor used it to identify the principal and its permissions, enumerate reachable services, and search for more secrets. Each new key opened another identity and authorization context—sometimes in another account—restarting discovery, collection, persistence, data access, and impact from a fresh point.

The resulting expansion occupied roughly seventy-two hours from initial access to broad compromise. It did not depend on a previously unknown zero-day or novel malware. AWS APIs, application databases, ECS and EC2 workloads, GitHub and Bitbucket runners, S3 objects, Secrets Manager, SSM Parameter Store, deployment scripts, infrastructure templates, and container images became one connected identity-and-secret environment. At the data layer, the actor ran several hundred distinct SQL statements across dozens of databases; elsewhere, rapidly adapted scripts and structured artifacts retained context across parallel workstreams.

Sygnia assesses the pattern as consistent with AI-assisted or agentic workflows. The evidence supports centralized automation, rapid scripting, environmental analysis, and task management as force multipliers. The public record does not provide a technical transcript proving that an unsupervised autonomous system conducted every action. This report preserves that boundary between direct telemetry and analytical attribution.

The seventy-two hours describe an approximate span from initial access to broad compromise, not a defensive countdown or a claim that activity stopped at that point. The decisive window can be only minutes: one identity reads a secret and a child identity begins to act. The first key is therefore the root of an identity dependency tree, not an isolated indicator. Even after it is disabled or goes quiet, its sessions, derived credentials, and account branches still require pursuit. Scoping and containment must proceed together.

The story that follows therefore stays anchored to state changes. An application-held secret became an AWS identity; that identity exposed additional secret-bearing surfaces; some of those secrets became new identities; those identities changed access, workloads, deployment artifacts, application users, data, and service availability. At every turn, the report asks what evidence establishes the transition, what uncertainty remains, and what action closes the path. That structure is more useful than arranging the same facts under a generic list of cloud tactics.

1.1 The public case study contains a strong behavioral chain and deliberately omits customer identifiers and reusable credentials

Sygnia does not disclose the customer, the vulnerable application's name, a vulnerability identifier, AWS account numbers, key values, source IP, complete user-agent string, database table names, or a second-by-second timeline. SOSEC therefore does not manufacture those indicators, assign the entry point to a CVE, or infer an industry. Public readers can verify the disclosed mechanisms without receiving customer-sensitive material.

We use “observed” for actions that the report explicitly lists: secret harvesting from named surfaces, IAM and runtime persistence, deployment and infrastructure changes, privileged application users, RDS queries, S3/ECS/ACL/SQS impact, and the four-key concurrent activity. We use “assessment” for AI assistance, operational memory, and agentic orchestration. The distinction is maintained throughout the article.

The seventy-two-hour interval does not provide a public timestamp for every technique. The diagrams show dependencies without inventing hour marks; an affected organization must reconstruct exact UTC timing from CloudTrail, identity, source-control, CI/CD, database, application, network, and workload telemetry. Later implementation guidance uses AWS and platform documentation and does not imply that the affected customer deployed or lacked a particular control.

The evidentiary boundary has a practical consequence. “The principal could read a secret” is a capability conclusion; “the principal called the read API” is an access event; “the returned value was then used” requires a matching authentication or activity record at the destination. These statements support different impact levels. A response team should rotate on credible exposure without waiting for destination use, but a public or regulatory conclusion about accessed data should preserve the difference between permission, attempted access, successful response, returned records, and confirmed transfer.

What the public record does not disclose cannot be filled with a plausible product name; those gaps are part of the finding. Because the application, vulnerable component, source path, release, and fix are undisclosed, this report can identify the exposed trust boundary and the cloud-side actions but cannot honestly name a vulnerable function or patched version. The dedicated location-and-response panel later in this chapter makes that absence explicit and replaces invented code detail with the precise operational locations that an affected organization can verify.

2 The application exposure yielded a durable AWS API identity rather than a temporary web session

The public report states that a weakness in an Internet-facing application exposed an AWS access key. That transition matters more than the undisclosed application detail. A key pair can sign AWS API requests from a different machine and can remain valid until disabled. The policies and trust relationships of the associated IAM identity determine the first visible portion of the cloud.

The first investigation record should preserve eventTime, eventSource, eventName, awsRegion, sourceIPAddress, userAgent, userIdentity, accessKeyId, request parameters, response elements, error code, request ID, and event ID. The access-key ID is a correlation value; the secret half should never appear in an operational log.

An application key may have months of legitimate S3 or queue activity. Detection should compare source network, client, region, service mix, call rate, denied enumeration, new resource access, and time of day with that history. A single identity call from a new address is a clue. A rapid sequence of permission discovery, secret listing, and sensitive reads gives it incident context.

Response cannot stop after deleting a value from application configuration. Disable the compromised key and handle issued sessions, then search container environments, image layers, logs, error pages, caches, object storage, databases, CI variables, backups, and developer systems for copies. Every still-valid copy can become another starting point if it reaches a different actor or process.

The durable design removes long-lived keys from AWS workloads and uses roles with short-lived credentials. External CI uses OIDC with constrained audience, subject, repository, branch, and environment claims. Short-lived sessions can still be stolen, but expiration, session identity, conditional policies, and narrowly scoped trust substantially reduce replay time and ambiguity.

The access-key ID is a correlation identifier in CloudTrail and IAM reports; the secret half is authentication material and should never enter tickets, chats, queries, or screenshots. If comparison is necessary, use a controlled one-way fingerprint and retain only the identifier and result. Disabling the long-lived key stops it signing new requests but does not revoke STS sessions, workload identities, or external tokens already derived from it, so every descendant credential requires its own row and closure test.

Root-cause closure also has to explain why the application made the credential retrievable. The public record does not choose among response disclosure, arbitrary file read, command execution, debug output, backup exposure, or deployment error. The affected owner must pin the actual release, route, task, configuration revision, and secret-injection path, preserve the vulnerable state, repair it, and prove with unauthenticated or low-privilege requests that the value is no longer reachable. A replacement should be issued only after permission reduction, trust redesign where possible, and a trusted redeployment that no longer copies the value into logs, diagnostics, backups, or image layers.

2.1 Each new credential restarts discovery, identity conversion, and a concurrent attack wave

sts:GetCallerIdentity can reveal account and principal. Read-oriented APIs across IAM, Organizations, EC2, ECS, S3, RDS, Secrets Manager, SSM, and deployment services expose resources within the identity's view. Denied requests also provide information about available services, guessed resources, and policy boundaries. Discovery is a conversation with authorization, including its errors.

Effective permission is not one attached policy. Identity policy, resource policy, permission boundary, session policy, service control policy, role trust, and explicit denial interact. Investigators should derive capability from actual calls and complete authorization context rather than treating an IAM policy name as a reliable summary of what the stolen identity could reach.

The next identity may be an AWS key, database password, personal access token, SSH key, OAuth token, signing key, webhook secret, or service credential. Sygnia found candidate material in managed secret stores, container and instance environments, runner environments, S3 objects, and application databases. Each discovery can cross an account, vendor, or organizational team boundary.

Organizations need an identity-to-secret-to-resource graph before an incident. It records which workload can read which secret, what platform and permission the secret opens, and which deployment, data, or identity objects that principal can modify. The graph is equally useful for blast-radius estimation and for deciding which consumers must move during rotation.

Detection can model the same questions. A new-source identity confirmation followed by broad cross-region enumeration, secret-service access, and CI or database discovery is more meaningful than a global threshold for any one API. Every newly observed key starts another behavior baseline and another search for adjacent high-value identities.

Sygnia describes attack waves rather than a clean linear kill chain. One key could continue to operate while another identity scope began enumeration, sometimes in another account. A runner token could open source and deployment systems while a database credential opened the data layer. More credentials increased the number of concurrent workstreams and the number of telemetry owners required to see them.

This pattern defeats a host-by-host view: a secret taken in account A can enter CI, deploy into account B, and produce a workload role in account C. The investigation unit must be the complete identity family, following secret reads, role assumptions, runner jobs, deployments, database authentication, and network activity. Platforms share one case ID, UTC window, and parent-child model until no new account, platform, or trust edge appears.

The response queue gives each credential four times—first possible exposure, first observed read, first observed use, and last possible validity—and links issuer, parent evidence, privilege, consumers, session duration, owner, and validation. Priority combines authority with propagation potential: a low-privilege repository token that can alter production may matter more than an administrator key in a quarantined account, while a database password that exposes third-party tokens may generate further branches.

AccessDenied proves only that one request failed in one context; another region, resource policy, session, or role may behave differently. Keep denied events and connect them to later authorization changes and successful calls. Closure is also issuer-specific: disable AWS keys in IAM, revoke GitHub tokens at their issuer, remove SSH keys from every trust location, and terminate database sessions while migrating consumers. A generic “rotated” status cannot represent all of those conditions.

3 The secret surface was a relationship network spread across runtimes, pipelines, objects, databases, and managed stores

Sygnia identifies ECS and EC2 environment variables, GitHub and Bitbucket runner environments, plaintext objects in S3, application databases, AWS Secrets Manager, and SSM Parameter Store. Different teams may operate each surface, yet the same production API key or database password can be copied across several of them. A storage inventory alone does not reveal the real blast radius.

Record both storage identity and credential purpose. A variable called PROD_TOKEN becomes actionable only after identifying its issuer, permissions, target, last use, owner, and rotation mechanism. Never copy the value into a general incident ticket. Use secret ARN or platform ID, version, a controlled fingerprint, access principal, and consumer relationship.

Connect read evidence to use evidence. CloudTrail can show GetSecretValue or GetParameter; GitHub, Bitbucket, AWS, database, or external API logs may later show the token in use. A confirmed read is already sufficient to rotate. Subsequent use changes impact confidence and helps establish the actor's sequence.

Duplicate copies complicate eradication. Rotating the authoritative vault value does not remove a still-valid key in an environment variable, image layer, S3 version, backup, runner cache, or database row. Invalidate credentials at their issuer, update every known consumer, then search for old copies and monitor for attempted use.

Long-term remediation uses workload roles and federated sessions instead of replaceable static keys, automated rotation for credentials that must remain, and continuous secret discovery in code, images, objects, logs, and databases. Findings need an owner and a deletion workflow. A scanner that only creates an ever-growing backlog does not reduce available credentials.

An actionable secret inventory covers the entire lifecycle: issuer, authoritative copy, readers, every materialized replica, consumers, derived sessions, replacement method, and the condition for retiring the old value. It also separates a confirmed read, plausible exposure inside a compromised process, and capability through unused permission. All three may justify rotation, but they are not the same impact fact.

Encryption excludes principals without decrypt authority; it does not protect a value from a stolen application role that already has KMS access. Rotation planning also needs consumer failure behavior: cache lifetime, restart requirements, lockout or queue effects, health checks, rollback limits, and an observation window. That information lets responders invalidate quickly without turning an unknown consumer into another outage.

3.1 ECS and EC2 runtimes expose startup secrets, roles, files, and runtime channels

AWS allows an ECS task definition to reference Secrets Manager or Parameter Store and inject the value as an environment variable. AWS documentation notes that a running container receives the value at startup and does not automatically receive a later rotation. A new task or forced deployment is required. This lifecycle is central to incident rotation planning.

A principal able to execute in the container, read process environment, reach an unsafe diagnostic endpoint, alter startup scripts, or inspect task configuration may obtain injected material. Environment values may also leak into child processes, crash reports, debug output, monitoring configuration, or application errors. Investigators need runtime and log-platform evidence in addition to secret-service reads.

A safe rotation creates or approves the new value, updates the secret and consumer configuration, registers a new task-definition revision where required, forces deployment, confirms all old tasks have stopped, and then invalidates the old credential. An actively exploited secret may require immediate invalidation and a planned service degradation instead.

Join CloudTrail task-definition and service updates with task start/stop events, exec sessions, secret access, and deployment records. Preserve cluster, service, task ARN, task-definition revision, execution role, task role, container image digest, and timestamps. These fields identify exactly which task generation carried the old value.

A more mature design retrieves a secret at runtime through a narrow task role and caches it for a bounded period when application availability permits. Whichever method is used, the role should read exact resource ARNs, with restrictive resource and KMS policies and private service endpoints where appropriate.

EC2 applications can obtain credentials from systemd environment files, shell profiles, user data, container configuration, application files, process state, or instance metadata. Sygnia observed environment-secret harvesting and reverse shells on EC2. Host execution therefore connected cloud authorization to conventional process and filesystem evidence.

Instance roles avoid long-lived keys but still grant temporary API authority to code on the host. Require IMDSv2, restrict hops, narrow role policy, and prevent containers that do not need metadata from reaching it. If an actor already runs under the application identity, the instance role's permitted APIs define immediate cloud reach.

Preserve instance ID, AMI, launch template, profile, security groups, subnet, user-data hash, volumes, processes, logins, scheduled tasks, systemd units, authorized keys, container inventory, and network connections. Disabling the original access key does not remove a shell, service, startup modification, or stolen role session on the host.

Broadly compromised runtimes should be rebuilt from a reviewed image and infrastructure definition. Production that cannot be replaced immediately is isolated while volatile evidence, sessions, credentials, and boot-chain differences are handled. The recovered source commit, runner, dependencies, base-image digest, registry, launch template, task definition, secrets, and deployment identity must predate the compromise or be independently regenerated; a familiar mutable tag or reused disk is not a trust chain.

ECS secret injection also has historical feature boundaries worth recording: Fargate introduced whole-secret injection in platform 1.3.0 and Linux Fargate added selected JSON keys or versions in 1.4.0; ECS on EC2 historically required agent 1.22.0 and 1.37.0 respectively. These are not affected versions for this incident. Investigators must capture the supported platform and agent actually in use. Across all branches, a running task does not refresh merely because the secret store changed.

Rotation therefore lists task ARNs and start times, launches the new revision, waits for healthy capacity, stops old tasks, and proves the retired credential fails. Stopping one task does not isolate an ECS service because the scheduler may replace it; rolling, CodeDeploy blue/green, and external controllers also use different deployment paths. ECS Exec cannot be enabled retroactively, so its absence is an evidence gap rather than an assumed shell path.

IMDSv2, hop limits, and network controls reduce metadata-theft paths but do not prevent code already running as a task or instance role from calling its permitted APIs. Combine them with service-specific least-privilege roles, egress controls, and first-seen API detection. When continued execution threatens integrity, containment takes priority and the lost volatile evidence is recorded explicitly.

3.2 CI runners concentrate source, deployment authority, cloud sessions, registries, and signing material

Sygnia observed secret harvesting from GitHub and Bitbucket runner environments. A runner may read source repositories, package registries, cloud accounts, signing services, and production deployments. Self-hosted runners can retain workspaces, caches, Docker sockets, SSH agents, and state between jobs, turning one pipeline foothold into access across organizational boundaries.

Immediately stop new jobs on affected runners and preserve runner identity, image, host, version, registration, job history, workspace, and network evidence. Revoke runner registrations and associated sessions. Rotate personal access tokens, deploy keys, registry tokens, signing keys, webhook secrets, OIDC trust, and cloud roles that the runner could use.

Review branches, tags, commits, pull requests, workflow and pipeline definitions, runner scripts, dependency locks, submodules, release artifacts, container images, and infrastructure code. Sygnia found “pentest,” “red team,” and fictional executive-authorization language in artifacts. A label is never authorization; compare every change with real approvers, tickets, signatures, and the permitted window.

Prefer OIDC federation for cloud access. Trust policy restricts repository, branch or protected environment, audience, and workflow context, while production deployment runs on isolated ephemeral workers. A job receives a short session for one purpose rather than a reusable AWS key stored in repository secrets.

Before resuming release, build from a reviewed commit on an independent clean runner, generate an SBOM and immutable digest, test, scan, and sign the artifact. Do not retag an image built during the incident as clean. Its layers, entrypoint, dependency downloads, and generated files may include changes outside normal source review.

Repository review must reconstruct authority, not merely compare the default branch. An actor can create a branch, alter a workflow, run it, exfiltrate its ephemeral credentials, delete the branch, and leave the production source apparently unchanged. Preserve organization and repository audit, workflow runs, environment approvals, runner assignments, artifact uploads, package publications, release events, deploy keys, webhook deliveries, and branch-protection changes. Join each run to its exact commit SHA and the identity that approved or dispatched it.

Self-hosted runner persistence sits below the provider audit plane: a job can modify services, scheduled tasks, the Docker daemon, credential helpers, caches, or the runner binary so later legitimate jobs execute attacker code. Removing the runner only stops scheduling. After evidence capture, revoke its registration and credentials, quarantine it, and rebuild from a reviewed image rather than re-enrolling the same disk with a new token.

OIDC improves on static keys only when issuer, audience, repository or workspace, and deployment-environment subject are exact. GitHub environment subjects do not normally carry the branch at the same time, so branch and tag restrictions belong in environment protection; Bitbucket trust likewise needs the real token's repository and deployment identifiers. Closing trust prevents new sessions but does not invalidate credentials already issued by AssumeRoleWithWebIdentity; those sessions must be revoked or explicitly denied while the runner and workflow are rebuilt.

A valid signature cannot cleanse an untrusted signer. Review incident-window signatures together with dependency locks, actions, reusable workflows, container bases, plugins, submodules, and remote scripts; then build on an independent runner under pinned dependency and network policy, producing a new SBOM, digest, and signature. Admission controls block old or unknown digests until provenance is restored.

3.3 S3, managed stores, and databases turn secret discovery into data access and control

Sygnia reports plaintext secret discovery in S3 and denial of bucket access as a demonstration of impact. Object storage often contains configuration backups, exported logs, database snapshots, deployment bundles, environment files, and manual exchanges. A private bucket prevents anonymous access, but an authorized stolen principal with GetObject can still retrieve its contents.

Management events are not sufficient for object-level scope. Enable CloudTrail data events or an appropriate event data store for critical buckets, then correlate bucket, key, version ID, principal, access-key ID, source, user agent, and request ID. S3 server access logs may add evidence with different fields and delivery behavior.

For a secret-bearing object, record bucket ARN, key, version, ETag or hash, modification time, encryption context, reading principal, and credential purpose. Keep content in controlled evidence storage. With versioning enabled, inspect previous versions and delete markers. Replacing the current object does not invalidate a credential embedded in history.

An access denial can originate in bucket policy, access point, object ACL, KMS key policy, organizational policy, or network conditions. Preserve the old and changed configurations and their events before restoring a trusted baseline. Fixing only one layer can leave another explicit denial or attacker-controlled access path.

Preventive design combines public-access blocks, exact read permissions, data-domain separation, restrictive KMS policy, object-level telemetry, data discovery, and removal of plaintext credentials. Encryption at rest does not stop a stolen identity that already has decrypt permission; identity and data controls must be reduced together.

Secrets Manager and Parameter Store provide encryption, versions, central policy, and CloudTrail events. An actor with broad list and read permissions can rapidly enumerate meaningful names and retrieve credentials for many systems. Sygnia observed collection from both services, showing why moving a value into a vault is only one part of secret security.

Search ListSecrets, DescribeSecret, GetSecretValue, value changes, resource-policy changes, and rotation changes. For Parameter Store, examine parameter description, path queries, get operations, tags, and policies. Group by access-key ID, session issuer, source, user agent, region, time, and secret resource.

Names can reveal system, environment, and purpose, so list permission also deserves minimization. A workload should read exact secret ARNs or tightly controlled paths, constrained by tags, account, VPC endpoint, resource policy, and KMS policy. Reading values and modifying policy or rotation belong to separate roles.

After a confirmed read, revoke the value at its issuer and create a replacement version, then update and restart consumers. Observe old-value use and errors. AWS keys, database credentials, certificates, OAuth tokens, and third-party APIs have different issuance and session behavior; the shared incident ledger must preserve those differences.

Maintain a consumer inventory and normal-read baseline for every high-value secret. A previously unused principal reading many secret values in a new region is high signal. Automatic rotation needs failure alerts and verified retirement of prior versions; an enabled checkbox is not proof that consumers moved.

Sygnia reports several hundred unique SQL statements across dozens of databases, including queries for user and transaction information. This scale supports the assessment of rapid adaptation and parallel work. It also establishes that AWS management logs cannot scope the incident alone. Database authentication, audit, query, proxy, application, and network records belong in the timeline.

Identify database user, source workload, RDS instance or cluster, endpoint, session time, TLS state, authentication method, and network path. If the actor routes queries through an application or jump host, the database sees a legitimate infrastructure source. Process and application evidence must connect that session back to the stolen cloud or runner identity.

Cluster statements by schema and table, read or write operation, errors, estimated rows, duration, and export behavior. Schema discovery and failed queries show intent but not successful access. DDL, user creation, grants, functions, triggers, event schedulers, and extensions may establish persistence within the database independently of IAM.

Containment revokes database credentials and active sessions, restricts network origin, reviews users and grants, preserves audit, rotates every consumer, and inspects proxies and jump hosts. The organization then estimates returned and exported data. A password change cannot recall records that have already been read.

Long-term controls use service-specific identities, managed rotation or short-lived database authentication where supported, read/write separation, minimum schema and row access, network segmentation, and durable audit. Detection focuses on new origins, broad schema discovery, many distinct statements, unusual errors, and query patterns outside the application's historical profile.

S3 scope conclusions first pin logging coverage: GetObject is a data event that trails do not record by default and Event history does not contain. If the incident-time selector covered only some buckets, prefixes, or read/write classes, the rest remain unknown; later logging cannot recreate past reads. Object versions and authorization are separate timelines, so preserve version IDs, delete markers, policies, ACLs, access points, KMS grants, and replication state together.

Managed-secret rotation closes only when issuer, replicas, consumers, and sessions agree. Secrets Manager's AWSPENDING and AWSPREVIOUS are version states, not proof that an old credential is invalid; Parameter Store versions, labels, and expiry likewise do not revoke the database, SaaS, or cloud credential represented by the string. Replace the real credential, refresh and validate consumers, invalidate old values and sessions, and continue monitoring old-value use.

Database impact needs layered proof: authentication establishes a session, audit shows a statement reached the server, query status shows success or error, engine or application evidence estimates returned rows, and network or export telemetry supports transfer. Normalize literals across hundreds of statements without discarding restricted raw SQL needed to interpret predicates and columns. Password rotation must also terminate pooled sessions and cover readers, proxies, replicas, data APIs, analytics copies, and jobs; a network allowlist cannot isolate misuse performed through a legitimate compromised application identity.

4 Four accounts, four keys, one source, one client fingerprint, and one second provide the clearest evidence of centralized concurrency

No single cloud API call proves that an AI system was used. The same-second observation first establishes something narrower and stronger: several identities in several accounts were being operated through a common source and client pattern concurrently. A human can launch scripts, conventional automation can coordinate them, and an agent can do so as well. The telemetry demonstrates orchestration.

Group events by access-key ID and compare timestamp precision, source IP, user agent, region, API family, request IDs, and session context. This analysis distinguishes common tooling from unrelated users and helps identify proxies or NAT. Then compare with registered enterprise automation. Context decides whether the shared fingerprint is malicious or normal.

If a legitimate security scanner normally uses the same four accounts and source, concurrency may be baseline. In this incident, newly acquired keys, secret collection, persistence, database access, and impact gave the pattern its meaning. Parallelism should never be interpreted without identity provenance and adjacent actions.

A durable detector does not need to claim “AI attack.” It can alert on multi-account, multi-credential sensitive enumeration or changes from a new common source in a short window, with approved automation excluded by identity and schedule. This remains valid when attackers change their model, framework, or marketing vocabulary.

Cross-account logging is a prerequisite. Each account alone sees a small number of events for one key. An organization trail and central analytics can place all four lanes in the same second. Stable account IDs, UTC handling, original event retention, and low ingestion delay are part of the detection control.

Reproduce the four observations from original events, retaining timestamp, account, access-key ID, event and request IDs, source, user-agent, API, region, and identity type, and verify that ingestion did not round time or rewrite fields. A VPN, NAT, or proxy can create a common source, while a shared SDK can create a common user-agent; the inference strengthens only when those fields coincide with new credential lineage, similar API order, and synchronized state changes. Approved automation therefore needs an identity-, scope-, time-, and behavior-based registry rather than an IP allowlist.

Concurrency also measures the response window. If key B begins sensitive discovery before the alert on key A is assigned, detection and handoff latency exceeded credential-conversion time; if B first appears after A is disabled, look for an existing session, stored copy, or pre-containment path. The four-key second was a sample: the published key-hopping view classifies 89 keys by inferred role—23 validation or pivoting, 26 discovery or sweeping, 24 ECS or container execution, six payload or SQL adaptation, one Redshift loop, and nine other—with as many as six workstreams overlapping in sub-minute windows. Those counts describe stateful lanes to correlate, not 89 accounts or operators.

Central analytics need identity-safe joins. Interpret an access-key ID in its issuer context, retain full principal IDs, distinguish temporary-session identifiers, and follow session issuer instead of a friendly role name. The graph must tolerate delayed CloudTrail delivery and deduplicate by event identity without erasing genuine repeated calls.

4.1 The AI-assisted assessment rests on combined speed, concurrency, tool adaptation, operational memory, and artifact language

Investigators saw a broad checklist applied repeatedly across new surfaces, scripts generated or adapted to the environment, concurrent identity use, structured self-documenting artifacts, and continuity across many credentials and workstreams. Together, these observations are consistent with AI assistance in reconnaissance, code generation, decision support, and orchestration. The conclusion does not rely on fluent comments alone.

Operational memory means that each key's account, permission set, completed actions, accessible resources, and remaining tasks stayed organized as the actor switched among workstreams. An LLM agent, conventional orchestrator, human team, or hybrid can provide that capability. The case evidence supports the resulting scale and continuity more directly than it identifies the exact internal implementation.

“Pentest,” “red team,” and fictional executive authorization in artifacts could have been designed to mislead responders, blend into development, or frame requests to a generative tool. The names are useful search terms and contextual evidence. Authorization still comes from real tickets, approvers, signed changes, identities, and time limits.

The evidence resolves into three layers: cloud and application actions directly observed; centralized automation and parallel work supported by those actions; and Sygnia's assessment that AI-assisted or agentic workflows contributed. The incident can be contained and remediated from the first layer even if the third later changes.

Rapid customization has a concrete evidentiary test. Compare each script or query set with the resources, schema, errors, and permissions discovered immediately before it. Tooling that changes names, regions, pagination, service choices, or SQL structure in response to the environment demonstrates adaptation. It still does not reveal whether the adaptation was manual or model-assisted. Provenance comes from file timestamps, commit history, execution records, comments, local state, and surrounding operator behavior, with artifact language carrying only supporting weight.

One public thread connects that adaptation to application mechanics. Sygnia describes analysis that related SQS queues, vulnerable workers, payload-injection points, and deployment files used to manage clusters. This is more than a generic cloud inventory: the actor was turning discovered application structure into a route from queued work to code execution and deployment control. The public report does not identify the customer components or reproduce their vulnerable code, so the exact function remains unknown, but the relationship explains why data, messaging, runtime, and deployment evidence have to be reconstructed together.

The published malicious-commit image grounds artifact language in a mechanism: a purportedly authorized “penetration test” step attempted to collect cloud credentials, production secrets, and instance metadata, encode environment material, and send it to a redacted external destination while failure-tolerant shell behavior kept the job moving. It joined social framing, secret collection, metadata access, and outbound transfer in one CI change. Remove every AI label and the exposed credential, identity expansion, secret harvesting, persistence, data access, impact, and recovery still form a complete case; the AI assessment explains tempo and coordination rather than replacing the mechanism.

4.2 Durable access spread across IAM identities and runtime shells

Sygnia observed creation or attempted creation of IAM users and additional access keys. This is the irreversible turn in the identity story: after the entry key goes inactive, a new user, key, role session, or cross-account trust can keep calling APIs on its own. The investigation therefore cannot stop at the entry key's last event; it follows CreateUser, CreateAccessKey, policies, groups, roles, trusts, login configuration, and MFA changes to every descendant.

A branch need not have a new user name. Adding a second key to an existing identity, widening a trust principal, selecting a permissive policy version, joining a privileged group, or changing a permission boundary creates a new path beneath a familiar object. Each change connects creator, time, source, permission origin, last use, accessed resources, and further objects; CloudTrail, credential reports, policy history, Access Advisor, and Config snapshots reconstruct the relationship.

The report also records reverse shells in EC2 and ECS. The network connection is only the visible outcome; the startup point can live in systemd, cron, an entry script, sidecar, task definition, user data, or a deployment pipeline. ECS evidence pins cluster, service, task ARN, revision, image digest, role, and deployment time. EC2 evidence pins AMI, launch template, volume, instance profile, user data, process, and network state. A callback endpoint going offline does not prove those startup paths disappeared.

The identity and runtime graphs must meet. A shell can read a credential that creates an IAM object, while a changed role or resource policy can let the next workload obtain a new session. Deleting one process or user may remove only a leaf. Trusted snapshots and write events rebuild users, keys, roles, trusts, identity providers, boundaries, policy versions, and critical resource policies while runtime evidence compares image, launch path, network, and deployment origin.

The scope is now explicit. Any branch that can authenticate independently, refresh a session, or execute on a later start has left the entry key's lifetime. Deactivating that key closes its branch only when the issuer relationship, execution source, and descendants have all returned to a trusted state.

4.3 Deployment artifacts and application identities hid persistence beyond IAM cleanup

Sygnia found persistence spread through infrastructure templates, deployment scripts, container images, cloud storage, and webhook redirection. A change may wait for the next pipeline, scale-out, failover, disaster-recovery event, or manual release. A quiet set of running instances therefore does not exclude a dormant artifact that already holds future execution authority.

Evidence spans source control, approval, signing, runners, registries, and deployment platforms. Incident-window commits, branches, tags, pull requests, workflows, webhooks, deployment keys, image pushes, manifests, and infrastructure plans share one timeline. “Pentest” or “authorized” in a commit message is text to verify; authority still comes from the approver, ticket, signature, and permitted time.

Images are compared by digest, layers, entry point, packages, startup scripts, and SBOM because a mutable tag does not establish identity. Infrastructure review removes formatting noise and then compares principals, permissions, egress, startup commands, external URLs, encryption, logging, and protection flags. Webhooks also require provider audit because URL, signing-secret, and delivery changes may never appear in CloudTrail.

The privileged application users in the report form another independent branch. They may live in a business database or identity service, with login, elevation, MFA, password reset, API token, OAuth client, invitation, and session evidence outside AWS. A review limited to IAM can leave the actor using an ordinary administration screen to export data, create integrations, or trigger deployment again.

Deployment provenance and application identity together explain why the case cannot close at “cloud key deleted.” Trust must remain continuous across commit, approval, runner, dependency, build, digest, signature, deployment, and runtime, while every user, token, webhook, export, and cloud integration created by a privileged application account is treated as a descendant. If any link remains controlled by an incident-window identity or artifact, the branch remains alive.

4.4 Financially motivated extortion turned reversible cloud configuration into leverage

Sygnia characterizes the objective as financially motivated: gain enough control of the victim's cloud estate to create leverage for extortion. In a cloud environment without a direct equivalent to an on-premises encryptor, the actor used mostly reversible impact actions to demonstrate that control: denying access to S3, limiting ECS services or containers to a maximum capacity of zero, creating network ACL rules that block traffic, and purging SQS queues.

Reversible configuration does not imply reversible business outcome. Purged queue messages are gone; stopped services lose requests or in-memory state; ACL changes interrupt dependencies; S3 denial can block backup and recovery. Investigate downstream consistency and recovery for each action rather than marking an API setting restored.

Preserve before and after configuration, CloudTrail event, principal, key, request parameters, source, client, and request ID. For ECS, include desired count and Application Auto Scaling targets, minimums, maximums, and policies. Several controllers may write the same effective capacity, and restoring only one field may not restart service.

Disable the attack identity before restoring control settings. Otherwise the actor can repeat the call as soon as capacity or access returns. Identity and session revocation, network containment, policy repair, workload integrity, and service restart belong to one ordered plan under incident command.

Preventive guardrails apply approval and explicit denial to production queue purge, service-to-zero, critical bucket and KMS policies, and security-boundary ACL changes. A separately held break-glass role needs a tested recovery path. Trusted configuration backups reside where workload identities cannot modify them.

The API names used for hunting should be treated as likely control locations, not as claims about Sygnia's undisclosed raw events. ECS disruption may involve UpdateService or Application Auto Scaling targets; network blocking may involve network ACL entry creation or replacement; bucket denial may involve bucket, access-point, ACL, or KMS policy changes; queue impact centers on PurgeQueue. Search the complete service change family and resulting state rather than assuming one method name from the business description.

SQS purge is urgent because restoring permissions or recreating a queue cannot recover available and in-flight messages removed during a window of up to roughly sixty seconds, including new arrivals. Preserve the queue ARN and URL, DLQ and redrive settings, producers, consumers, checkpoints, and purge event, and pause producers when needed. A DLQ is not a source-queue backup; recovery needs idempotent replay and reconciliation from an independent ledger or a defined residual-loss window.

ECS recovery compares desired count, scalable targets, scheduled scaling, deployment configuration, capacity providers, and external controllers; network recovery compares ACLs with routes, security groups, firewalls, load balancers, and host rules; S3 recovery preserves policy, ACL, access points, public-access block, KMS, and VPC endpoint policy before applying the smallest trusted difference. All three begin only after the attack identity is constrained and use a canary or designated recovery principal instead of blindly overwriting state.

Business results close each impact branch: reconcile queue messages and transactions, verify ECS capacity, health, requests, and state, exercise network dependencies in both directions, and confirm that authorized S3 applications can read the correct versions without wider access. A successful configuration API response is only the beginning of recovery verification.

5 A CloudTrail event becomes evidence only after it is placed back into identity, session, resource, and follow-on context

Core fields include eventVersion, userIdentity, eventTime, eventSource, eventName, awsRegion, sourceIPAddress, userAgent, requestParameters, responseElements, requestID, eventID, resources, readOnly, and errors. Services may omit or truncate fields, so retain the original JSON beside normalized analytics.

userIdentity distinguishes IAM user, assumed role, service, federation, and root. For a temporary session, follow sessionContext.sessionIssuer, principal ID, ARN, session name, source identity, tags, and MFA back to the issuer. For a long-lived key, access-key ID provides the direct cross-event join.

Source IP can represent a proxy, NAT, VPC endpoint, or AWS service. User agent is spoofable and shared by SDKs. They are useful clustering fields, not standalone attribution. The same-source, same-client observation gains meaning from credential provenance, action sequence, and known enterprise automation.

Management events do not cover every data action. S3 object access requires selected data events; SQL requires database telemetry; runner secrets and commits require provider audit; application administrators require application logs. Incident preparation identifies crown-jewel data events and preserves them long enough for a cross-platform investigation.

Normalize account, region, event ID, request ID, principal, access key or session, resource, source, and UTC time while retaining originals. Do not sort by delivery-file order. Duplicate and delayed records are expected. A shared schema lets cloud, CI, database, and application teams connect evidence without renaming the same identity at every handoff.

Interpret CloudTrail by event version and category: a field may be inapplicable, omitted by the service, or truncated by a size limit. Preserve the raw record, delivered-object hash, and parser version. Management, data, network-activity, and database records answer different questions, while Event history cannot replace the organization trail. Each query retains category, selector, region, resource, retention, time window, text, and result hash.

Keep original timestamps, derived UTC, clock skew, and a search margin. Events sharing a timestamp cannot be ordered by row position; use request IDs, session issuance, resource versions, process ancestry, and first downstream use. Every negative finding also carries a coverage statement: without full-window S3 read data events, healthy delivery, and retained owner and caller perspectives, the conclusion is only that no read was found in the available evidence, followed by the blind spot.

5.1 The evidence chain follows each credential wave from application entry to business result

The chain begins with the Internet application's request, route, version, instance, and key-exposure location, then joins the first AWS use of that accessKeyId. It adds another layer only when a new fact appears: secret read and first use of a derived identity, IAM or runtime persistence, deployment or application-identity change, and the resulting RDS, S3, ECS, ACL, or SQS data and business effect.

Nodes use stable case IDs. AWS identities retain account, partition, principal ID, ARN, session, issuer, and validity; objects retain ARN, key, and version; artifacts retain commit or digest. Every edge carries source, time, and confidence, distinguishing “could read,” “did read,” “issued,” “deployed,” and an analytical association inferred from time or origin.

The graph is queried downward from entry to blast radius and upward from databases, deployment roles, and other crown jewels to possible ancestors. A missing edge identifies a log owner and next query; it is not permission to invent the bridge. Old-value success after a recorded invalidation reopens the branch and tests active versions, sessions, clocks, and issuer behavior.

The graph exposes the irreversible turn. Once a child identity succeeds on another platform, it owns an independent timeline; silence from the parent key cannot close it. Deadlines, detection, and acceptance now follow those lanes. Treating the entry key as the only object would mislabel active branches as finished.

5.2 Containment, rotation, rebuild, and recovery must move as one ordered program

The control order is established; execution now depends on advancing different branches without destroying one another's evidence. Investigators preserve logs, snapshots, processes, tasks, configuration, and artifacts while control owners act through approved playbooks. Both streams share change IDs and record operator, time, prior state, new state, and verification.

Local order follows live risk. An identity deleting data is cut before complete volatile collection; an isolated workload holding the only shell evidence may be captured briefly before replacement. Emergency explicit denials target compromised principals, issuance windows, untrusted routes, or destructive actions and exempt an independent response identity so logging and recovery do not disappear with the attacker path.

The identity graph gives every branch seven statuses: issuer, child sessions, CI, runtime, consumers, trusted artifact, and old path. Each is complete, in progress, excepted, or unknown; green in one platform cannot close another. Broad controls need a tested rollback route, and business exceptions carry exact resource, owner, short expiry, and enhanced monitoring.

Acceptance joins technical and business outcomes: old authentication and refresh routes fail, replacement runtimes pass integrity and health checks, unapproved artifacts cannot publish, queues reconcile, and databases complete identity, query, and data review. A successful control-plane API response proves acceptance of a request; only a closed attacker path and a recovered service close the fork.

5.3 Identity, time, and concurrency turn one key into a queryable credential family

A long-lived key that calls AssumeRole receives another access-key ID, and later events change to userIdentity.type=AssumedRole. Searching only the entry key makes activity appear to vanish at that boundary. In reality, the identity has changed its identifier and continues inside a new validity window.

Each assumption preserves requester, target role ARN, source identity, external-ID conditions, session policy, tags, duration, source, and returned temporary key. A caller-chosen session name is only a search term; principal ID, the issuance event, and sessionContext.sessionIssuer establish parentage.

Some branches do not contain one direct AssumeRole edge. A changed task definition, instance profile, trust policy, or CI OIDC workflow can cause a legitimate service to issue the next session. The configuration write is then the parent transition and the service issuance the child, so identity events and resource versions must occupy the same graph.

“Issuer disabled” and “all derived sessions and refresh paths ended” are separate times. Expiry proves closure only when issuance, maximum duration, and issuer are known and no task, instance, CI job, or federation path can refresh the session. The session table therefore retains issuance, last use, termination or expiry, temporary denial, and trust repair.

5.4 Configuration, runtime, pipeline, and data evidence prove what changed and what recovered

CloudTrail request parameters can omit large fields, and a response may not contain final state. Configuration analysis therefore compares the trusted pre-incident value, the actor or uncertain incident value, and the approved recovered value. AWS Config, service versions, infrastructure state, tags, and independent exports complete the API event instead of letting a method name stand in for impact.

The comparison uses behavior-changing versions: identity policy and trust, key, security group and NACL, route, ECS task revision, launch template, Lambda hash, S3 or KMS policy, SQS redrive, webhook, log selector, and security service. Where Config coverage or retention is incomplete, logs, backups, artifacts, and service owners reconstruct what they can and leave the missing interval explicit.

Defensive changes stay separate from actor changes. Independent response roles, session tags, and change IDs preserve prior state, new state, time, and reason. Trails, Config, GuardDuty, Security Hub, retention, KMS access, and alert routing receive their own protected review because they determine confidence in every other finding.

Post-recovery drift monitoring compares semantics rather than bytes: policy reordering may be equivalent, while one wildcard can expand authority. After declared infrastructure and real resources converge, principals, actions, resources, conditions, network paths, executable content, digests, and security coverage remain under comparison. Manual exceptions carry owner, reason, expiry, and compensating observation.

6 The first hour aims to prevent a second credential from growing while preserving the most volatile evidence

Establish incident command with named cloud-identity, network, CI/CD, forensic, database, application, and business owners. The first seed record contains only known facts: key ID, principal, account, source, first and last activity, current calls, and any child identity already connected to it. Command orders separately carry scope, owner, exception, duration, rollback, and verification so they do not blur into investigative findings.

Central CloudTrail, credential reports, Config snapshots, application deployment and logs, runner jobs, repository audit, database sessions, and ECS/EC2 inventory move into an independent security account. Volatile tasks, instances, processes, and network state are captured first when risk permits. Every team uses one UTC window, case ID, native identifier, and evidence location while executing the ordered response already defined in the previous section.

The sixty-minute checkpoint does not seek a complete story. It reports momentum: how many unknown identities can still authenticate, how many suspect workloads can reach the Internet, whether pipelines can publish, whether issuers can mint another session, and whether destructive actions remain reachable. It also lists the entry, active identities and accounts, current sensitive actions, evidence gaps, business effect, and next decision.

6.1 Between one and six hours, turn the entry key into a credential family and begin high-value rotation and isolation

Cross-account and regional queries join STS, IAM, managed secrets, S3, EC2, ECS, RDS, network, logging, and deployment events to every seed. Lanes by key and session mark first secret read, first child-identity use, persistence, data action, and impact. Source and user agent enter clustering only after registered automation is excluded, so shared egress never substitutes for an identity relationship.

The ledger is ranked by external reach, privilege, production use, signing or deployment authority, and data access. The six-hour checkpoint directly shows the seven states for each high-value branch: issuer, child sessions, CI, runtime, consumers, trusted artifact, and old path are complete, in progress, excepted, or unknown.

The checkpoint records log coverage, last activity, data-evidence level, current control, business state, owner, and next evidence for every account, platform, and crown jewel. If any unknown identity can authenticate, reach the Internet, publish, create another identity, or query data, attacker momentum remains. Legal and privacy receive confirmed reads and successful queries with their evidence limits, not theoretical permission presented as impact.

6.2 From six to twenty-four hours, response shifts from interrupting activity to proving which trust relationships remain valid

The scope matrix checks account, identity, secret, workload, repository, runner, artifact, database, and application user in both directions: downward from each compromised identity to resources and descendants, and upward from every crown jewel through principals, resource policies, network paths, deployment mechanisms, and credentials. An uncovered platform keeps an owner and deadline rather than disappearing from the summary.

Each dataset separates technical reach, successful query or read, return to the process, and transfer or other use. Configuration and artifacts compare trusted pre-incident, incident, and recovered state. Any successful old key or session, unknown digest, unusual SQL, or new webhook reopens its branch; reaching the second day does not lower the evidence requirement.

The twenty-four-hour report states facts, confidence, blind spots, remaining active branches, business state, and trusted-recovery progress. It also names the new facts that would change a major decision, such as a compromised signer, assumption of a supposedly unreachable production account, a second entry, or missing object data events. AI assistance remains tempo context; identity, resource, and data evidence set scope.

6.3 From twenty-four to seventy-two hours, remove distributed persistence and establish a new verifiable production baseline

Every identity branch now occupies one of four states: issuer inactive with all child sessions and refresh paths closed; still active under an expiring business exception and compensating controls; proven unreachable for the relevant period; or unresolved but owned, isolated, and dated. “No longer observed” is not a fifth state because activity may pause and telemetry may be incomplete.

Artifacts likewise divide into blocked and trusted sets. The first contains incident-window or unknown images, packages, runners, templates, scripts, commits, and signatures. The second pins reviewed source, build environment, dependencies, signer, digest, and deployment record. Accounts, federation, roles, users, policies, trusts, resource policies, and privileged application users are compared with the recovered baseline; unfamiliar objects gain provenance or leave the environment.

Seventy-two hours is a response benchmark against the observed expansion window, not automatic closure. Data impact, third-party work, long rebuilds, and legal decisions may continue. Someone absent from the early response must nevertheless be able to start from any identity, artifact, database, or impact record and replay its scope, current state, and closing evidence. “Recovered” by oral memory is not reproducible.

7 A detection matrix composes observable attack-wave signals instead of searching for a mythical universal AI indicator

Identity discovery includes new-source GetCallerIdentity, cross-region lists, IAM or Organizations enumeration, and concentrated denials. Secret collection is short-window access across managed stores, S3, runners, databases, and workload environments. Identity expansion appears as AssumeRole, new users and keys, and trust or policy writes. The detector first recognizes these atomic events, then joins each fork by parent session, resource, and time.

Persistence covers EC2 or ECS commands and egress, task or launch changes, unknown images, startup mechanisms, workflows, webhooks, deployment scripts, and application administrators. Data and impact signals include new-origin SQL, object reads, S3 or KMS denial, ECS capacity at zero, NACL blocks, SQS purge, and logging or backup changes. State-changing rules retain old and new values where possible.

Orchestration analytics count keys, accounts, sensitive API classes, sources, clients, and repeated sequences in short windows, weighting identity relationships and state change above raw volume. A stable backup role's many reads can matter less than one new key reading a deployment secret and creating a privileged identity. Same-source and same-client observations add weight only after registered automation, shared NAT, and proxies are excluded, and the rule does not attribute a model.

False-positive suppression requires complete automation context: dedicated role, fixed pipeline, known repository, bounded API family, approved change, and predictable schedule, not an IP allowlist. Delivery stopping, a selector losing a critical bucket, database or runner audit lag, or a security account losing decrypt access is itself a coverage alert.

Enrichment adds effective permissions, key age and last use, account owner, resource criticality, adjacent secret reads, child sessions, and approved change. At lower confidence, automation performs only reversible, narrow, evidence-preserving control through an independent response identity with before-and-after state, idempotency, and rollback; broad or destructive action still requires explicit approval.

7.1 Detection and identity guardrails make every credential conversion visible and interruptible

Root and routine IAM users do not retain long-lived keys. Employees use federation or IAM Identity Center, workloads use roles, and CI uses OIDC. Administrative sessions require strong MFA, a managed device or trusted network, and task-appropriate duration; production, staging, CI, and operations use separate principals.

Policies derive a minimum set from observed access and constrain resource ARN, region, tag, source VPC, organization, and session attributes. Deployment roles cannot read arbitrary secrets, secret readers cannot modify IAM, and logging identities cannot administer workloads. Delegation boundaries also include iam:PassRole, trust changes, policy versions, service deployment, and resource-policy authority.

Identity architecture exposes provenance by construction: human federation, CI OIDC, workload roles, and emergency administration use distinct role families, sourceIdentity, and session tags. Access Analyzer, credential reports, last-accessed data, and the relationship graph continually locate external trust, shared identities, old keys, and unused permission, measuring success by authority removed rather than reports produced.

Secret governance measures actual materialized copies, ownerless consumers, long validity, environment-variable injection, and repository or object findings. The objective is fewer copies, shorter lifetime, and visible consumers. Static third-party credentials that cannot yet disappear are centrally stored, source- and permission-restricted, and where possible placed behind a broker so internal callers continue using short-lived identities.

Guardrail failure remains visible. A denied attempt to create a key, weaken logging, purge a queue, or set production capacity to zero produces a case with principal and change context. SCPs, permissions, alerts, and break-glass recovery are designed and exercised together so a silent denial neither hides another attempted path nor locks responders out.

7.2 Exercises and metrics test whether defenders can interrupt an attack wave within an hour

Begin with a production application key from a new source. At ten minutes inject a managed-secret read; at twenty, a second-account key; at thirty, a runner change and RDS query; at forty, ECS capacity reduction. The second identity is the test: do responders acknowledge the fork and immediately extend query and command scope to the new platform?

Sandbox accounts generate real harmless CloudTrail events to measure central ingestion, query, and alert delay. Add missing S3 data events, clock skew, shared NAT, unknown consumers, modified infrastructure, and a business refusal to pause releases. Incident command must state confidence, authority thresholds, exceptions, and compensating controls while evidence remains incomplete.

Measure actor conversion time beside defender response time: secret read to child identity's first use, then discovery, denial, and descendant search. Other checkpoints include cross-account scope, trusted canary, layered data finding, and evidence-pack completion. The metric locates logging, permission, automation, ownership, or decision paths that are slower than identity branching.

Every missed objective receives an owner and retest date. “Improve visibility” is not an action; enabling read data events for named buckets, centralizing named accounts, setting database-audit retention, and validating saved queries are reviewable changes. The next exercise starts by testing whether they shortened the same interval.

8 A service owner should deliver an executable identity, secret, artifact, data, and response inventory within thirty minutes

The thirty-minute deliverable is not a fresh architecture document. It is the smallest reliable package already maintained in the service catalog and confirmed current after notification. If an owner must search production consoles for the first time while four identity lanes are active, the organization has already ceded the tempo advantage.

For a payments API on ECS, the identity entry names the production account, task and execution role ARNs, task-definition revision, OIDC deployment role, maximum session duration, exact Secrets Manager and S3 reach, human owner, and independent response role. “The service uses IAM” cannot answer whether one key can become a database or deployment identity.

The secret entry retains ARN, version stage, real issuer, target database user or external API, consumers, startup injection, and old-session end condition without plaintext. The artifact entry pins source branch, workflow, runner, dependencies, digest, signature, infrastructure, deployment controller, and last trusted commit. An unknown consumer or build step always carries a query, temporary restriction, owner, and deadline.

The data entry covers RDS, S3, SQS, caches, analytical copies, and external processors with classification, audit, selectors, retention, query owner, normal identity, backup or replay, and business reconciliation. Missing SQL or object-level logging appears beside its alternate evidence and impact limitation; “nothing unusual” cannot erase the gap in a summary.

Together the entries form an executable dependency chain: role to secret, secret to external identity, workflow to deployment authority, artifact to runtime, and data map to business effect. Every row has primary and backup owners, on-call route, escalation authority, and a link to a non-production-tested response workflow. A flat asset list cannot support a branching incident when the usual owner is absent.

1. Deliver the identity table. List exact production, staging, CI, and operations ARNs, accounts, policies, credential sources, session duration, and owners.
2. Deliver secrets and consumers. List each credential identifier, issuer, consumer, restart requirement, rotation order, and old-session handling.
3. Deliver the trusted artifact chain. Pin repository, protected branch, workflow, runner, image digest, signature, infrastructure source, and last trusted commit.
4. Deliver data and logging scope. State RDS, S3, SQS, and external-data audit, retention, classification, query owner, and recovery method.
5. Deliver the exercised response entry. Link the approved workflow, required permission, approver, business effect, rollback, and validation record.

A service owner has completed the handoff only when the incident team can select any row and execute its next action without asking what the identifier means, where the permission lives, or how success is measured. The deliverable should fit on a few readable pages, link to deeper evidence, and print cleanly without shrinking identifiers into illegible columns. Dense machine exports belong behind it; the front layer is an operational map.

8.1 The final evidence pack independently reproduces scope, recovery, and operational closure

The package contains application entry logs and version, original CloudTrail and queries, the identity-relationship graph, credential reports, Config history, secret ledger, source and runner audit, artifact digests and signatures, runtime collection, database audit, network evidence, and every defensive change.

Each object records source, collector, time and timezone, tool, hash, access control, and processing history. Derived rows link to original eventID and requestID, and graph edges lead back to records. Shared copies redact sensitive values while controlled originals remain available; a conclusion that cannot be replayed gains evidence or loses confidence.

Review starts from one forked identity, follows its parent event to first use, authority, persistence or data action, and then checks issuer, last use, current state, and refresh path. A second sample follows one deployment change through commit, runner, dependency, digest, signature, deployment, and runtime. Together they test whether identity relationships and artifact provenance genuinely close.

Impact closure joins control plane, data plane, and business outcome. Irreversible effects such as SQS purge require replay, reconciliation, and explicit acceptance of residual loss. Every unknown names the missing source, alternate evidence, compensating control, owner, and reopening condition; a quiet dashboard is not a conclusion.

The decisive metric is that the identity tree has stopped growing: old and unexplained identities cannot authenticate, compromised issuers cannot mint replacements, untrusted pipelines cannot publish, suspect workloads cannot refresh roles or reach the Internet, dormant artifacts cannot deploy, and unknown privileged application users or resource trusts are gone. Same-second activity across four accounts explains the branching speed, and AI assistance explains the orchestration context; the deliverable remains evidence that any independent reader can follow from the first key to every closed branch.