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.
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 “firstname.lastname@example.org” and the P2 (which the user sees) is “email@example.com”, it really is asking a lot of users to catch this.
Microsoft Fights Back
We take you through 10 best practices, considerations, and suggestions that can enrich your Microsoft Teams deployment and ensure both end-user adoption and engagement.
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:
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."
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.