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. A HubSpot account used by an employee for customer service was compromised by malicious actors. 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. The “HubSpot employee access” control is located in HubSpot’s account settings. It can be seen in the image below. 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 may also be found in SaaS apps and should therefore be disallowed. 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 found that Sitel’s support engineer was attacked using remote desktop protocols. 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. The support engineers are not able to delete or create users, or access customer databases. They also have very limited access to customer data.
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.
Although the breach caused little damage, there are three key security lessons.
- Security from Device to SaaS – securing a SaaS environment isn’t enough when it comes to protecting against a breach. It is crucial to secure devices that are used by high-privilege users. 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. Security of SaaS is dependent on daily review of events, such as password resets and changes to MFA.
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 didn’t share the details of how the breach occurred, but it did inform readers that LAPSUS$ is actively recruiting employees in telecoms and major software developers to help them 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 platform is a significant challenge. As we have seen, global corporations need to be vigilant about 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. Advanced security measures are required by companies, including strong MFA and IP allow lists as well as blocking access to support engineers. Security teams can be assisted by an automated solution such as SaaS Security Posture Management.
The importance of device security in SaaS is another takeaway from these attacks. A compromised device can allow a user to access a SaaS application from an already compromised device, compromising even the most secure SaaS platform. For full protection, combine device security with SaaS security for end-to-end security.
The challenge of protecting SaaS solutions can be complex and time-consuming. 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.
