Notifications
Clear all
Topic starter
18/08/2026 2:11 pm
TL;DR: BlueBench-Intrusion-003 shows how a leaked CI service identity can enable AWS discovery, role assumption, secret access, persistence, and S3 exfiltration in a controlled intrusion scenario, with Cotool noting that model performance varied sharply on evidence-backed incident reporting. The findings matter because long-lived non-human credentials still create fast-moving blast-radius risk that conventional review processes miss.
NHIMG editorial — based on content published by Cotool: BlueBench-Intrusion-003, a real AWS intrusion benchmark built from leaked CI credentials
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Map service-account trust to downstream persistence paths Document which CI users can assume roles, read production secrets, or create Lambda and EventBridge resources.
- 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.
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.
👉 Read Cotool's benchmark analysis of leaked CI credentials and AWS intrusion reporting →
Leaked CI credentials in AWS environments: what breaks next?
Explore further
18/08/2026 3:04 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Leaked CI credentials can drive full AWS intrusion and data theft
