Most client-side attacks are based on delivering emails to the target, nevertheless by underestimating the need to build an adequate “trust level” towards the target, there’s a fair chance that the exercise will fail even at this early state. Below we will begin by listing some techniques, considerations, and tips on how to successfully deliver emails and establish this “trust level”.
SMTP in general
SMTP servers which are flagged as the MX for each domain, by design, accept connections by any system on the internet and relay the messages to their users. The term “system” does not imply mail servers, so the “system” does not have to be a mail server necessarily. Anyone may connect to this type of SMTP server at port 25 using a client (Outlook, Thunderbird or even telnet) and send a message directly to its domain(s) users. Unless this SMTP server is an open relay (very rare nowadays) messages can be relayed only to users of the domain(s) it serves, any other attempt to send messages to other domains will be rejected.
As a first step the target’s MX server that is responsible for email relaying, has to be identified. This can be done easily by querying any DNS server for the target’s MX records:
$ host -t mx target.com target.com mail is handled by 20 mx2.target.com. target.com mail is handled by 10 mx1.target.com.
Mail spoofing techniques
Obviously, the chances that an email will seem legitimate are increased dramatically if the sender email address is spoofed to an email address which belongs to the target’s domain. The sender address is declared in two fields.
During usual email communication using clients like Outlook, Thunderbird, etc. the user cannot control these fields directly. Both are filled by the mail client with the email address that was defined upon user account creation.
MAIL FROM command
Below we describe how to detect errors and blocking mechanisms when using the MAIL FROM command in order to spoof the target’s email. Telnet or a similar program should be used in order to quickly and correctly identify such mechanisms. After target enumeration, the actual spoofed emails can be sent by any email client properly configured to send email directly to target’s MX server.
Since there are several mechanisms that will block the spoofed “MAIL FROM”, the most important part is to check if the email has reached the target.
The message can be relayed from any SMTP server to reach the target’s MX. The reason we choose directly the target’s MX to communicate with, is that we will have strong indications if our message is rejected (due to blocking technologies that are mentioned below) through error messages that would not otherwise be visible (if an intermediate SMTP was used to relay the message).
An example SMTP communication with target’s MX server with telnet is demonstrated below.
$ telnet mx1.target.com 25 Connected to mx1.target.com. Escape character is '^]'. 220 mx1.target.com ESMTP - Welcome HELO test 250 mx1.target.com says HELO to [xxx.xxx.xxx.xxx:xxxx] MAIL FROM: <firstname.lastname@example.org> 250 2.1.0 Ok RCPT TO: <email@example.com> 250 2.1.5 Ok DATA 354 continue. finished with "\r\n.\r\n" Date: Fri, 1 Aug 2014 11:12:29 +0300 From: Spoofed <firstname.lastname@example.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Target >> Target" <email@example.com> Subject: Email subject Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Email message . 250 2.0.0 Ok: queued as XX/XX-XXXXX-XXXXXXXX
Observe for error responses. Below are some examples of rejected attempts:
Error msg: <mail.target.com #x.x.x SMTP; 550 This system is configured to reject spoofed sender addresses>
Error msg: 554 Client host [xxx.xxx.xx.xx.xx] blocked using spam.target.com=[xx.xx.xx.xx] Spamhaus PBL. Please visit http://www.spamhaus.org/lookup/ for more information on why this message could not be delivered
“From: ” header
If the above technique fails due to rejected MAIL FROM from a legitimate served domain email address (MX has no reason to accept messages from the domain users it serves, the latter should be done by another SMTP that uses authentication), then we may possibly trick the MX server with a MAIL FROM from a random email address e.g. firstname.lastname@example.org, but forge the “From:” header. Using the “From: “ header in order to spoof the sender addresses when sending an email might fail without producing any errors. Thus, it is proposed only if the previously described technique has failed. Below we demonstrate this technique using a telnet client. We may use command line email clients, which are easier to use, that will accept the data section of an email through a given file.
$ telnet mx1.target.com 25 Connected to mx1.target.com. Escape character is '^]'. 220 mx1.target.com ESMTP - Welcome HELO test 250 mx1.target.com says HELO to [xxx.xxx.xxx.xxx:xxxx] MAIL FROM: <email@example.com> 250 2.1.0 Ok RCPT TO: <firstname.lastname@example.org> 250 2.1.5 Ok DATA 354 continue. finished with "\r\n.\r\n" Date: Fri, 1 Aug 2014 11:12:29 +0300 From: Spoofed <email@example.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Target >> Target" <firstname.lastname@example.org> Subject: Email subject Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Email message . 250 2.0.0 Ok: queued as XX/XX-XXXXX-XXXXXXXX
Sender Policy Framework (SPF)
Since SMTP itself does not have a way to verify that the address that is used in MAIL FROM command is the real one, SPF (ref. Wikipedia https://en.wikipedia.org/wiki/Sender_Policy_Framework) fills that gap but only for the MAIL FROM command and not the From header of message. The following demonstrates a domain that advertises SPF:
$ dig +short TXT target.com "v=spf1 ip4:XXX.XXX.XXX.X/XX a mx ?all"
Note: It’s not in scope of this article to fully explain how to correctly setup SPF, but an important thing to remember is that the MX SMTP server must be configured to honor SPF records, even for the domain(s) it serves.
DomainKeys Identified Mail (DKIM)
As mentioned already, SPF does not verify message content. To overcome this limitation DKIM (ref. Wikipedia https://en.wikipedia.org/wiki/Dkim) is utilized that signs the message to confirm its origin.
MS Exchange reject spoofed domain emails
MS Exchange can be configured to prevent spoofed emails which target authoritative domain(s) by removing the “ms-exch-smtp-accept-authoritative-domain-sender” permission assigned to MX SMTP servers. For further information follow the link (the configuration is still the same for newer versions of MS Exchange, like 2010 and 2013)