Want to know how much spam is costing your business? Find Out Here

Phishing is a term that describes sending email to a wide group of users, with the purpose of tricking them into clicking on a link, or revealing personal information. Spear phishing and whaling are forms of targeted email phishing attack, where a combination of social engineering and email spoofing techniques is used to steal money or confidential information from businesses – and it is becoming increasingly prevalent.

Spear phishing targets a group of people – for example, employees or customers of a specific company, or even a specific person.

Whaling is a variation of spear phishing, that specifically targets high-level executives within an organisation, with the objective of conning them into sharing confidential company information. Whaling emails are designed to masquerade as critical business email, sent from a legitimate business authority. A fraudster may, for example, identify key executives with funds transfer authorisation, and send counterfeit emails authorising funds transfers, using those executives’ details. 

The critical thing to understand about spear phishing and whaling is that it does not typically involve hacking into an organisation’s email network, or insider knowledge. Nor does it typically involve viruses, and thus cannot be prevented by email virus filters. And people are being duped, every day.

Before we discuss how to combat spear phishing, let’s look at some recent real life examples in New Zealand. Last month, the New Zealand Law Society reported two instances where a firm's email had been used to send fraudulent payment instructions.

In the first instance, during a conveyancing transaction, the law firm received monies from its client for the purpose of paying another law firm. The first firm had previously received payment instructions from the second law firm. After receiving the client monies, the first firm received an email purporting to come from the second law firm, requesting that payment be made to a bank account which was different to that previously advised. The payment was made by the first firm to what turned out to be a bank account controlled by fraudsters, resulting in loss of the money.

In the second example, another New Zealand firm was involved in an international property purchase and was given false instructions, purportedly from the client, to deposit a portion of the funds into what turned out to be a fraudster-controlled bank account. Information on the "New Zealand" bank account was attached to the email and included a false statement.

Another recent example is where the CFO at a large SMX customer was instructed by an email, supposedly from his CEO, to transfer USD$192,000 to an international bank account. The CFO was deceived by an email that looked completely legitimate, down to the sender's email address displayed in the CFO’s mail client looking 100 percent correct. The incoming email contained no malware or links to malicious sites that would trigger the multiple security filters in place. If the CFO involved in this scam hadn't had the presence of mind to query the reason for the request, which ultimately led to this scam unravelling, this company would have lost a significant amount of money.

“40 years of changing the engines in mid-flight.”

Anyone involved in email security within an organisation needs to understand the inherent weaknesses of email that go back to the dawn of the internet. Email has been around since the 1970s and while there have been multiple updates to the original standards, the general principles have remained the same. Part of the reason for incremental changes to the email standards, rather than a complete re-write, is that it's impossible to organise a complete upgrade with email providers around the world as it's deployed in a vast array of servers, operating systems, implementations and configurations. As Dave Crocker, one of the pioneers of email, and author of the seminal RFC822 from August 1982(!), puts it, "We've had 40 years of changing the engines in mid-flight."

It's because the roots of the email protocols still in use go back to the 1970s, long before the internet was commercialised and when email was used primarily by academics and researchers, that we have problems with spoofing and forgery today. Back then there was no need to prevent email forging as no-one was doing it. The same reasons apply to the torrents of spam and other email abuse that still comprises somewhere in the range of 75 percent of all email we see. Today we can filter out 99.99 percent of the spam, but targeted email fraud using increasingly sophisticated spear phishing and whaling spoofing techniques is now a major problem and, we believe, is the largest single email cybersecurity threat for New Zealand companies.

So what can be done to combat these email fraudsters?

The New Zealand Law Society has strongly advised its members to confirm emailed instructions by another means, such as direct phone contact. This is sound advice. No significant transfer of funds should ever be made without verification.

But there’s a lot more that can be done – and should be done – particularly by companies and organisations involved in high-value online transactions, or holding valuable customer data.

Here are the key measures critical to success in combating sophisticated spear phishing and whaling attacks:

Review SPF security – control who can send email from your domain

SPF, or Sender Policy Framework, is a simple email validation system that provides a mechanism for domain owners to specify in the DNS (Domain Name System – the internet-based service that translates domain names to IP addresses), which IP addresses can send email from that domain. Setting up SPF records is quite straight forward and you should specify the IP or hostname of all your MTAs (Message Transfer Agents – i.e. software that transfers email messages from one system to another). This could include third parties such as Salesforce, that might send mails to your clients on your behalf, or your cloud email security vendor.

When creating an SPF record, it is important to ensure the “hard fail” option is enabled by appending "-all" to the end of the SPF record. This will authorise security filters receiving email from non-authorised sources to drop these messages. Most cloud email security vendors, such as SMX, provide a simple "include:" statement to be inserted straight into your SPF record if using their outbound email delivery service.

SPF verification should also be carried out on your incoming email flow. Check with your IT provider or internal IT staff to confirm that this check is currently enabled.

Review your DKIM security – detect forged incoming mail

Like SPF, DKIM (Domain Keys Identified Mail) is also managed by the domain owner and allows you to essentially sign all emails with a key that proves the email came from an authorised source. The domain owner publishes a public PKI (Public Key Infrastructure) key to a specific DNS TXT record and all outgoing email is then signed with the corresponding private key ‘hashing’ the body and select headers, including their values. The resulting hash is then Base64-encoded and is inserted into the email header created for this purpose – the DKIM-Signature.

The receiving MTA then looks up the public key of the sender's domain as listed in the DKIM-Signature header and verifies that the message was signed correctly and the body and select headers haven't been modified in transit. If the resulting hash verification check fails then the email is likely forged and should be discarded.

The main difference between SPF and DKIM is that SPF works at the envelope data layer and DKIM operates at the header and message body layer.

At this point, it's worth explaining the differences between envelope and message data. In the email world we often use the analogy of the postie delivering a letter. In this analogy the postie is your mail server (MTA) and the letter is the email. In order to deliver your letter to you, the postie looks at the envelope only (hopefully!) and delivers it to the address on the envelope. When you receive the letter, you discard the envelope and read the letter inside – i.e. the email/message body.

This distinction between information the MTA parses and what the user sees in their mail client is important as it's these differences that scammers exploit to their advantage.

Other measures using SMX SmartRules®

Sophisticated email security software – such as SMX SmartRules® – allows SMX, or an organisation’s IT department, or an external IT service provider, to create and apply customised rules to both inbound and outbound email.

These rules can be created to, for example, prevent confidential information being attached or included in outgoing mail. Rules can also be created specifically to target spear phishing and whaling attacks.

For example, a rule can automatically identify the age of a domain sending incoming email. A domain registered today is more likely to be used for phishing attacks than an older, established domain. Such emails can be quarantined for closer inspection by an IT manager.

Other rules can be created to compare your normal email receiving profile against incoming email patterns and identify abnormalities.

SMX has recently developed, in conjunction with some of our larger customers, specific new rules and supporting processes to protect identified likely or known phishing targets within an organisation.

As mentioned, phishing attacks rely on a mismatch between what the phishing target sees in their mail client and what the MTAs parse. By providing SMX with a list of phishing targets and victims, along with the normal email addresses they send from, SMX's DLP (data loss prevention) engine is configured to block or quarantine any emails which have mismatches or are not on an approved list of authorised addresses.

This does require creating and maintaining a list of authorised addresses associated with each phishing target. However, once this rule is set up maintenance is only required when list members change and this can be carried out by the individual user with minimal training.

And consider the human factor

People are the weakest link in any security process. As such, SMX advises its most vulnerable customers to put in place a formal email security audit, training and awareness process. With SMX customers this normally involves SMX working with either an internal IT team or outsourced IT service provider.

Security awareness training should include:

  1. Identifying potential whaling or spear phishing targets within your organisation – these roles should include finance, management and IT security
  2. Conducting security awareness training for all identified roles – this training should include an awareness of these types of attacks and familiarisation with your organisation’s security policies
  3. Creating and publishing robust internal procedures for handling and identifying security incidents, responding to external queries requesting information on senior company executives, etc.
  4. A process for reviewing and updating the specific email security measures such as those discussed in this blog.

All companies and organisations should conduct some security awareness training for their affected staff. Ensuring robust processes are in place when, for example, transferring funds and that affected staff are aware of these procedures would be a minimum to help protect against these types of attacks. Security awareness training should also enable staff to know how to handle external requests for information relating to senior executives.

More information

If you have any concerns about a potential whaling or spear phishing attack on your business, please contact the SMX helpdesk via email, or phone 0800 769769, select option 1.