Among the stolen credentials was a Moveworks service token that granted remote access to Atlassian systems. Other compromises included a Smartsheet account with administrative access to the Atlassian Jira instance, a Bitbucket service account with access to the Cloudflare source code management system, and an AWS environment with “no access to the global network and no customer or sensitive data.”
“From November 14 to 17, the threat actor did reconnaissance and then accessed our internal wiki (which uses Atlassian Confluence) and our bug database (Atlassian Jira),” Cloudflare added. “They then returned on November 22 and established persistent access to our Atlassian server using ScriptRunner for Jira, gained access to our source code management system (which uses Atlassian Bitbucket), and tried, unsuccessfully, to access a console server that had access to the data center that Cloudflare had not yet put into production in São Paulo, Brazil.”
The company added that the incident was in no way an error on the part of Atlassian, AWS, Moveworks, or Smartsheet, and happened because it failed to rotate the stolen credentials assuming they were unused.
Cloudflare said it was able to completely contain and remove the infection owing to its adoption of a zero-trust architecture.
“Because of our access controls, firewall rules, and use of hard security keys enforced using our own Zero Trust tools, the threat actor’s ability to move laterally was limited,” the company said. “No services were implicated, and no changes were made to our global network systems or configuration.”
Acknowledging the attack’s intention for establishing persistence and fearing overlooked persistence, Cloudflare resorted to a comprehensive remediation approach with additional proactive steps for future attacks.
