A Practical Guide to Phishing pt. 2

<okay, I started this about five years ago. Jesus. Pt. 3 may take some time, I never actually started it. I got busy.>

Wherein we look at a more clever example

So in part 1, we looked at a fairly obvious example of phishing. It had a lot of clues that helped us identify it as a phishing email, and so with a bit of skeptical thinking, we were able to see how a preponderance of evidence quickly accumulated and showed us that the email in question was in fact a phishing email.

Obligatory disclaimer: this is not to be thought of as anything other than me, and my personal opinion, wanting to give folks a resource. None of this is official FSU anything in any way, shape or form. I’m only using them because it’s a real-world place, and that makes the lesson more concrete than “company.com” FSU is pretty cool, and they, like everyone else, are trying to deal with phishing. So there’s some self-interest here: if this series helps people not get taken advantage of, then the jobs of the people I work with and for get muuuuch easier.

Email Headers, dun-dun-DUNNNNN

Before we get started on this bit, we have to do a bit of discussion on email headers. This can seem a bit intimidating, (IT people and programmers, stop getting offended, you already know this stuff. This is for people who aren’t you. Go find something to do if you’re about to kvetch that I’m insulting your intelligence. Or not, y’all get taken in by this kind of thing a lot more than you should), but it really isn’t. Headers can be complicated when there are a lot of them, but the basic concept is simple.

Any email can be, very basically, split in two parts: the message, or the content, which includes things like the body of the message and any attachments, and the headers, which are everything else. The from: address is a header, the to: address is a header…if it isn’t content, it’s headers.

Headers can be rather different depending on the email service being used to send and to receive. For example, here’s a set of headers for an email from my boss (real content removed, we only care about the header names in this instance):

Received: from <server> by <server> with <service>; <date & time>
From: Bossman <email address>
To: John <email address>
Subject: <some text>
Thread-Topic: <some more text>
Thread-Index: <a large gibbereshy number that helps with message threading>
Date: <date and time of message>
Message-ID: <more gibberesh to help with email sorting>
References: <still more gibberesh>,<comma-SEPARATED gibberesh>
In-Reply-To: <more gibbereshwilliteverend>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator: <this is Exchange/Outlook specific>
MIME-Version: 1.0
X-MS-Exchange-Organization-MessageDirectionality: <this is Exchange/Outlook specific>
X-MS-Exchange-Organization-AuthSource: <this is Exchange/Outlook specific>
X-MS-Exchange-Organization-AuthAs: <this is Exchange/Outlook specific>
X-MS-Exchange-Organization-AuthMechanism: <this is Exchange/Outlook specific>
X-MS-Exchange-Organization-Network-Message-Id: <this is Exchange/Outlook specific>

Exchange and Outlook have a lot of headers.

Gmail tends to have fewer:

Delivered-To: ME!
Received: <email server info>;<date and time>
X-Received: <more of the same>
Return-Path: <sender>
Received: from <sending email server> by <receiving email server> for <ME!> (<SSL info>);
Fri, 05 Jun 2015 14:45:37 -0700 (PDT)
Received-SPF: <SPF is used to help reduce spam and phishing. It sort of works>
spf=<more SPF stuff>;
dkim=<DKIM is also used to help reduce spam and phishing. It sort of works too.>
Received: <”my” email server> for <ME!>; Fri, 05 Jun 2015 14:45:37 -0700 (PDT) DKIM-Signature: <there is a lot of DKIM and SPF in Gmail>;
X-Received: by <”my” email server>;
Fri, 05 Jun 2015 14:45:37 -0700 (PDT)
Return-Path: <sender. Yes, there is a lot of duplication in email headers>
Received: <name & IP address of sender’s computer> by <”my” email server> for <ME!>
(<SSL Info>);
Fri, 05 Jun 2015 14:45:36 -0700 (PDT)
Date: Fri, 5 Jun 2015 17:45:36 -0400
From: <friend of mine>
To: John Welch <ME!>
Message-ID: <more server stuff with friend’s computer’s name>
In-Reply-To: <a large gibbereshy number that helps with message threading>
References: <another large gibbereshy number that helps with message threading>
<you guessed it! more gibberesh>
Subject: <yeah! something humans can read!>
X-Mailer: <name of email client used to send the email>

So still a lot, but not as much as Exchange. What you’ll notice is that headers are all information about the email message. Who sent it, who gets it, the subject, various bits of non-human-readable stuff for message threading, sometimes the name of the computer that sent the email, sometimes even the name of the email client that sent it.

If you don’t immediately fully understand email headers, that’s fine. What is more important is that you get the basic concept: email headers are what help you figure out who sent the email and who gets the email. There’s one more important part: with the exception of things like the DKIM/SPF info, email headers are trivial to fake. Literally, trivial to fake. It’s not even hacking 101 stuff, it’s too easy for that. All email headers are just bits of text in the message. They have no expectation of truthfulness, nor should they be used that way. 

But, over time, people (largely because people in my line of work allowed them to think this) have started to think of email headers as some kind of trusted info, that you can’t fake that stuff. Well, if you’ve been told that, you’ve been lied to. Most of it is almost effortlessly faked. I’ll repeat that because it’s important:

Email Headers are trivial to fake, and can lie to you with ease.

So, now, onto our actual phishing attempt!

This one, is actually pretty clever:

Someone put a bit of effort into this one

So unlike the rampant errors we saw in part 1, this one gets some things right. First, it’s coming from the right domain, with both a plausible name, (Webmail Help Desk) and email address (helpdesk@fsu.edu).

However, we can quickly see a few things that don’t pass the smell test. First, the To: field is blank. So as before, Strike one. Next, it’s addressed to “FSU.EDU Member”. This is not horribly incorrect, but it’s still wrong. While yes, I am technically a member of the fsu.edu domain, getting an email addressed to me that way is very weird. Also, this is coming, supposedly, from FSU. From the “Webmail Help Desk”. They have my email address, obviously since I got this email in my FSU email, so one would assume that my name is similarly available. (It always is for actual helpdesk folks.) So that’s strike two, and a fairly large one.

Now, let’s look at the first paragraph.

In an effort to keep our records up to date, please take moment to verify your personal information, we are carrying out upgrading with our anti-virus and anti-spam in our data base, We are sorry for any inconvenience this may cause you.

So, while this sounds plausible on the surface, after all, anti-virus and anti-spam software do need updating, it’s vanishingly rare that doing so would require every single person with an fsu.edu email address to personally verify them. It’s especially rare that they’d need you to send them your username and your password. For one, they already have your user name. It’s part of your email account record. It’s right there, available via a short script anytime they want. Secondly, if your email address were “invalid”, how would sending you an email help? If it’s an invalid address, you’d never get the email, the address they are sending it to is invalid

Also, if that address was invalid, they’d already know, as they control the assignment of email addresses, and would also see lots of bounces (Email that tries to go to an email address that doesn’t exist is “bounced” or returned to sender.) Also, everyone trying to send you email would be unable to do so. 

Finally, if your email address was indeed “wrong”, i.e. your name spelled incorrectly, wouldn’t you notice that oh, I don’t know, every time you typed it? You’d either work to get it corrected, or decide it’s not important and leave it alone. In any event, this is kind of a major strike. Strike three to be precise.

The password request fails the sniff test too. First, there’s no reason for email admins or helpdesk folks to have your password. They, literally, have no need of it. The password is either correct or not, and if you don’t have the right password, then you’re the one put out, not them. Also, if your password was wrong, exactly how would you get that email? 

Exactly. They’re trying to “verify” my fsu.edu email password by sending email to my…fsu.edu email account. I got the email, my password and user name are therefore correct, or I am at least using the password that works. So no need to reply, by getting this email at this account, I have successfully verified that I am in fact using the right user name and password.

Verification Accomplished

Also, Strike four. The last line is just there to gin up fear:

Note that failure to verify your identity immediately will leave us no other option than to deactivate your account from our database.

Again, you are successfully logging in and receiving email, a thing that can be checked at the email server mind you. So if they want to see if your email account info is correct, they’d just have to look at the proper server logs and they could see that you are in fact able to check your email, which carries the basic requirement that your user name and password are correct.

The physical analogy would be someone trying to get you to give them your car keys or fobto “verify they’re the right ones” in a way that requires you to drive your car to where they are. Did you unlock the car with the key or the fob? Did the key or fobwork to start your car? Congratulations, you clearly have the right one(s), no need to drive anywhere, go back inside and finish that Netflix binge!

I do like the “Warning Code” bit at the bottom, that makes it sound really “official”. Using a monospaced font so it looks like something a nerd would use is also a nice touch.

But now, for the clever bit. See the “from” address? That “helpdesk@fsu.edu” bit? You might be thinking “So what if I reply to the email with my user info, it’s going to go back to the FSU help desk, how is that bad?” Well, let’s hit reply and see what happens:

One of these things does not belong…

Wait, where’d THAT come from? How did an FSU email address suddenly turn into some random gmail address? 

Remember that first bit about headers, that you probably skipped through because honestly, it really is quite dry and boring? Well, there’s a header called the “reply-to” header, and here’s what it’s for, (From the actual standard that determines such things):

This field provides a general mechanism for indicating any mailbox(es) to which responses are to be sent. Three typical uses for this feature can be distinguished. In the first case, the author(s) may not have regular machine-based mail- boxes and therefore wish(es) to indicate an alternate machine address. In the second case, an author may wish additional persons to be made aware of, or responsible for, replies. A somewhat different use may be of some help to “text message teleconferencing” groups equipped with automatic distribution services: include the address of that service in the “Reply-To” field of all messages submitted to the teleconference; then participants can “reply” to conference submissions to guarantee the correct distribution of any submission of their own.

For example, let’s say you’re putting on a wedding, and both the bride and groom are emailing invitations along with sending paper invitations, and rather than having some responses go to the bride and others to the groom, you want them all to go to “smithwedding@gmail.com”. To facilitate that, you’d set up an email message template with the reply-to address set to smithwedding@gmail.com, so that way, no matter who sends the email, any responses will come to smithwedding@gmail.com. 

Also, what happens when the from: and the reply-to: headers are different? Reply-to wins:

If the “Reply-To” field exists, then the reply should go to the addresses indicated in that field and not to the address(es) indicated in the “From” field.

If we look in our Bit o’ Spam, why what do we find?

From: WEBMAIL HELP DESK <helpdesk@fsu.edu>
Reply-To: <info.admindesk01@gmail.com>

Well look at that. You clever little sods, if someone just hit reply and filled in their account info without double-checking the email address they’re actually sending it to, they’d be properly screwed. 

That, by the way, is why even when it’s not obviously a phishing email, you still double and triple-check things. Because the jerks behind this crap are in fact, rather clever.

As we’ll see in the final installment, they can be VERY clever.