Web security company Cloudflare on Thursday revealed that a threat actor used stolen credentials to gain access to some of its internal systems.
The threat actor, believed to be state-sponsored, was discovered on November 23, nine days after the actor used credentials compromised in the October 2023 Okta attack to access Cloudflare’s database.
The security firm explained that the stolen login credentials, an access token and three service account credentials were not modified following the Okta incident, allowing the attackers to probe Cloudflare systems and conduct reconnaissance starting on November 14.
According to Cloudflare, the attackers were able to access Atlassian Jira and Confluence, as well as the AWS environment, but network segmentation prevented them from accessing the Okta instance and the Cloudflare dashboard.
The attackers created an Atlassian account to gain persistent access to the environment on November 16 and returned on November 20 to verify that they still had access.
On November 22, the threat actor installed the Sliver Adversary Emulation Framework to gain persistent access to the Atlassian server, which was then used to act horizontally.
The attackers viewed 120 code repositories and downloaded 76 of them to the Atlassian server, but did not leak them. Cloudflare notes that a small number of the repositories contained encrypted secrets that were immediately returned, even though they were themselves strongly encrypted.
The attackers used a Smartsheet service account to access Cloudflare’s Atlassian suite, and the account was terminated within 35 minutes on November 23 after unauthorized access was detected. The user account created by the attacker was found and disabled 48 minutes later.
Cloudflare says it also implemented firewall rules to block the attackers’ known IP addresses, and the Sliver Adversary Emulation Framework was removed on November 24.
“During this timeline, the threat actor attempted to access numerous other systems at Cloudflare but was unsuccessful due to our access controls, firewall rules and the use of hard security keys implemented using our own Zero Trust tools,” the company said.
“We also continued to investigate every system, account and log to ensure that the threat actor did not have persistent access and that we understood exactly which systems they touched and which ones they attempted to access,” the company said.
