Detecting CI/CD Secrets Theft: Sentinel and GuardDuty Detections

Retrospective: this article looks back at events from January 2023, written in 2026 with the benefit of hindsight.

After a CI/CD provider breach, attackers use stolen secrets to access your cloud. Detecting that use — and use of secrets after rotation — tells you whether you were affected.

Signals worth watching

• Cloud credentials stored in CI/CD used from IP addresses outside your CI/CD provider's ranges.
• Deployment roles performing actions outside normal deployment patterns (for example, reading data, creating users).
• API calls with access keys after you rotated them (attempts with revoked keys).
• Service principal sign-ins from unfamiliar locations.
• New secrets or keys created by CI/CD identities.

Where the data lives

• AWS CloudTrail: activity by CI/CD IAM users or roles; InvalidClientTokenId errors indicating use of deleted keys.
• Entra ID service principal sign-in logs for Azure deployments.
• CI/CD audit logs (who changed secrets, pipelines and contexts).

A starting query

Use of invalid or deleted AWS keys:

AWSCloudTrail
| where ErrorCode in ("InvalidClientTokenId", "SignatureDoesNotMatch")
| summarize Attempts = count() by UserIdentityAccessKeyId, SourceIpAddress, bin(TimeGenerated, 1h)

After rotation, any attempts using old key IDs suggest the key was stolen.

Response

1. Confirm all secrets were rotated.
2. Investigate any activity by CI/CD identities from unexpected sources.
3. Review changes made to infrastructure during the exposure window.
4. Move to OIDC federation to remove stored cloud secrets.