Résumé
Okta is an identity provider: the single front door thousands of companies use to log their employees into everything. So when Okta's customer-support system was breached in late 2023, the blast radius was a who's-who of security-conscious companies. The entry point was almost mundane. An employee had signed into their personal Google account on an Okta laptop and saved a corporate service-account password into it; the attacker got that password and walked into Okta's support system. There they downloaded diagnostic files that customers had uploaded, some of which contained live session tokens, and used those tokens to step directly into the customers' own Okta environments. It is the lesson that session tokens are as good as passwords, support systems are production systems, and a personal browser profile can be the crack in the wall.
How it happened
Between 28 September and 17 October 2023, an attacker used stolen credentials to access Okta's customer-support case-management system. The credentials belonged to a service account, and they leaked through an ordinary-seeming mistake: an employee had signed into a personal Chrome profile on an Okta-managed laptop and saved the service-account password into their personal Google account, which synced it out of the company's control.
Inside the support system, the attacker downloaded HTTP Archive (HAR) files that customers had uploaded for troubleshooting. HAR files are full recordings of a browser session, and they can contain valid session tokens. The attacker extracted those tokens and replayed them, hijacking the sessions to access the customers' own Okta tenants directly, with no need for the password or MFA, because a session token represents an already-authenticated session. Okta initially said the breach touched 134 customers, with confirmed session hijacking at five, including BeyondTrust, Cloudflare, and 1Password, which detected it through their own monitoring. But a month later, on 29 November, Okta disclosed a far wider exposure: the attacker had also downloaded a report containing the names and email addresses of every user of its support system, effectively all of its customers.
The damage
Beyond the 134 case-file victims and the five confirmed session hijacks, and then the contact details of the entire support userbase, the deeper damage was reputational and structural: a breach of an identity provider is a supply-chain breach for every customer that depends on it, and the customers, major security firms, caught the intrusion before Okta confirmed it. BeyondTrust flagged the activity to Okta on 2 October, but Okta's security team did not confirm the breach for another 17 days, during which the attacker kept its access. The market noticed too: Okta's share price shed roughly $2 billion in value in the week after disclosure. It was a pointed reminder that the company guarding everyone's front door has to hold itself to the highest standard.
Why Okta still matters
Okta leaves three lessons. First, session tokens are bearer credentials: a stolen token bypasses passwords and MFA entirely, so they must be protected like passwords, bound to device and IP, kept short-lived, and scrubbed from any file before it is shared. BeyondTrust's own admin account was protected by FIDO2 and a managed-device policy, so when the stolen token was replayed it was blocked, and the attacker's fallback to admin API calls was also caught, a clean demonstration that device-bound MFA beats a stolen session. (Okta's named fix was to bind admin session tokens to network location.) Second, support systems are production systems: they hold real customer data and access and must be secured to the same standard. Third, personal-account sync on managed devices is a leak path, which is why Okta blocked personal Google sign-in on managed devices afterward. Okta's identity layer is also the exact pivot Scattered Spider exploited in attacks like MGM.
Comment le corriger
- Revoke and rotate the compromised service-account credential and invalidate all session tokens that could have been exposed, forcing re-authentication.
- Notify affected customers fast and transparently (the delay drew justified criticism), and help them hunt for token replay in their tenants.
- Block personal-account sign-in and profile sync on managed devices so corporate secrets cannot leak into personal accounts.
Comment l’éviter
- Treat session tokens as bearer credentials: bind them to device and IP, keep sessions short, and re-authenticate for sensitive actions.
- Scrub diagnostic files (HAR captures) of session tokens and secrets before they are uploaded or shared; never upload a HAR with live tokens.
- Secure support and internal tooling to the same standard as production, since it holds real customer data and access.
- Block personal-account sign-in and browser-profile sync on managed devices, the exact leak path here.
- Detect and respond to token replay (an existing session reused from a new device), and act on customer reports immediately.
Références
- https://sec.okta.com/articles/2023/11/unauthorized-access-oktas-support-case-management-system-root-cause/
- https://sec.okta.com/articles/october-security-incident-recommended-actions/
- https://blog.cloudflare.com/how-cloudflare-mitigated-yet-another-okta-compromise/
- https://www.beyondtrust.com/blog/entry/okta-support-unit-breach
Vulnérabilités liées
Tout OpSec →- HIGHOPSEC-INTERNET-ARCHIVE-2024
The Internet Archive, the nonprofit behind the Wayback Machine, had a brutal October 2024: a data breach, a website defacement, and a wave of DDoS attacks, all at once. Underneath the chaos was an unglamorous root cause. An authentication token sat in plain text in a public config file; the team rotated it repeatedly, but each new token landed right back in the same exposed file, so the leak never actually closed. With it, an attacker downloaded the source code, found more credentials hardcoded inside, and walked out with a database of 31 million users. Weeks later a second token from that same stolen code, for the support system, exposed 800,000 support tickets, some with people's ID documents. It is the lesson that rotating a secret is useless if it goes straight back into a public file, and that one leak unravels everything.
- HIGHOPSEC-MERCEDES-BENZ-2024
Publicly disclosed January 30, 2024, a Mercedes-Benz employee accidentally committed a GitHub authentication token to a public repository, leaving it exposed from September 29, 2023. RedHunt Labs found the token during an internet-wide scan; it granted unrestricted, unmonitored access to Mercedes-Benz's internal GitHub Enterprise Server, allowing anyone to download private source-code repositories that could contain API keys, cloud access keys, database connection strings, blueprints, and SSO passwords. After notification, the token was revoked on January 24, 2024. Mercedes-Benz stated customer data was not affected but could not confirm whether anyone besides the researchers accessed the repositories during the exposure window.
- CRITICALOPSEC-MIDNIGHT-BLIZZARD-2024
In January 2024, Microsoft revealed that Russia's foreign-intelligence service, the same APT29 behind SolarWinds, had been reading the email of its senior leadership. The way in was almost insulting in its simplicity: a forgotten, non-production test account with a weak password and no MFA. The attackers guessed the password by spraying common ones across many accounts, then pivoted through a forgotten over-privileged application to grant themselves access to corporate mailboxes, including those of executives and the security and legal teams. It is the lesson that your security is only as strong as the account you forgot about, and that even Microsoft's perimeter fell to a missing MFA checkbox.
- CRITICALOPSEC-23ANDME-2023
23andMe held the most personal data there is: people's DNA. In 2023 attackers got into more than 18,000 accounts and, through a single social feature, turned that into the genetic and ancestry data of roughly 6.9 million people. The break-in required no flaw in 23andMe at all. Attackers simply took username-and-password pairs leaked from other companies' breaches and tried them, betting, correctly, that people reuse passwords. The accounts had no MFA, and 23andMe did not notice the five-month wave of automated logins. From those footholds, the attackers scraped relatives' data through an opt-in feature, and the fallout, fines, a $50 million settlement, and ultimately bankruptcy and a fire-sale of the DNA database itself, shows that a breach can be fatal even when your own systems were never hacked.
- HIGHOPSEC-MICROSOFT-SAS-2023
Microsoft's AI research team shared open-source training data via an Azure Storage Shared Access Signature (SAS) token committed to a public GitHub repo around July 2020. The token was misconfigured to scope access to the entire storage account with full-control permissions instead of the intended read-only bucket, so anyone with the link could view, delete, and overwrite files. Wiz researchers discovered it in June 2023, finding 38 terabytes of exposed internal data including two employees' workstation disk backups with secrets, private keys, passwords, and over 30,000 internal Teams messages. Writable pickle-format models created a model-poisoning supply-chain risk; Microsoft revoked the token and reported no customer data was exposed.
- HIGHOPSEC-SOURCEGRAPH-2023
On July 14, 2023, a Sourcegraph engineer accidentally committed an active site-admin access token in a pull request, and automated secret-scanning controls failed to catch it. On August 30, 2023, an attacker used the leaked token to elevate a newly created account to site-admin and access the administrative dashboard. The attacker raised API rate limits and created a public proxy app granting arbitrary users free access to Sourcegraph's APIs and underlying LLM, with instructions spreading widely online. License-key recipient names and emails, a subset of customer license keys, and community account email addresses were exposed; Sourcegraph stated no private code or passwords were compromised.