During the last week of March, three major tech companies – Microsoft, Okta, and HubSpot – reported significant data breaches. DEV-0537, also known as LAPSUS$, performed the first two. This highly sophisticated group utilizes state-of-the-art attack vectors to great success. Meanwhile, the group behind the HubSpot breach was not disclosed. This blog will review the three breaches based on publicly disclosed information and suggest best practices to minimize the risk of such attacks succeeding against your organization.
HubSpot – Employee Access
On March 21, 2022, HubSpot reported the breach which happened on March 18. Malicious actors compromised a HubSpot employee account that the employee used for customer support. This allowed malicious actors the ability to access and export contact data using the employee’s access to several HubSpot accounts.
With little information regarding this breach, defending against an attack is challenging, but a key configuration within HubSpot can help. This is the “HubSpot Employee Access” control (shown in the figure below) in HubSpot’s account setting. Customers should disable this setting at all times, unless they require specific assistance, and then immediately turn it off after completing the service call.
A similar setting appears in other SaaS applications and should be disabled there as well. Employee access is typically recorded in Audit Logs, which should be reviewed regularly.
Learn how an SSPM can help protect your organization from SaaS misconfigurations
Okta – Lack of Device Security for Privileged User
Okta subcontracts some of its customer support to the Sitel Group. On January 21, an Okta security team member received an alert that a new MFA factor was added to a Sitel Group employee account from a new location.
An investigation revealed that a Sitel support engineer’s computer was compromised using a remote desktop protocol. This known vulnerability is normally disabled except when specifically needed — which helped Okta investigators narrow the timeframe for the attack to a five-day window between Jan. 16-21, 2022.
Due to the limited access support engineers have to their system, the impact on Okta customers was minimal. Support engineers don’t have access to create or delete users or download customer databases. Their access to customer data is quite limited as well.
On March 22, DEV-0537, which is more commonly known as LAPSUS$, shared screenshots online. In response, Okta released a statement saying, “there are no corrective actions our customers need to take.” The following day the company shared details of its investigation, which included a detailed response timeline.
While this breach was limited in the damage it caused, it offers three important security lessons.
- Security from Device to SaaS – securing a SaaS environment isn’t enough when it comes to protecting against a breach. Securing the devices used by highly privileged users is of paramount importance. Organizations should review their roster of high-privilege users and ensure that their devices are secure. This can limit the damage of a breach via the attack vector that faced Okta.
- MFA – It was the addition of MFA that allowed Okta security to discover the breach. SSO does not go far enough, and organizations that take SaaS security seriously must also include MFA security measures.
- Event monitoring – The Okta breach was discovered when security personnel saw an unexpected change in the event monitoring log. Reviewing events such as changes to MFA, password reset, suspicious logins, and more, are critical for SaaS security and should be performed daily.
See Cloudflare’s investigation of the January 2022 Okta compromise for a good example of a response to such a breach.
Find out how Adaptive Shield provides endpoint posture management and SaaS configuration control
Microsoft – MFA for all privileged users
On March 22, Microsoft Security shared information relating to an attack it suffered at the hands of DEV-0537. Microsoft had a single account compromised, which resulted in source code being stolen and published.
Microsoft assured its users that the LAPSUS$ attack didn’t compromise any of their information, and further stated that there was no risk to any of their products due to the stolen code.
Microsoft did not specifically share how the breach was carried out, although it did alert readers that LAPSUS$ actively recruits employees at telecoms, major software developers, call centers, and other industries to share credentials.
The company also offered these suggestions for securing platforms against these attacks.
- Strengthen MFA implementation – MFA gaps are a key attack vector. Organizations should require MFA options, limiting SMS and email as much as possible, such as with Authenticator or FIDO tokens.
- Require healthy and trusted endpoints – Organizations should continuously assess device security. Ensure that the devices accessing SaaS platforms comply with their security policies by enforcing secure device configurations with a low vulnerability risk score.
- Leverage modern authentication options for VPNs – VPN authentication should leverage modern authentication options such as OAuth or SAML.
- Strengthen and monitor your cloud security posture – Organizations should, at minimum, set conditional access for users and session risk configurations, require MFA, and block high risk logins.
For a full list of Microsoft’s recommendations, see this note.
Final thoughts
Securing SaaS platforms is a major challenge, and as seen this week, even global enterprises need to stay on top of their security. Malicious actors continue to evolve and improve their attack methods, which forces organizations to be on the lookout and prioritize their SaaS security constantly.
Strong passwords and SSO solutions are no longer enough by themselves. Companies need advanced security measures, such as strong MFA, IP allow lists, and blocking unnecessary support engineer access. An automated solution like SaaS Security Posture Management (SSPM) can help security teams stay on top of these issues.
The importance of device security in SaaS is another takeaway from these attacks. Even a fully secured SaaS platform can be compromised when a privileged user accesses a SaaS app from a compromised device. Leverage a security solution that combines device security posture with SaaS security posture for full, end-to-end protection.
The challenge of securing SaaS solutions is complex and beyond burdensome to complete manually. SSPM solutions, like Adaptive Shield, can provide automated SaaS security posture management, with configuration control, endpoint posture management, and 3rd party application control.
Note — This article is written and contributed by Hananel Livneh, Senior Product Analyst at Adaptive Shield.