Shared mailboxes are a really handy component of Microsoft 365 in that they allow multiple users to access a single mailbox. This works really well for generic accounts like info@, accounts@, etc. However, there are some security issues with these that I don’t think many people are aware of.
The first point to note is that shared mailboxes in Microsoft 365 actually have a login and password. Thus, they can be accessed directly using these details. Don’t believe me? Well check out the following documentation:
which says:
“Every shared mailbox has a corresponding user account. Notice how you weren’t asked to provide a password when you created the shared mailbox? 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”
So, by default, when you create a shared mailbox you are actually creating an account with a system password in your environment. No so bad you think right? Well, the problem is that, by default, IMAP and POP3 are enabled on all mailboxes, including shared ones.
Some actually use this IMAP ability to be able to open shared mailboxes on mobile devices, however doing this comes with a huge risk in my books.
Why? Well, if IMAP is enabled, that means basic authentication is enabled and that is bad as I have said previously:
Disable basic auth to improve Office 365 security
You may feel an unknown system or complex password on a shared mailbox is good enough but to remote bad actors running automated cracking programs against accounts on your tenant, it is only a matter of time until they generate a matching password for that shared mailbox. Once they have that, boom, they’re into that mailbox. From that foothold, they can then launch all types of attacks, but the most likely being phishing your users. It’s all down hill from there!
If you use shared mailboxes on mobile devices, this means you have to know the password for the shared mailbox prior to configuration on the mobile device. Because the shared mailbox has an account, it can have it’s password changed. That means, if you want to use shared mailboxes on mobile devices, you reset the password for the shared mailbox so you know it. You then give that to users so they can configure access on their phones. Anyone else see a problem here? You are providing multiple people access to a single resource with a shared password. What is a shared password? It ain’t a secret for sure now is it? So, what happens when a user leaves the business? I’ll bet most businesses don’t go and reset the password on all the shared mailboxes that user had access to. This means you now have someone outside your business who has a login (shared mailbox email address) and password to a resource in your tenant.
Here’s a scenario where that came back to bite the business. A disgruntled user was terminated and their individual login account was disabled. After the user has fired, they connected back into a shared mailbox directly using IMAP and started sending all sorts of nasty emails to all staff from this mailbox. Now if they had been smart, they would have done this from an anonymous IP address, not one assigned to them from their ISP so we could track them down. However, the damage was done. Why? All because access to the shared mailbox was permitted by insecure protocols and shared passwords.
As with most things security, it is pretty easy to protect yourself from this BUT it requires changing the defaults. The easiest way is to:
Block sign-in for the shared mailbox account
along with disabling IMAP, POP and basic auth. Yes, I fully appreciate that may have productivity ramifications, so you need to balance up the risk. However, given how easily this can be exploited, and the damage it could to the business, I’d rather be in the safe and secure camp than the ‘it’ll never happen to us’ blind faith camp personally. Anything that allows anonymous external users the ability to access accounts externally and allows them to keep guessing passwords as you can with IMAP spray attacks is very, very bad in my books. If you read this article:
make sure you note the very last paragraph which says:
“Update, March 21, 2019: This post has been updated to reflect specific cases in which IMAP-based password-spraying attacks were successful, particularly as threat actors targeted shared service accounts, (e.g., hr@company[.]com or helpdesk@company[.]com) or exploited weaknesses in MFA implementations and third-party email client logins.”
So please, secure your shared mailboxes NOW! If you really, really need shared mailbox access on mobile devices I would suggest you use Office 365 groups instead until Microsoft enables shared mailboxes natively on mobile devices (which is on the roadmap).
CIAOPS 
A few details that you left out about shared mailboxes — They are created with a disabled account in Active Directory. That means when they are created, even if you knew the password, you could not log into Active Directory with the account (It is disabled — AD won’t accept any password for the account). In order to log into the accounts, they have to be enabled (Which is a security concern of itself).
My experience in the past with shared mailboxes has been that if the account is disabled in AD, it is also disabled in Azure AD. I’ve looked at a number of shared mailboxes and they all appear disabled (I don’t enable shared mailboxes so people can log into them though).
Also you can log into Shared Mailboxes with IMAP and the Outlook App now supports opening shared mailboxes. They do not require you to know the password to the shared mailbox.
Also Azure AD allows you to lock Office 365 accounts when there are too many bad password attempts within a certain period of time (AD does too). If you haven’t configured this already, I think this would be more a security concern in my mind than a shared mailbox.
LikeLike
My experience is that the account is NOT disabled at all and that interactive login is enabled by default. I am talking largely about a total cloud environment NOT a sync from on prem environment. Maybe that is different but Azure AD ONLY shared mailboxes in my experience have interactive login ENABLED by default. You can only login to a Shared Mailbox directly if you have the password. Typically you access a Shared mailbox via your own mailbox which has been given permissions to the shared mailbox. To my knowledge, then an only then, independent of the protocol can you login without an identity challenge. Azure AD does have a lockout period but it is auto reset and enabled and doesn’t stay locked out indefinitely. Thus, an attacker simply needs to be patient and keep trying even with Azure AD lock out simply because it is not permanent. Per MS docs:
By default, smart lockout locks the account from sign-in attempts for one minute after 10 failed attempts. The account locks again after each subsequent failed sign-in attempt, for one minute at first and longer in subsequent attempts.
Smart lockout is always on for all Azure AD customers with these default settings that offer the right mix of security and usability. Customization of the smart lockout settings, with values specific to your organization, requires paid Azure AD licenses for your users.
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-smart-lockout
LikeLike
Great article. Could you comment on Resource Mailboxes (i.e. Equipment/Room Mailboxes) and how they relate to Shared Mailboxes?
Do you have any advice around securing these type of accounts?
LikeLike
They are effectively exactly the same thing and should be treated and secured in the same way.
LikeLike