Categories
Email Security Phishing

A Curated List of Phishing Resources

Collection of useful resources for red teamers, pentesters, security reseachers and anyone interested in technical and non-technical aspects of phishing and related topics. The GitHub project is available here.

Idea, concept and some resources from Awesome Red Teaming.

Email Security

Encryption Standards

Email Authentication

Filter Techniques

OSINT for Phishers

Phishing Infrastructure

Payloads and Filter Evasion

Tools and Frameworks

OSINT Tools

Phishing Campaign Tools

Payload Tools

Books and Ebooks

Campaign Write-ups

Phishing Prevention and Detection

Phishing-related Scientific Research

Miscellaneous

Phishing Economy

Phishing Ethics

Phishing Filosophy: Some philosophy to consider before launching a phishing test against your own company

Definitions

OpSec

Phishing Quiz

Report Sites

Other

Categories
Email Security

Encryption and Signing

STARTTLS & SSL/TLS

As we already learned in the Email 101 the security standard of email is quite low by default. To improve the security the introduced email protocols (SMTP, IMAP, POP3) allow basic authentication.

To provide confidentiality and integrity to the authentication mechanism SSL/TLS can be used. As email is a old system, STARTTLS was introduced in the beginning to enable SSL/TLS communication on the standard ports, if both sides support it.

The difference between SSL/TLS and STARTTLS is that SSL/TLS use different ports than the unencrypted protocols, while STARTTLS uses the default ports and begins with unencrypted communication. This behaviour is often referred to as opportunistic TLS.

So lets see how that looks in a real world example. Here, we use gmail.com and SMTP for further analysis. The encryption for SMTP, IMAP and POP3 is not different, therefore the choice of protocol is arbitrary.

Locating the SMTP Server

First, we need to identify the location of the corresponding SMTP servers. The google support provides the necessary information:

There are two ports listed for SMTP communication. We can see that port 587 is used for STARTTLS encryption. However, in the introduction above it has be stated that STARTTLS uses the standard ports. The reason is that this port is specifically named in RFC 8314 as additional STARTTLS port for SMTP. Other protocols still use the default port for STARTTLS.

Probing the STARTTLS port 587

When connecting to port 587 as listed for STARTTLS, we receive the following result.

The ehlo command is used to list the available services. There is no option to start the authentication process right away. Before authentication, the STARTTLS commands needs to be performed to establish an encrypted connection for the transmission of authentication credentials.

Interestingly, connecting to the default SMTP port 25, also results in a connection that requires STARTTLS to be performed before authentication, thus not allowing for the unencrypted authentication.

To perform the STARTTLS procedure, openssl is used instead of telnet. openssl supports several ciphers related to STARTTLS, SSL and TLS.

The command used to connect to the service is as follows:

openssl s_client -starttls smtp -connect smtp.gmail.com:587

As a result, the authentication can be performed. An exemplary command to do so is AUTH PLAIN, where the username and password are both transmitted as base64 encoded string.

Probing the Implicit TLS port 465

Connecting to port 465, using implicit TLS via openssl, is performed by using the following command:

openssl s_client -connect smtp.gmail.com:465

As expected, the results are similar to STARTTLS after the secure connection is established.

Examining the Ciphersuites

An interesting aspect is the ciphersuite that is used to establish the encrypted connection. TLS offers a wide variety of different algorithms that can be used. A ciphersuite consists of:

  • Key exchange and agreement algorithm to establish the foundation for encrypting and decrypting messages as well as to authenticate client and server
  • Encryption algorithm to encrypt and decrypt messages
  • Message authentication code algorithm to verify the integrity of messages

In our previous example, openssl and the gmail.com SMTP server negotiated the following cipersuite:

The cipersuite is named

TLS_AES_256_GCM_SHA384

This translates to AES with 256 bits in Galois/Counter mode for encryption and SHA384 hash algorithm for integrity protection. Key exchange and authentication are arbitrary for this ciphersuite.

openssl can be used to enumerate the supported cipersuites of a server. The command for TLSv1.3 (for TLS < TLSv1.3 the cipher parameter must be used instead of cipersuite parameter) is:

openssl s_client -ciphersuites [suite] -connect smtp.gmail.com:465

[suite] is the name of the ciphersuite to use. TLSv1.3 ciphersuites implemented in openssl are:

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_AES_128_CCM_8_SHA256
  • TLS_AES_128_CCM_SHA256

Another option for fast enumeration is using the nmap ssl-enum-ciphers script:

nmap –script ssl-enum-ciphers -p 465 smtp.gmail.com -Pn

However, nmap supports only TLSv1.0, TLSv1.1 and TLSv1.2 so far.

Server-side Encryption

Using TLS can secure the MUA to MSA communication. However, MTA communication needs also to be secured separately. SSL/TLS is also the preferred protocol to establish secured MTA to MTA communication.

As users cannot verify if the communication is encrypted, it is recommended to assume that no protection mechanisms are used.

Several local initiatives certify that their MTAs transfer emails only via SSL/TLS to other systems under the condition that they are also part of the initiative.

PGP, OpenPGP and GnuGP

When it comes to end-to-end solutions, there two major systems: OpenPGP and S/MIME. OpenPGP is a standardised cryptosystem, developed on basis of Symantec‘s PGP software. Later on, GnuPG was released based on the OpenPGP standard as an alternative to the PGP software.

There are two different approaches to add OpenPGP compliant content to emails: PGP/Inline and PGP/MIME.

PGP/Inline

PGP/Inline adds the encrypted and/or signed message as email body. The advantage is that client that don’t understand PGP are still able to view it. However, is not PGP-aware the client will show the encrypted message which may be confusing to users.

The specification for PGP/Inline requires that PGP messages in the body starts with:

—–BEGIN PGP MESSAGE—–

This is followed by version information. The message itself is in ASCII Armor a.k.a Radix-64 format. ASCII Armor is variant of base64. It also adds a CRC checksum after the encoded message. The encoding is necessary as the OpenPGP format is binary. Then, the block ends with:

—–END PGP MESSAGE—–

An exemplary OpenPGP message from the RFC looks as follows:

—–BEGIN PGP MESSAGE—–
Version: OpenPrivacy 0.99

yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzSvBSFjNSiVHsuAA==
=njUN
—–END PGP MESSAGE—–

In some cases, the message is not encrypted, but a signature is added. In this case MESSAGE is substituted by SIGNATURE.

PGP/MIME

The ASCII Armor encoded message is similar for both PGP variants. But the content type header is now changed from text/plain to multipart/encrypted or multipart/signed. Besides the boundry required by the RFC for multipart messages, an application parameter is required as well. The parameter indicates the purpose of the message, e.g. encryption, signing or key exchange.

An example for a PGP/MIME encrypted message is given by the RFC:

From: Michael Elkins <elkins@aero.org>
To: Michael Elkins <elkins@aero.org>
Mime-Version: 1.0
Content-Type: multipart/encrypted; boundary=foo;
protocol=”application/pgp-encrypted”

–foo
Content-Type: application/pgp-encrypted

Version: 1
–foo
Content-Type: application/octet-stream

—–BEGIN PGP MESSAGE—–
Version: 2.6.2

hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4OjeW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZg9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YAAABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW31yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
=zzaA
—–END PGP MESSAGE—–

–foo–

S/MIME

To encrypt and sign messages, S/MIME often relies on similar algorithms as OpenPGP. However, S/MIME is based on X.509 certificates. This provides a CA as root of trust (if signed appropriately).

Similar content types as in OpenPGP are used for signing, while a separate application parameter, application/pkcs7-mime, is set.

Alternative Encryption

As the number of people using cryptosystems to secure their emails is rather limited, some mail providers offer alternative solutions. We now take a look at the protonmail system.

When sending an email via protonmail, there is the option to set an expiration date for the email.

Of course protonmail cannot enforce an expiration, if the email has already left the protonmail servers. Therefore, as indicated in the screenshot above, an additional access control is needed to enforce that. Protonmail requires to set a password to access the email.

After the password is set, we can send the email to a non-protonmail user.

The email received by the non-protonmail user, contains HTML code that is rendered as a message box containing the link to the message, the password hint (if set) and the expiration date (if set).

Following the provided link, opens a web page on the protonmail servers. Here, the non-protonmail user is asked to provide the password. If the password is provided before the message is expired, the message can be received.

The non-protonmail user can also directly reply on the web page, as well as download the public key (if provided).

From a security perspective, this alternative encryption scheme for email exchange relies on the password or pre-shared secret. To understand the security implications of such a scheme, we take a short look on three important properties: Confidentiality, authenticity and integrity. To narrow down the scope, we only focus on the part after the unsecured email with link and hint is received.

Confidentiality

The communication between browser and web page is secured with TLS, thus providing protection against eavesdropping. This enables to confidentially transmit the password. Without the password, no access to the message is possible, thus providing confidentiality as long as the password is only known to sender and receiver.

Authenticity

The content of the initial link may be altered while transmission. The sender name presented in the email may also be spoofed. To establish authenticity from this base, two different aspects can be considered. First, the password (pre-shared secret) may be used to establish mutual authentication. This can be the case if both parties are aware of a piece of information that is only available to them. Second, if the receiving party is aware of the protonmail server domain, the recipient can verify that the link in the email is directed to a legit protonmail domain. From there, security depends on the trust in protonmail servers, as they handle the password input and presentation of the message, including header information about sender and recipient.

Integrity

While no integrity of the initial email is established, the TLS secured connection to the protonmail servers provide integrity protection of the message. As for the other properties, a high level of trust in protonmail in required.

In cases were a password is already exchanged or can be established via the provided hint, this scheme enables users exchange messages more secure than as plain email. However, as there is no end-to-end encryption of the messages, trust in protonmail is required.

Categories
Email Security

Email 101

Email is the foundation of phishing as it is addressed on phishiverse.com. Understanding the basics is important to exploit the environment and understand limitations and capabilities of email-based phishing.

Email Formats and Structures

The email environment is build on easy-readable text formats and protocols. An email consists of two parts: Header and body

Header fields can have any type of information. Examples for additional fields for authentication are explained here. They have to be in format “field name: field body”, e.g. Subject: Saying Hello, and terminated by CLRF. Minimum requirement of header fields are the origination date field and the originator address field.

The body is typically plain text or as the RFC states: “The body is simply a series of lines of text that are uninterpreted […].” Based on this, an example of a valid email looks as follows:

From: John Doe jdoe@machine.example
To: Mary Smith mary@example.net
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: 1234@local.machine.example

This is a message just to say hello.
So, “Hello”.

Email Storage on the Server

On server-side emails are stored as files in different formats such as mbox, eml, emlx, msg and various variants. mbox for example starts with the so-called From_line, which is also used as delimiter. The syntax is “From “, sender address and UTC timestamp. Between multiple emails in one file is also a CSRF. Other parts of the email are not modified. The standard directory structure to store emails on a server is called maildir and consists of three folders: new, cur and tmp. New emails are first written to tmp and then moved to new. Client software, presenting the email to a user, move them to cur and uses flags to indicate the state, e.g. replied or trashed.

The MIME Extension

MIME content is an important extension of emails, enabling HTML messages and attachments. MIME adds two fields to the email header: MIME-version and MIME-content. In the above example a MIME extended email would look like:

From: John Doe jdoe@machine.example
To: Mary Smith mary@example.net
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: 1234@local.machine.example
MIME-Version: 1.0
Content-Type: text/plain

This is a message just to say hello.
So, “Hello”.

Adding Attachments to Emails

Changing the content type to multipart/mixed enables to add attachments. This type requires an arbitrary boundary that can be any value that is not a part of the message. This boundary is the delimiter between each part and also marks the end of message. To ensure this, in practice, often relatively long random values are chosen. In this example, the emails consists of two multiform parts.

From: John Doe jdoe@machine.example
To: Mary Smith mary@example.net
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: 1234@local.machine.example
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=”=-E8St/G7V0J7Oz/sfHhk5″

–=-E8St/G7V0J7Oz/sfHhk5
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

This is a message just to say hello.
So, “Hello”.

–=-E8St/G7V0J7Oz/sfHhk5
Content-Type: image/jpeg; name=”jpeg.jpg”
Content-Disposition: attachment; filename=”jpeg.jpg”
Content-Transfer-Encoding: base64

/9j/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgKCgkICQkKDA8MCgsOCwkJDRENDg8Q
EBEQCgwSExIQEw8QEBD/yQALCAABAAEBAREA/8wABgAQEAX/2gAIAQEAAD8A0s8g/9k=

–=-E8St/G7V0J7Oz/sfHhk5–

The first part contains the same text message as in previous examples. The content-type also indicates that it is plan text content.

However, in the second part the content-type indicates a jpeg file.
Content-disposition further indicates that the image is attached.
Alternatively inline can be used to indicate inline content, which is also the default.

Lastly, the content-transfer-encoding field indicates that the image is base64 encoded. The subsequent string is hence the base64 encoded raw image data. Multiple attachments are each a separate multiform part, delimited by the boundary defined in the email header.

Adding HTML to Emails

Sending HTML content via MIME extension is closely related to attachments. multipart/alternative is typically used instead of multipart/mixed.

From: John Doe jdoe@machine.example
To: Mary Smith mary@example.net
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: 1234@local.machine.example
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=”=-E8St/G7V0J7Oz/sfHhk5″

–=-E8St/G7V0J7Oz/sfHhk5
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

This is a message just to say hello.
So, “Hello”.

–=-E8St/G7V0J7Oz/sfHhk5
Content-Type: text/html; charset=”utf-8″
Content-Transfer-Encoding: 8bit

This is a message just to say hello. So, “Hello”.

–=-E8St/G7V0J7Oz/sfHhk5–

The multipart/alternative type is used to present multiple alternative messages to the system, whereas the last part is the sender’s preferred option.

As each email body part has its own content-type field, the value of them can also be set to multipart, thus allow to nest different types. This for example is often used when an email contains HTML and an attachments.

So far you learned, how emails are defined, stored on servers and you are aware of the most common MIME extensions.
In the second part of this page you learn how emails are sent and received.

How Emails Reach their Destination

Mail user agents (MUA) or e-mail clients can be any piece of software that acts a client to interact with email servers. Calendar, contact and task management software is often combined, e.g. Thunderbird, Outlook or Evolution. Another popular form of MUA is webmail, where the user accesses emails via browser and web page, e.g. gmail, Protonmail or AOL. Three major protocols are used for the interaction between MUA and the servers for sending emails (SMTP) and receiving emails (IMAP or POP3).

The Simple Mail Transfer Protocol

After the user requires the MUA to transmit an email, is that the MUA connects to the message submission agent (MSA) via SMTP. SMTP is text-based, build on TCP/IP and uses TCP port 25 for communcation. It inherits security properties of TCP/IP but does, by default, not extend them. As a result, anyone can connect to a MSA and submit emails, if no further measures are taken.

It is important to know that there is no relation between the actual email header fields and the email transmission process. From and To header fields are unused. Instead the so called envelope from and envelope to fields are used. These are given to the MSA upon transmission request via SMTP. Also these values are not further verified by default.

Besides those two values, a third, so called data parameter is send. The data parameter contains the email format as described in previous sections, including the From and To fields.

An SMTP email transfer for the previous example looks as follows:

MAIL FROM:John Doe jdoe@machine.example
250 Ok
RCPT TO:Mary Smith mary@example.net
250 Ok
DATA
354 End data with .
From: John Doe jdoe@machine.example
To: Mary Smith mary@example.net
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: 1234@local.machine.example

This is a message just to say hello.
So, “Hello”.
.
250 Ok: queued as 12345

From MSA to the Recipient

After the MSA received the email, it forwards them to a message transfer agents (MTA) via SMTP. This process is repeated by the MTA if required until the email reaches the recipients message delivery agent (MDA). MDAs typically offer two protocols to receive messages from them: POP3 and IMAP. Both protocols are used to receive messages from the MDA and set flags, e.g. the deleted or seen flag.

In this section you learned how emails reach their destination and which are the important protocols and agents and how they interact with each other. From a phishing perspective it is important to know which information emails contain and which fields can be manipulated in order to spoof an email an make it look more real.