The phenomenal growth in the adoption of software as a service (SaaS) has prompted enterprises of all sizes to move their critical data to SaaS-based applications. And as attackers tend to follow data to induce a breach, their new area of focus is enterprise SaaS. The recent Midnight Blizzard attack by nation-state actors clearly reinforces the fact that this trend has only just begun.
One interesting aspect of this attack, as well as other recent attacks on SaaS, is that the attackers leveraged a combination of traditional attack vectors, like poor posture controls around authentication and new attack vectors, likeOAuth based applications. It’s worth mentioning that this attack vector has also recently been leveraged by opportunistic threat actors to automate both business email compromise (BEC) attacks and phishing attacks, as well as push spam and deploy virtual machines (VMs) for crypto mining. This underscores the fact that attacks on SaaS apps are not exclusive to state-sponsored groups only.
The anatomy of an OAuth attack on SaaS apps
Let’s drill into some of the tactics that attackers seem to have used in this attack:
- Initial Access via password spraying on test tenant accounts.
- Defense Evasion by using distributed residential proxies in addition to limiting the number of attempts to stay under the radar of systems that keep an eye on the volume of such defense evasion attempts.
- Persistence by granting access to OAuth applications to maintain access, even if they were to lose access to the account used during initial access.
- Privilege Escalation using the OAuth application to grant elevated access to the Microsoft corporate environment.
- Lateral Movement via the OAuth application’s elevated access towards Exchange Online.
While the tactics remain very similar to a classic MITRE framework, the techniques used to perpetrate the attack have evolved enough to exploit the new attack surface left open by OAuth applications.
OAuth applications are the new blindspot
For an end user who is looking to get things done in the most easy and effective way, OAuth applications are a huge blessing because they allow users to interconnect or integrate their apps and data very easily from within the SaaS application they are using, by simply issuing a few commands. Let’s say for example, you are working away in Slack and want to connect to your Google Drive to obtain specific data. The OAuth app for Slack will allow you to approve access to your Google Drive, via an OAuth token and by using your credentials to collect that specific data of your interest.
You no longer have to login to Google Drive and be prompted for multi-factor authentication (MFA) when you can easily obtain the data from it directly from within your Slack messaging app.
Similar to the Slack and Google Drive example discussed above, OAuth apps also enable you to connect your calendar, HRMS accounts, DevOps platform, payroll account, and other accounts to various other SaaS apps.
However, with beauty comes danger and with ease, risks.
The easy onboarding of OAuth apps without security checks is one such risk. These apps can be provisioned by any end user with just one click. Now with the thousands of OAuth apps available from public marketplaces, you can only imagine how the ease of provisioning exponentially compounds risk, unless SaaS admins set up stricter controls.
Another risk comes from users easily building custom/internal OAuth apps using the low/no code frameworks that most SaaS applications offer. These frameworks provide a mechanism for code execution and persistence by bad actors, if accounts are compromised similar to what was seen in the Midnight Blizzard attack. Since most organizations do not have any vetting or review processes around internal OAuth applications, risks get further aggravated. Let’s also factor in the lack of visibility and control over user transactions, and subsequently, exfiltration of data, beyond the perimeters you control.
There are a few additional risks that must be tracked when using OAuth tokens on applications protected by multi-factor authentication (MFA). The first one arises because as temporary tokens, OAuth tokens are designed for use post authentication, and therefore don’t require re-authentication, allowing bad actors to bypass MFA once they gain initial access. The other risk with OAuth tokens is that although they are based on a temporary token design, they often can be refreshed indefinitely in most implementations, which gives bad actors persistence access.
And lastly, a major risk factor is the lack of expertise on the SaaS admin team in dealing with security issues arising from the use of OAuth apps. Most SaaS admins are not aware of the risks from OAuth apps or have no easy way to vet the app before approving one.
How to defend against OAuth app-based attacks
In order to help you pre-empt these types of attacks it’s very important to educate and partner with your SaaS application administrators, closely monitor your SaaS applications posture, risk profile OAuth apps in real time, and cut off all the insecure and unnecessary doors and windows that exist in Microsoft applications.
Here are the core system hardening techniques that are enforced by a good SaaS Security Posture Management (SSPM) solution that can help you protect your Microsoft SaaS applications.
Let’s look at the techniques in detail:
- Initial Access:
- Ensure you are notified when MFA and configuration alerts are turned off.
- Block legacy authentication.
- Ensure passwords are enforced on mobile devices.
- Enforce password complexity, rotation, and expiration.
- Defense Evasion:
- Make sure Microsoft 365 audit logs are enabled and monitored to help Office 365 teams investigate activities for anomalies and for routine security operations or forensic purposes.
- Ensure Microsoft Defender for Cloud Apps provides log collectors that automatically collect and upload the logs and then perform anomaly detection on collected log data.
- Enable the Advanced Threat Protection Safe Attachments policy such that it extends malware protections such as routing all messages and attachments without a known malware signature to a special hypervisor environment. In that environment, a behavior analysis is performed using a variety of machine learning and analysis techniques to detect malicious intent.
- Restrict content sync across your Microsoft apps and whitelist your domain’s globally unique identifier (GUID) to ensure that only domain-joined and approved machines can sync data across Microsoft applications and devices to lower the risk of data leaks.
- Enable Advanced Threat Protection (ATP) for SharePoint, OneDrive, and Microsoft Teams to protect against inadvertent sharing of malicious files. When an infected file is detected, that file is blocked so that no one can open, copy, move, or share it until further actions are taken by the organization’s security team.
- Ensure all devices are configured to meet well thought out device compliance policies.
- Persistence:
- Ensure that users cannot install Microsoft Outlook add-ins because attackers commonly use vulnerable and custom-built add-ins to access data in user applications. While enabling users to self install add-ins does allow them to easily acquire useful supplemental features that integrate with Microsoft applications, this user action can create risks for you, if not monitored carefully. By disabling a user’s ability to install add-ins in Microsoft Outlook, you reduce the threat surface and mitigate risk.
- Ensure that all installed OAuth apps have a Netskope calculated real-time risk score that falls below the level of ”High” severity.
- Ensure OAuth apps are not over privileged to allow impersonation of any user.
- Restrict the creation or registration of new applications by disallowing the permission to do so for all the users within the tenant.
- Educate the SaaS application administrators about the risks of OAuth applications and provide them an easy to reference database for such applications.
- Privilege Escalation:
- To reduce the risk of malicious applications tricking users into granting them access to your organization’s data, it’s recommended that you allow user consent only for applications that have been published by a verified publisher or let the administrator grant the permissions.
- Disallow users from providing consent to applications.
- Disable the ability to modify app role assignments in OAuth apps to ensure that the application does not give users or SaaS apps access to resources they should not have access to.
- Limited administrators are users who have more privileges than standard users, but not as many privileges as global admins. Leveraging limited administrator roles to perform required administrative work reduces the number of high value, high impact global admin role holders you have. Assigning users roles like Password Administrator or Exchange Online Administrator, instead of Global Administrator, reduces the likelihood of a global administrative privileged account being breached.
- Disable custom script execution to prevent content from being uploaded to SharePoint for potential malicious code execution, which may lead to a wide array of security issues.
- Lateral Movement & Data Exfiltration:
- Ensure basic authentication for Exchange Online is disabled while modern authentication for Exchange Online is enabled.
- Block client-side rules that automatically forward email to external domains. The use of client-side forwarding rules to exfiltrate data to external recipients is an increasingly used vector for data exfiltration by bad actors.
- Ensure a DomainKeys Identified Mail (DKIM) signing policy exists.
- Ensure hosted outbound spam and malware filter policies along with strong authentication, web mailbox and anti-phishing policies are in place.
- Ensure that Domain-based Message Authentication, Reporting, and Conformance (DMARC) Records for all Exchange Online domains are published as it works with Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to authenticate mail senders and ensure that destination email systems trust messages sent from your domain.
- Ensure audit logging for non-owner mailbox access is enabled to help track login to a mailbox as well as actions taken while the user is logged.
As security is a process rather than a state, a properly hardened system should also be accompanied by mature monitoring, incident handling, and privilege approval process. For this, you need real-time visibility into your user, the Oauth application, and permission management inventories to receive alerts on notable changes.
SSPM is a fundamental security control designed to monitor compliance with industry regulations and minimize cloud-based risks. It dramatically reduces the attack surface across multiple SaaS applications and provides invaluable risk context for a complete cloud-based zero trust strategy.
All of the above defenses and more are part of the Netskope SSPM solution. Also note that similar defenses needed for other vendor’s SaaS applications are also enabled by Netskope SSPM. These defenses can be easily found and applied in the form of out-of-box detection rules in Netskope SSPM as categorized under the different tactics of MITRE ATT&CK & the sub-domain titled “Third-Party Apps”.