The 58th Edition of the Identity Jedi Newsletter

What happened?

On October 20th, Okta released a public notice that

 “Okta Security has identified adversarial activity that leveraged access to a stolen credential to access Okta's support case management system.” 

A direct quote taken from the blog they posted here,

Using this access the adversary was able to view files uploaded by Okta customers. Specifically HTTP Archive Files ( HAR ). Using these files the adversaries were able to access sensitive data which they could use to access customer environments.

One of the customers was BeyondTrust. Using a combination of their products, and processes they were able to detect and stop a potential breach of their systems. That is what we are going to dive into.

Anatomy of a breach

Last week I talked about People, Process, and Technology and how when implementing IAM you need all three of those to come together to have a successful deployment. Well you also need those things to defend against attacks as well. In this case it seems as if BeyondTrust had all three.

Disclaimer: Going forward, I’m making some assumptions based on what information is available. I’ll source all the places where I get my information from.

Ok so let’s start with what we have:

Comprised customer management system with access to sensitive data. Specifically HAR files. ( Here’s some background on those.)

In a nutshell, HAR files represent an archive of web traffic between a browser and a server. In that traffic, you can see request responses and the information that was sent over. Specifically cookies.

In this particular case, session cookies.

Why are these important? Well remember HTTP is a stateless protocol. Said differently every time you make a HTTP request, everything is contained within that transaction of the request. Nothing is saved. It’s like talking to someone who only has a 10-second memory.

So in order to get around that we creates sessions, and specifically session cookies. Using this you can always pick up where you left off in the HTTP conversation. TL;DR: Get the session cookie, and you can impersonate a session.

Where do you find session cookies? In HAR files of course.

So an adversary gains access to Okta’s customer support system ( Which we don’t have any details on how that happened), and the are able to view HAR files submitted by Okta customers. These files are submitted in order for Okta support staff to help troubleshoot issues.

In this case one of those customers was BeyondTrust and said adversary attempted to use a session cookie in order to impersonate an Okta administrator in the BeyondTrust tenant.

Shout out to the BeyondTrust team for realizing a detailed review of the attack. You can check it out here.

Let’s break down the steps.

But first, a word from our sponsors. Just kidding. Just breaking this into separate sections, to give your eyes a break. It’s a Deep Dive, with a lot of text to read.

Breaking down the attack and response

Ok, let’s dive in to attempt to get into BeyondTrust’s ( BT) environment. I’m going to take bullets from the BT’s blog and break them down.

Here we go:

• Within 30 minutes of the support file upload there was an attempt to access the BeyondTrust Okta admin console as the BeyondTrust Okta administrator using an IP address in Malaysia linked to anonymizing proxy/VPN services.

• Okta events are logged from this Malaysian IP however there were no prior authentication events or activity from this user in this location as we would normally expect.

• Attacker was authenticated but access to the Okta console was denied due to a non-default Okta security policy configuration enforced by BeyondTrust security teams:

  • Default deny access and only allow access if specific criteria is met.

  • Attacker denied console access due to policy requirement of requiring Okta Verify on a managed device

So BT notices an attempt for an admin login to Okta from an IP address linked to Malaysia, with no prior authentication events or activity. It’s not clear here whether or not this was detected in real-time or correlated after the fact during the incident investigation. But the key to this first deflection is the next part.

The attacker was authenticated BUT denied access to the Okta console due to a security policy configured by the BT security team.

So hear we have an example of a couple of things.

• Conditional Access - Just because you are who you say you are, doesn’t mean you can do what you want. In this case the BT setup an additional policy around privileged accounts that required more conditions than just authentication. In this case the device trying to access must have Okta Verify.

• Policy and Process - The policy around this needed to be set and the process selected for how to implement this. Now we don’t know the gory details of how BT when about setting this up, but we could guess that they had discussions around protecting their privileged accounts ( I mean they are a PAM company) and what the process should look like

Let’s keep moving..

• Attacker attempts to gain access to main Okta dashboard but receives a policy challenge

  • Note: It is important for Okta customers to enhance security policies through settings such as prompting admin users for MFA at every sign in. While this was within an existing session the attacker hijacked, Okta still views dashboard access as a new sign in, and prompts for MFA.

So the attacker pivots and try’s another angle of access. Once again we see a display of conditional access. When the attacker attempts to get to the dashboard they can’t get in because it prompts for MFA. EVEN though it has an existing authenticated session.

Ok, now it starts to get really good…

Like any good attacker, this adversary doesn’t just make one attempt. They keep probing until they find something. In this case it was API access. ( Fun fact: API traffic now makes up 80% of web traffic. We should probably start talking about that in identity….but I digress)

• Attacker uses Okta official API to create a fake service account named “svc_network_backup” in an attempt to make it look like existing service accounts.

  • Note: Session cookies can be used to authenticate to official Okta API and in many cases these lack the policy restrictions that apply to the interactive admin console.

APIs are like the back alleys of big cities. Nobody wants to go down them, but they connect everywhere and all sorts of shady shit goes down because no one is really paying attention. And yet they are everywhere. The first thing that jumps out to me here is the fact that policy enforcement is different between the dashboard, and the API. If you’re going to have API’s that mimic an interactive interface, then you have to protect them like the interactive interface.

But like those nails in the 80’s we press-on.

• Attacker acted quickly but our detections and responses were immediate, disabling the account and mitigating any potential exposure.

• BeyondTrust initiated an incident response process, immediately isolating and forensically investigating all systems and accounts associated with the administrator.

We don’t have a ton of details here, but I would assume that BT had some kind of alerting setup around the creation of new accounts. Specifically admin accounts in this case. Which triggered their action to create a response. It would be interesting to know how BT was setup organizationally for this. Did the identity team get the alerts and then reach out to the security team? Was it the security team that saw these alerts? However it was setup, cleary they have good communication processes in place that allow them to react quickly to situations such as this.

All of this happened in one day. ( According to the timeline that BT posted). A good example of people, process and technology coming together to respond to an issue.

IAM Resilience

A word from our friends at Acsence

Become a paying subscriber of Identity Jedi Newsletter to get access to this post and other subscriber-only content.

Already a paying subscriber? Sign In