Script to disable direct Shared Mailbox logins

A while back I spoke about

The Insecurity of Shared Mailboxes

and how that even though they have an Azure AD Account they should have their logins disabled and access rights ONLY provided via the mailbox.

To make things easier for people I have now created a script that will allow you to view and potentially disable the direct logins for all your shared mailboxes to make them more secure.

image

The scripts requires that you are already connected to both Exchange Online and Azure AD.

At the top of the script, you’ll find a variable called $secure. If that is set to $false then no changes will be made to your environment, you’ll just get a report like shown above. Shared mailboxes that have direct login enabled will be displayed in red.

image

Now, if you change the variable $secure to $true then any shared mailbox that is currently enabled for direct connection will have that ability disabled. The output will display two lines for each mailbox that has direct access enabled. The first line indicates that direct logins are enabled and then the second line will show that has now been secured. In this scenario, all that is happening is that the shared mailbox identity is simply being blocked as I outlined in my earlier article.

image

 The last possibility is that the shared mailboxes direct logins have already been disabled, and in this case the results of the script should simply show that result in green.

In summary then, you can run this script with the variable $secure set to $false to just display the direct login condition of your shared mailboxes. You can run this script with $secure set to $true and then not only will the direct login condition of the shared mailboxes be reported but they will all then be blocked for direct login.

You will find this script in my GitHub Office 365 repository at:

https://github.com/directorcia/Office365/blob/master/o365-exo-sharedblock.ps1

The insecurity of shared mailboxes

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:

https://docs.microsoft.com/en-us/office365/admin/email/create-a-shared-mailbox?view=o365-worldwide#block-sign-in-for-the-shared-mailbox-account

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.

image

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.

Edit sign-in status flyout in the M365 admin center

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:

https://www.proofpoint.com/us/threat-insight/post/threat-actors-leverage-credential-dumps-phishing-and-legacy-email-protocols

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).

Email message traces in Office 365

A very common need these days is to do an email message trace. This can be done the old way in the Exchange Online Admin center or the new way via Mail Flow in the Security and Compliance center.

image

You simply enter the details and then run a search.

image

and the output looks like the above, where you can also drill in and get more detail.

image

As with all things Office 365, you can achieve the exact same thing using PowerShell as I have shown above. The code to achieve this is quite straight forward but I have uploaded it to my GitHub repo to save you the trouble:

https://github.com/directorcia/Office365/blob/master/o365-msgtrace.ps1

Where PowerShell comes into its own is when you need to a variety of tasks, perhaps an investigation of a breach. Using PowerShell you can easily dump all the information to CSV for further analysis rather than having to root it out in the web interface.

Reporting mailbox logins

Before much of what is covered here is possible you need to ensure you have enabled all the logging in your Office 365 tenant. I’ve covered how to do that here:

Enabling Office 365 mailbox auditing

Enable mailbox auditing in Exchange Online

Enable activity auditing in Office 365

Once you have done that you will be able to track what’s going on in your tenant much better.

In the situation of a compromised mailbox, a bad actor has control of it using legitimate credentials. This eliminates looking for failed logins, because there won’t be any. It also makes the finding the bad actor tougher because their access is most likely mixed in with the legitimate user.

The place to start is to run an audit log search as I have detailed here:

Searching the Office 365 activity log for failed logins

image

However, as I mentioned, we can no longer search for failed logins, we need to use a different search criteria. I would suggest that you instead run a search using the attribute “User signed in to mailbox” as shown above. That will produce something like shown for all users. Problem with this is that times and dates are in UTC not local time and it is cumbersome to manipulate in a web page. You can of course manipulate by exporting the results to a spreadsheet for more control.

image

Unsurprisingly, I feel PowerShell offers a much better solution to check the logs and report as you can see above. The script to do this I have made freely available at my Github repo here:

https://github.com/directorcia/Office365/blob/master/o365-mblogin-audit.ps1

Basically, it will search the Audit log for Exchange Items that are Mailbox logins and send that output to a nice table via the Out-Grid command. As you can see, using Out-Grid you can now easily sort by time by clicking the column heading, and thanks to the script, the times are local not UTC!

By default, the script will check the last 48 hours but you can easily modify that to suit your needs by either entering the scope in hours or entering a start and end date in the variables at the top of the script.

With this output I can now look for suspect IPs that login into the mailbox and begin hunting from there. However, remember, all of this relies on you enable your auditing BEFORE you need it. So, if you haven’t enabled it, go do it now! You’ll find scripts to enable the logs also in my Office 365 repo here:

https://github.com/directorcia/office365

Monitor outbound spam as well

image

Hopefully everyone is well aware of the need to protect Office 365 email from inbound spam, however what are you doing about outbound spam?

Hopefully, no bad actor gains access to your environment BUT if they did and they started using you accounts to send spam email how would know?

image

For this reason, I suggest that it is a good idea to go into the Exchange Administration console, select Protection, then Outbound spam. Edit the default policy (that’s really your only option), then select outbound spam protection on the left hand side. Then I suggest you should enable the option to send an email when there is a suspicious outbound email to somewhere that is monitored.

That obviously, won’t stop outbound spam but it should at least give you a heads up that it is happening.

Updated script to now check for Sweep

pexels-photo-1433350

The bad actors out there are clever and they’ll use any means at their disposal. Normally, when a user is successfully phished the first thing bad actors do is manipulate the email handling rules of the mailbox to hide their activity.

Unfortunately, there are quite a lot of different ways to forward email in Office 365 including via the mailbox and via Outlook client rules. It was brought to my attention that there is in fact another way that forwarding can be done, using the Sweep function. You can read more about this ability at:

Organize your inbox with Archive, Sweep and other tools in Outlook.com

Sweep rules only run once a day but do provide a potential way for bad actors to hide their activity, however as it turned out Sweep was in fact being exploited by bad actors inside a compromised mailbox.

I have therefore updated my publicly available PowerShell script at:

https://github.com/directorcia/Office365/blob/master/o365-exo-fwd-chk.ps1

That will now also check and report on any Sweep rules in finds in mailboxes as well as any other forwards configured in the tenant.

Let me know if you find any other methods that this doesn’t cover and I’ll look at incorporating those as well.

Enabling modern authentication in Office 365 script

Just a quick note to let you know that I have uploaded another short script to make life a bit easier. This one will enable modern authentication in a tenant for Exchange Online and Skype for Business Online (it is already on for SharePoint Online).

Modern authentication basically prevents multiple logins when using multi factor authentication for desktop apps like Outlook and Skype for Business client. You can read more about this here:

How modern authentication works for Office 2013 and Office 2016 client apps

Enabling modern authentication will also impact older clients like Office 2010, so enable it on your tenant with the understanding that when you do you really should be running the latest version of Office on all desktops.

That said, you can find my script here:

https://github.com/directorcia/Office365/blob/master/o365-modern-auth.ps1

Note, that you’ll need to have connected to Exchange Online and Skype for Business online in PowerShell for the script to execute correctly.

PowerShell script to check Outlook mail rules

image

After I finished the recent PowerShell script to check for Exchange style mailbox forwards I received some motivate from Robert Pearman to develop a script to also go and check what the Outlook rules are doing for Office 365 mailboxes.

Taking what Robert provided I decided to extend my initial script to report on what I consider suspect Outlook mail rules. Here’s my thinking:

– Firstly there are going to potentially be lots and lots of Outlook rules when you look across all mailboxes in Office 365, so I decided to focus on actions that one could deem to more suspicious than others. I settled on the following rule actions as ones to check: forward to, redirect to, copy to folder, delete message, forward as attachment to and send text message notification to.

–  Turns out you can create an Outlook rule that forwards, redirects and fowards as an attachment messages to alternate email addresses. A bad party could set this up to send themselves emails from a compromised mailbox.

– If a rule copies rather than moves a message then that to me is also suspicious. Why would you want two copies of the same email message in different locations in your inbox unless you aren’t in full full control of the inbox and someone is squirrelling away messages to a location the owner never created?

– If a rule deletes a message then there is a chance that a bad actor is trying to prevent the mailbox owner from seeing something.

– If a rule notifies someone via SMS that may be the fingerprint of a bad actor trying to keep tabs on a mailbox.

I will also admit, that there are plenty of situations where the above situations are the results of legitimately configured inbox rules. However, for the reasons I have indicated, I believe the actions to warrant the most inspection.

As you can see from the above image, the script will do what it did before and check the mailbox rules to see if there are any forwardings as before but now the script will also dig through each mailbox and throw up warnings when a suspect rule is enabled or disabled for a user.

Once you have located any suspect rules, you can then start digging further to see whether there is a business justification for such. If not, then you may have a compromised mailbox on your hands.

You’ll find the updated script at:

https://github.com/directorcia/Office365/blob/master/o365-exo-fwd-chk.ps1

and remember to keep coming back as I’ll continue to update and extend it over time. if you have any feedback on this script of suggestion for things you’d like to see please let me know so I can look at developing them. Thanks again to Robert Pearman for this input on this.