The current article series include two articles.
The former article is – How can hostile element execute Spoof E-mail attack and bypass existing SPF implementation? | introduction | 1#2
For the avoidance of any doubt, the purpose of this demonstration should not be applied, in any form or manner whatsoever for exploiting and attack organizations.
The only purpose of this article is – to provide you a way to verify the mail security settings of your existing mail infrastructure, so you will be able to be aware of existing vulnerability in your mail infrastructure and find the required solutions for mitigating and blocking the “holes” that can and probably will be exploited by a variety of hostile elements.
|THIS CODE AND ANY ASSOCIATED INFORMATION ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK OF — USE, INABILITY TO — USE, OR RESULTS FROM THE — USE OF THIS CODE REMAINS WITH THE — USER.|
How to simulate Spoof E-mail attack and bypass SPF sender verification | Step by Step
Implement the required necessary arrangements
To be able to achieve the two main goals:
- Succeed in simulated Spoof E-mail attack
- Succeed on bypass SPF sender verification check
We have made these preliminary preparations:
- Purchase a dummy domain name – the purpose of the dummy domain name is to serve as a decoy for the SPF sender verification process that will implement by the mail server that represents the destination recipient.
- Configure the required SPF record in the DNS server which hosts the dummy domain name.
- Add the required information meaning the IP address of the mail server that he uses for performing Spoofing or Phishing attack.
In the following screenshot, we can see an example for the SPF (a TXT record) that was created for the “dummy domain name” –thankyouforsharing.org
The IP address that appears is the mail server IP address that is used by the hostile element for sending the Spoof E-mail to the destination recipient.
Our spoof E-mail attack simulation scenario characters
To be able to demonstrate the way that hostile element can use for implementing Spoof E-mail attack + bypassing the SPF sender verification check, let’s use the following scenario:
A hostile element plans to attack (execute Spoofing \ spear Phishing attack) company named – o365pilot.com
- The recipient whom the hostile element seeks to attack is Bob, the company CEO that uses the
E-mail address firstname.lastname@example.org
- The fake identity that the hostile element will use is the identity of Suzan the company CFO that uses the E-mail address email@example.com
- The hostile element knows that the mail infrastructure of o365pilot.com implements an SPF sender verification check for each incoming mail.
- To be able to bypass the SPF sender verification check, the hostile element uses a dummy domain name named – thankyouforsharing.org
- The hostile element will use an E-mail message that includes two sender’s E-mail address:
Using an SMTP Telnet session for executing the Spoof E-mail attack
In the following section, we will review how to run a simulation of Spoof E-mail attack in which we use an SMTP telnet session for executing the attack.
The telnet client that we use
Technically, we can use the built-in Windows telnet client, but this telnet client is a little limited and not so convent.
Personally, I would like to work with a dedicated telnet application. There are a variety of free telnet clients. In our specific scenario, I use a very nice telnet client named – conemu
The two parts of the SMTP telnet session
It’s important to me to emphasize the “two parts” of the SMTP telnet session:
- The first part (A), is the part in which we sue the SMTP commands that are related to
the Mail envelope part.
- The first part (B), is the part in which we sue the SMTP commands that are related to
the Mail header.
The set of two identities that we use in the SMTP telnet session
To be able to bypass the SPF sender check, we will use a set of two identities:
- Dummy E-mail address identity – firstname.lastname@example.org (the E-mail address that belongs to the Mail envelope).
- The spoofed E-mail address –email@example.com (the E-mail address that belongs to the Mail header).
In the following screenshot, we can see the “complete SMTP telnet session” that simulates the Spoof E-mail attack:
- The purpose of the first part is to “occupy” the destination mail server with “non-useful” information that will help us to present ourselves as a legitimate organization.
- The purpose of the second part is to send the Spoof E-mail that includes the information about the spoofed sender.
In the following section we will provide, a “step by step” description of the SMTP telnet commands that we use:
0. Addressing the destination mail server
Using SMTP telnet session for communicating the destination mail server
To be able to address the “destination mail server” meaning, the mail server that represents the domain which we want to attack (In our example, the mail server that represents the domain o365pilot.com), we need to know the hostname or the IP address of the destination mail server (the hostname that appears in the MX record for the particular domain name).
The telnet commands that we use for starting a SMTP session with another mail server is:
1. Initialize the SMTP session
The first command that we use is the HELO command which we use for initializing the session with the remote mail server.
Technically speaking, we don’t have to provide any additional info besides the HELO command, but in our scenario, our main purpose is to present ourselves as a legitimate mail server that represents the domain name – thankyouforsharing.org
For this reason, we will specify the domain name after the helo command.
The command syntax that we use is
2. Provide the sender identity
In this part, we provide the sender identity (the sender E-mail address) by using the
command: MAIL FORM
The command syntax that we use is
3. Provide the recipient identity
In this part, we provide the recipient identity (the sender E-mail address) by using the command: RCPT TO:
In our scenario, we want to send Spoof E-mail to the destination recipient Bob
The command syntax that we use is
In this stage, we have “finished” the Mail envelope phase.
Technically speaking, to be able to send the E-mail to the target recipient, we don’t need to provide additional “identity information.”
The purpose of this phase is, to provide the required information for “building” the Mail header part. The meaning is – the sender, and the recipient identities + the information that will appear in the E-mail message that sent to the destination recipient.
Just a quick reminder, in the mail header phase, we use the command FROM for specifying the sender identity, and the command TO specifying the destination recipient identity.
4. Initializing the Mail header section
To be able to “signal” the destination mail server that we want to start the Mail header phase, we use the command –
5. Providing the spoofed identity of the sender
In this step, we provide the “apparently identity” of the company CFO – Suzan
To make the spoof identity look like a reliable and trusted identity in the eyes of the destination recipient, we will provide two separated parts of “Susan’s identity” –
Suzan Display name + Suzan E-mail address
- The display name of the spoofed sender is the string that appears between the quotation marks.
- The spoofed E-mail address of the sender is the E-mail address between the angle brackets.
The command syntax that we use is
6. Providing the identity of the destination recipient
Technically speaking, there is no mandatory need for providing the E-mail address of the destination recipient. The reason that we provide the E-mail address is that when using telnet session if the TO the field is empty, the information about the recipient displayed as – “Undisclosed recipients”
The command syntax that we use is
In this phase, we will define the E-mail message subject + the mail content
7. Providing the E-mail message subject
To be able to define the E-mail content message that will include subject + the text that we want to send, we use the command subject: + the required text.
In our specific scenario, we will use the subject command + the following text
8. Add a space between the subject in the mail body
To be able to add the required mail text that will appear in the E-mail message, we need to add a space between the subject command and the text that we will add.
key for creating the required space.
9. Providing the E-mail message text
In our specific scenario, we will add the following text string
10. “Ending” the SMTP session with the mail server
To be able to “end” the SMTP session, we use the point character.
The result of our Spoof E-mail attack
In the following screenshot, we can see the Spoof E-mail that was sent to our
destination recipient – Bob. Notice that the E-mail message looks like a legitimate E-mail message.
To only “hint” to the fact that the particular E-mail message is not a “standard E-mail message” (Spoof E-mail in our scenario) is that way that Outlook client use for displaying the information about the sender identity.
When we look in depth at the “top part” of the E-mail message, we can notice that the information about the sender includes the E-mail message of the sender.
This behavior doesn’t consider as a “normal behavior” of a legitimate recipient.
In the following screenshot, we can see an example of an E-mail that sent from the “real user.” When the E-mail is a legitimate E-mail message, the mail client such as Outlook or OWA will display only the display name of the sender.
If you are wondering how did Outlook “notice” that the E-mail message was sent by a “standard organization recipient,” the answer is that when we use the telnet session, we provide the spoofed E-mail address, but we didn’t provide any user credentials.
For this reason, the recipient is identified as Anonymous (the information is saved in a mail field named – X-MS-Exchange-Organization-AuthAs).
When Outlook or OWA mail client recognized a scenario in which the sender considers as Anonymous, the information about the sender will include the E-mail address of the source sender.
Analyzing the information of the Spoof E-mail by using email analyzer
In the following section, we will review that way that we can use for analyzing the information that saved in the Mail header of the Spoof E-mail that sent to Bob.
The process in which we examine the “evidence” that saved in the Mail header could consider as a reverse engineering process of a forensic process in which we use the existing evidence for draw conclusions about the events that happened in the past
The information that saved in the Mail header includes many important details and “hints” that we can use for understanding better the events that occurred during processing of the Spoof
E-mail attack simulation.
Technically, we can analyze the information in the E-mail message header by using a simple text editor such as notepad, but the most preferred option is to use a mail analyzer.
In our specific example, we will use the Microsoft web tool the ExRCA (Exchange remote connectivity analyzer) for analyzing the information that was saved in the mail header.
How to “extract” the mail header information from the E-mail message?
They get the information this is “stored” in the E-mail message (the Spoof E-mail that was sent to the recipient Bob), we need to choose the specific E-mail message, choose the File menu
and then the option – Properties.
- Select the information that appears in the – internet header
- Copy the information (we can use the key combination COPY + C).
- Select the tab – Message Analyzer
- In the empty text box, paste the information that was copied in the former step (we can use the key combination COPY + V).
- Click on the Analyze headers button
At the top of the screen, we can see the information about the identity of the sender and the recipient.
In the summary section (A), notice that the information about this “identities” is the information that we have provided in the second phase of the telnet session, which we described as the “Mail Header phase”.
As mentioned, the mail server removes the Mail envelope that includes information about the sender identity that stored in the MAIL FORM field.
In our specific scenario, the E-mail address that we use in the MAIL FORM field was – firstname.lastname@example.org.
The information about this E-mail address was removed in the mail header will include information about the sender E-mail address that appears in the TO mail field.
The “sender information” that appears, is the information that is seen by the destination recipient (Bob). In other words, from Bob’s perspective, the E-mail address was sent by Suzan the company CFO.
In the received header section (B), we can see information about the mail server that was involved in the mail flow.
The information about each of the mail servers includes the IP address of the mail server and in case that the mail server provides his “name” (the term “name” could translated to hostname, the domain name of the FQDN).
In our specific scenario, the mail server that we use for simulating the Spoof E-mail attack provides his name – thankyouforsharing.org
The information about the mail server hostname was provided by us in the SMTP telnet session, in the begging of the session when we use the HELO command.
Phishing Confidence Level
The value of the PCL (Phishing Confidence Level) is – 0.
The meaning is that the E-mail message not recognized as phishing or spoof E-mail.
In the section named – Authentication-Results, we can see the following information:
spf=pass (sender IP is 22.214.171.124) smtp.mailfrom=thankyouforsharing.org
The meaning of this information is that, from the point of view of the destination mail server that performs the SPF sender verification test, the check completes successfully (spf=pass).
Just to remind you, one of our primary goals in this “Spoof E-mail attacks simulation” was to prove that we can bypass existing SPF protection implementation.
The mail server (the mail server that hosts the recipient whom we want to attack) “inform” us, that he checks the E-mail address that appears in the MAIL FORM field that in our scenario was – email@example.com
Notice that when using the SPF sender check, the verification is regarding the “domain name”, and not for the “hole E-mail address.”
In the section named – Received-SPF, we can see an additional information:
We can see that the destination mail server (the mail server that host Bob) informs us that the mail server that represents the domain name thankyouforsharing.org, consider is a legitimate mail server – thankyouforsharing.org designates 126.96.36.199 as permitted sender.
Pass (protection.outlook.com: domain of thankyouforsharing.org designates 188.8.131.52 as permitted sender) receiver=protection.outlook.com; client-ip=184.108.40.206; helo=thankyouforsharing.org;
As we have already learned, the destination mail server removes the Mail envelope after he finishes the required procedure for accepting the E-mail message.
So theoretically, there is no information about the sender who was mentioned in the Mail envelope (the MAIL FROM field).
This assumption is correct, apart from one exception: the RETURN-PATH field.
The SMTP standard definition that the responsibility of the destination mail server is – to “fetch” the E-mail address that appears in the MAIL FORM field and copies this E-mail address to the RETURN-PATH field.
The destination mail server “wipe out” information that appears in the Mail envelope, but one thing that the destination mail server does before he removes the Mail envelope is – copy the information that appears in the MAIL FORM field to an additional mail field named – RETURN-PATH.
The purpose of this mail field is to hold the E-mail address that will used in case that the
E-mail message could not sent to the destination recipient.
In case that the destination mail server will need to notify the “source sender” about some problem, the NDR message will be sent to this E-mail address (the E-mail address that was registered as the RETURN-PATH).
In our scenario, the E-mail address (the “dummy E-mail address”) that appear in the mail envelope was firstname.lastname@example.org
The destination mail server copied this E-mail address, and the result is that this E-mail message populates the field RETURN-PATH.
In other words – the only “evidence” that we have for the “trick” that was implemented by the hostile element is the information that is stored in the RETURN-PATH field.
X-MS-Exchange-Organization-AuthAs – authentication versus non-authenticated sender
The last detail that I would like to review is the part in which we classify the source sender as “know recipient” or anonymous sender.
In our scenario, the hostile element spoofs the identity of a legitimate organization user by presenting himself as email@example.com
Despite the fact that we manage to “bypass” the SPF sender verification mechanism, and manage to send the E-mail message to the target recipient mailbox, the sender didn’t provide user credentials.
For this reason, the sender was classified as Anonymous.
This information about this “observation”, can help us to identify and detect E-mail message that manages to bypass our “SPF wall.”
It is important for us to know your opinion on this article