Spear Phishing, Conclusion

In this concluding post on the topic of Spear Phishing (read the first one here), allow me to share something which happened to one of our clients last week.

The sender “appeared” to be the CEO; but that was only the “From:”.  The actual sender in the envelope was mirza.shafgat@bingutab.com – a fake sender.  The originating IP address was 97.74.135.162; this IP is in Scottsdale, AZ, and corresponds to DNS name p3plsmtp09-01-2.prod.phx3.secureserver.net.  The server connected to our device with a EHLO message of p3plwbeout09-01.prod.phx3.secureserver.net.

Our client’s domain is none of this.  However, the From: and To: fields appeared to be both from someone @ our client’s domain.

The first reaction one could have would be to apply SPF control.  However, SPF is applied to the envelope, not to the body headers.  The envelope shows bingutab.com as the sending domain, and secureserver.net as the EHLO domain.  Upon checking the SPF record of the server, we note that the sending IP is included.  So SPF did not fail.  The email, on the surface, looked legitimate.  Besides, SPF isn’t mandatory.  In this case, the server had one and it matched.  In many other cases we’ve seen, there simply wasn’t an SPF record to match.  We cannot discard emails only based on that fact, because SPF isn’t required.  If it exists, it must be respected; but since it isn’t a requirement, if a domain has no SPF record, we still need to accept emails from that domain.

In case it isn’t clear, there’s a specific reason why the envelope sender doesn’t match the apparent sender (From:).  Your domain _could_ have an SPF record; in which case, it’d be extremely easy for us to catch that email as a spoof, because it’d be originating from an IP address that isn’t authorized.  And if, by any chance, it did originate from an IP that you’ve authorized in your SPF record, then you’ve a much larger problem because one of your servers has been compromised ☺

So, how do you block such emails?  Actually the answer is simpler than I’ve made it look so far.  We can easily create a rule that says “if the header:from is from someone at my domain, the recipient is to someone at my domain, but the sender is not, block that email”.

However, we cannot apply such a sweeping rule without thorough consideration.  You may have hired a marketing firm to send emails on your behalf, including emails to your own employees/colleagues, and generally, they make it a habit of using a From: that makes them appear as though they’re coming from your company.  For example, I’ve seen emails from evite.com doing just this.  You set up an invitation for your entire company, specify your own email address, and  click GO.  They’ll generate an email to everyone on your list (your colleagues), the header:From will contain _your_ email address; but the envelope sender will be something random @evite.com.

To avoid catching such legitimate emails in the sweeping net of the rule above, we create a list of email addresses and domains that _you_ want to authorize to send such ‘spoof looking’ emails.  So, say I were to do this for our company, the rule would look something like this:-

deny header:from endswith @networkboxusa.com recipient endswith @networkboxusa.com sender notinacl authorized-spooffers.

I know, it sounds/looks/reads strange.  But it’s a very effective way to solve the issue of spear phishing that’s currently plaguing many companies.  And the only input we need from you is that list of domains or companies you want to allow in the rule above.

Makes sense?

Has your company experienced Spear Phishing?

Or any other form of spam?