Battling e-mail phishing
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.
Comments
Anonymous
Dec 3rd 2022
9 months ago
Anonymous
Dec 3rd 2022
9 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
Anonymous
Dec 26th 2022
8 months ago
Anonymous
Dec 26th 2022
8 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
8 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
8 months ago
Anonymous
Dec 26th 2022
8 months ago
https://defineprogramming.com/
Dec 26th 2022
8 months ago
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
https://defineprogramming.com/
Dec 26th 2022
8 months ago
rthrth
Jan 2nd 2023
8 months ago