OAuth attacks are on the rise. In December, the Microsoft Threat Intelligence team observed threat actors misusing OAuth apps to take over a cloud server and mine cryptocurrency, establish persistence following business email compromise and launch spam activity using the target organization’s resources and domain name.
What is OAuth?
A widely adopted standard that facilitates secure and delegated access to resources on the internet, OAuth (Open Authorization) is designed to address the challenges of user authentication and authorization for third-party applications. OAuth allows users to grant another application limited access to their resources – such as personal data, online accounts, and other sensitive items in SaaS environments – without sharing their credentials.
OAuth is crucial in enabling seamless and secure connections between SaaS applications. When users attempt to connect a third-party SaaS application to their account (e.g., linking a productivity tool to a cloud storage service), OAuth is the intermediary authentication mechanism. The user is redirected to the SaaS provider’s authentication server, where they log in and grant permission for the third-party application to access specific data. The third-party app then receives an access token, which it can use to interact with the user’s data within the defined scope while maintaining its security and privacy. This decentralized and token-based approach enhances security and user control in the interconnected landscape of SaaS applications.
OAuth integrations are used to improve workflows, add functionality and improve the usability of the original application. However, when deployed by threat actors, they are very dangerous and difficult to detect. As recently observed by Microsoft and noted by Adaptive Shield researchers earlier this year, threat actors can create an app that looks credible on the surface but contains an unnecessary and high-risk request for permissions. Once users connect it to their application, that app has free reign to do anything within its permission set.
Three domains must be secured within the SaaS stack to successfully prevent OAuth attacks.
Securing SaaS against OAuth attacks
OAuth attacks highlight the importance of implementing strong access controls, securing user accounts and monitoring for unusual or suspicious activities.
1. Implement strong access controls
SaaS security begins with access control. This limits who and what can create user accounts.
At their core, OAuth integrations are cloud apps that can access data on behalf of a user, with a defined permission set. When a Microsoft 365 user installs a MailMerge app to their Word, for example, they have essentially created a service principal for the app and granted it an extensive permission set with read/write access, the ability to save and delete files, as well as the ability to access multiple documents to facilitate the mail merge.
The organization needs to implement an application control process for OAuth apps and determine if the application, like in the example above, is approved or not. We often see threat actors that abuse this method and introduce a malicious application whose handlers could use the permissions granted to go into Microsoft 365, Google Workspace, Salesforce, Slack and many more, download data and files and use SaaS malware to maintain persistence.
There are several access controls that can be implemented to prevent unauthorized OAuth integrations. While not every app has all these options, most apps should have at least one of these configurations to prevent OAuth attacks.
- Create an Allowlist and approval process apps that are allowed or banned from connecting to applications
- Prevent integration without approval for any third-party app requesting high-risk scopes
- Maintain and review logs of OAuth integrations
- Where possible, require admin approval for any third-party integration
2. Fortify identity security for user accounts
Identity is the perimeter, and SaaS users that are left unsecured can be exploited by threat actors in several ways. Following a successful phishing or password spray attack, threat actors can easily access an application with the same permission set as their victim.
Once inside, they can quickly connect their malicious application to the hub application and grant it high privileges. Even if they lose access to the hub app, their malicious application will still be connected with its original permission set.
Storm-0324, a malicious threat actor group, exploited Microsoft Teams in this manner. Taking advantage of lax security settings with Teams, the threat actor group was then able send a Teams message as an external user, impersonate employees as they conducted phishing attacks, launch malware and modify the content of sent messages without leaving a trace.
Security teams should view user security through two separate lenses. The first is the way they access the applications. Apps should be configured to require multi-factor authentication (MFA) and single sign-on (SSO). Password policies should follow the recommendations of leading standards, and local access to applications should be disabled for all users.
Second, security teams need to reduce the SaaS attack surface by hardening global and user configurations – in the example above, organizations could have prevented external users from sending a message.
The third lens follows the user once they are within the application. Monitoring user activity for anomalies in behavior and actions can help raise flags if the account has been taken over by a threat actor or if the user is acting against the best interests of the company and poses a threat. This lens, referred to as identity threat detection and response (ITDR), is essential in detecting threats before they cause damage.
Securing user accounts – both in terms of the way users access the application and their behavior within the app – is a key piece in preventing OAuth attacks from gaining purchase within the app.
3. Monitor third-party app activity
Security teams must monitor and govern all third-party applications that are connected to the SaaS stack and have full visibility into the scopes requested during the OAuth integration. They should verify OAuth clients through their client ID and secrets to ensure that only registered and authenticated clients are granted access. Apps that are dormant should be disconnected, as should apps that were installed by a user who has been deprovisioned.
In addition, security teams should review app activity. Automated tools should scan the logs and report whenever an OAuth-integrated application is acting suspiciously. For example, applications that display unusual access patterns or geographical abnormalities should be regarded as suspicious. Sudden increases in API calls, access data from a new location, frequent requests for new access tokens and repeated changes in app permissions are also signs indicating a malicious application.
Security teams should regularly review their logs to see if their OAuth applications are behaving as expected and remove those applications that are suspicious or dormant.
Threat actors want your SaaS
SaaS applications contain nearly 70% of all corporate data. They are a very tempting target for threat actors looking to monetize their attacks. OAuth applications are easily overlooked by security teams and are granted the access required by cybercriminals to carry out their attacks.
For true OAuth security, organizations must regularly audit and review OAuth permissions and educate their users on the dangers of phishing attacks coming from the applications themselves. Automating OAuth monitoring is also crucial for a healthy SaaS ecosystem.