Cloudflare’s investigation of the January 2022 Okta compromise
Authors: John Graham-Cumming, Lucas Ferreira, Daniel Stinson-Diess
Overview
Cloudflare learned of an Okta compromise on March 22, 2022 at 03:30 UTC. The company uses Okta internally for employee identity management but determined they were not compromised as a result of this incident. Notably, “Okta is not used for customer authentication on our systems” and customers need not take action unless they use Okta themselves.
Investigation and actions
During January 2022, attackers gained access to an Okta support employee’s account. A screenshot circulated showing a Cloudflare employee’s email address alongside evidence of an attacker posing as an Okta representative with potential password reset capabilities.
Cloudflare’s Security Incident Response Team (SIRT) mobilized immediately upon notification.
Timeline (times in UTC)
| Time | Action |
|---|---|
| 03:30 | SIRT receives initial warning via tweet |
| 03:38 | Team identifies Cloudflare-specific information in posts |
| 03:41 | Incident room established |
| 03:50 | No suspicious audit log events detected for exposed user |
| 04:13 | Direct outreach to Okta initiated |
| 04:23 | SIEM logs reviewed for three months of suspicious activity |
| 05:03 | Affected user accounts suspended |
| 05:06 | Access logs investigation began |
| 05:38 | Executive acknowledgment published |
| 05:44 | Password reset list finalized for 144 employees |
| 06:40 | Leadership communicated password reset directive |
| 07:57 | Okta confirmed no malicious activity detected |
How Cloudflare uses Okta
Cloudflare integrated Okta with Cloudflare Access to protect internal resources. The organization implemented hardware (FIDO) tokens for authentication, which “would also need to be changed” by attackers attempting account compromise, making detection straightforward.
The company maintains independent logging infrastructure: “Cloudflare reads the system Okta logs every five minutes and stores these in our SIEM so that if we were to experience an incident such as this one, we can look back further than the 90 days provided in the Okta dashboard.”
Key security events monitored included user password resets, MFA factor updates, and session impersonation attempts.
Response measures
Cloudflare implemented five primary actions:
- Requested detailed compromise information from Okta
- Suspended the exposed employee account
- Searched Okta system logs for suspicious events dating back three months
- Cross-referenced password resets through Google Workplace email logs
- Required password resets for all 144 employees who modified passwords or MFA since December 1, 2021, with mandatory identity verification via video call
Guidance for Okta customers
The company advised other Okta users to:
- Enable multi-factor authentication organization-wide, preferably using hardware keys
- Audit all password and MFA modifications, with special attention to support-initiated changes
- Force password resets if any suspicious activity is detected
- Implement additional security layers independent of Okta
Conclusion
Cloudflare’s security teams continue investigating the incident. The organization maintains ongoing communication with Okta regarding additional logs and information. The company committed to publishing updates should new findings alter their assessment.