Email spoofing is the forgery of an email header so that the message appears to have originated from someone or somewhere other than the actual source. Email spoofing is a tactic used in phishing and spam campaigns because people are more likely to open an email when they think it has been sent by a legitimate source. The goal of email spoofing is to get recipients to open, and possibly even respond to, a solicitation.
Although most spoofed email falls into the nuisance category and requires little action other than deletion, the more malicious varieties can cause serious problems and pose security risks. For example, a spoofed email may purport to be from a well-known shopping website, asking the recipient to provide sensitive data such as a password or credit card number. Or the spoofed email may ask the recipient to click on a link that installs malware on the recipient’s computing device.
One type of spear phishing used in business email compromises, involves spoofing emails from the CEO or CFO of a company who works with suppliers in foreign countries, requesting that wire transfers to the supplier be sent to a different payment location.
Email spoofing is possible because the Simple Mail Transfer Protocol (SMTP) does not provide a mechanism for address authentication. Although email address authentication protocols and mechanisms have been specified to battle email spoofing, adoption of those mechanisms has been slow. The SMTP AUTH extension specified in RFC 4954, “SMTP Service Extension for Authentication”, defines a way for an SMTP client to negotiate an authentication mechanism with an SMTP server to authenticate the client and, if desired, to set up additional security on the client-server session.
Some other proposed solutions to authenticating email senders include Sender Policy Framework (SPF), a protocol defined in RFC 7208 to allow domain managers to authorize individual hosts to use a domain in email; Domain-based Message Authentication, Reporting and Conformance, defined as an email authentication protocol in RFC 7489; and DomainKeys Identified Mail, which provides a way to validate a domain name identity associated with a message. Sender ID, described in RFC 4407, is an experimental protocol based largely on SPF and promoted by Microsoft, but failed to gain any significant deployment.
To prevent becoming a victim of email spoofing, the FBI and the Federal Trade Commission urge recipients to keep antimalware software up to date, be wary of tactics used in social engineering and contact the sender directly when sharing private or financial information instead of responding through an email.
Since the email protocol SMTP (Simple Mail Transfer Protocol) lacks authentication it used to be extremely easy to spoof a sender address. As a result, most email providers have become experts at intercepting spam before it hits your inbox. But wouldn’t it be much better if they were able to stop it from being sent in the first place? Well, there have been a few attempts to enforce rules that could accomplish this:
SPF (Sender Policy Framework): this checks whether a certain IP is authorized to send mail from a given domain. This method uses records that tell receiving mail servers whether an IP is on the list for the sending domain. Unfortunately using SPF lead to many false positives and the rules are applied loosely at best. So this still leaves the work to the receiving server.
DKIM (Domain Key Identified Mail): this method uses a private and a public key fetched by a Mail Transfer Agent (MTA). These are compared and only if it is a match the mail will be sent on. But DKIM only signs the specified parts of the message, the message can be forwarded and the signature will still match. This is called a replay attack.
DMARC (Domain-based Message Authentication, Reporting, and Conformance): this policy gives a sender the option to let the receiver know whether its email is protected by SPF or DKIM and what actions to take and who to report to when dealing with mails that fail authentication. This takes away the doubt on the receivers end, but unfortunately DMARC is not very widely used.
How are they able to pull it off?
The easiest way to spoof mails is if the evil-doer finds a mail server that has an open SMTP (Simple Mail Transfer Protocol) port.
As stated before, SMTP itself lacks authentication so servers that are poorly configured in this way are prey to abusers. And there is nothing that can stop a determined attacker from setting up his own email server.
Having done that there is – freely available – software that will allow you to use any sender address you like. The receiver would have to check the full headers of the mail to find out whether the mail came from the “real sender” or if it was spoofed. This takes some knowledge and time, that you probably do not want to spend on every incoming mail. In these cases however replies go to the actual handler of the email address and not the attacker.
That is why, in cases like CEO/CFO fraud you will often see that the attackers registered a domain very similar to the one of the company they were trying to trick.
A difference in the domain that could be easily missed by the intended victim, like for example ma1warebytes.org. That will enable them to get any replies from their victim in case they were asked for more information or confirmation.
Use cryptographic signatures (e.g., PGP “Pretty Good Privacy” or other encryption technologies) to exchange authenticated email messages. Authenticated email provides a mechanism for ensuring that messages are from whom they appear to be, as well as ensuring that the message has not been altered in transit. Similarly, sites may wish to consider enabling SSL/TLS in their mail transfer software. Using certificates in this manner increases the amount of authentication performed when sending mail.
Configure your mail delivery daemon to prevent someone from directly connecting to your SMTP port to send spoofed email to other sites.
Ensure that your mail delivery daemon allows logging and is configured to provide sufficient logging to assist you in tracking the origin of spoofed email.
Consider a single point of entry for email to your site. You can implement this by configuring your firewall so that SMTP connections from outside your firewall must go through a central mail hub. This will provide you with centralized logging, which may assist in detecting the origin of mail spoofing attempts to your site.
Educate your users about your site’s policies and procedures in order to prevent them from being “social engineered,” or tricked, into disclosing sensitive information (such as passwords). Have your users report any such activities to the appropriate system administrator(s) as soon as possible.