March 22nd, 2022: CyberHoot is investigating a potential breach at Okta, developers of a cloud-based identity and access management solution used by thousands of companies world-wide. Okta is currently investigating, and has released an incident summary on their website here. This blog entry states:
"The potential impact to Okta customers is limited to the access that support engineers have. These engineers are unable to create or delete users, or download customer databases. Support engineers do have access to limited data - for example, Jira tickets and lists of users - that were seen in the screenshots. Support engineers are also able to facilitate the resetting of passwords and multi-factor authentication factors for users, but are unable to obtain those passwords."
Reuters first reported that Okta was looking into reports of a possible digital breach after a hacking group known as Lapsus$ claimed responsibility for the incident and published screenshots claiming access to an Okta internal administrative account and the firm’s Slack channel.
The hacking group Lapsus$ first emerged in December, alleged to have stolen source code and other valuable data from increasingly prominent companies, including Nvidia, Microsoft, Samsung, and Ubisoft. They have backed up their claims by leaking portions of critical code in apparent extortion attempts. Early investigations by security researchers broadly reported they seemed to be using phishing to compromise their victims. Now it seems possible that some of those high-profile breaches stemmed from the group’s Okta compromise.
What do we know as of 5pm 3/22/2022:
Lapsus$ today corrected the claim by Okta that a laptop was compromised stating they had “access to a thin client rather than a laptop” and “that it found Okta storing AWS keys in Slack channels”.
What Should You Do?
With the idea that this is an evolving situation and we could learn more that requires additional action, CyberHoot is making the following early recommendations for anyone using Okta for their Identity and Access Management needs:- Investigate your Okta System Log for the following two events to see if any entry by an Actor that is not one of your own administrators has occurred. Be on the lookout for a tenant marked as “Okta System” or “system@okta.com”. Be especially diligent in looking for deactivations or password update actions.
- eventType eq “user.mfa.factor.deactivate”
- eventType eq “user.account.update_password”
- Consider revoking Okta Support access until further notice. It was a super engineer account used to disable MFA and reset a password that may have led to these other breaches mentioned above.
- Keep in contact with Okta to see if they change their recommendations on defensive measures as they emerge. Ensure you have Two-Factor Authentication (2FA/MFA) enabled for users accessing Okta authenticate services before they can go elsewhere.
- Put Access Control Lists (ACLs) limiting administrative access to Okta admin console from only your own company’s locations to prevent random internet users from connecting in. This may require careful testing and VPN access consideration for remote users.
- Ensure your network activity monitoring is enabled and pay close attention to authentication against internal systems.
- Ensure staff is alerted to this Okta breach and pay attention to suspicious activity.
- Restrict access to all your Remote Management Tools to Internal IPs alone.
- Consider removing Administrative rights to employees for their day-to-day use and instead limit admin rights for the time being.