Whaling Attack

How to Protect Against Whaling Attacks

A whaling attack is a sophisticated form of spear phishing that targets the top-level management of a company. The attacker researches the victims, press releases, and their activity on social media. Then, they use that information to craft targeted, well-prepared emails, pretending to be a VIP or known sender that the victim trusts. The most common goal of whaling is to trigger a financial transaction or extract sensitive/secret information from the victim. 

The 2015 Ubiquiti Networks whaling attack is a textbook example of the dangers of whaling attacks. In the Ubiquiti case, the attacker impersonated the CEO of a company and sent an email to a key employee in the financial department who could authorize transactions. The attacker requested an urgent trade, and the employee authorized it. As a result, Ubiquiti Network lost $47 million USD.

In a whaling attack, the attacker puts significant effort, time, and resources into creating legitimate-looking emails with meaningful information. As a result, it’s difficult to distinguish a fake email from a legitimate one. This article will explain anti-whaling attack best practices in detail and explore five common mistakes you should avoid.

Summary of key anti-whaling attack best practices

The table below summarizes the best practices we will review in this article.

Anti-whaling attack best practices

There’s no silver bullet for preventing whaling attacks. In the sections below, we’ll describe best practices to help organizations take a multifaceted approach to prevent and mitigate this cybersecurity threat. 

Deploy SPF, DKIM, and DMARC

Sender Policy Framework (SPF) is an email authentication protocol that verifies that the sender’s IP is authorized to send emails using the domain name in the sender’s email address. SPF requires the domain owner to create a DNS TXT record listing the IP address ranges and additional domains allowed to send emails on behalf of their domain.  For example, below is an example of the DNS TXT record for the ironscales.com (using the Linux command line):

nslookup -type=txt ironscales.com | grep spf
  ironscales.com   text = "v=spf1 ip4:52.25.139.218 ip4:52.24.201.102 ip4:52.59.6.156 ip4:3.122.200.234
  include:spf.protection.outlook.com include:spf.mandrillapp.com
  include:mktomail.com include:stspg-customer.com
 include:20641927.spf10.hubspotemail.net -all"

The recipient mail server compares the sender’s IP against all the IPs in the DNS record to verify the email's legitimacy. If the verification fails, the mail server can discard forged emails before reaching the victim. 

Simplified SPF Verification Process

Domain Keys Identified Mail (DKIM)  is a popular email authentication protocol. DKIM allows the sender to digitally sign an email with a private key and place the DKIM signature in the email headers. For the recipient to verify the digital signature, the domain owner needs to create a DNS TXT record with the public key in it. 

Since public-private keys come as a pair, the signature verification will only be successful if the email is signed with the private key of the sender domain and verified with its public counterpart. Unless an attacker steals the private key of the domain they want to impersonate, they cannot create valid signatures that can be verified with the public key of that domain. For example, imagine a scenario where you use a third-party email service provider to sign emails on behalf of your domain. You may not have control of the private key, and a breach on this service provider will expose your private key, which you can then use to impersonate your domain. 

A  DKIM - DNS TXT record for an example domain.

While SPF and DKIM help improve email security, how can a recipient mail server infer the sender's SPF or DKIM verification domain? There are two email headers in an email that specify this:

1. ”Mail From” header (or Return-Path from the recipient’s perspective): this is the actual sender email address that the recipient mail server sees when the sender tries to connect to it. This header usually is not visible to the recipient of the email.
   
   
2. “From” header: this is the sender’s email address that the email client application will show to the recipient. 

Consider the following example:

Mail From: bad@attacker.com

From: CEO - Bob <ceo@bank.com>

The email client, e.g., Outlook, will only show “ceo@bank.com” to the recipient. The verification would succeed if the attacker created an SPF/DKIM record for their attacker.com domain since they control this domain and its DNS records. However, they can still deceive the recipient since the “From” header appears legitimate.

You can mitigate this risk with Domain-based Message Authentication, Reporting, and Conformance (DMARC). DMARC was designed to work alongside SPF and DKIM and will perform, among others, these checks:

1. Check that SPF or DKIM verification succeeded.
2. Check if the “Mail From” header is the same as the “From” header.

If any conditions fail, the recipient will use the DMARC (DNS TXT record) to report the “violation” to the impersonated domain. Furthermore, your company can discard emails that fail DMARC verification, which prevents the malicious “Mail From” and “From” headers technique.

Leverage an AI/ML solution

While cybersecurity professionals try to keep up with current phishing trends, attackers get creative to stay a step ahead. Phishing emails often come in waves, making it hard to analyze each malicious email manually. This makes Artificial Intelligence (AI) and Machine Learning (ML) models even more attractive since, after being trained with actual normal and phishing emails in your company, AI/ML will help detect and block such emails automatically. 

These tools can also act as a virtual security analyst that automatically performs incident response steps for identified malicious emails. This helps reduce your security analysts' workload and the risk of human error.

Invest in an anti-phishing service platform

Since the widespread adoption of SPF, DKIM and DMARC, attackers have shifted to newer strategies. For example, some attackers will register a new domain, “appIe.com,” to impersonate Apple. The attacker used the uppercase “i” instead of the lowercase letter “l,” making it impossible to detect unless one converts “appIe.com” into uppercase. Alternatively, an attacker could try registering a domain using any TLD domain, e.g., “example.net,” to impersonate the legitimate “example.com.”

To make these attacks even more challenging to detect visually, attackers often replace characters in a domain with visually similar characters from another language. Example: the English letter "a" (U+0061) can be replaced with the Cyrillic letter "а" (U+0430). Both are visually identical. This kind of attack is called an IDN homograph attack.

To prevent attacks like this, you may consider investing in an anti-phishing platform, allowing your company to be notified before the domain is abused for whaling/phishing or to damage your company’s reputation.

Deploy AV, EDR, and sandbox solutions

Although not very common, the attacker can send an email containing a malicious link or attachment during a whaling attack. The goal is to install trojan malware, a keylogger, or a malware stealer that can record the screen or what the victim is typing, thus leaking sensitive information. 

Therefore, it is a best practice to “arm” your email gateways, email servers, and employee computers with security tools such as antivirus (AV), endpoint detection and response (EDR), or sandboxes that scan email content. One AV might not detect all malware, and using multiple AVs can increase your chances of detecting a threat. 

Implement the four-eyes principle 

The most common type of whaling aims to trigger a financial transaction by impersonating a top executive and contacting a key finance staff member. The four-eye principle is a policy that requires at least two people are required to approve a significant financial transaction, regardless of who requested it or how “urgent” the email sounds. In this example, someone who is able to write a check is not authorized to sign checks, and the person who is authorized to sign checks is not authorized to write checks. Requiring two people to inititiate and authorize financial transactions reduces the risk of a whaling attack succeeding..

Enforce multi-factor authentication (MFA)

While credentials stealing is more “phishing-like” than whaling, it is also possible that an attacker might try to steal credentials and abuse them to log into a CEO’s account and view, modify, or steal sensitive documents. Such an account takeover can also enable the attacker to execute additional phishing attacks that target colleagues, vendors, and business partners. Strong passwords are essential, but they are simply not enough. As more and more applications provide MFA, organizations should implement it where possible. This way, even if a privileged account’s credentials are stolen, they cannot be abused without first bypassing MFA.  

There are different mediums of communications that can be used to ensure MFA such as SMS, email, phone call, authenticator apps, etc. While each medium has its own advantages and disadvantages, all these traditional methods can be circumvented if the attacker uses a phishing kit such as Evilginx that simulates the MFA process. To prevent this, Fast Identity Online 2 (FIDO2) was introduced. FIDO2 uses a cryptographic key pair that is securely stored on the user’s device, making it difficult for hackers to steal the keys. On user log-in, the FIDO2-enabled server sends a challenge to the user's device. This device uses the private key to sign the challenge and return it to the service. The server uses the public key to verify the response and ensures that it came from the registered device and has not been tampered with. This will not work if the connection is done to the attacker’s phishing site since the public-private key pair is generated with the legitimate FIDO-enabled website, not the attacker’s site.

Regularly Conduct phishing simulations

While we covered different best practices to defend against whaling, your company should periodically evaluate its resiliency against whaling and phishing by regularly conducting phishing simulations. These simulations help test defenses, filters, security tools, and the effectiveness of user awareness training. 

Security and phishing training for employees

Human behavior is the weakest link in an organization's defense against whaling attacks and phishing. And since no single security technology or stack can stop 100% of all email attacks, it is essential to establish security awareness training (SAT) to ensure all employees learn about whaling attacks and how to recognize and report them.  Like phishing simulation testing, SAT should be conducted regularly and randomly to keep employees updated with the latest whaling or phishing techniques and refresh their memory. 

It is also vital to empower the employees and explain their essential role in defending the company. Doing so motivates them as they feel involved in protecting their company as an extension of the security team.

Five whaling attack mistakes to avoid

While the best practices we covered above might sound simple in theory, there are some common pitfalls worth considering. Here are five whaling attack mistakes you should avoid. 

1. 1. Not testing employees’ anti-whaling knowledge. Users might scroll or swipe without reading the content if you only provide a PDF document or some PowerPoint slides during user awareness sessions. You can ensure the user goes through the training material by providing simple quizzes during the session or a simple test at the end.
   2. Not explaining “simple” email security concepts in training sessions. What’s simple to a cybersecurity professional isn’t intuitive to everyone. Make sure your security awareness training content is intuitive, brief, and easy to remember. Not all employees are security-aware and might not understand concepts like “Mail From” or “From” email headers.
   3. Misconfiguring email security protocols. Test and debug SPF/DKIM/DMARC implementations and ensure no critical business email is blocked due to a misconfigured SPF, DKIM, or DMARC. Don’t forget to check third party services like marketing automation, CRM, and survey tools (such as Salesforce, HubSpot, SurveyMonkey) that can send email using your domain.
   4. Poorly configuring regular expressions. Be careful with regular expressions or content filters for specific keywords. Ensure you only check for specific terms and do not use “lax” regular expressions that might match more than the sensitive keywords, thus blocking other legitimate emails.
   5. Chastizing employees who fail phishing simulations. Do not punish or embarass employees that fail whaling/phishing simulations. Work with them one-on-one and explain what they did wrong and how they can improve. Otherwise, employees won’t be willing to report their mistakes.
   6. Discouraging communication. Advocate for a security-conscious culture and the practice of "over-communicating" if something seems off or fishy. There is never harm in seeking confirmation.
   7. Security culture. Your security team should constantly seek to stay up to date with cutting edge security practices, software versions, and attack vectors.

Summary

Whaling attacks are highly targeted, difficult to detect email security threats. By implementing the right mix of security configurations, platforms, and training, organizations can reduce the risk they fall victim to a whaling attack. Regarding effective mitigation, the key takeaway is that no single best practice alone is enough. Mitigating the risk of a whaling attack requires a mix of technical controls and user education.