Client Side Penetration Testing – T&T Part 1

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.

MX enumeration

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.

• The “MAIL FROM” SMTP command that is in fact used as “Bounce To” address in order to reach the sender in case of delivery failure
• The message header “From: “ (e.g. From: “Spoofed” <spoofed@target.com>) that defines the address that will shown as sender at target’s mail client

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: <spoofed@target.com>
250 2.1.0 Ok
RCPT TO: <target@target.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 <spoofed@target.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" <target@target.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

“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. me@gmail.com, 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: <me@gmail.com>
250 2.1.0 Ok
RCPT TO: <target@target.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 <spoofed@target.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" <target@target.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

$ dig +short TXT target.com
"v=spf1 ip4:XXX.XXX.XXX.X/XX a mx ?all"

• Mail servers may reject messages from systems without a FQDN.
• Messages from dynamic IPs will likely be rejected because there is common practice to include dynamic IP ranges to spam-lists to prevent spam.
• Do not attach executables to emails because they will likely blocked
• Many mail servers block password protected archives too for obvious reasons