Fish are beautiful. Phish makes good music. Phishing, however, is a completely different story. So when you get that urgent email from your company's CEO, asking for an immediate wire transfer, think twice.
Maybe you have seen similar emails come through, usually requesting a transfer of money, hopefully to end up in your spam folder. Maybe you are an IT admin and encountered a situation where your users received such emails. In any case, targeted phishing attacks, commonly referred to as “spear phishing,” seem to be on the rise. All of this is made possible by spammers and scammers sending spoofed emails to your users.
Today, information on a company’s structure is readily available online on places like LinkedIn or Facebook, or even your own company’s website. With an increase in the amount of information available on any particular employee in your company, it becomes fairly easy to know who to target. When combined with an email spoofing attack, a situation like this can easily fool the average user. We have seen with several clients now that the users in charge of their financials had received emails from somebody claiming to be the CEO, even using his or her signature. The phisher sends a request to make a money transfer, usually saying it is urgent so that the user will act on it hopefully without confirming.
How is this possible?
The sender of an email reports their own name and email address in the From header of the email. They can therefore put any name or email address they want the recipient to see. Most decent spam filters will catch this however since there are actually two fields in an email header that says where an email is from. There is the envelope sender (think of it like the return address on snail mail) and the message sender (think of it like the signature line on the letter inside the envelope). The envelope sender usually can not be spoofed if you have an SPF record in place as part of it is the sending server. This is where a discrepancy would arise between the external server sending the email and the message sender claiming to be from internal to the company.
The most sophisticated attack we have seen however came from a phisher who had purchased a domain name similar enough but only 1 letter off from the domain being attacked. In this way the only thing the phisher had to spoof was the name of the CEO, but left the domain name of the email address as the fake one. This would not throw up any red flags to a spam filter because the email envelope sender is an external domain, and the From label matches that external domain. To a computer, these are two unique domains, but not to a human just giving a glance at the email address. Because the name matches and the email signature matches, only a very close look revealed that these were in fact not the real sender.
What you can do to prevent this
Email is not meant to be the most secure form of communication over the internet. The inherent risk is that anyone can send an email and put whatever information they want in it, and the burden of proof is on the recipient to determine if it is real or fake, usually using tools provided by the sender in the email itself or by using their domain’s DNS records. There are, however, some simple steps you can take to prevent attacks such as those above:
Publish an SPF record for your domain in your DNS. This is the most basic form of protection against spammers and spoofers from using your domain. The Sender Policy Framework allows you to tell email recipients which servers they should accept emails from your domain for. It is a publicly accessible record that essentially says that if a sending server is not on your list of approved mail servers there is a high chance of the email being fake. That said, this still places the burden of determining whether an email is real or fake onto the recipient.
Sign your email with DKIM. This is another publicly available record in your DNS that contains a public encryption key. DomainKeys Identified Mail provides a way for a recipient to verify that the email in question really did originate from one of your mail servers. Your email server signs legitimate email headers with the private encryption key, which the recipient can then decode with the public key. Only an email signed with the proper secret private key will be able to be authenticated when decrypted with your public key, preventing unauthorized emails from being sent or legitimate emails being modified during transport.
Create a DMARC policy for your domain. Domain-based Message Authentication, Reporting and Conformance utilizes the SPF record and the DKIM record to fully prevent spoofing. Most modern email recipients support decoding DMARC records. This form of protection is used by some of the world’s largest banks and financial entities to prevent people from receiving a fake email claiming to be from them.
All of the above protections of course come at the expense of convenience and also require that your company have both an email server or service that supports using these protections, as well as having control over all possible systems that need to legitimately send emails as if they were from a user in your domain. Some of these are also dependent on your domain registrar supporting the proper record types or characters needed for these records to function correctly.
Thankfully both Google Apps and Microsoft Office 365 support SPF, DKIM, and DMARC as both senders and recipients. If you need assistance setting up any security measures, or just want to consult on what the best methods for your use case is, contact Cloudbakers today.Originally published on February 29, 2016