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.
The table below summarizes the best practices we will review in this article.
| Best practice | Benefit |
|---|---|
|
Deploy SPF, DKIM, and DMARC. |
These email security protocols make it easy for email security tools to detect and block emails with spoofed senders before they reach the employee. |
| Leverage an AI/ML-based solution. | Detects creative and unseen phishing emails using trained AI/ML models. |
| Invest in an anti-phishing platform. | Detects newly-registered typosquatting domains that might make the sender credible. |
| Activate AV, EDR, and sandbox solutions. | Helps detect and block emails with malicious content. |
| Implement the 4-eyes principle. | Eliminates the risk of a single employee authorizing a large transaction. |
| Enforce multi-factor authentication (MFA). | Reduces the risk of credential attacks leading to an account takeover. |
| Security awareness and phishing training for employees. | Reduces the risk of employees falling victim to whaling by educating them on whaling attacks and how to recognize them. |
| Conduct phishing simulations. | Measure the effectiveness of your user awareness training. |
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.
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:
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:
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.
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.
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.
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.
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..
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.
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.
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.
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.
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.