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
In the Graph API we can also do something simular using the following filter
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 https://github.com/gscales/Powershell-Scripts/blob/master/ZapStatistics.ps1 To run a Report on a particular mailbox use
Get-ZapStatistics -MailboxName mailbox@datarumble.com -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 mailbox@datarumble.com -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).
Analysis
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 mailbox@datarumble.com -startdatetime (Get-Date).AddDays(-14)
Then dump out the first message in the Collection
$Messages[0]
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 gscales@datarumble.com -MessageId "<57a196603977b4b3d9e0680d3119d816 baseny-wroclaw.pl="">"
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 gscales@datarumble.com -InternetMessageId "<57a196603977b4b3d9e0680d3119d816 baseny-wroclaw.pl="">"
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
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
Get-ZapStatistics -MailboxName mailbox@datarumble.com -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 mailbox@datarumble.com -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).
Analysis
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 mailbox@datarumble.com -startdatetime (Get-Date).AddDays(-14)
Then dump out the first message in the Collection
$Messages[0]
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 gscales@datarumble.com -MessageId "<57a196603977b4b3d9e0680d3119d816 baseny-wroclaw.pl="">"
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 gscales@datarumble.com -InternetMessageId "<57a196603977b4b3d9e0680d3119d816 baseny-wroclaw.pl="">"
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 gscales@msgdevelop.com (nothing too big or small).