Cloudflare systems hacked using credentials stolen during the Okta hack

Yesterday (1st February 2024) web security firm Cloudflare disclosed a security breach where an unauthorized actor utilized stolen credentials to access some of its internal systems. The company identified the incident on November 23rd 2023, discovering that the threat actor, suspected to be state-sponsored, exploited credentials compromised during the October 2023 Okta hack to infiltrate Cloudflare’s internal wiki and bug database.

The pilfered login details, comprising an access token and three service account credentials, were not updated after the Okta breach. Consequently, the attackers could conduct reconnaissance on Cloudflare’s systems beginning November 14, according to the security company.

In a statement an Okta spokesperson told SystemTek “This is not a new incident or disclosure on the part of Okta. On October 19th, we notified customers, shared guidance to rotate credentials, and provided indicators of compromise (IoCs) related to the October security incident. We can’t comment on our customers’ security remediations.“

Cloudflare reported that the attackers successfully penetrated an AWS environment, along with Atlassian Jira and Confluence. However, network segmentation prevented access to Cloudflare’s Okta instance and the Cloudflare dashboard.

With entry into the Atlassian suite, the threat actor sought information on the Cloudflare network by searching the wiki for terms such as “remote access,” “secret,” “client-secret,” “openconnect,” “cloudflared,” and “token.” A total of 36 Jira tickets and 202 wiki pages were accessed.

On November 16, the attackers created an Atlassian account to maintain persistent access, returning on November 20 to verify their continued access. Subsequently, on November 22, the threat actor installed the Sliver Adversary Emulation Framework on the Atlassian server, establishing persistent access for lateral movement. They attempted to access a non-operational console server at a São Paulo, Brazil, data center on the same day.

While the attackers viewed 120 code repositories and downloaded 76 of them to the Atlassian server, they did not exfiltrate the data. Cloudflare noted that these repositories primarily dealt with backup processes, global network configuration, identity management, remote access, and their use of Terraform and Kubernetes. Encrypted secrets found in some repositories were immediately rotated, even though they were strongly encrypted.

The attackers utilized a Smartsheet service account to access Cloudflare’s Atlassian suite, and the account was terminated on November 23, within 35 minutes of detecting unauthorized access. The user account created by the attacker was deactivated 48 minutes later. The company implemented firewall rules to block the attackers’ known IP addresses, and the Sliver Adversary Emulation Framework was removed on November 24.

Cloudflare emphasized that throughout the attack timeline, the threat actor’s attempts to access various Cloudflare systems were thwarted by access controls, firewall rules, and the use of hard security keys enforced with their Zero Trust tools.

Cloudflare found no evidence that the threat actor accessed its global network, customer database, configuration information, data centers, SSL keys, workers deployed by customers, or any other information, except data within the Atlassian suite and the server hosting their Atlassian instance.

On November 24, Cloudflare initiated security improvements, tasking numerous technical employees with enhancing security and confirming that the threat actor no longer had access to the company’s systems. Over 5,000 individual production credentials were rotated, nearly 5,000 systems were triaged, and test and staging systems were physically segmented. Additionally, every machine within the Cloudflare global network was reimaged and rebooted.

Even though the São Paulo data center equipment was not accessed, it was sent back to the manufacturers for inspection and replacement, despite no evidence of compromise being discovered.

Cloudflare asserted that the objective of the attack was to gather information on the company’s infrastructure, likely in an attempt to establish a deeper foothold. A separate investigation by CrowdStrike found no evidence of additional compromise beyond what was identified in Cloudflare’s investigation. The company expressed confidence in understanding the threat actor’s actions and limiting their impact to the observed systems.