Beau Bullock //

Overview

Microsoft Exchange users have the power to grant other users various levels of access to their mailbox folders. For example, a user can grant other users access to read emails from their Inbox. If a user (or Exchange administrator) isn’t careful and sets permissions incorrectly they might grant access to their mailbox to everyone at an organization. This creates a situation where any user at the organization can now read email from the mailbox with too broad permissions.

Using MailSniper, it is possible to quickly enumerate mailboxes like this that are accessible by any user. In this blog post, I’ll be describing how this problem can occur, how to locate mailboxes with permission issues, and ultimately how to read email from these mailboxes without the need for the mailbox owner’s credentials.

Setting Mailbox Permissions with Outlook

Changing permissions on a mailbox is a relatively easy thing for a user to accomplish on their own using the Microsoft Outlook client. If a user right clicks a folder such as the “Inbox”, then clicks Properties…”, a folder properties menu will open.

Clicking on the “Permissions” tab one can see the current settings for the folder. This is where things get a bit interesting. By clicking the “Add…” button this allows a user to specify a certain account to grant various permissions to. This would be ideal because a user can limit access to specific people. However, you will notice there are “Default”, and “Anonymous” items already included in Permissions. The “Default” item essentially includes every user at an organization with access to email.

If a user mistakenly sets the permission level for the “Default” item to anything other than “None” (besides Contributor), they are potentially allowing every employee at an organization access to that mailbox folder.

Setting permissions on mailbox folders can also be set by an Exchange administrator. Using the Set-MailboxFolderPermission cmdlet on the Exchange server directly, these mailbox permissions settings can be modified.

Invoke-OpenInboxFinder

As a penetration tester, finding mailboxes that are essentially world-readable can be extremely valuable. They could allow for a number of interesting attack vectors. For one, we could search through another user’s emails for certain things like passwords or sensitive data without having their credentials. Another attack vector could be that if the user’s email address is tied to a password reset system an attacker could trigger the password reset, then access the user’s email containing the password reset link.

I’ve added a function into MailSniper called Invoke-OpenInboxFinder to help find mailboxes with permissions set to allow other users access. To use it though we first need to gather a list of email addresses from the target environment. MailSniper has a module called Get-GlobalAddressList that can be used to retrieve the Global Address List from an Exchange server. It will try methods for both Outlook Web Access (OWA), and Exchange Web Services (EWS). This command can be used to gather an email list from Exchange:

Get-GlobalAddressList -ExchHostname mail.domain.com -UserName domain\username -Password Spring2017 -OutFile global-address-list.txt

If you are on a system that can communicate with the target organization’s internal Active Directory domain it is also possible to use Harmj0y’s PowerView to gather an email list. Import the PowerView script into a PowerShell session and run this to get an email list:

Get-NetUser | Sort-Object mail | ForEach-Object {$_.mail} | Out-File -Encoding ascii emaillist.txt

After gathering an email list, the Invoke-OpenInboxFinder function can check each mailbox one at a time to determine if the current user has access. It also will check to see if there are any public folders in Exchange that could potentially be accessed as well.

To use Invoke-OpenInboxFinder import the MailSniper PowerShell script into a PowerShell session with:

Import-Module MailSniper.ps1

Next, run the Invoke-OpenInboxFinder function with:

Invoke-OpenInboxFinder -EmailList .\emaillist.txt

Invoke-OpenInboxFinder will attempt to Autodiscover the mail server-based off of the first entry in the email address list. If this fails, you can manually set the Exchange server location with the -ExchHostname flag.

In the below example the command terminal is running as a domain user called ‘jeclipse’. After running Invoke-OpenInboxFinder against a list of email addresses from the domain two public folders were discovered. Also, the Inbox of “maximillian.veers@galacticempireinc.com” is accessible to ‘jeclipse’. Invoke-OpenInboxFinder will print out the permission levels for each item. It can be seen in the output that the “Default” item is set to “Reviewer”.

Searching Other User’s Mailboxes with MailSniper

After discovering that a mailbox has broad permissions that allows a user to access it, MailSniper could then be used to read and search through the messages in the target mailbox. The Invoke-SelfSearch function of MailSniper previously was purposed for primarily searching the mailbox of the user who was running it. I’ve modified it slightly to allow for checking another user’s email. A new flag called “OtherUserMailbox” needs to be specified to access other mailboxes. An example command would be the following:

Invoke-SelfSearch -Mailbox target-email-address@domain.com -OtherUserMailbox

In the screenshot below I am using the “jeclipse” account to search maximillian.veers@galactiempireinc.com’s mailbox. Three results were found where the subject or body of his emails contained the terms password, creds, or credentials.

Office365 and Externally Facing Exchange Servers

Invoke-OpenInboxFinder also works across the Internet against Office365 and externally facing Exchange servers if Exchange Web Services (EWS) is accessible. Unless, Autodiscover is set up externally it is likely you will need to manually specify the target hostname with -ExchHostname. For connecting to Office365 the hostname would be “outlook.office365.com”. Specify the -Remote flag to have Invoke-OpenInboxFinder prompt for credentials that can be used to authenticate to the remote EWS service.

An example command for checking mailboxes hosted on Office365 for broad permissions would be the following:

Invoke-OpenInboxFinder -EmailList .\emaillist.txt -ExchHostname outlook.office365.com -Remote

Below is a screenshot from an actual real-world assessment where the customer utilized Office365. We had access to a single user’s credentials at the organization. By running Invoke-OpenInboxFinder using an email list gathered from the Global Address List we were able to determine that three separate accounts at the organization allowed our user to read their email.

Recommendations

Obviously, preventing an attacker from gaining access to a valid user account would be the first step in defending against this. The problem though is that it doesn’t prevent your current employees from using this technique to see what other users’ ur’ mailboxes they have access to. Also note that it does appear that you must have a valid domain account that also has a mailbox in Exchange associated with it to check permissions on other uss’ mailboxes.

If possible, restricting these types of changes from being made on the Outlook client would be helpful. I’ve found a few older (2010) posts stating the permissions tab can be locked down with a GPO. I have not personally tried any of the solutions offered on these pages but it might be worth checking out. You can find those here , and here.

Use the Invoke-OpenInboxFinder function in MailSniper, or the Get-MailboxFolderPermission cmdlet on Exchange to audit these settings for all accounts at an organization.

Conclusion

Mailbox permissions are something that should be looked at by both blue and red teams. With the way Outlook includes the “Default” permission item in folder properties, it makes it far more likely that a user mistakenly grants everyone at an organization access to their mailbox. On the red team side this could provide an opportunity to find passwords or other sensitive data within emails that might further access on the network. Blue teams should worry about that but they also have other things to worry about. Some other things blue teams should worry about are high-profile accounts (C-Suite types) accidentally sharing their mailboxes out with the company, corporate employees snooping on other employees, or even the legalities of mailbox modification through these avenues.

______

You can download MailSniper from Github here: https://github.com/dafthack/mailsniper

Special thanks to ‘doomguy’ for opening an issue in the MailSniper repository on Github asking if this capability would be possible!

Join the BHIS Blog Mailing List – get notified when we post new blogs, webcasts, and podcasts.