SaaS RootKit: Attack to Create Hidden Rules in Office 365
Bad actors are always on the search for new methods of attack, making it our job to always stay two steps ahead of them. Keeping organizations secure doesn’t stop at hardening security settings. It also means staying on top of changing or emerging weak points that can be exploited.
Adaptive Shield security researchers have discovered a new attack vector due to a vulnerability within Microsoft’s OAuth application registration. Through this vulnerability, an attack can use Exchange’s legacy API to create hidden forwarding rules in Microsoft 365 mailboxes. This blog will take a look at how these hidden forwarding rules are created and the threat they pose.
SaaS-to-SaaS Access Through OAuth 2.0
For companies to protect themselves from this new attack vector, there must first be a foundational understanding of third-party app access. Third-party apps connect to other apps by gaining access and permission to different information and settings. These apps are incredibly valuable to businesses. When connecting a third-party app, the app requests one or more scopes. To enable these privileges, a user must first verify their identity and then grant permissions that allow the app to execute code to perform logic within their environment but still behind the scenes.
Figure 1. Connecting third-party apps
The OAuth 2.0 mechanism simplifies the process of authentication and authorizations to offer a fine-grained delegation of access rights. OAuth doesn’t share password data, but instead uses authorization tokens to prove an identity between consumers and service providers to provide an authorization flow for apps. Represented in the form of scopes, an application asks for the user’s authorization for specific permissions. Third-party apps can be completely harmless and a valuable tool to business, but they can also be an executable file and a big threat.
Learn more about the top use cases to secure your entire SaaS stack.
Inbox Rules
So what are inbox rules in Microsoft 365? Simply put, they are actions that occur based on preset conditions within a Microsoft mailbox. For example: auto-marking the importance level of incoming messages, automatically deleting outgoing emails, automatically forwarding incoming emails and so on. Forwarding rules can be set up by a company that wants emails forwarded for a specific user’s mailbox. To configure this setting, admins typically use ForwardingSMTPAddress or ForwardingAddress. Alternatively, users can set them up themselves using Mail-Flow Rules or Inbox Rules, which trigger different forwarding rules based on different attributes of the user’s inbox.
Below is an example of how users can create an inbox rule.
Figure 2. Creating forwarding rules in Microsoft
Figure 3. Creating forwarding rules in Microsoft
Hidden Forwarding Rules
Compass Security’s Damian Pflammater first discovered an undocumented method that can be used to hide these types of inbox rules. As seen in figure 3, these hidden forwarding rules are fully functional and can be seen on the backend. However, when a user searches for them through common interfaces such as email clients, admin dashboard or API, the rules are not visible (Figure 4).
Figure 4. Back-end of hidden forwarding rules
Figure 5. Hidden forwarding rules
Pflammater reported his discovery to Microsoft and received the following response.
“[…] Our engineering team investigated the behavior that you described. They determined that it is not considered a security issue because it requires control of the account to create these rules. However, they are considering ways to improve the software in the future.”
“[…] MSRC will not be tracking the issue and we won’t have future updates about it […]”
In other words, Microsoft said, “It’s not a bug, it’s a feature.”
The Next Evolution: An Attack Method Through SaaS
After reading about Pflammater’s discovery and Microsoft’s response, our researchers were intrigued enough to explore this behavior more. Third-party app access combined with hidden forwarding rules creates a sort of SaaS rootkit. A rootkit is a collection of computer software, typically malicious, designed to enable access to a computer or an area of its software that is not otherwise allowed and often masks its existence or the existence of other software. Rootkit detection is difficult, because a rootkit may be able to subvert the software that is intended to find it. An attacker’s hidden forwarding rules in Microsoft 365 act as a SaaS rootkit.
The SaaS rootkit allows attacks to create malware that lives as a software-as-a-service app and maintain 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.
Figure 6. Fake app permissions request
The attacker’s job is simple: Create an app that looks credible to entice a user to accept and gain permissions. While a bad actor can’t find online permissions/scopes in the user interface (UI), they are able to add them through a terminal script. An attack creates an app, then sends an offer to users to connect to the app. 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. The user will see an OAuth app dialog box on the official Microsoft site and will likely accept it as they normally would. When a user accepts, they are giving the bad actor the token for the specific permissions access.
Figure 7. Terminal script of hidden rule
Now that the attacker has permissions, they can create the hidden forwarding rules. 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 endpoint detection and response tools.
Microsoft Response
After contacting Microsoft to bring the issue to their attention, we received the following response:
“We have gone over the report in detail, including all of your additional files. Unfortunately, it was determined that while the issue you reported is valid, it does not meet our bar for immediate servicing. In this case, we do think this can be improved upon, but due to the high requirements on the attacker, with the issue being post exploitation of an administrator, this would not be tracked by the security team for servicing.
That being said, this submission has been flagged for future review by the product team as an opportunity to improve the security of the affected product.”
How to Best Mitigate a SaaS Rootkit Attack
There’s no one bulletproof way to eliminate SaaS rootkit attacks, but there are a few best practices that can help keep organizations more protected.
- Monitor third-party app access and their permissions to ensure that apps are legitimate and given only the access they require.
- Track activities and be on the lookout for new inbox rules to identify any new connections from untrusted domains.
- Disable third-party app registrations where possible to reduce risk.
Conclusion
Hidden forwarding rules are still a threat, even more so when they appear through the trusted Microsoft website. The traditional controls that were created to stop malware have struggled to keep up with the evolution of malware and the new attack vector that can exploit any SaaS app, from Microsoft 365 to Salesforce to Google Workspace, etc. Organizations should use native security configurations to control the OAuth application installations across SaaS apps to protect users from malicious attacks like these.
Get Forrester’s Report “Embrace A Paradigm Shift In SaaS Protection: SaaS Security Posture Management”.
