Lately I’ve been doing a lot of phishing exercises – by looking at last couple of years I would say that we can finally see some increased awareness. Unfortunately, this increased awareness is mainly between the IT security folks: the phishing (or social engineering) campaigns usually have very devastating results.

When conducing a social engineering attack through e-mail, I normally try to mimic the bad guys, to make the attack as realistic as possible. I tend to group them as below:

• Phishing e-mails where the victim is being enticed to click on a link (and potentially later enter her/his credentials to a phishing web site),
• Phishing e-mails with an executable in the attachment (either directly, or in an encrypted archive). The goal is to get the victim to unpack and execute the binary. For engagements, I normally use a benign executable that typically enumerate the local machine and exfiltrates that data to me (through DNS, for example),
• Phishing e-mails with an office document in the attachment, that has been weaponized (i.e. a macro in Word, Excel or PowerPoint). The weaponization is normally similar to the previous bullet, where, for the engagement purposes, we normally want to know how many users opened the attachment.

Of course, any phisher worth his weight will always try to make the phishing e-mail look as legitimate as possible. Besides nicely creating the e-mail in HTML, probably the most important field (for the victim) is the sender.
As I’m sure most of our readers know, with SMTP there are two places where the sender is being defined: the envelope from field (use during SMTP) and the body from field, which is normally displayed in MUA’s (mail user agents) such as Outlook, Thunderbird and similar.

The issue here, that I’ve been consistently seeing when conducting such phishing engagements, is that the majority of servers verify only the envelope from field and ignore the body from field (or just use it for anti-spam detection). And of course, there are even those that do not check the envelope from field and simply allow anything to be set there.

This will result in an attacker being able to send e-mails such as the one below:

$ nc mail.server 25
Trying 10.10.10.10...
Connected to mail.server (10.10.10.10).
Escape character is '^]'.
220 mail.server ESMTP Postfix
EHLO server
250-mail.server
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: notreallyimportant@phisher.com
250 2.1.0 Ok
RCPT TO: bojan.zdrnja@infigo.hr
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From: "Recruitment" <recruitment@sans.org>
Subject: Your job application
To: Bojan Zdrnja <bojan.zdrnja@infigo.hr>
…
.
250 2.0.0 Ok: queued as C811CC0EB0E7

As you can see above, the e-mail was happily accepted by the SMTP server and delivered to the (potential) victim. The envelope from field was here set as notreallyimportant@phisher.com – generally it is important that this domain exists. While SPF can protect against attackers forging the sending domain, in most cases attackers will not care: they can simply register a new domain and set correct SPF records for it.

The issue is in the way the e-mail is shown in clients. Here is what the e-mail above will look like in Outlook:

This is probably game over for a typical victim. The only way for the victim to verify where the e-mail came from would be to check the message headers, which is probably something virtually none of the recipients will do (and, by the way, getting to message headers in Outlook is waaay to complex for an average user).

Gmail displays this a bit better, here is the same e-mail sent from my server:

We can see that Gmail added some extra information next to the sender’s name – the domain of the envelope sender (which passed SPF). When I picked a domain without SPF records, this is what the e-mail looked like in Gmail:

No domain in extra information now, but there is an icon with a question mark, indicating that Google was not able to verify the sender. I wonder how many users will see this ?
In each of the cases above, as we can see, the attacker simply needs to be a bit creative on forging the e-mail. Of course, many systems will detect (or will try to detect) the phishing e-mail by examining the body – but we know that this can be always circumvented.

So, what can we do here? One might think that we can start blocking e-mails if the body from field does not match the envelope from field. Or, we might block body from field if the e-mail originates from the Internet, but the body from is set to our organization? Unfortunately, this might break a lot of things such as mailing lists which will have the body from field set to the sender typically.

There does not seem to be a silver bullet currently. I normally recommend that organizations set their SPF and DKIM records, but the real issue is with the e-mail clients - so I believe we need to push organizations such as Microsoft to add more information to the displayed e-mail. Google seem to be on a right path here with Gmail, but even there the display could be improved.

How are you battling such e-mails? Share your experience with us here.

--
Bojan
@bojanz
INFIGO IS