It seems like every week I see a new phishing story coming through my social media feeds. The stories are all basically the same, someone with access to financials in an organization receives an email from “an executive” and follows instructions to wire thousands, hundreds of thousands or millions of dollars overseas.
While I’m admittedly surprised that large sums of money are transferred based on emails without any type of validation, it apparently is not uncommon. The email turns out to be, of course, not from an “executive” and the money is in most cases is long gone.
The other attack that seems to be making the news quite a bit these days is the distribution of “ransomware” via email. In particular, it seems like the healthcare industry is targeted with these types of attacks. A user opens an email attachment and suddenly they’ve encrypted whatever files they have access to; short of restoring the data from backups, the only answer is to pay a ransom in Bitcoins.
Proper security includes depth in defense and in some cases your users are the final layer of protection. Below are a few things that can be implemented at virtually no cost that could help protect your organization.
Notable Attacks
If you’re asking “does this really happen”, here are a few recent examples for you:
- Omaha’s Scoular Co. loses $17 million after spearphishing attack
- Ubiquiti Networks Says It Was Victim of $47 Million Cyber Scam
- Mattel fought elusive cyber-thieves to get $3M out of China
So now that we’ve established that the threat is real (and costly), how does this happen?
How It Happens
Short of a compromise of your internal systems, there’s basically two ways that these emails trick your users:
To understand this scenario, you need to know that every email has essentially two “from” addresses. You have the “mail from” field which is also referred to as the “envelope” or “P1” address and then you have the “from” field which is referred to as the “P2” address. Many of your spam filtering solutions will look at the P1 address so what happens is the phishing email is sent with a P1 that is from a company that is publishing a valid SPF record but the P2 (which is what the user sees in Outlook) will appear to be from your organization. So the message arrives and to your spam solution it looks legit and to the user it appears as internal. When the user replies to the message, they likely have not noticed that it’s actually going to the P1 address.
Similar Domain Names
In this scenario, effort is made to register a domain similar to your own. So if your domain is “iwitl.com”, the email might come in with the domain “lwitl.com”; assuming the username portion of the email matches, it takes a keen eye to catch this. (Don’t see the difference? The first “I” was replaced with an “L”.) Combined with the above where the P1 was “ceo@lwitl.com” and the P2 (which the user sees) is “ceo@iwitl.com”, it really is asking a lot of users to catch this.
Microsoft Fights Back
Microsoft is implementing a few things to help defend against these types of attacks. One of these features is “Safety Tips” which is a visual indication in OWA around how safe an email is. Unfortunately this feature is only rolling out to OWA today although I wouldn’t be surprised to see it make its way into Outlook in the future. Another feature, related to HTML links and attachments, is “Advanced Threat Protection” which is part of the E5 license or available separately as an add-on.
What You Can Do
First of all, if you don’t have a proper SPF published today, you should start there. After that, implementing DKIM and DMARC can help protect against “insider phishing” emails. Even if you implement DMARC with an action of “none”, you can use a transport rule to protect your own users from “insider phishing” emails. For more details on this setup, see “Office 365 – SPF, DKIM and DMARC in Exchange Online“. Another option is to modify inbound emails and provide “visual cues” to your users about the source of the email.
Providing Visual Cues
I have somewhat mixed feeling on this type of action. I’ve seen it implemented at a few clients and while I’m not a fan of modifying the content of the email, it could prove helpful. The effectiveness will certainly depend on the percentage of external vs internal emails that a person receives; at some point I’m sure there’s a subconscious habit to ignore any warnings.
The idea here is to modify the either the subject line or body of an email such that a user has additional information about it. While messaging admins might look at the message headers, it’s unreasonable to think that your average user is going to think about that. You can easily use transport rules to give users a little more insight as to whether an email is safe or not. In the earlier stated phishing examples, one would hope that it would at least cause the recipient to ask a few more questions before wiring millions of dollars overseas.
As an example, you might force all external email to show the following:
And if a message fails SPF because a company has failed to properly configure it, you might modify the email as such:
Configuration
The setup here is not that difficult. Basically it’s two transport rules that use the “prepend disclaimer” function to modify inbound emails. If you have emails that are known to be spoofed (e.g. external applications) then you may need to add some exceptions.
You’ll want this rule to be a higher priority than the others (basically just for formatting purposes). It can be created with the following code:
New-TransportRule -Name "Visual Cue - External to Organization" -Priority 0` -FromScope "NotInOrganization"` -ApplyHtmlDisclaimerLocation "Prepend"` -ApplyHtmlDisclaimerText "<div style=""background-color:#FFEB9C; width:100%; border-style: solid; border-color:#9C6500; border-width:1pt; padding:2pt; font-size:10pt; line-height:12pt; font-family:'Calibri'; color:Black; text-align: left;""><span style=""color:#9C6500; font-weight:bold;"">CAUTION:</span> This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.</div><br>"
As a reminder, you may need to add exceptions to this rule for addresses that are technically external but you don’t want to be tagged as such.
Rule for Invalid SPF
For this rule, we’re looking for all scenarios where the SPF evaluation returns anything other than “Pass”.
New-TransportRule -Name "Visual Cue - No SPF Validation" -Priority 1` -HeaderContainsMessageHeader "Authentication-Results"` -HeaderContainsWords "spf=TempError","spf=PermError","spf=None","spf=Neutral","spf=SoftFail","spf=Fail"` -ApplyHtmlDisclaimerLocation "Prepend"` -ApplyHtmlDisclaimerText "WARNING: The sender of this email could not be validated and may not match the person in the ""From"" field."
Limitations
Again, this is not a perfect solution and Microsoft is likely to eventually bring features like “Safety Tips” to Outlook and the mobile platform. If the email is sent as “plain text”, the appended warnings lose some of their visibility as the warning is also in plain text without any color.
Additionally, the scenario I really wish we could account for here is when the message is sent with a similar domain and the P1 and P2 don’t match. Unfortunately, there is not an X-header that indicates this even though it seems like it would be relatively easy to identify. Also, if an email is received with a similar domain where the P1 and P2 do match, it’s going to be difficult to catch. With both of these scenarios, you can only hope that the notification of it being an “external email” is enough.
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.
The idea to itself is very good but the implementation could use some improvements.
The rule for Invalid SPF will produce false positives sooner or later.
Consider this ‘Received-SPF’ header:
Pass (protection.outlook.com: domain of none.com designates 1.2.3.4 as permitted sender)
This is perfectly legitimate and correct SPF record but it will be marked by the rule.
‘None’, ‘Neutral’, ‘Fail’ are common words that can to be parts of domain names, simple word-match is not a good idea here.
Instead it is better to use ‘Authentication-Results’ and explicitly call result of the SPF check.
This would look like this:
-HeaderContainsMessageHeader “Authentication-Results”
-HeaderContainsWords “spf=TempError”,”spf=PermError”,”spf=None”,”spf=Neutral”,”spf=SoftFail”,”spf=Fail”
Cheers,
GW-
Good call, I agree that makes more sense.
I’ll update the article.
Thanks!
If transport rules are used, is there a way to prevent the disclaimers from being included in replies, forwards, etc?
CR-
Once a message is received from external, it would get stamped with the warning. A reply back would not (as we’re only stamping inbound from external) add another warning but if the external party replies to your reply, it would be stamped. If you don’t want any subsequent replies from the external party to be stamped, you could add an exception that basically says if the body of the email already contains the content of the warning, don’t apply it again.
Thanks for the question!
Joe
I would like to implement this at my organization, but do not see a way to remove the stamp from our replies. Customer emails us, email gets stamped. We reply to the same message and stamp is still in the previous body. IS there a rule to delete specific text patterns from replies?
Brad-
Unfortunately with this approach, there message is modified and there is not an option to remove those modifications.
Thanks
Joe
Very good written article. It will be supportive to anyone who utilizes it, including me. Keep doing what you are doing – can’t wait to read more posts.
great and helpful blog to everyone.. thanks a lot for sharing
Thanks for the this useful article.
I believe that a better approach is using categories instead of disclaimers,
I’d recommend to use this action:
Set the message header ‘Keywords’ to the value ‘This email originated from outside of the organization’
BR
Is there a way to validate the SPF rule is working?
I get the following error when creating the transport rule
To be valid, all rules have to include at least one action. Please specify an action.
Parameter name: Actions
+ CategoryInfo : InvalidArgument: (:) [New-TransportRule], ArgumentException
+ FullyQualifiedErrorId : [Server=BY2PR17MB0312,RequestId=f0b57ba8-f4d4-4d45-8a7f-afddc3cc8804,TimeStamp=3/8/2018 9:23:32 PM] [FailureCategory=Cmdlet-ArgumentException] A5C5448F,Microsoft.Exchange.MessagingPolicies.Rules.Tas
ks.NewTransportRule
+ PSComputerName : outlook.office365.com
-FromScope : The term ‘-FromScope’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:3 char:1
+ -FromScope “NotInOrganization”`
+ ~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (-FromScope:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
@Cory Russell, the command is meant to be a single line item. Copy what’s here to text file, then remove the carriage returns (which includes the ` symbol at end of each line) to make it all one line item. Disable word wrap helps.
Has anyone configured a way to Dynamically add Displays names as new users are created?
Since this method is pre-pending to the body of the email, wouldn’t it adversely effect S/MIME signed messages?
There’s some HTML formatting missing from the Invalid SPF rule, for it to look like the image with the red background and a border.
New-TransportRule -Name “Visual Cue – No SPF Validation” -Priority 1`
-HeaderContainsMessageHeader “Authentication-Results”`
-HeaderContainsWords “spf=TempError”,”spf=PermError”,”spf=None”,”spf=Neutral”,”spf=SoftFail”,”spf=Fail”`
-ApplyHtmlDisclaimerLocation “Prepend”`
-ApplyHtmlDisclaimerText “CAUTION: WARNING: The sender of this email could not be validated and may not match the person in the “”From”” field.”
To edit directly in ECP if it’s already applied:
CAUTION: WARNING: The sender of this email could not be validated and may not match the person in the “From” field.
Has anyone figured out a way to have these banners displayed in different languages based on the clients language preferences set? Is there perhaps a mail flow rule that can be set to grab something from the charset or headers that will determine the language preference of the client and send a translated message instead of the English message?
still helping users three years on… Thank you