[German]This is the "best" image that the authentication service Okta is giving off right now. The Lapsus$ gang had claimed to have hacked Okta, which possible could have threatened hundreds of customers and made them victims of attacks. But it turned out to be "much ado about little". But Okta had to admit a lapse of its own: There was a misjudgement and they informed the public about the facts far too late and reacted.
Advertising
Background: The Lapsus$ "hack"
Okta is a provider of authentication services in the cloud used by many companies. A few days ago, it became known that the provider Okta was investigating a hack on its network – but only after the Lapsus$ group went public with it and claimed an intrusion into the authentication service's systems.
At that time, screenshots had appeared in the Telegram channel of the Lapsus$ cybergang suggesting a hack of Okta. Bill Demirkapi had published some of these screenshots on Twitter (see photo above). It all looked serious, as supposedly a SuperUser access to some services was visible in the screenshots. This has since been cleared up, but the excitement was great. Especially since it is now known that an attack attempt was noticed in January 2022, but the whole thing only became public in March 2022, when Lapsus$ posted screenshots and pointed to a hack.
Okta admits a mistake
Colleagues at Bleeping Computer have picked up on it – Okta's actions must have put him under quite a bit of pressure. In the following tweet, there is a message that Okta admits a mistake in its hesitant pursuit and delayed disclosure of the alleged hack.
Advertising
The basis is probably this announcement from Okta, which sheds some light on the whole thing. On 20 January 2022, the Okta security team was made aware that a new password had been added to the Okta account of a Sitel customer service engineer. The access was probably from an unusual location and multi-factor authentication was not used on the account. They reset the account as a precaution, even though it was only an unsuccessful single attempt to access it. At the same time, the third-party provider Sitel, which assists Okta in providing customer support, was informed. The notebook from which the access was made belonged to a contractor that had just been bought out by Sitel. So outsourcing at it's best. Sitel then commissioned a forensic company to investigate the incident.
According to the timeline above, which Okta published, the investigation into the access ran from 20 January 2022 to 28 February, with the report going to Sitel on 10 March 2022. Okta received the report on 17 March, but it wasn't until 22 March 2022 that things started to move because Lapsus$ posted screenshots of the access to Okta's IT infrastructure.
It is now probably clear that the Lapsus$ screenshots were taken from the computer of a Sitel support technician to which an attacker had gained remote access via RDP. So while the attacker never gained access to the Okta service via account takeover, a computer logged into Okta was compromised and he was able to take screenshots and control the computer via the RDP session, the blog post says.
Okta makes a point of limiting a support technician's access to basic tasks when handling incoming support requests. Support technicians use a range of customer support tools to do their jobs, including Okta's Jira instances, Slack, Splunk, RingCentral and support tickets via Salesforce.
The majority of support engineering tasks are carried out using an internally developed application called SuperUser, or SU for short, which is used for basic administration functions of Okta client tenants. This application does not provide "god-like access" to all users. The tool was developed using the principle of least privilege to ensure that support technicians only have the specific access they need to perform their duties. They cannot create or delete users. They cannot download customer databases. They cannot access Okta source code repositories.
At this point, it becomes clear, if Okta's statement is true, that the Lapsus$ group's main purpose in publishing the screenshots was to generate public attention. From the forensic investigation, it appears that the attacker had a five-day window between January 16 and 21 2022 to access the Sitel laptop. Okta then analysed more than 125,000 log entries to determine that a maximum of 366 customers (approximately 2.5%) could potentially be affected because their accounts were accessed by Okta's Sitel tenant.
It seems that Okta did not inform its customers at all, because the assessment was that there was no danger. In this FAQ Okta admits to having made a mistake with regard to informing customers. They did not demand more information from Sitel, but assumed that everything had gone smoothly. And the customers were informed too late because the evaluation did not suggest this. The bottom line with regard to the Okta hack is that the Lapsus$ leaks are "more appearance than reality", but also a misjudgement on the part of Okta with regard to the handling of the information and the handling of the case.
Addendum: Okta has since announced that the Lapsus$ hackers actively controlled a contractor's laptop with access to the internal network for only 25 minutes. During that time, data from exactly two customers had been viewed. Details can be found at Engadget in this article, for example.
Similar articles:
Ubisoft hacked by Lapsus$ cyber gang (March 2022)
Cyber attacks on Nvidia and McDonalds (Feb. 25, 2022)
Samsung bestätigt Hack, Quellcodes durch Lapsus$ geleakt
Lapsus$ allegedly publishes source code of Microsoft Azure, Bing and Cortana
Authentication service OKTA hacked by Lapsus$?
Lapsus$ hacks: statements from Okta and Microsoft
Lapsus$ hacker group debunked? Teenager from Britain and Brazil suspected?
7 teenagers arrested in connection with the LAPSUS$ hacks
Lapsus$: Two UK teenagers charged in connection with hacking for this group
Advertising
