Hackers are bloody good at what they do. Every other week there’s a new headline: “Global Affairs Canada Hit by Cyberattack”, “Cyberattack brings down Vodafone Portugal mobile”, “Tech giant Nvidia has been completely compromised”.

These headlines are designed to grab our attention. Granted, the three above are fairly tame, all things considered, but others certainly sensationalize the story, taking whatever angle is going to get the most clicks and plasters that – front and center, 36pt – where it can’t be missed. And the more terrible / shocking / horrifying the title is, the more attention it gets. Humans absolutely LOVE some drama, a ‘bit of juice’ to follow. It’s in our nature to tune in with a carton of popcorn when something goes wrong, and watch it all unfold.

Often the actual story is no way near as spectacular, dire, foreboding, world-ending as the headline leads us to believe, and the whole things blows over and is forgotten about in a matter of weeks or months.

But what does eveyone do when they hear even an inkling of a new cyber attack? They write the next sensational headline: “Hundreds of companies potentially hit by Okta hack”. Okay – I’m intrigued.

Okta Attack: Whodunit

The same hackers responsible for several of the titles listed above are also to blame for the latest big headline putting Okta in the hot seat.

Lapsus$ hacking group (or, allegedly, a bunch of teenagers led by another teenager living at his Mom’s house in London) put the Identity Access Management (IAM) company – and their customers – on high-alert when they posted screenshots that then circulated Twitter early this week (March 22nd).

They claimed to have gained ‘Superuser/Admin’ access to Okta.com, called the company out for having poor security measures in place, and stated that (before the account got suspended) they did not steal any databases from Okta; that their focus was on Okta customers only. They also emphasized, “for the 100th time” (quote, unquote) that they had been in there since January (two whole months) before being detected and having their access revoked.

To cut a long story short: Lapsus$ used RDP (WHEN will people learn?!) to gain access to the computer of a Customer Support tech in Costa Rica, who was employed by outsourcing firm, Skyes, which was owned by call-center giant, Sitel, which was contracted as a sub-processor by Okta.

In order to do their jobs, Customer Support personnel need access to customer data, which is why they are popular targets for hackers. Hackers can use them as a sneaky way in to the bigger players, which is exactly what was attempted in this attack.

A Series of Unfortunate Events

After a few days of confusion, outrage, and carefully-worded statements over dates and potential impact, the Okta CSO (David Bradbury) cleared the air once and for all with a timeline of when and how it all went down:

• January 20, 2022, 23:18 – Okta Security received an alert that a new factor was added to a Sitel employee’s Okta account from a new location. The target did not accept an MFA challenge, preventing access to the Okta account.
• January 20, 2022, at 23:46 – Okta Security investigated the alert and escalated it to a security incident.
• January 21, 2022, at 00:18 – The Okta Service Desk was added to the incident to assist with containing the user’s account.
• January 21, 2022, at 00:28 – The Okta Service Desk terminated the user’s Okta sessions and suspended the account until the root cause of suspicious activity could be identified and remediated.
• January 21, 2022, at 18:00 – Okta Security shared indicators of compromise with Sitel. Sitel informed us that they retained outside support from a leading forensic firm.
• January 21, 2022, to March 10, 2022 – The forensic firm’s investigation and analysis of the incident was conducted until February 28, 2022, with its report to Sitel dated March 10, 2022.
• March 17, 2022 – Okta received a summary report about the incident from Sitel
• March 22, 2022, at 03:30 – Screenshots shared online by LAPSUS$
• March 22, 2022, at 05:00 – Okta Security determined that the screenshots were related to the January incident at Sitel
• March 22, 2022, at 12:27 – Okta received the complete investigation report from Sitel

To sum it up, the screenshots were from an attack that occurred in late January, was investigated over the course of about six weeks, within which time, the hackers posted their expose online and made Okta look… the opposite of transparent. Opaque, that’s the word I’m looking for.

Also in his statement, Bradbury expressed embarrassment over the event, apologized about the delay in taking action after receiving the initial report from Sitel, and pointed out a particularly noteworthy (and reassuring) factor:

At Okta, policies and security protocols in place limit the access provided to Support Engineers to “basic duties in handling inbound support queries”, with the majority of support tasks performed via an “internally-built application called SuperUser (SU) … an application built with least privilege in mind to ensure that support engineers are granted only the specific access they require to perform their roles. They are unable to create or delete users. They cannot download customer databases. They cannot access our source code repositories… Because of the access that the support engineers had, the information and the actions were constrained.”

A Sliver of a Silver Lining

What Bradbury is saying is that once the hackers got in, there wasn’t a whole lot they could do – a claim that was more or less validated in the fact that a mere 366 customers were potentially impacted in the attack, but not to the extent that they had to take any restorative action. And that, dear reader, is the power of the Principle of Least Privilege (POLP).

Where it really mattered, Okta’s implementation of the Principle of Least Privilege worked: the victim engineer had only enough privileges required to do his / her job, and these privileges simply weren’t enough to give Lapsus$ the foothold needed to cause widespread damage.

Maybe I’m too much of an optimist, but I feel there’s at least some positivity to be seen here. Yes, an attacker got in. No, they weren’t able to do any real damage. At this stage, I feel like a more appropriate headline would be: “Privileged Access Management controls prevent hackers from launching widescale attack” (what a breath of fresh air!)

The Point

The point is, Privileged Access Management (PAM) is an absolute must. It’s a safety net to catch anything (or anyone) malicious that slips through the other security layers, as in the Okta case.

Admin By Request’s Privileged Access Management solution exists to act as that safety net, with minimal input or management required from you. Install the client, and the Principle of Least Privilege is immediately enforced on every user, along with the ability for Just-In-Time, fully audited elevation – so that employees can continue to do their jobs, safely.

Where third-party contractors are concerned, they can get protected too – Admin By Request offers a completely free, life time plan for smaller organizations.

Conclusion

This latest story acts as proof that appropriate use and enforcement of least-privilege principles can be the saving grace in the event of a cyber attack, and they should be implemented in every enterprise with a comprehensive PAM solution such as Admin By Request.

Yes, hackers are good at what they do. But they’re often not quite good enough to circumvent advanced cybersecurity software built on POLP.

Better luck next time, hackers.