Monday, December 17, 2018

ZAP (Zero-hour auto purge) Junk email reporting for Office365 using EWS and REST

Zero-hour auto purge is one of the features of Office365 that will detect malicious and Spam emails and move them to the Junk email folder for any email that has breached the first level defences and has been delivered to users mailboxes. There is a good description of how it works here but basically when the service learns a particular message was malicious/spam it can retrospectively detect and eliminate/move any simular messages that arrived previously and weren't detected.

This is a good and much need feature as no AntiSpam or Malware solution is perfect (no matter what the vendor say) so there will always be the case where thing slip through. But this very fact is what causes an exposure point where the potentially malicious email sits in the Inbox of end user up until the time its gets zapped. What I wanted to present in this post is a few ways you can measure the amount of the time you may have been vulnerable for and show some methods you can use to look more at messages and it's potential malicious content.

How to detect messages that have been zapped in a EWS and REST script

There is a good reference article for this here , what happens when a Message is Zapped and moved to the Junk Email folder is a Internet Message Headers is added which will also create a underlying Extended property see

We can use  this in a EWS or REST script to do some reporting on. In EWS we can use an Exists Search filter on Messages in the JunkEmail folder to find just messages where this property has been set meaning that these messages have been zapped

 $ZapInfo = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition([Microsoft.Exchange.WebServices.Data.DefaultExtendedPropertySet]::Common, "X-Microsoft-Antispam-ZAP-Message-Info", [Microsoft.Exchange.WebServices.Data.MapiPropertyType]::String)
 $Sfexists = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+Exists($ZapInfo) 

In the Graph API we can also do something simular using the following filter

$filter=singleValueExtendedProperties/any(ep: ep/id eq 'String {00062008-0000-0000-c000-000000000046} Name X-Microsoft-Antispam-ZAP-Message-Info' and ep/value ne null) 

What this does is returns us a collection of Messages that have been zapped, I went a step further in my script and put a DateTime filter around this as well (but technically the Junk Email folder has a default retention period of 30 days so it shouldn't really have a large volume of email). Once you have messages return if you check the datetime the message was received and then using the Time-Span function in PowerShell calculate the TimeSpan  against last modified time (which should have been the time the Message was Zapped and moved to the JunkEmail folder) this will give you a good indication of the time that these messages sat in the Inbox of the user (this becomes your vulnerability period). You can also look at the read setting of the Email to determine if the user had actually read the Message that was Zapped. I've gone a another step further in my reporting script to also do some Antispam analysis of the email headers using some code I previously wrote so you can also look the DKIM,DMARC etc values this mail received as well. So in the end what my reporting script does is checks for Zapped messages in the Junk Email folder for a specific time period and then produces a report on the actually exposure time and relevant information around this so it can be further evaluated. The output of the report is something like this

I've put the EWS script that can do this report on GitHub To run a Report on a particular mailbox use

 Get-ZapStatistics  -MailboxName -startdatetime (Get-Date).AddDays(-14)  | Export-Csv -Path c:\Reports\mailboxName.csv -NoTypeInformation

I've also added the same type of script to my Exch-Rest Module so you can do the same thing using the Microsoft Graph API

 Get-EXRZapStatistics  -MailboxName -startdatetime (Get-Date).AddDays(-14)  | Export-Csv -Path c:\Reports\mailboxName.csv -NoTypeInformation

The module is available from the PowerShell Gallery or GitHub

DevOps - Looking at deeper analysis and proactive measure

I thought I'd start including a DevOps section in some of my posts to show how you can delve a bit deeper to look what we are reporting on and some potential proactive measures you might be able to put in place to earn such a DevOps tag. In this section I'm assuming you know enough about development to know your way around objects,methods,properties etc. I'm going to be using my Exch-Rest module because its the best tool I have to do this and its also a good way to improve the module itself (and its free).


So first lets just look at one of the Messages that have been zapped to do this just pull the Messages into a collection like

$Messages =  Get-EXRZapStatistics  -MailboxName -startdatetime (Get-Date).AddDays(-14)

Then dump out the first message in the Collection


This give us something like

So we have a whole bunch of interesting information about the source that is trying to essentially attack or steal the users credentials. We have

Source SMTP server IP Address in the CIP and SPF Values
We have the Reverse DNS PTR (which tells us the sending server country location)
The HostName of the SMTP server which does resolve in DNS to the same IP Address as the PTR record but the HostName doesn't match
The SCL value of 1 which is pretty low

I can see the message was Read by the user (which isn't good if this is a user). So the next thing that might be useful is looking at the content of the messages to see if it has any attachments. We can do this using the InternetMessageId and the following

$message = Find-EXRMessageFromMessageId -MailboxName -MessageId "<57a196603977b4b3d9e0680d3119d816"">"

This gives us some information like the following

So this tells us right away there where no Attachments so that is one less thing to worry about it also shows the they tried to fool the target user by putting in a different email address in the SenderName then the actual senders Email address as they where trying to make it appear as if it was a system generated message that came from Microsoft itself.

So now we know that there where no attachments it probably just has a link they want the user to click. To get more information on links in the body of the Message we can use something like the following

$expandedEmail = Get-EXREmailBodyLinks -MailboxName  -InternetMessageId "<57a196603977b4b3d9e0680d3119d816"">"

and then we can view the links in the email like

Bingo there you have an attempt to fake the domain name to make it look like something that a user may have used before so they might feel confident entering their details into etc. At this point you might want to trawl through what ever logs you have available to see if a user did actually visit that URL and take some urgent action if they did.

Being Proactive

So what I've gone through above are some manual steps above to show that the while you can be assured that the cloud is doing its job to a certain extent there are some extra measures you can take to keep a closer a eye on what potential these malicious email are trying to do and catch any unsuspecting users before something like this becomes a bigger problem for you. The cloud isn't set and forget and if your not doing some extra checks on what is happening in the service your not being as an effective for the company you work for (or on behalf of) as you can be. Some other quick DevOps ideas

  • Setup a Azure Runbook that uses Certificate Authentication and AppOnly tokens that will report on the Zapmessages and do some further automated analysis on a Daily or Weekly basis.
  • Look for correlations based on the information you have in the Zapped messages, if your being targeted by someone there is a good chance that location data, Ipaddress from one attacked maybe used in subsequent ones. So apply those patterns to look at your Message Tracking logs which will give you details about SenderIp ect.
Hire me - If you would like to do something similar to this or anything else you see on my blog I'm currently available to help with any Office365,Microsoft Teams, Exchange or Active Directory related development work or scripting, please contact me at (nothing too big or small).   

Monday, December 10, 2018

Updates to the Exch-Rest PowerShell Module to support PowerShell Core, Azure Cloud Shell and more ADAL integration options

I've had some time recently to do some much needed updates to my Exch-Rest module so it now supports both Azure Cloud Shell and PowerShell Core on Linux (tested on RHEL,CentOS, Debian and Ubuntu). So now you can logon to an Office365 Mailbox using this Module with Powershell on Linux and send Email or a Skype for Business Message or do some mailbox reporting eg

The requirements on Linux is you need to be using the latest version of PowerShell core installed as per .This ensures that all the required .net Core libraries will be available as older version of .Net core didn't have some of the libraries I'm using and I didn't want to backport for older versions.  Also because there are no Linux forms to interact with for authentication you need to pass in the credentials to use via a PSCredential and the code will use the password grant to get the Token eg
$cred = Get-Credential -UserName
connect-exrmailbox -MailboxName -Credential $Cred
Azure Cloud Shell

As Cloud Shell is a browser based version of  PowerShell core running on Linux the same connection method of using the credentials as above is needed.

ADAL Integration

I've also added full integration with the ADAL library for authentication so in addition to the native dependency free script methods the module now distributes the ADAL libraries and supports Authentication using that library as well as Token refreshes for scripts that run over an hour etc (using Acquiretokenasync in the ADAL). This supports the following scenarios such as
To use the ADAL libraries for Logon use the following 

connect-exrmailbox -MailboxName -useADAL

To use the Never Prompt to use the ADAL Cache
connect-exrmailbox -MailboxName -useADAL -Prompt Never
For connecting using the currently logged on credentials use
connect-exrmailbox -MailboxName -useADAL -useLoggedOnCredentials -AADUserName

(The -AADUserName variable is optional but usually required read the GitHub link in the second bullet point)

For those who want to do something simular and are using EWS you will need something like the following to get the AccessToken using ADAL in a normal PowerShell Script.

    $ClientId = "d3590ed6-52b3-4102-aeff-aad2292ab01c"
    $ResourceURI = ""
    $EndpointUri = ''
    $Context = New-Object Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext($EndpointUri)
    $AADCredential = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.UserCredential" -ArgumentList ""
    $authResult = [Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContextIntegratedAuthExtensions]::AcquireTokenAsync($Context, $ResourceURI, $ClientId, $AADcredential)
    if ($authResult.Result.AccessToken) {
        $token = $authResult.Result
    elseif ($authResult.Exception) {    
        throw "An error occured getting access token: $($authResult.Exception.InnerException)"    
    return $token

This also goes along with support for using the Module in an Azure Runbook which was added last month.

The Exch-REST Module is available from the PowerShell Gallery and GitHub

A big thankyou to all those people who provided feedback on using the module hopefully these upgrades make it easier to use in more scenarios.

Hire me - If you would like to do something similar to this or anything else you see on my blog I'm currently available to help with any Office365,Microsoft Teams, Exchange or Active Directory related development work or scripting, please contact me at (nothing too big or small).