I am trying to learn and understand the attack. Can someone please help me brainstorm some possibilities? (please note, I do not intend to question Cloudflare's business practices or security program; my intention is to learn and understand).
--
Blog: The threat actor (TA) accessed Okta’s customer support system and viewed files uploaded by Cloudflare (CF) as support cases.
Why was the session token part of the support files uploaded to Okta support? Does Okta require it for troubleshooting?
TA hijacked a session token of a CF employee from a support ticket.
Blog: Using the token extracted from Okta, the TA accessed Cloudflare’s Okta and compromised two separate Cloudflare employee accounts within the Okta platform.
How did this happen? Was the stolen token privileged? Also, why only 2 employee accounts? Were these different employees, or was one the same one whose token was compromised? What does Okta employee account compromise mean - did TA reset the password and MFA, and how or was there no MFA?
Blog: TA used stolen credentials to get access to our Atlassian server and accessed some documentation and a limited amount of source code.
Did the stolen employee credentials only have access to Atlassian?
Blog: TA gained access to a set of credentials
Does this mean multiple credentials got uploaded to the Okta support system?
Blog: The Okta compromise was in October, but the threat actor only began targeting CF systems using stolen credentials from the Okta compromise in mid-November.
Does this mean the compromised token was long-lived?
Blog: We failed to rotate one service token and three service accounts (out of thousands) of credentials that were leaked during the Okta compromise.
I didn’t get this. Does this mean that over time, CF employees had uploaded support info for 1000s of apps managed by Okta? Which credentials did CF rotate initially after the Okta compromise?
Leaked Credentials:
1. Moveworks service token that granted remote access into our Atlassian system.
Is this service token a bearer token? And without expiry. Is this like an API key?
TA accessed Atlassian Jira and Confluence using the Moveworks service token to authenticate through the gateway.
2. A service account used by the SaaS-based Smartsheet application that had administrative access to our Atlassian Jira instance,
So here, the Smartsheet Saas was given access to the on-prem Atlassian Jira instance? What kind of trust is it? Is this as well managed through Okta? And how does support case filing include a service account? Here, does the Service account mean again some kind of hardcoded API key without expiry
TA used the Smartsheet service account to gain access to the Atlassian suite. They used Smartsheet credentials to create an Atlassian account that looked like a normal Cloudflare user. They added this user to a number of groups within Atlassian so that they’d have persistent access to the Atlassian environment.
Since the Smartsheet service account had administrative access to Atlassian Jira, the TA was able to install the Sliver Adversary Emulation Framework, which is a widely used tool and framework that red teams and attackers use to enable “C2” (command and control), connectivity gaining persistent and stealthy access to a computer on which it is installed. Sliver was installed using the ScriptRunner for the Jira plugin.
This allowed them continuous access to the Atlassian server, and they used this to attempt lateral movement. With this access, the Threat Actor attempted to gain access to a non-production console server in our São Paulo, Brazil data center due to a non-enforced ACL. The access was denied, and they could not access any global networks.
3. A Bitbucket service account, which was used to access our source code management system
4. AWS environment that had no access to the global network and no customer or sensitive data.
Were these AWS access keys? Also, it looks like these keys did provide access to the AWS account. That means the access key didn’t require MFA.
The only production system the TA could access using the stolen credentials was our Atlassian environment.
Mitigations:
Blog: We decided a huge effort was needed to further harden our security protocols to prevent the threat actor from being able to get that foothold had we overlooked something from our log files.
What does hardening security protocol mean here? Is it techniques for D&R or something else
Blog: We undertook a comprehensive effort to rotate every production credential (more than 5,000 individual credentials)
I believe this means forced resets on employees (Okta users), right?