Exchange email security is a huge front to defend. There are now so many attack surfaces that it can be hard to decide how to start. Here are a few things that you might want to consider when thinking about your Exchange infrastructure security setup.
This is by no means a full list.
1. Full Access and Send As Permissions
A brilliant feature of Exchange is the ability to grant users access to others’ mailboxes. You can do this in two ways, either by using the “Full Access” permission, which effectively gives them the same rights as the owner of the mailbox, or by granting “Send As,” which just gives them the permissions to change the “from” field to a specified user.
To grant full access, you can use a PowerShell command like the following:
Get-Mailbox “MailboxToView” | Add-ADPermission -User “PersonWhoNeedsPermission” -ExtendedRights “Full Access”
Be aware that in Exchange 2013 and later, any member of ‘Domain Admins’ cannot view other users’ mailboxes.
To find out who has access to mailbox, you can run the following PowerShell command:
Get-Mailbox | Get-MailboxPermission | Where { $_.AccessRights -eq “FullAccess” -and $_.User.ToString() -ne “NT AUTHORITYSYSTEM” -and $_.User.ToString() -ne “NT AUTHORITYSELF”} | Select Identity, User | fl
This will give you a list of mailboxes with users and groups that are able to access them.
Note: this may take a while to run across many mailboxes!
2. Transport Rules
One of the most commonly overlooked Exchange security points is the humble transport rule. If you have a malicious administrator, they can potentially view everyone’s email just by setting up a transport rule.
I know of an organization where someone had modified the default signature transport rule to blind carbon themselves on every single email that left the company. It was only by chance when another sysadmin was asked to modify the signature that they noticed this.
This kind of behaviour is quite hard to detect, but a simple PowerShell command would have revealed this:
Get-TransportRule | Where {$_.BlindCopyTo -ne $null} | fl Name, BlindCopyTo
Other actions that could potentially be used for malicious purposes are as follows:
Get-TransportRule | Where {$_.ModerateMessageByUser -ne $null} | fl Name, ModerateMessageByUser
This command will list any rules where approval is needed before the message is delivered.
Get-TransportRule | Where {$_.DeleteMessage -eq $true} | fl Name
This command will list any rules that simply delete the message.
3. Exchange Roles
Microsoft has used the Role-Based Access Control model (RBAC) since Exchange 2010, and it became more prominent in Exchange 2013 and later. In essence, you assign users and groups permissions to perform actions and tasks using the “who, what, where” method.
As an example, let’s take a branch manager of ExampleCo’s London office (who). Management want the branch manager to be able to change the out-of-office replies (what) for their branch (where).
Exchange role security allows us to do this by creating a custom role group:
New-RoleGroup -Name ExampleCo_London -Roles (See Later) -Members BranchMgr1
This will create a role group with no scope applied – no “where,” i.e., BranchMgr1 will be able to use their permissions on all Exchange objects that support it.
We can limit the scope to a single organizational unit by omitting -Members and supplying -RecipientOrganizationalUnitScope instead:
New-RoleGroup -Name ExampleCo_London -Roles (See Later) -RecipientOrganizationalUnitScope “LondonOU”
In order to achieve our goal of allowing BranchMgr1 to change the out-of-office replies, we can assign them the “Help Desk” built-in role:
New-RoleGroup -Name ExampleCo_London -Roles “Help Desk”
You can also create your own roles with a custom set of permissions.
We had a situation recently where we needed to find out who had changed a transport rule on one of our Exchange servers; luckily, there is an easy PowerShell command to view who has permissions to change a mailbox or server:
Get-ManagementRoleAssignment -Role “Transport Rules” -WritableServer Exchange -GetEffectiveUsers
Running this on our environment yielded a list of groups who could perform this task:
4. Exchange Edge Servers
I cannot stress enough how important it is to have an Exchange Edge server. These are highly cut-down servers that just expose port 25 (SMTP) to the outside world. This narrows their attack surface dramatically and offloads spam and anti-virus processing to another (virtual) server.
Edge servers are not members of your active directory domain, so as long as you’re not sharing passwords between admin accounts (you’re not, are you?), then an attacker who manages to get control of your Edge Server doesn’t really have much of a foothold.
Required information from Active Directory that is used for early recipient rejection for example, is sent via a one-way Edge Sync process.
5. Hybrid Configurations
I’ll finish by just drawing your attention to Office 365 and Hybrid configurations. It is possible to apply most of the on-premise configurations to the cloud or hybrid part of your Exchange configuration.
You can use the following command to establish a connection to the Exchange Online servers:
$creds = Get-Credential
$eonlinesession = New-PSSession – ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $creds -Authentication Basic -AllowRedirection
Import-PsSession $eonlinesession
Check that you’ve connected successfully by issuing something like get-mailbox and see if it returns mailboxes that you know are offsite.
Once you’re done, don’t forget to disconnect; otherwise, you can run into issues later on in which you use up all of the available PowerShell sessions for your user (you then have to wait for them to timeout, which is not fun.).
Remove-PsSession $eonlinesession
