A Shared Mailbox has been available since the early days of the Exchange servers, and the same is true for Exchange Online. Organizations primarily use a shared mailbox for users who have left or, if we need to collaborate, an inbox for multiple users. Because a shared mailbox allows multiple users to access it, it has security gaps. One of them is the “hidden object” in Entra ID.
This post identifies a specific security risk with Shared Mailboxes in Exchange Online, explains it, and offers a few tips and commands to block sign-ins.
Shared Mailbox in a Nutshell
A shared mailbox is a kind of user mailbox with some changes. A shared mailbox is a mailbox that multiple users can access to read and send messages. The kicker? It has no username or password of its own, and you cannot log into it directly. Access is strictly governed by permissions (Delegation) mapped to individual user identities. More on Microsoft Learn.
Note: There are a few ways to access a shared mailbox, including direct access.
Why set up a shared mailbox?
- Shared calendar and contacts allow a mailbox to include a shared calendar and contact list for scheduling, tracking appointments, or managing shared client/vendor details.
- Better collaboration and tracking because everyone can see what has already been answered, avoid duplicate replies, and see what is still open.
- Replies appear from the team with Send as/Send on behalf” responses that look like they come from the shared address, not a personal user, which is cleaner for external contacts.
The General Risks
Shared mailboxes in Exchange Online introduce several risks, particularly in the areas of security and management. If not properly controlled, these risks can result in data exposure, unauthorized access, and operational inefficiencies.
No Slack account needed.
The Primary Risks
- Over-permissive delegation: FullAccess or SendAs permissions can expose all contents to delegates; if a delegate’s account is hacked, attackers access everything without separate creds
- No built-in advanced protections unlicensed: Without an Exchange Online Plan 2 license, no retention, eDiscovery, or litigation hold, leading to data loss from deletions or purging.
- Limited auditing: Harder to trace actions in shared setups vs. individual mailboxes; relies on unified audit log for delegates, but gaps exist for reporting/phishing tools.
- Inadequate Permissions Management: Permissions (FullAccess/SendAs) are often over-assigned or never revoked, allowing ex-employees or compromised users lingering access to sensitive data; lacks native RBAC enforcement, leading to persistent oversharing.
- MFA Bypass via Delegation: Delegates access the shared mailbox using their own credentials in Outlook/OWA, silently bypassing MFA prompts for the shared account itself. Attackers with stolen delegate credentials gain full read/write access without additional factors.
Tip: You can configure an authentication method for a Shared Mailbox.
From the Trenches
Shared mailboxes are the “ghost ships” of the enterprise, often unmonitored, frequently exempted from strong authentication, and sailing with a treasure trove of sensitive data. In the trenches of MDR and Incident Response, we don’t just wait for an alert, we hunt.
Here are a few hypotheses we use for shared mailbox hunting, a proactive approach, and thinking like an attacker. An adversary doesn’t see a shared mailbox as a functional tool, because he can see it as a “pre-authenticated” identity that bypasses security filters and grants them a trusted seat at the corporate table without triggering MFA.
- Delegate Permission Grant by Compromised Account: An attacker who has already breached a standard user account is moving laterally by granting themselves “Full Access” or “SendAs” permissions to a high-value shared mailbox to monitor sensitive communications.
- Shared Mailbox Weaponized for BEC Sends: An unauthorized actor is leveraging the mailbox’s trusted internal reputation to distribute fraudulent invoices or phishing lures, ensuring the messages bypass external spam filters and carry the weight of corporate authority.
- Shared Mailbox Inbox Rule Manipulation: A threat actor is deploying stealthy, automated mailbox rules to silently delete or redirect incoming replies from victims, effectively masking their presence and managing the evidence trail in real-time.
- Mass Data Exfiltration from Shared Mailbox: An adversary is utilizing their access to perform bulk “Sync” or “Bind” operations, systematically scraping the mailbox’s entire historical archive of contracts, PII, and sensitive intellectual property for future extortion.
- Never Seen Delegate Access: A compromised legitimate account is being used to “discover” and access a sensitive shared mailbox for the first time, signaling that an attacker is exploring their existing permissions to find low-hanging data.
By identifying these patterns and more, we shift from a reactive stance to an active defense, ensuring that these “ghost ships” are no longer a blind spot in our environment.
The Unmanaged Object
Not really a hidden object, but mostly, it’s unknown, not maintained, or monitored.
In the long past, when creating a Shared Mailbox on an Exchange server, the rule was to disable the corresponding AD account. Because there is no secondary usage of the Active Directory account, it prevents attacks.
Nowadays, with Exchange Online, an object appears in Entra ID after creating a shared mailbox, a room mailbox, or any resource mailbox.
A shared mailbox in Exchange Online is backed by an Entra ID account that is automatically created with a password set by the system. Although this initial password is not known to administrators, it can be reset to a known value. Once reset, the account can be accessed like a standard user account, including through APIs or other direct authentication methods.
The following images show a standard shared mailbox in Exchange Online and Entra ID with mailbox policies, GAL settings, and Entra ID information.
Known gap: A shared mailbox with the default mailbox policies, and the big question. Are you using default mailbox policies for shared mailboxes?
A quick check of the object in Microsoft Entra will show the known fields, values, and information. With the new Microsoft 365 Tenant, the shared mailbox is disabled by default.
In the modern Microsoft 365 tenants, the default behavior has shifted to automatically block sign-in for the underlying user object upon creation.
The Recon Phase
As always, the AADInternals is part of my research, attack flows, and discovery phases. I ran AADInternals for a quick enumeration to provide an additional fact about the objects.
Note: You can run AADInternals against a list of users to receive detailed results.
We have an AI. Why not use it? The AI can provide a list of potential names for shared mailboxes.
We can take those users and search for their existence.
If you want to spray the mailbox, you can run MailSniper to search through emails in a Microsoft Exchange environment for specific terms (passwords, insider, network architecture information, etc.).
Blocking Sign-ins
Additionally, no one needs to reset the password to a shared mailbox or make any unusual or routine changes to it. Specific actions on the shared mailbox can be performed by a delegated mailbox, and mailbox policies and permissions can be adjusted for collaboration. That’s it.
Microsoft 365 admin console provides a reset password button for Shared Mailboxes.
There are many scenarios in which attackers can launch a password attack on shared mailboxes to steal credentials. Multiple users shared and used the same mailbox, making it challenging to identify and detect the attack.
Note: Something to think about. How many environments maintain shared mailbox access, and how many monitor them for attacks?
I’m abusing Microsoft 365, Google Workspace, and AI platforms daily, including Exchange Online and its associated resources. One common technique in the field involves identifying weaknesses and misconfigurations in cloud-based objects. For example, when conducting a brute-force attack against a shared mailbox in Exchange Online, I send authentication attempts directly to the Exchange Online service instead of relying on timing analysis or interpreting HTTP response codes.
In this scenario, a response code message will do the work and tell me whether the inbox is valid. The equal can be with AADInternals, which can enumerate the object with various available commands, and a login mode can be one of them. Once I get the response code, I test for a mailbox type. Externally, Exchange Online provides information about who’s shared objects. The process continues checking for valid shared mailbox objects.
So, should I block sign-ins? Sure thing! Attacking shared mailboxes is 100% successful. Because of many reasons:
- Enumeration and discovery of cloud resources can often go unnoticed, especially in environments where monitoring is incomplete or misconfigured.
- Shared and service objects frequently suffer from poor maintenance and lack proper lifecycle management or regular security reviews.
- These accounts are often excluded from key security controls
- Many of these objects still rely on single-factor authentication, making them particularly vulnerable to specific attacks.
TIP: If you’ve got the proper audit and logging, in scenarios such as brute force or password spray, it will raise the correct detection and hunting rules
Configure the Block Sign-ins
If the mailboxes are not blocked, you should mitigate it.
You can block sign-in to the shared mailbox via the Microsoft 365 portal or Microsoft Graph. I’m a shell person, so I shared a few commands to connect to Microsoft Graph and Exchange Online Management with specific permissions, check for shared mailboxes, and block sign-in.
Install-Module Microsoft.Graph
Install-Module ExchangeOnlineManagement
Connect-ExchangeOnline
Connect-MgGraph -Scopes "User.ReadWrite.All"
Then, you can block credential sign-ins for a single mailbox
$UID = (Get-EXOMailbox "Test1").ExternalDirectoryObjectId
Update-Mguser -UserId $UID -AccountEnabled:$false
Then, you need to get a list of all current Shared mailboxes’ state
Get-EXOMailbox -RecipientTypeDetails "SharedMailbox" | ForEach {Get-MgUser -UserId $_.ExternalDirectoryObjectId -Property "DisplayName, AccountEnabled"}
Once it works, you can disable Entra ID accounts for all Shared mailboxes
Get-EXOMailbox -RecipientTypeDetails "SharedMailbox" | ForEach {Update-Mguser -UserId $_.ExternalDirectoryObjectId -AccountEnabled:$false}
