Leaked CI credentials can drive full AWS intrusion and data theft

At a glance

What this is: This benchmark reconstructs a real AWS intrusion that began with leaked CI credentials and ended in IAM discovery, secret access, persistence, and S3 object exfiltration.

Why it matters: It matters because service identities, role assumptions, and secret exposure can turn a single compromise into multi-stage cloud impact, which is directly relevant to NHI governance and least-privilege IAM controls.

By the numbers:

• GPT-5.6 Sol led the benchmark at 88.3% accuracy, narrowly ahead of GPT-5.5 at 87.9%.
• The benchmark covered 40 tasks across 24K+ log events from CloudTrail, S3 access logs, VPC Flow Logs, and GuardDuty.

👉 Read Cotool's benchmark analysis of leaked CI credentials and AWS intrusion reporting

Context

Leaked CI credentials remain one of the most reliable entry points in cloud intrusion because they authenticate as legitimate automation, not a human user. Once an attacker validates that identity, IAM discovery, role assumption, secret retrieval, and data access can follow without triggering the same controls many teams rely on for interactive compromise. That makes this a cloud identity problem as much as a logging or detection problem.

BlueBench-Intrusion-003 uses a real AWS intrusion to test whether models can reconstruct that chain from telemetry and write a defensible incident report. The scenario is typical of modern NHI failure modes: a service identity with standing access, a reachable secret store, and enough privilege to pivot into persistence and exfiltration before defenders close the loop.

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 standing privilege increase cloud blast radius?

A: Standing privilege increases blast radius because a compromised service account can be used immediately, often with broad read access and trusted role paths. In AWS, that trust can extend into secrets access, serverless persistence, and storage enumeration. The attacker does not need time to wait for approval, which makes containment harder.

Q: How do security teams know a cloud intrusion has moved beyond access into persistence?

A: Look for the attacker creating durable control-plane objects such as Lambda functions, EventBridge schedules, new roles, or altered logging settings. Those changes show the identity is no longer just exploring. They are trying to keep access alive after the initial credential compromise is discovered.

Q: Who is accountable when a compromised pipeline identity reaches production?

A: Accountability sits with the team that owns the pipeline identity, the system that granted the access, and the programme that failed to constrain the credential lifecycle. NIST CSF and NIST SP 800-53 both expect ownership, least privilege, and auditability for privileged access, including machine identities used in software delivery.

Technical breakdown

How leaked CI credentials become an AWS entry point

A CI service identity is attractive because it is already trusted by automation pipelines and often has broad read access to build, deploy, or secret-management services. If those credentials leak, the attacker does not need to break authentication in the usual sense. They authenticate as the pipeline user, enumerate the account, and identify roles, secrets, and storage paths that can expand access. In cloud environments, the first successful call often matters more than the initial leak because it proves the identity is still live and usable.

Practical implication: treat CI identities as high-risk NHIs and revoke or rotate them as soon as exposure is suspected.

Role assumption, secrets access, and persistence in AWS

Once inside, the attacker in this case assumed a support role, read a production secret, then used Lambda and EventBridge to create persistence. That sequence matters because AWS abuse often chains identity primitives: temporary role credentials, secret retrieval, and serverless scheduling. The attacker does not need malware in the traditional sense if the control plane itself can be used to keep access alive. This is why standing trust between service accounts, IAM roles, and secret stores creates a compound risk surface.

Practical implication: separate secret access from role assumption paths and alert on unusual combination patterns across IAM, Secrets Manager, Lambda, and EventBridge.

Why exfiltration is often preceded by defense-evasion probes

The benchmark notes denied defense-evasion probes before S3 object exfiltration. That pattern is common in cloud incidents because attackers test whether monitoring, logging, or stop actions are available before they move to bulk access. A failed attempt to disable logging can still be useful evidence: it shows intent, awareness of controls, and the presence of a privilege boundary. For incident response, these failed steps are as important as the successful ones because they establish what the attacker tried to suppress.

Practical implication: alert on attempts to modify logging, telemetry, or event delivery even when the action fails, because failed suppression often precedes exfiltration.

Threat narrative

Attacker objective: The attacker aimed to maintain durable cloud access long enough to reach production data and extract objects from S3 while avoiding detection.

1. Entry occurred through leaked CI credentials for a live AWS service identity, which the attacker validated before using it for further access.
2. Escalation followed through IAM discovery, support-role assumption, and access to a production secret, which expanded the attacker’s effective privileges.
3. Impact came through Lambda and EventBridge persistence attempts, denied defense-evasion probes, and S3 object exfiltration from three buckets.

NHI Mgmt Group analysis

Leaked CI credentials are not just an access issue, they are a cloud identity collapse event. Once a service user can authenticate, many teams still rely on human-centric assumptions about review, approval, and session duration. This case shows why NHI governance has to account for automation identities that are valid, reusable, and operationally embedded. The practitioner conclusion is straightforward: if the identity can build or deploy, it can also become the breach path.

Standing trust between IAM, secrets stores, and serverless services creates a compounded blast radius. The attacker’s path from role assumption to secret retrieval to Lambda persistence is a governance chain, not three separate events. That means a narrow control like secret rotation is insufficient if IAM roles can still reach the same secret and then persist through EventBridge. The field needs lifecycle controls that treat these dependencies as one governed access graph, not isolated products. Practitioners should model the access graph first and the tooling second.

Cloud incident response fails when teams cannot say which control boundary the attacker crossed first. The benchmark shows how easy it is to confuse initial access, privileged assumption, and exfiltration when telemetry is spread across CloudTrail, S3, VPC logs, and GuardDuty. That is a detection governance problem as much as a forensic one. Teams need evidence chains that preserve identity context from the first authentication event through the final data movement, or the response will stay descriptive instead of decisive.

Secret sprawl inside CI/CD pipelines is the named failure mode this intrusion illustrates. A leaked pipeline credential becomes more dangerous when the same workflow also exposes secrets, role trust, and persistence hooks. This is exactly the kind of hidden dependency OWASP NHI and NIST-style access governance are meant to surface. Practitioners should treat pipeline secret exposure as a lifecycle failure, not an isolated leakage event.

Cloud control-plane abuse is becoming the default shape of NHI compromise. The attacker did not need to invent a new exploit when the environment already exposed a valid service identity, a production secret, and serverless persistence options. That pattern is why NHI security now sits at the intersection of IAM, PAM, and cloud operations. Security teams should assume the control plane itself is part of the attack surface and govern it accordingly.

What this signals

Secret sprawl is the governance signal behind incidents like this one. When pipeline identities, production secrets, and serverless persistence all sit in the same trust chain, the environment has already outgrown manual review. Our research shows 88.5% of organisations acknowledge that their non-human IAM practices lag behind human IAM, which explains why these chains remain so difficult to govern. The practical next step is to map and reduce hidden trust links before they become an attacker’s shortest path.

The deeper programme signal is that cloud security teams cannot treat IAM, secrets management, and runtime control as separate workstreams anymore. The attack path in this benchmark shows how identity compromise turns into persistence when the control plane is already permissive. That is why lifecycle visibility, access boundaries, and monitoring of control-plane mutations need to be managed together rather than escalated in sequence.

For practitioners

• Revoke and reissue exposed CI identities immediately When a pipeline credential is leaked, treat it as an active identity compromise, not a secret hygiene issue. Reissue the service identity, invalidate dependent tokens, and trace every role and secret it could reach before restoring normal access. This should include support-role trust paths and any automation accounts that inherit from the same pipeline.
• Map service-account trust to downstream persistence paths Document which CI users can assume roles, read production secrets, or create Lambda and EventBridge resources. Then restrict those combinations so no single automation identity can both retrieve secrets and establish durable execution. The goal is to remove hidden privilege chains that allow one credential to become a full intrusion path.
• Alert on failed logging and telemetry suppression attempts Create detections for StopLogging, event delivery changes, CloudTrail tampering, and other monitoring suppression actions, even when they fail. In this case, denied defense-evasion probes were part of the attacker’s reconnaissance and should be treated as an escalation signal rather than noise.
• Correlate CloudTrail, S3, and GuardDuty around the same identity Build incident review workflows that preserve the service identity across authentication, secret access, persistence, and exfiltration events. If the same principal appears in all four, the response should pivot from single-alert triage to full blast-radius analysis and bucket-level containment.

Key takeaways

• This intrusion shows how a single leaked CI identity can cascade into IAM discovery, secret access, persistence, and S3 exfiltration.
• The benchmark also shows that incident reporting quality depends on preserving identity context across CloudTrail, S3, VPC, and GuardDuty evidence.
• Teams should govern CI credentials as live non-human identities, with lifecycle control over trust paths, persistence hooks, and telemetry suppression attempts.

Key terms

• Leaked CI Credential: A leaked CI credential is a build or deployment identity whose secret has become accessible outside the intended automation boundary. In cloud environments it often functions like a live service account, so exposure can immediately enable authentication, discovery, and privilege chaining if lifecycle controls are weak.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Control Plane Abuse: Control plane abuse occurs when an attacker uses legitimate administrative interfaces to perform destructive or high-impact actions. In NHI terms, the problem is not malware execution but trusted authority that can scale changes across many systems at once.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.

What's in the full report

Cotool's full article covers the operational detail this post intentionally leaves for the source:

• The benchmark's run-by-run scoring and spread methodology, including how accuracy was measured across three trials.
• Per-model latency and cost breakdowns for incident-report generation across the 16 evaluated systems.
• The full attack-path evidence used in the sandbox, including CloudTrail, S3 access logs, VPC Flow Logs, and GuardDuty event handling.
• The model refusal analysis that distinguishes investigative ability from service-level cybersecurity refusals.

👉 Cotool's full benchmark details the attack path, scoring methodology, and model-by-model performance spread.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners who need to connect identity risk to operational decisions across cloud and security programmes.