The ease of onboarding SaaS applications is creating a false sense of security. SaaS applications are introducing new areas of attack, and security teams must remain vigilant to ensure the security of their data
Recently, Adaptive Shield security researchers discovered a new attack vector caused by a vulnerability within Microsoft’s OAuth application registration. Through this vulnerability, an attacker can leverage Exchange’s legacy API to create hidden forwarding rules in M365 mailboxes.
To understand this new attack vector, we need to understand its key components, which include hidden forwarding rules and SaaS-to-SaaS app access. When these two elements are combined, the threat actor has created what amounts to a malicious SaaS rootkit.
Leveraging OAuth 2.0
SaaS-to-SaaS access describes the conditions where a third-party app integrates with the primary app to extend the functionality of the primary app. The OAuth 2.0 mechanism simplifies the process of authentication and authorization. Users verify the identity of the third-party app, and with a few clicks, grant requested permissions to the app. The app is then able to execute code behind the scenes.
Hidden Forwarding Rules
Forwarding rules describe actions that occur based on preset conditions within a Microsoft mailbox. Users or admins can use forwarding rules to trigger protocols based on different attributes of the user's inbox. Hidden forwarding rules are fully functional and can be seen on the back end but are not visible in common interfaces such as email clients, the admin dashboard, or an API.
While third-party app integrations are normally safe and improve the productivity of the primary app, these apps can act as malware. The SaaS Rootkit allows attackers to essentially create malware that lives as a SaaS app and maintains access to the victim’s account while going unnoticed. An attack through these hidden forwarding rules should not be mistaken for a one-off but rather the start of a new attack method through SaaS apps.
Evolving SaaS Attack Methods
When it comes to a SaaS Rootkit, an attacker's job is simple – create a credible-looking app that can entice a user to accept and grant permissions. The attacker creates an app and sends an offer to users to connect to the app. The user will see an OAuth app dialog box on the official Microsoft site (as seen in Figure 1) and will likely accept it as they normally would. Unfortunately, in this scenario, they are giving the bad actor the token for the specific permissions access. After a user accepts and grants permission, the attacker can use it to create forwarding rules and hide them from the user interface like a rootkit.Mitigating SaaS Rootkit Attacks
Traditional controls that were created to stop malware attacks are struggling to keep up with the evolution of new attack vectors that exploit SaaS apps. While there is no bulletproof way to eliminate SaaS Rootkit attacks, organizations can strengthen native security configurations to control OAuth application integration and monitor the activity of their users. This includes monitoring SaaS-to-SaaS access, tracking activities, and disabling or monitoring SaaS-to-SaaS app registrations.
Rogue OAuth apps are equivalent to malware and operate no differently than sending a malicious executable file. This type of attack cannot be detected by EDR (endpoint detection and response) tools and shouldn’t be mistaken for a one-off. This is the start of a new attack method through SaaS apps.
