In April we covered the description of Email Spoofing using Microsoft Outlook, but what about detecting and mitigating it on the Mail Transfer Agent (MTA)? There are multiple technologies that have attempted to address the issues surrounding spoofed emails on the MTA, but they all have shortcomings that can limit their usefulness.
DKIM, or Domain Keys Identified Mail, allows recipient mail systems to retrieve a cryptographic key from the sender’s DNS and perform calculations on the headers of the message to determine if the message came from that sender. This only works if the sender uses DKIM on outgoing mail and publishes the key for the recipient to verify the calculations. It also has limitations when dealing with third party senders that send email with spoofed ‘From’ addresses.
SPF, or Sender Policy Framework, lets senders list all of the systems that send email on behalf of the company. It’s easy to do, but can be problematic again with third party senders and with automated systems that send email directly outbound instead of through the MTA. Additionally SPF has limits on the amount of data that can be in the DNS text file, including limits on recursion, and both DKIM and SPF require the recipient to make a decision on what to do with a message that fails checks.
DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is a step in making DKIM and SPF easier to use by allowing the sender to publish a DNS text record that tells the recipient what they should do with a message that fails checks. While helpful, this does not address problems of DMARC compliant email senders such as webmail systems that allow the ‘Friendly From’ address to be specified by the sender. These systems can be abused in that the envelope sender passes the DMARC checks, but the ‘Friendly From’ address that is spoofed is the one that Microsoft Outlook displays to the recipient. This behavior is allowed by SMTP in that there is no enforcement on the envelope sender and the ‘Friendly From’ address being the same and it’s not a good idea to force that behavior since it would cause problems; for example, breaking third party marketing campaigns.
In Cisco Email Security AsyncOS 10.0 release, a new feature was introduced to make detecting and handling these spoofed messages easier with Forged Email Detection. In previous versions a combination of Message Filters, various Content Filters, and dictionaries could be created and used to detect and mitigate these messages. But with the 10.0 release, much of the workflow has been consolidated into a Content Filter Condition using an administrator-created dictionary Text Resource to match against containing common terms for the organization. It scores the email based on matches to the “Friendly From” field in the message and for Cisco, the terms would include: CEO, CFO, CIO, CISO, Chuck, Robbins, crobbins, chuck.robbins, and more. This would allow for matching on messages that purport to come from high-value senders in the company enabling customers to combat email spoofing and Business Email Compromise more effectively.
To learn more about other features included in our latest AsyncOS 10.0 release, you can watch this video. To learn more about Cisco Email Security, visit cisco.com/go/emailsecurity.
What’s up with the forged email detection feature ?
Adding names of the “important” persons in your company makes no sense – ask your customers to add DMARC records and give us the the ability to test DMARC result on a content filter.