SaaS vendors are continuously improving their native security controls, with the intention of preventing misconfigurations that can lead to dangerous consequences. In practicality, this means that if a SaaS provider has reason to believe a user’s mailbox has been hacked, the user will receive an alert directly to their inbox notifying them of the suspicious activity.
While this approach works well when there’s a user associated with said mailbox, what happens if a mailbox doesn't have an owner? Or what if the user attached to this mailbox has no license? In such cases, no one ever gets those alerts.
At first glance, this might not seem like a problem; if there’s no owner and no licence, then there’s no actual risk, right? Unfortunately, this isn't the case. In every enterprise, there are hundreds of mailboxes that fit these exact criteria. Yet these same mailboxes often contain valuable information, such as financial data, intellectual property, business information, security events, and more.
What are Shared Mailboxes?
There are various reasons an email account may not be associated with one particular user. One common example is that of shared mailboxes, often used in organizations to provide multiple users with access to the same emails. Shared mailboxes are commonly used in departments such as accounts receivable, the SOC, and customer support, where multiple people need to operate the same mailbox. At Adaptive Shield, we see approximately one shared mailbox per every 20 employees, making this a relatively common phenomenon. In general, shared mailboxes have no specific owner and there is no licence--and very often, these mailboxes are used to send and receive emails containing highly sensitive data.
What is the Risk?
Threat actors are constantly looking for mailboxes to take over, either for spam-related activities, or to launch highly convincing BEC (Business Email Compromise) scams that can eventually lead to destructive financial outcomes. Shared mailboxes present attackers with an easy entry point into organizations and usually have the following inherent problems:
- Their audit logs may be turned off or may be misconfigured
- Their passwords are built in and are static since there’s no one to change them
- MFA is usually not an option because there's no user and no licence
- They have no clear owner
Add enabled legacy protocols to the mix, and you’ve got a great recipe for a long standing take-over campaign.
How to Prevent Shared Mailbox Threats
Auditing is not enabled by default. You’ll need to change this configuration to detect who can access another user’s mailbox.
Keep in mind that admins are always adding members to shared mailboxes, and as such, it’s highly recommended to enable this setting. There are several measures you can take to reduce your attack surface and prevent breaches in the first place, as well as to adopt a defense-in-depth approach, in case such breaches have already occurred. While the first logical step would be to disable access for all users, there are many instances where this simply isn't practical. Below, we’ll define a more user-friendly approach that still provides access to these mailboxes while strengthening security posture.
To start, in Office 365, it is possible to login to a shared mailbox, as every shared mailbox has a corresponding user account. The obvious solution to prevent this would be to enable multi-factor authentication--but in this case, that’s not an option because the user has no license. If you try to access the mailbox through the UI, you won’t see much. But using authentication methods such as IMAP, EWS, etc, will allow you to access all emails within the shared mailbox.
Microsoft recommends blocking sign-in for the shared mailbox account; According to their documentation, “The account has a password, but it's system-generated (unknown). You aren't supposed to use the account to log in to the shared mailbox. But what if an admin simply resets the password of the shared mailbox user account? Or what if an attacker gains access to the shared mailbox account credentials? This would allow the user account to log in to the shared mailbox and send email. To prevent this, you need to block sign-in for the account that's associated with the shared mailbox."
So that should, in theory, take care of sign-in. But what If, for some reason, you still want to allow direct access? Make sure to reduce the attack surface by disabling legacy protocols such IMAP and adopt a defense-in-depth approach by preventing shared mailbox users from accessing Powershell (which would be enabled by default) and other unnecessary privileges. In addition, take care of shared mailbox access, as users with permissions to the group mailbox can “send as” or “send on behalf” of the mailbox email address, if the administrator has given that user permissions to do so.
Then discover and map the permissions of a shared mailbox’s members and monitor actions performed by non-owners with permissions. And of course, as we all know, life is not always a straight line. In order to review non-owner actions, you’ll have to enable mailbox auditing, since in some organizations, mailbox auditing is not enabled for all users. Last and most important, go and check if your organization has shared mailboxes right away to understand your own risk.
Attackers are always on the lookout for ways to breach organization and enhanced SaaS Security Posture Management (SSPM) is no longer just a “nice to have” for enterprises. At Adaptive Shield, we help organizations proactively prevent SaaS misconfigurations, like the issues presented in this article and related to shared mailboxes, and SaaS misconfigurations in other apps (e.g. Salesforce, Zendesk, Zoom, etc) that can lead to security risks.
About the writer
.webp)
