Phishing emails are a popular malware delivery vehicle for attack. While there are many ways for an attacker to increase the chances of success for their phishing emails, one of the most effective methods involves spoofing the message to appear to come from a trusted source. Ready to learn more?
*This article by Marc Laliberte was originally published in the October edition of Cyber Defense Magazine.
Phishing emails are a popular malware delivery vehicle for attackers. In fact, according to Verizon’s 2017 Data Breach Investigations Report, two-thirds of all malware in 2016 was installed via email attachments. Often the most difficult part in crafting a phishing email is designing it in such a way that the victim will believe it and follow the instructions.
While there are many ways for an attacker to increase the chances of success for their phishing emails, one of the most effective methods involves spoofing the message to appear to come from a trusted source. Before we can dive in to how the attackers spoof the sender and how to protect against it, we first need to go over some email message basics.
The format and process for most email messages is actually very similar to a traditional snail mail message. An email message includes an envelope with routing address information, and a message letter that sits inside the envelope. The envelope address headers are just like what you would expect to see in a traditional mail envelope. There is a header for the sender, called MAIL FROM, and a header for the recipient, called RCPT TO. In the case of a CC or BCC recipient, the sending mail server simply adds more RCPT TO headers to send digital copies of the message to the other recipients. Email servers use these envelope headers when deciding where to route a message and where to send delivery failure messages if any issues are encountered along the way.
Inside the message envelope sits the email message itself. The message also uses several headers, including separate headers for the sender (FROM header), recipient (TO header), a header for the message subject (Subject header), and a timestamp for the message (Date header), among others. Your email client uses these message headers, not the envelope headers, when displaying details like the sender, recipients, and subject of a message.
Most email clients trust these message headers as-is. This means an attacker can spoof a message’s FROM header to be any address they want, whether it be your company’s CEO, your best friend, or your bank. By spoofing the sender address in their phishing emails, attackers make the context of their message more convincing, increasing the chances that the victim will fall for it. In fact, nearly all malicious e-mail messages use a spoofed sender address. Luckily, there are technologies and standards available to protect yourself and your users from sender address forgery.
Sender Policy Framework (SPF) is an open standard developed by the Internet Engineering Task Force (IETF), designed to combat sender address forgery in envelope MAIL FROM headers. SPF enables organizations to specify what servers are allowed to send emails with an envelope MAIL FROM address in their domain by using DNS records. Recipient mail servers can then use these special DNS records to confirm that a message from any given domain truly came from that domain.
To implement SPF in the simplest way, domain administrators must create a DNS TXT record in their domain that specifies which IP addresses or hostnames are allowed to send mail for that domain. An example SPF record for the domain “example.com” might be “v=spf1 ip4:18.104.22.168 A:mail.example.com” which means the IP address 22.214.171.124 and the server located at mail.example.com are allowed to send email for the domain.
When a recipient mail server with SPF record validation enabled receives a message, it uses a DNS query to check the SPF records for the sender’s domain. If an SPF record is found, the mail server will compare the allowed source addresses with the address of the actual server which sent the email. The admin in charge of the recipient mail server is given control over what to do when a message fails SPF checking. They can configure the mail server to drop the email entirely, or they can configure it to tag the message as possibly spam, but accept it anyway.
A major drawback of SPF is that it only cares about the envelope MAIL FROM header, it doesn’t check the message FROM header contained in the email itself. Because email clients typically use the message FROM header to display the sender of an email, an attacker can still spoof this header while providing valid address for the envelope header.
Another technology available to combat spoofing is DomainKeys Identified Mail (DKIM). DKIM is the combination of Enhanced DomainKeys from Yahoo and Identified Internet Mail from Cisco. In a nutshell, DKIM uses cryptographic digital signatures to authenticate email messages, allowing recipient mail servers to verify the authenticity of the message sender and even the message contents. DKIM is similar to SPF in that it uses DNS TXT records to house important information, in this case RSA public keys for digital signature verification.
DKIM works by first naming a few important parts of the message to protect, usually including the FROM and TO headers, the subject header, the date header, and even the message body itself. The sending mail server then computes a cryptographic hash of the chosen sections and then encrypts it using a private key, creating a digital signature. The digital signature and a few informational fields are added back to the message as a special DKIM-Signature message header before he message is sent. Because the corresponding public key is published in a DNS TXT record for the sending domain, recipient mail servers can decrypt the hash and verify it, confirming the protected fields were not spoofed or modified in message transit.
DKIM unfortunately has its own limitations. While header fields protected by a DKIM signature can be confirmed as valid, a message without any DKIM signature at all causes problems. The DKIM standard does not provide a mechanism to confirm if a message should have a DKIM header when no header is present. This means, without other protections in place, an attacker can simple omit a DKIM header from their phishing email to bypass DKIM protections.
Back in 2011, a group of organizations including AOL, Comcast, Google, and Yahoo, among others, came together to create an even more comprehensive technology standard to address email spoofing called Domain-based Message Authentication, Reporting and Conformance or “DMARC” for short. Within its first year, 60% of internet mailboxes used DMARC verification for anti-spam and anti-phishing.
DMARC allows a message sender’s domain to advertise if their messages should be protected by SPF and/or DKIM, and provides instructions to recipient mail servers for what to do if a message fails these checks. Along with the normal SPF and DKIM checks, DMARC also checks if the envelope MAIL FROM header matches the message’s FROM header.
DMARC assumes that the domain administrator has already configured DKIM and SPF for their sending domain. DMARC then uses a DNS TXT record, just like SPF and DKIM, to verify important information for the sending domain. The DMARC DNS record includes a policy for the recipient mail server to apply when DKIM and/or SPF records fail, such as rejecting the message, quarantining it, or allowing it through, and an email address to send reports to for non-compliant messages.
DMARC fills in the gaps left over from SPF and DKIM, providing additional anti-spoofing protections and directions for recipient mail servers on how to handle potentially spoofed messages. A recent report by ValiMail and the Global Cyber Alliance found 76% of email inboxes now support DMARC verification. Unfortunately, according to a recent report by Return Path, DMARC implementation is still very low in most verticals, ranging from 16% (Healthcare) at worst to 61% (Payment Services) at best.
To find out why these anti-phishing standards aren’t more widely used and what might be done to increase their adoption, check back for Part II next month.