August 29, 2016

Dealing with compromised accounts in Exchange Online

We have lately had a rash of compromised email accounts in our Office 365 Exchange Online infrastructure. It appears a well-crafted phishing email caught at least a small percentage of our 100,000-plus mailboxes.

The outbound SPAM protection in Office 365 and Exchange Online is very robust. Suspected SPAM messages are sent through a high-risk pool of IP addresses, and accounts are limited to 10,000 outbound messages per day before being blocked by the anti-SPAM intelligence. A support ticket must be filed with Microsoft to reactivate an account once it is blocked from sending outbound mail.

Normally, the anti-SPAM alerts received when an account hits the outbound message limit are sufficient for administrative notification. The most recent set of spammers, however, have been intelligently working underneath this notification system by sending less than 10,000 messages daily. The spammers instead cover their tracks by setting up email forwarding or an inbox rule to hide any bouncebacks from the slew of outbound junk.

Email forwarders victimized the most recent compromised accounts. These accounts came into the help desk with the same symptom of not receiving email messages. A look at the mailbox through Exchange Online PowerShell reveals the cause:

PowerShell Prompt

The spammer set the mailbox to forward all mail to an external address under their control, thereby hiding the nefarious activities.

To remove the forwarder, run the following in PowerShell:

Set-Mailbox -ForwardingSmtpAddress $Null

In some cases, spammers will instead setup an inbox rule to hide their activity. View all inbox rules for a mailbox through PowerShell by running the following:

Get-InboxRule -Mailbox

For a clean mailbox, this should return nothing or return valid inbox rules created by the customer.

It never hurts to educate your customers on never giving out login information through an email!

May 5, 2016

Add permission to Public Folder recursively with PowerShell

We had a request to add permissions for a customer throughout a deeply nested structure in our Exchange Online Public Folders.

These commands will not override or change permissions where they are already set.

Connect to Exchange Online PowerShell

$Cred = Get-Credential
Connect-MSOLService -Credential $Cred
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $Cred -Authentication Basic -AllowRedirection
Import-PSSession $Session

Add Permissions and Verify Success

In PowerShell, run:

Get-PublicFolder -Identity "\Folder Name" -Recurse | Add-PublicFolderClientPermission -User jsmith -AccessRights Owner

Verify the change was successful:

Get-PublicFolder -Identity "\Folder Name" -Recurse | Get-PublicFolderClientPermission | Where-Object { $PSItem.User -like "SMITH*" }

Use the customer’s name in the Where-Object cmdlet. All of our accounts are named in a “LASTNAME, FIRSTNAME” format, and the command reflects that. This command will print all of the customer’s rights through the tree.