Leaked CI credentials can drive full AWS intrusion and data theft

At a glance

What this is: This is a benchmark write-up based on a real AWS intrusion scenario where leaked CI credentials enabled discovery, role abuse, persistence and S3 theft.

Why it matters: It matters because CI identities often sit outside human access governance, yet they can still provide the attacker with the same AWS control plane reach as an operator.

Context

CI credentials are machine identities, not just deployment shortcuts, and they become a governance problem when their scope, lifetime and downstream role assumptions are poorly controlled. In AWS, that can turn a single leaked service account into a path across IAM discovery, secrets access, persistence and storage theft.

The article’s scenario is grounded in a controlled lab intrusion, but the access pattern is familiar to cloud teams that rely on long-lived build credentials. The identity issue is not the tooling itself; it is the fact that CI identities can inherit enough trust to move from build systems into production AWS assets.

Key questions

Q: What fails when leaked CI credentials are reused in AWS environments?

A: Leaked CI credentials fail the moment teams treat them like ordinary application secrets rather than live service identities. They can authenticate, enumerate IAM, reach secrets stores, and sometimes assume roles or create persistence. The result is a cloud intrusion path that can move from initial access to exfiltration without a separate malware step.

Q: Why do service accounts with role-assumption rights increase AWS breach risk?

A: Because the attacker rarely stops at the first identity. Role-assumption rights let a leaked service account move into higher-value permissions, often including secret access and storage reach that were not obvious from the original credential. That turns one compromised machine identity into a chain of trust expansion across the account.

Q: How can security teams tell whether credential theft has moved into cloud persistence?

A: Look for MFA registration changes, new OAuth app consents, unusual sign-ins, and service principal or admin role changes after the initial compromise. Those actions indicate that stolen credentials are being converted into durable access rather than a one-time login. Identity telemetry is the clearest place to see that transition.

Q: What should security teams do first after a CI identity is exposed?

A: First, revoke and rotate the exposed credential, then immediately enumerate every role, secret and automation path that identity could already reach. If the account has touched production services, assume the attacker may have established persistence through native AWS services and investigate those paths before restoring normal access.

Technical breakdown

How leaked CI credentials become an AWS entry point

A CI service identity is a non-human identity that often authenticates with long-lived access keys or tokens. If those credentials leak, an attacker does not need to guess an initial foothold because the identity itself already carries trusted access into AWS APIs. The first useful action is usually validation, then discovery of what the identity can see and which roles it can assume. In practice, the exposed credential matters less than the permissions attached to it and the secondary paths those permissions unlock across IAM, Secrets Manager and storage.

Practical implication: inventory CI credentials as production identities and remove any that can authenticate without tight issuance and scope controls.

Why role assumption and secrets access amplify the blast radius

Once a CI identity can call IAM and assume a second role, the attacker is no longer limited to the original build context. Role chaining changes the effective privilege set, often exposing production secrets that were not reachable from the first credential alone. Secrets Manager access is especially dangerous because a single readable secret can unlock additional services, tokens or downstream automation. This is where machine identity governance intersects with access design: the original credential may look modest, but its trust relationships can be broad.

Practical implication: review every role that a CI identity can assume and treat secret-read permissions as high-risk access paths.

How persistence and exfiltration follow control-plane access

Persistence in cloud incidents often uses native services rather than malware, because scheduled functions and event triggers survive session loss. In the benchmark case, Lambda and EventBridge were used to maintain access after the initial credential was no longer the only foothold. Once persistence exists, object exfiltration from S3 can be staged through ordinary API calls that blend into routine cloud traffic. The technical lesson is that identity compromise in AWS is often a control-plane problem first and a data-loss problem second.

Practical implication: monitor for native-service persistence patterns after any CI credential compromise and correlate them with S3 access anomalies.

Threat narrative

Attacker objective: The attacker’s objective was to turn a leaked CI identity into durable AWS access and data theft from S3.

1. Entry began with a leaked CI service credential that authenticated successfully into the AWS environment and allowed the attacker to validate the identity.
2. Credential and privilege expansion followed when the attacker enumerated IAM, assumed a support role, and used Secrets Manager to read a production secret.
3. Persistence was established with Lambda and EventBridge, while the attacker probed monitoring controls and then pulled objects from three S3 buckets.
4. Impact was S3 object exfiltration from the environment, enabled by a machine identity that had enough trust to move through the account.

Breaches seen in the wild

• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
• Amazon AWS Hacked Accounts Crypto-Mining: Compromised IAM credentials across multiple AWS accounts fuel large-scale crypto-mining campaign.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Leaked CI identities are not peripheral build artefacts; they are production access paths. The article shows that a CI credential can validate into AWS, discover IAM, assume a broader role and reach secrets and storage. That sequence demonstrates a governance failure in how machine identity scope is assigned and monitored. Practitioners should treat CI credentials as first-class identities with explicit lifecycle control.

Role chaining turns a narrow credential leak into a cloud-wide trust problem. The decisive issue is not whether the first key is limited, but whether it can reach a role that opens Secrets Manager, persistence services or data stores. This pattern is directly relevant to NHI governance because the trust boundary is defined by the whole chain, not the initial account. The practical conclusion is to govern delegated access paths, not just the originating secret.

Control-plane persistence is the hidden advantage of AWS intrusions. Using Lambda and EventBridge to stay resident means the attacker can outlast a credential reset if the persistence layer is not identified and removed. That is a named failure mode in cloud identity operations: revoking the leaked credential alone is not the same as revoking the trust path it already created. Teams need containment logic that assumes the attacker may have already promoted the compromise into native services.

Data theft in these incidents follows identity abuse, not noisy exploitation. The article’s path from credential use to S3 exfiltration shows why detections focused only on malware or endpoint signals miss cloud intrusions. For IAM and NHI programmes, the meaningful signal is the combination of unusual identity validation, role assumption and secret read access. Security teams should read this as a control design problem around access scope, offboarding and delegated trust.

What this signals

Machine identity compromise in CI pipelines is a cloud governance issue, not a tooling issue. The practical question is whether the identity can be issued, assumed, and re-used outside the intended build boundary. Once that happens, the attacker is operating through legitimate AWS control-plane access, which means detection and containment must start with identity scope and delegated trust.

CI leakage creates a blast-radius problem that traditional access review cannot see in time. A review process may record the identity and its permissions, but it will not necessarily reveal the live sequence of role assumption, secret access and persistence creation that the attacker executes in minutes. That is why cloud identity programmes need monitoring at issuance and at assumption, not only at review.

Delegated trust chains are now the decisive control surface for AWS environments. If a leaked build identity can pivot into support roles, secret stores and native persistence services, the effective boundary is the entire role chain. Practitioners should redesign trust to make each hop explicit, narrow and observable, especially where CI systems touch production.

For practitioners

• Audit CI service identities as production accounts List every CI credential, the roles it can assume, and the secrets it can read. Remove credentials that are shared, unowned or used outside a documented build path.
• Restrict role assumption from build systems Limit which AWS roles CI identities can assume and require explicit approval for any path that can reach production secrets or privileged operations.
• Segment Secrets Manager access from pipeline identities Separate read access for production secrets from routine build access so a leaked pipeline credential cannot become a secret-retrieval path.
• Hunt for native-service persistence after credential exposure Search for Lambda, EventBridge and similar control-plane changes that appeared after the leaked identity was first used, then remove any scheduled or automated footholds.
• Correlate S3 reads with identity anomalies Compare unusual S3 access patterns with IAM discovery, role assumption and secret-read events to determine whether the attacker moved from access to exfiltration.

Key takeaways

• A leaked CI credential can become a full AWS intrusion path when the identity can enumerate IAM, assume roles and read secrets.
• The article’s scenario shows that persistence and exfiltration can be built with native AWS services, not just malware.
• The control that matters most is the delegated trust chain, because revoking one key does not undo the access it already opened.

Key terms

• Canonical Service Identity: The single approved record that represents one service or workload across multiple discovery sources. It prevents the same system from being treated as separate entities when connectors expose different names, labels, or metadata. In AI-assisted operations, canonical identity is what makes ownership, dependency, and blast-radius analysis trustworthy.
• Role Assumption: Role assumption is the process of using one identity to take on the permissions of another trusted role. In cloud security, it is a major escalation path because a compromised key may not only access its own resources, but also pivot into additional accounts or services through assumed roles.
• Control-Plane Persistence: A way for an attacker to maintain access through management features rather than by holding a normal user session. In this article’s pattern, SSH key insertion and NETCONF abuse are examples of persistence that live inside administrative workflows.
• Delegated trust chain: The sequence of systems, intermediaries, and policies that carries a consumer’s permission from the original request to the final data exchange or transaction. This chain is only as strong as its weakest handoff, so governance must cover scope, revocation, and third-party accountability end to end.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It is designed for practitioners who need to control service identities across build, cloud and privileged access paths.