Forged Email: Detect Spoofing with Cisco Email Security

Available Languages

Download Options

Forged email is email that uses a forged sender address. It’s meant to fool the recipient about who sent the message.

Forging, or “spoofing,” email is easy to do. It can be done from within a LAN or from an external environment using Trojans. Forged email is often used in spam and phishing campaigns.

This paper focuses on the resolution of spoofs that come from outside an organization when a sender impersonates an employee. The attacker’s purpose is to deceive the employees in order to steal money or information. We will discuss four variants of this attack and propose solutions using Cisco® Email Security running AsyncOS 9.7.1.

Table of Contents

What You Will Learn................................................................................................................................................................... 1

The Problem of Forged Email.................................................................................................................................................. 3

Anatomy of a Forged Message and Its SMTP Details....................................................................................................... 4

As noted, this paper looks at forged email arriving from outside an organization. Spoofing where an internal mailbox is compromised is out of scope for this paper. In this document, alpha.com is the example customer domain being spoofed.

1. Envelope From abuse: Making the domain in the sender’s Mail From value (also referred to as "Envelope From”) the same as the recipient’s domain. This paper uses the terms “Mail From” and “Envelope From” interchangeably.

2. From header abuse: Using a legitimate domain for the sender’s Envelope From value but using a fraudulent From header.

3. Cousin domain abuse: Sending email from cousin domains that pass Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-Based Message Authentication, Reporting, and Conformance (DMARC) checks. The From value will show a similar sender address that impersonates a real one (for example, using alice@a1pha.com to impersonate alice@alpha.com).

4. Free email account abuse: Using free email (Yahoo, Gmail, etc.) that pass SPF, DKIM and DMARC checks. The From header will show a legitimate sender address with an executive’s name@gmail.com.

The four variants of attacks described above are shown in Figure 1 in the mailbox alan@alpha.com. the variants are listed in the same order described, along with a legitimate healthcare mailer. Each fraud lists an executive’s name in the From field. Figure 2 shows the details of an attack similar to the first variant in Figure 1.

Our goal at Cisco is to block any spoofs in these categories but allow legitimate mailers, like the one sending the healthcare notice, to be delivered. Legitimate mailers are also called “legitimate spoofs” in this white paper.

The structure of the message in Figure 2 is very similar to our first variant in Figure 1. Both are examples of Envelope From abuse. The Envelope From field, shown below in the Simple Mail Transfer Protocol (SMTP) connection, is illegally using the domain name alpha.com. Envelope From abuse is easily remediated with sender verification, discussed later. But the problem is that sender verification checks only the SMTP envelope portion shown in Figure 2. The harder-to-detect spoofs introduced earlier (From abuse, cousin domain abuse, and free email account abuse) all have legal SMTP envelope portions, but the body portions of the message are designed to deceive the recipient. These two portions do not have to agree. In fact there are legitimate external mailing lists in which they may not.

This white paper discusses the features of AsyncOS 9.7.1 for Cisco Email Security, an operating system designed to handle email infrastructures. AsyncOS 10.0 has a new feature, Forged Email Detection, that has a dedicated content filter and an executive name dictionary. Because the 10.0 Forged Email Detection feature addresses From abuse in the message body, it can be used instead of the content and message filters discussed here for version 9.7.1. Refer to the 10.0 Administrator Guide for specifics on that version. Aside from the Forged Email Detection feature, the discussion in this paper applies to both releases.

The default settings of Cisco Email Security will prevent broad-based attacks such as malicious files and snowshoe spam. But spoofing, like other targeted attacks, is tailored to a specific organization. For that reason, preventive tools for spoofing attacks are disabled. Their application may vary from one organization to another, and an improper application can lead to a high incidence of false positives.

The workflow in Figure 3 is a high-level view for remediating spoofing attacks on your organization. We provide details for each step. The result is a defense-in-depth approach to Forged Email Detection. Attackers will change their methods against an organization over time, so the administrator needs to monitor any change and follow up with appropriate warnings and enforcement.

Figure 3. Forged Email Defense Workflow

The elements that address best-practice settings, and filters that monitor, warn, and enforce against spoofing attacks, are shown in Figure 4. The monitor should quarantine copies of all possible spoofs, illegitimate as well as legitimate mailers, for one week, and then delete them. The administrator must update the Enforce filter, noting what it missed but what the monitor or a recipient caught. We will refer to this diagram throughout this white paper.

The decision tree in Figure 5 is structured to detect and remediate any of the four spoofs shown in Figure 1. The sender verification in decision blocks 2 and 3 is redundant to the condition “No Envelope from match on recipient domain” in blocks 5 and 6. If your filters follow this design, then use either one or the other. Dropping mail from violations at the SMTP connection assumes that you have no need to analyze the message content for a false positive. Our Monitor filter conditions in decision block 5 have a broader range of matches than the Enforce filter in block 6 due to the use of OR instead of AND logic. Your filter logic may be different from these, but you should follow the same approach: monitor liberally but enforce conservatively.

The Enforce filter is a message filter that sets an X-header before policies are applied downstream. In decision block 7, we can apply content filters within those policies. For example, a message that is tagged with a spoof X-header needs to be handled differently when the recipient is an executive rather than a standard employee.

This white paper will look at these blocks individually by demonstrating how they remediate the specific spoofs we discussed at the beginning. At the conclusion we will combine all these together in a solution described by this decision tree. Plan to make a similar decision tree for your email solution before you begin to apply your anti-spoofing polices.

Before configuring specific filters, recognize that our spoof samples are corner-case attacks on Alpha Inc. They involve multiple failures. Many spoofs are remediated by exercising best practices. As you can see from the pipeline in Figure 4, you should:

●Limit the use of white-listed domains in the Host Access Table (HAT) to a very few core business partners

●Track and update members in your SPOOF_ALLOW sender group (HAT), if you have one

●Track and update allowed senders in your SPF records, if you publish them

●Drop positively identified spam

●Enable graymail detection and flag or place instances in the spam quarantine

Note: Publishing DNS TXT records for sender authentication gives you better fraud detection than maintaining dictionaries alone. However, methods of publishing these are beyond the scope of this white paper.

Look at decision blocks 2, 3, and 4 in Figure 5. Incoming messages that fail a DNS check or do not have any SBRS scores will drop to the UNKNOWNLIST. To avoid that result for messages that spoof with Envelope From abuse, we’ve segmented off part of the UNKNOWNLIST SBRS range for a CAUTION_LIST (see Figure 6). “Include SBRS Scores of None" is included in group 4, and “Connecting Host DNS Verification” is included in group 5.

This segmentation allows you to specialize the mail-flow policies for messages that fail these checks. You may be introducing delays for some legitimate messages. Not shown here is an ALLOWED_SPOOFER list for legitimate mailers that can send messages to your organization.

Figure 6. Modified Host Access Table to Address Forged Mail

Some spoofers manually telnet the SMTP connection and accidentally break syntax rules in RFC 2821. . Strict parsing on the listener will catch some of these (see decision block 1 in Figure 5). But sophisticated attackers won’t be dissuaded.

It is not typical for a Cisco customer to encounter all the spoofing variants described in the Problem section, but many are plagued by at least one. As a case study, we will be framing our suggested solutions for this multi-variant attack on the alpha.com domain. The suggestions come from Cisco Email Security experts with real-world experience who have been working to protect customers from these attacks. These are guidelines rather than fixed antidotes for particular problems. Implement these solutions in an ongoing process of monitor, warn, and enforce.

You need to monitor all inbound spoofing traffic, legitimate and illegitimate. For that, identify the domain names that should not be values in the Envelope From or From headers and make them members of a dictionary. We’ve done this in Figure 4 with No_Spoof_Domains. Create a filter and put into a Spoofs quarantine a copy of every email where the Mail From or the From header matches a domain in the dictionary. Set a reasonable Delete on Expire policy (possibly 7 days). This practice gives you visibility into what is being spoofed.

Also consider spoofing from legitimate mailer services that are abused by illegitimate clients. Focusing on the From header, make a dictionary for executive names, called Execs. Also, list internal group names such as “IT-Support-Services” that should not be in the From header. One form of malware attack is to infect an internal client, causing it to harvest the LDAP directory for executive names and group mailing lists. All the possible violations of From and Mail From values resulting from such a query need to be considered in your Monitor filter. Copy the filter matches to quarantine and possibly notify the admin with a copied attachment (see Figure 7). Send the original message to the recipient untouched.

Figure 7. Message Filter: Monitor All Spoof

Warn

Modifying the subject header of incoming messages will break digital signatures. However, until an enforcement policy is in place, we suggest warning all employees receiving an incoming message with the subject tag [External Sender] (see Figure 8).

The day that a spoofing attack is realized, you need to begin both the warn and the monitor phases of your defense. In Figure 4 see the relative positions of these message filters in the pipeline. Once the Enforce filter is in place, you can remove the warn message filter.

Figure 8. Message Filter: Tag All Incoming Messages

Enforce

Write filters to address the particular spoofing types that you discover during the monitoring phase. Continue to monitor as a separate process and set up a separate quarantine to catch false negatives. You should monitor aggressively but enforce conservatively. Start your enforcement filters with quarantine copy as your remediation. Modify the original message’s subject with an appropriate warning before sending it to the recipient. As you gain more confidence in your enforcement filter, change to quarantining or drop the original message. Maintain your monitor quarantine to catch samples missed by enforcement and update your enforcement filter as needed.

Below are the logs from two messages in Alan’s mailbox titled “Mail From Abuse” and “Know your Benefits update from Alpha.” Note that wsa.train is an illegitimate sender, and mail.outside.com is a legitimate one.

Note: In the above logs, the From and To fields are actually “mail from“ and “rcpt to,“ respectively, in the SMTP envelope. The same is true for message tracking reports. The following proceedure using sender verification will drop mail for violations in the SMTP connection. You can also do the same with a message filter.

When using sender verification, you must know the details of any legitimate mailers so that you can add their domains to your SPOOF_ALLOW sender group. Sender verification will block all domains that use your domain in the Envelope From, including legitimate senders, if you don’t implement exceptions for them. Messages that illegitimately use your domain will be dropped at the beginning of the SMTP conversation in the listener at the HAT. See Figure 4 for this position in the pipeline.

After enabling sender verification, it is useful to track rejected connections, just in case you missed adding any legitimate mailers in your SPOOF_ALLOW sender group. Until you are certain, you may want to enable Rejected Connection Handling in message tracking (Figure 9) to track legitimate and illegitimate Envelope From spoofs, as shown in Figure 10.

Figure 9. Message Tracking

Figure 10. Rejected “Envelope From” Abuse

When you are confident that the SPOOF_ALLOW sender group is correctly populated, you should disable Rejected Connection Handling for optimum performance.

Addressing From Header Abuse

Sender verification will not stop messages where the Envelope From and From header values do not agree. The following message was delivered after sender verification was enabled. Here is a sample caught by our Monitor filter but missed by sender verification.

Figure 11. “From Header” Abuse

The challenge is the recipient may interpret “From: ‘John’ john.chambers@alpha.com” as an internal sender, and react to its call to action. For example, sensitive corporate information could be sent back to Reply-To: <john@mmkt2r2.tztk.ru>. The recipients are unaware of the actual sender’s mailbox john.chambers@wsa.train since they can’t see the Return-Path as well as the Reply-To address in the client (Outlook, for instance), unless viewing the detailed headers. Most mobile devices cannot provide this detail. Outlook hides it by default.

There are two methods to detect this From value:

1. Publish SPF records for your domain alpha.com, and enable SPF and System Independent Data Format (SIDF) verification in your default mail flow policy. Set the conformance level to SIDF Compatible and write either a message filter or a content filter that detects SPF failures stamped into the header. (See Figure 12.)

2. Create a dictionary that accounts for executives. In this case, one entry will be John Chambers. For every executive name, the dictionary needs to include the username and all possible surnames as terms. When the Executive Name dictionary is complete, use a content filter or message filter to match on the From header value for incoming messages. Your dictionary needs to be part of the Monitor filter to catch false postives from external mail expanders. Be sure to run the system for trial periods before quarantining matches.

Recommended remediation: Create a filter that inspects SPF failures or matches on an Executive Name dictionary and removes the From header in the body of the message. From header removal will cause the Envelope From value to automatically be written into the From field. This makes the actual sender’s address viewable in the message inbox. Save the original From value in the X-header to support your action (shown on the next example).

Here is the same message that we showed before, but this time it was processed by our filter. The first two conditions were satisfied, and both the From and Reply-To fields were removed. The recipient can now see the real sender address. That will also be the address that the recipient replies to.

Figure 12. Sample of From Header Abuse Remediated with SPF

Important: Preventing the abuse of a corporate domain name using sender verification and dictionaries can be accomplished with SPF records with significantly less effort (outside of the effort to implement SPF in the first place)! If your records are published, and you specify allowed senders, you can:

●Detect Envelope From abuse

●Detect From header abuse

●Allow legitimate senders

Instead of an SPF check, we could have used an Executive Name dictionary, provided that one of its records was the name john.chambers. This is a good alternative if you don’t wish to publish DNS records. If you have a list of legitimate senders, which many enterprises do, then you need to keep the domains updated in your SPF records if you’re using that method, or you need to address those updates in your SPOOF_ALLOW sender group if you are using sender verification, discussed earlier.

If you are not implementing SPF, you can define an Executive Name dictionary as shown in Figure 14.

In the filter below, SPF condition is replaced by a dictionary match on the From field to get the same results, which was our second method discussed earlier.

Note: You can exhaustively list all the variations of executive names and their surnames. Or you can create regular expressions inside of the dictionary. Suggestions regarding regex syntax are beyond the scope of this white paper.

Figure 15 shows the sample “friendly From Abuse” that is run with and without applying the filter in Figure 14. The second message in Alan’s inbox is the unfiltered message. It’s From value is “John Chambers.” In the first message, the From value is stripped out and replaced with the Envelope from value john.chambers@wsa.train, and the subject is prepended with [Possible Spoof]. The original From value is recorded in the header X-Original-From.

Cousin domain names are visually similar to the victim’s domain name; aipha.com looks like alpha.com. But since they are different, they can be uniquely verified with DKIM and SPF. They will not get blocked by sender verification. And because their Envelope From and From header values agree, they’ll pass strict DMARC verification. The message in Figure 16 passed the Enforce filter that we created for the From header abuse, but it would have been caught by the Monitor filter, provided that a cousin’s dictionary was applied.

Figure 15. Sample of Cousin Domain Abuse

Recommended Remediation: Create a Filter that matches on an Executive Name dictionary AND a dictionary of cousin domains. You can create a dictionary of cousin domains based on your own domain by going to: https://github.com/elceef/dnstwist and applying their Python algorithm. The algorithm will create variants of a domain and then do a DNS lookup to verify that the cousin domain is registered.

Figure 16. Content Filter: Remediate Cousin Domain Abuse

Note: Some of these filter samples use the header X-Phony-From in place of the header X-Original-From. Their usage is identical.

The following is the matched content from both Executive Name and Cousin dictionaries. We chose to not apply the rule to remove the friendly From header since it will be replaced with the same field. Instead we modified the subject header and quarantined the message. The quarantine menu in Figure 18 shows the matching conditions.

Messages from Gmail can be structured so that the sender’s email address is not shown in the inbox. When you open the message in any email client, you can see more sender information. But the sender’s address isn’t visually available on a mobile device, even when the message is open. Similarly on a mobile device, clicking Reply will not populate the To field with chuck.robbins@gmail.com. Instead it will be “Chuck Robbins” or “Chuck.” In that case, the recipient won’t know that this is an external email. The message will also pass all of the sender authentication checks, as highlighted here.

Figure 18. Sample of Free Email Abuse

For this case, matching on domain names in the From field is ineffective. Free mail spoofs could have the following structures:

All these are rare for incoming business mail. Many admins will warn executives not to send unicast inbound from their free email account. In the following content filter, we match on the first condition above, copy the From information to a new header X-Original-From, strip the friendly From header, and quarantine the message. Alternatively, we could send a duplicate message to quarantine and send the modified message to the executive. Figure 21 shows a sample free mail spoof after it was processed by the content filter in Figure 20.

Similar to the other filters, in Figure 20, Content Filter Remediation of Free Email Account Abuse, the X-Original-From header receives the value of the original From before the value of From is stripped out. This is useful when the recipient requests a reason for why the message was acted upon. You could also use X-Original-From to address false positives.

You can also create a filter that matches the From value being an executive name destined to multiple recipients. But for counting multiple recipients you need to use a message filter shown in Figure 22. The rcpt-count depends on the organization. Either of the filters in Figures 20 or 22 will result in the modified message in Figure 21.

Figure 21. Message Filter Remediation of Free Email Account Abuse

Comprehensive Configuration to Address All Listed Spoofing Types

The following filters represent all the concepts presented in this paper. We’ve tested the scripts that were presented earlier against this configuration and obtained the same results as the individual filters. Like the earlier material, this is presented only as a suggestion for your environment. We have set the conditions for a positive spoof of Envelope From abuse, From header abuse, cousin domain abuse, or free mail abuse in the message filter block and then remediate the matches with content filters.

There are different mail policies for executive and nonexecutive recipients, as shown below. Spoofs to executives have their headers modified and are “quarantine copied” to a policy quarantine. Any spoofs to nonexecutives have their headers modified and are sent to the spam quarantine. As you become more confident of your filter efficacy, you can change the quarantine copied to quarantine.

In the structure for the message filter Positive_Spoof, the operations performed by:

“if sendergroup != "SPOOF_ALLOW" { “ and

“ header-dictionary-match("No_Spoof_Domains","From", 1) “

can be replicated by publishing SPF, DKIM, and DMARC records that indicate who can send on your behalf. The DMARC check and remediation can be done in the HAT, or you can remediate spoofs in a message filter with an SIDF condition. The added value of this approach is that the DNS text records will limit both Mail From and From abuse of the corporate domains. Message filters can then address what is left: executive names, internal group lists, and cousin domains.

Note: Publishing DMARC, DKIM, and SPF records, and enabling verification of the these in the Cisco Email Security solution, is beyond the scope of this white paper. For that please refer to the following:

Not shown ahead of the message filters (Positive_Spoof and Free_Mail_Spoof) are the message filters (Quarantine_Spoof_copy and Tag_Incoming_Mail). We should remove Tag_Incoming_Mail because that is done by the Enforce filters. But we should keep the Quarantine_Spoof_copy. If it catches a spoof that Positive_Spoof and Free_Mail_Spoof did not, then we need to adjust accordingly.

We understand the challenge of remediating email attacks such as the spoofing campaigns discussed here. If you are having challenges with implementing these techniques, please contact Cisco Support and open a case. Or reach out to your Cisco account team.