Four credentials believed unused, and the Atlassian server they opened
Not yet reviewed
This one was written here from the source and has not yet been signed off, so it carries no byline. Every factual claim in it comes from the document linked below and can be checked against it. The judgements are ours, and until somebody has been back through them they are marked as unverified rather than presented as settled.
From 14 November 2023 a threat actor used one access token and three service account credentials, taken in the October 2023 Okta compromise and never rotated, to probe Cloudflare and then reach its self-hosted Atlassian server. The actor accessed Confluence and Jira, created an Atlassian user account, installed the Sliver framework through the ScriptRunner for Jira plugin, and viewed 120 code repositories, 76 of which Cloudflare treats as exfiltrated. Cloudflare detected the actor on 23 November and terminated all access on 24 November.
What worked
On 23 November the actor added the Smartsheet service account to an administrator group at 15:58, an automated alert reached the security team at 16:00, and the SOC deactivated the account at 16:35. The actor's attempts on Cloudflare's Okta instance and the Cloudflare Dashboard were denied, and the attempt to reach a console server for the not yet in production São Paulo data centre failed. Cloudflare credits access controls, firewall rules and hard security keys enforced through its own Zero Trust tools for limiting lateral movement, and says no customer data or systems were affected.
What failed
Out of thousands of credentials leaked in the Okta compromise, one service token and three service accounts were not rotated because they were mistakenly believed to be unused. The Moveworks service token granted remote access into the Atlassian system, and the Smartsheet service account held administrative access to Jira, which let the actor create a lasting user account and install Sliver. The actor first gained access to Atlassian services on 15 November and was not noticed until the administrator group change on 23 November. A non-enforced ACL is what allowed the attempt on the São Paulo console server to be made at all. The clean-up, named Code Red, ran from 27 November to 5 January and included rotating more than 5,000 production credentials and forensic triage of 4,893 systems.
The number
4 credentials
out of thousands leaked in the Okta compromise were left unrotated, because they were believed to be unused.
What to do instead
After a supplier breach, rotate from an inventory and not from memory: a credential counts as unused only when logs prove it, and then it should be deleted rather than left in place. Do not give SaaS integration accounts administrative rights over the systems they plug into. Alert on changes to administrator groups, since that is the detection that fired here. Hold staging and pre-production equipment to the same enforced ACLs as production. Expect the clean-up to cost far more than the rotation you skipped.