Okta — stolen service account token → support-system compromise
A leaked service account credential (a Google account used by an Okta employee) gave attackers access to Okta's support case-management system. Customer HAR files with session tokens were accessed, enabling downstream compromise of Okta's customers.
What happened
An Okta employee signed into a personal Google account on an Okta-managed laptop. The Google account's credentials were compromised. The attacker found Okta service account credentials saved in the Google account and used them to access Okta's case-management system. HAR files uploaded by customers (containing session cookies) were exposed.
Timeline
Okta employee signs into personal Google account on work laptop.
Attacker accesses Okta support system.
BeyondTrust notifies Okta of suspicious access.
Okta confirms breach scope publicly.
Root cause
Service account credentials stored in a personal cloud account created a trust bridge between corporate and personal security boundaries. The personal account was the weakest link.
Impact
- 134 Okta customers impacted (1% of customer base)
- Downstream breaches at BeyondTrust, Cloudflare, 1Password (all defended successfully)
- Stock-price drop, customer-trust hit
Partially. Securie's secret-lifecycle manager tracks service account credentials and flags long-lived credentials. The 'personal cloud account' trust boundary is a policy control, not a technical one.
Lessons
- Never store corporate credentials in personal cloud accounts
- Service account credentials should be short-lived (OIDC / Workload Identity)
- Scrub HAR files of session tokens before sharing
- Trust boundaries between corporate and personal are porous — assume that