Circleci breach lessons for early detection and identity control

At a glance

What this is: This is an analysis of the CircleCI breach and the identity-control failures it exposed across credentials, session theft, and production access.

Why it matters: It matters because IAM, NHI, and privileged-access teams need to design for stolen sessions and token abuse, not just login security.

By the numbers:

• On December 29, 2022, one of CircleCI's customers alerted their respective Security Team of suspicious GitHub OAuth activity.
• The internal investigation into the unauthorized third-party intrusion and the entry point of the attack was completed by January 4, 2023.

👉 Read Unosecur's analysis of the CircleCI breach and early incident detection

Context

CircleCI was breached after malware on a worker laptop stole two-factor authentication-enabled credentials and allowed impersonation of the employee from a remote location. The incident then extended into production access, where tokens, keys, environment variables, and other sensitive information could be reached.

For identity teams, the lesson is not just that an endpoint was compromised. The governance gap was the assumption that authenticated sessions, generated tokens, and encrypted data would remain protected once the initial login succeeded. That assumption fails when attackers can reuse session cookies and reach privileged production workflows.

Key questions

Q: What breaks when session cookies are stolen from a compromised employee device?

A: A stolen session cookie can let an attacker impersonate the user without re-entering credentials or completing MFA. That breaks the assumption that successful authentication means the session is trustworthy for its full lifetime. Teams should treat bearer tokens and active sessions as sensitive credentials and monitor them separately from passwords.

Q: Why do production token generators create outsized risk in identity environments?

A: Because they sit at a privilege choke point. If an attacker compromises the person or system that issues production tokens, they can inherit downstream access that outlives the original login. This is why token issuance needs stronger separation, stronger monitoring, and tighter role design than routine administrative access.

Q: How do security teams know whether runtime secrets are actually protected?

A: They test whether keys, environment variables, or tokens can be recovered from live processes, memory, or execution paths. If decryption material is reachable during runtime, the secret is exposed even if storage is encrypted. Effective governance measures runtime exposure, not just stored encryption status.

Q: Who is accountable when a third-party notices suspicious identity activity first?

A: The organisation owning the affected sessions and credentials remains accountable, even when a customer or partner detects the abuse first. External alerts should be treated as a control signal, not a substitute for internal identity monitoring. Frameworks such as the NIST Cybersecurity Framework 2.0 reinforce the need for detect and respond ownership.

Technical breakdown

How session-cookie theft turns endpoint malware into remote impersonation

Session cookies are bearer artefacts. If malware on an employee device steals them, the attacker can reuse the authenticated session without re-entering the password or completing MFA. In this case, the laptop compromise bypassed the usual login boundary and created a path from endpoint infection to remote identity impersonation. Antivirus did not stop the attack, which shows that prevention controls on the workstation do not eliminate the trust carried by active sessions. Once a session is captured, the attacker inherits whatever the user could do during that valid session window.

Practical implication: monitor for session hijacking indicators and treat bearer-token exposure as a separate control problem from password theft.

Why production token generation creates a high-value privilege choke point

The employee at the centre of the incident had responsibility for generating access tokens for production systems. That concentrates risk: if an attacker reaches the operator, they can often obtain downstream tokens that outlive the interactive session and grant broader access than the original login. This is an NHI governance issue because tokens, keys, and environment variables function as non-human identities once issued. The compromise of a privileged workflow is often more damaging than compromise of the account itself, because the attacker can pivot into systems that were never directly reachable from the endpoint.

Practical implication: separate token issuance from general user access and review which production credentials inherit workstation trust.

Why encrypted data can still be exposed when runtime keys are reachable

Encryption does not protect data if the keys are available in memory or accessible through a running process. The article notes that the attacker could obtain encryption keys by accessing a running process, which means the protection boundary had shifted from storage to execution. That is a runtime identity and secrets problem, not a pure data-at-rest issue. When attackers can touch live processes, the confidentiality promise of encryption weakens because the operational secret needed to decrypt the data is already present in the environment.

Practical implication: treat runtime key exposure as part of secrets governance, not just storage encryption policy.

Threat narrative

Attacker objective: The attacker wanted to impersonate a trusted employee, expand into production systems, and extract sensitive customer data and secrets.

1. Entry occurred through malware on a CircleCI worker laptop, where the attacker stole two-factor authentication-enabled credentials and session cookies.
2. Escalation followed when the attacker reused the impersonated session to reach production systems and obtain access tokens, environment variables, keys, and other sensitive data.
3. Impact included unauthorized access to customer data and possible access to encrypted information after the attacker obtained runtime encryption keys.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing session trust is a brittle assumption in modern identity programmes. The CircleCI breach worked because the environment treated a valid session as proof of ongoing trust after the endpoint was compromised. That is a failure of the assumption that authenticated access remains safe until the user actively signs out. The implication is that session state, not just login state, must be treated as a security boundary in identity governance.

Token issuance becomes a privileged control plane when production access is concentrated in one operator workflow. In this incident, the person generating access tokens for production systems became the pivot point for wider compromise. That pattern fits OWASP-NHI and NIST CSF thinking because issuance authority is itself a governed identity function. Practitioners should treat token generation roles as high-risk production identities, not ordinary administrative convenience.

Runtime encryption collapses if the decryption material lives inside the running process. The attacker did not need to break cryptography in the abstract; they needed access to the process that held the key. That is a control-gap story in which storage protection was not enough because operational secrets were exposed at execution time. Practitioners should conclude that live-process access is a secrets and workload-identity issue, not only a data-security issue.

Early detection is the difference between a contained credential event and a broad identity compromise. CircleCI’s own investigation was triggered by suspicious GitHub OAuth activity reported by a customer, which shows how external telemetry can surface identity abuse before internal controls do. The broader field lesson is that incident detection must be tied to identity signals, token usage, and anomalous delegation paths. Practitioners should assume that some compromise paths will be noticed first by the wrong party.

Identity blast radius: once a trusted session can mint tokens, the compromise radius expands from a laptop to production systems, stored secrets, and potentially encrypted data. This is the governance failure mode the breach exposes. The blast radius was created by a chain of trust that extended too far from endpoint to issuance to runtime access. Practitioners should redesign around smaller identity blast radii rather than longer trust chains.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
• For a broader incident lens, read The 52 NHI breaches Report for recurring compromise patterns and root-cause analysis.

What this signals

Identity blast radius is the right concept for programme owners to track here. Once an employee session can mint production tokens, the compromise radius expands across human access, machine credentials, and runtime secrets, which means containment design matters as much as authentication design.

The practical signal for teams is whether their identity telemetry can distinguish normal session continuation from compromised session reuse. If it cannot, customer-reported anomalies will keep outrunning internal detection, and the programme will remain dependent on luck rather than control.

For practitioners, this is a cue to reassess how bearer credentials, runtime secrets, and delegated production authority are linked in the access model. The more those links are implicit, the more difficult it becomes to prove that the identity boundary still exists.

For practitioners

• Separate session trust from production authority Limit what a valid interactive session can do after a device compromise by isolating token generation, production access, and administrative workflows into distinct roles with explicit approval paths. Do not let a single endpoint session inherit the ability to mint powerful downstream credentials.
• Instrument bearer-token and cookie misuse detection Monitor for reused session cookies, unusual OAuth activity, and token generation from unexpected devices or locations. Identity telemetry should flag when a session continues to act after its endpoint posture changes.
• Move encryption keys away from live process exposure Review where runtime keys, environment variables, and secrets are accessible to running processes, and reduce the number of places where decryption material can be recovered from memory or process state. Storage encryption alone is not enough if live execution reveals the key material.
• Treat customer-reported identity anomalies as high-priority signals Build an incident path that can consume third-party OAuth alerts, suspicious login reports, and partner telemetry without delay. In this breach, a customer notice helped surface the compromise, so external identity signals should feed the same triage queue as internal detections.

Key takeaways

• The breach showed that a compromised endpoint can become a production identity incident when sessions, tokens, and runtime keys are all trusted too far.
• The scale of the problem is not theoretical: one customer alert exposed a chain that reached customer data, production systems, and encrypted material.
• The control that matters most is not only login protection, but separation of session trust, token issuance, and live secret exposure.

Key terms

• Session Cookie Theft: Session cookie theft is the capture of a logged-in session token so an attacker can act as the authenticated user without re-entering credentials. In identity governance terms, it is bearer-credential compromise that can outlast the original login and bypass MFA unless the session itself is monitored and revoked.
• Token Issuance Authority: Token issuance authority is the privilege to create or distribute credentials that grant access to downstream systems. It is a high-risk identity function because whoever controls issuance can widen the blast radius far beyond their own login, especially when production access or machine credentials are created from the same workflow.
• Runtime Secret Exposure: Runtime secret exposure occurs when keys, tokens, or environment variables can be recovered from a live process rather than from secure storage alone. It matters because encryption at rest does not protect data if the decryption material is available during execution, making process access part of the secrets boundary.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and downstream credentials that become exposed when one identity control fails. It is a practical measure of how far a compromised session, service account, or token can spread before containment, and it should shape role design and monitoring priorities.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• A closer walkthrough of the CircleCI attack chain, including the employee laptop compromise and credential theft path.
• The platform-level detection and response capabilities Unosecur says can surface anomalous identity behaviour earlier.
• FAQ guidance on detecting identity incidents, automated response, and compliance monitoring in live environments.
• The article's own positioning on how unified identity visibility applies across human, machine, and AI identities.

👉 Unosecur's full blog covers the attack sequence, detection story, and response framing in more detail.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or operational governance, it is worth exploring.