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-Has-Attach:
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.

A Practical Guide to Phishing, pt. 1


<I actually started this some years ago, but it seems to still be of use>

“Just say no” is such a bad teaching method

This is not for my compatriots in IT or the computer biz. Y’all already know this, or should. This is instead for y’all to pass along to folks who just want to know how to not get screwed by their email. Also, this is long. Unfortunately, details matter, and this is teaching how to analyze, not click bait overview, it’s going to be long. So get comfy, and take notes. This part will deal with an attempt that is fairly easy to spot, as basic training for the more sophisticated versions.


What I am going to attempt in this series is to deconstruct some phishing attempts in a way that helps you avoid problems. I’m not going to do this via fear, or scare tactics or overuse of italics and capital letters. Instead, I’m going to do something my industry is regularly bad at when it comes to talking to people outside of the industry: I’m going to assume everyone reading this is smart, capable, but with a specialty in a different area, and good at things I probably suck at. So, just as y’all would teach me something you’re experts at, I’m going to go over how to properly analyze phishing emails in a way that will hopefully help you, via logicreason, and the application of skeptical thought.

Round one: Easy

So here’s one of a type you’ll see a lot, and it’s one that makes sense in a corporate environment, the “You have exceeded your mailbox space” email. The theory behind it is simple, and one that makes it fairly effective: we all know we have limited email space, and we may have even gotten “quota exceeded” messages before, so we’re all primed for this one:

This is a screenshot from my email client of choice, Outlook 2016 for OS X. But it’s going to look similar regardless of client, and for our purposes, the client differences aren’t important. Now, some background info: I currently work for the Florida State University…

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” 

…so any and all emails coming to me from someone at FSU will always end with fsu.edu, so, someone@fsu.edu or similarThat’s an important thing to remember. If you work for say, Apple, then (I’d guess) your email ends with some variant of apple.com. This will change with your company, but just looking at your own email address will provide you with this info.

So let’s take a deeper look at the email, its subject, and who its from. First the subject: Helpdesk. Okay, right there, that’s a flag. I’ve been in the IT business a long time, the number of emails I’ve sent to non-IT people with just the word “Helpdesk” in the subject, when the reason is that a person is over-quota on email may in fact be zero. I’m hardly in the minority here. In general, legitimate IT emails, even automatically generated ones will have a subject that gives you a real hint as to what the email is about. It’s important to us, we hate having to explain an email we just sent. Okay, so strike one: bad subject.

Secondly, who sent me that email? Well, according to the name, Camille Erin Chung. There’s nothing unusual about that in and of itself, but that’s not an actual email address. So now let us hover over the sender until we can see the actual email address:

Camille did not knowingly send this email.

Okay, BIG red flag here. Just like emails to me should have “@fsu.edu” or similar in the to address, emails from my someone working at FSU should have the fsu.edu bit in their email address too, right? But this doesn’t. Looking at it, it actually seems to be from a place in Canada, (the ca part. All countries have a country code. Things started in the USA, so we don’t end everything with .us, but yeah, country codes are a thing even on the internet.) A bit of digging, by which I mean “typing uwo.ca into a web browser” shows me pretty quick that this is actually an email address supposedly from Western University of Canada.

While it is always possible that FSU or any university might outsource their helpdesk, it is highly, highly unlikely that they’d do so to another university in Canada. Your company may have outsourced its email to say Google or Microsoft or some other company, but you should have an example of a legitimate email from your helpdesk folks available. Compare it to these kinds of emails, and if the last part after the @-bit doesn’t perfectly match, then the chances of it being a phishing email are climbing vertically. Strike two: bad sending email address.

Another thing to be aware of: the “from” address in an email is trival to fake. Literally, trivial. I’m hardly a scripting genius, but I could, with ease, crank out all kinds of emails from everyone you know, and they’d all have the correct from address and be completely fake. The validity of information is only as good as its reliability, and the from: address in an email is barely reliable. Also, generating a list of email addresses to send emails to is even more trivial. Really. Email addresses are as concrete as writing love letters in the sand at the waterline.

Next up, the to: address. This should be me, right? I mean, it was sent to me, it should have my email address. Yet, we see: blank. Look at the first screencap. Blank. Which means my email address was in the bcc: (blind carbon copy, the field you use when you want to send an email to someone or a lot of someones, but not have the person in the to: field know you did it, or reveal a lot of email addresses) field. 

Why would that happen? Barring lots of people having email quota issues, (and as it turns out, email servers are adept at automatically sending quota warning emails to people, one at a time, with their name in the to: field) there’s no reason for this, and really, even if it was a lot of people, still no reason for this. Another sniff test failed, another strike. Strike three: bad recipient/to: address.

So finally, the message itself:

This is an Email Service Alert from Helpdesk. This is to inform you that your mailbox has exceeds its storage limit, you will be unable to receive and send emails. To re-set your Account Space on our database, prior to maintain your INBOX from 20G to 20.9G. CLICK HERE to Activate

Okay, so people can be snotty and snobby about grammar, but it is vanishingly rare that a legitimate email about an email quota will be this badly written. That’s strike four: bad grammar.

Next, and this is kind of subtle until you think about it: “…you will be unable to receive and send emails.” Now, in a real over-quota situation, that’s correct. If you have hit your quota, you will in fact have problems sending and receiving emails.

So let us apply logic and skeptical thought. Ask yourself: “have I been sending and receiving emails today in a normal fashion?” If the answer is “yes”, bang, strike four: can still send and receive email even over quota. If the answer is “no”, has your email program been flashing you warnings outside of “Helpdesk” emails? They all will. Every common email program will fuss at you if you go over quota. I’m pretty sure even Pine and Elm will, and if I’m wrong, I’m sure within the first ten responses someone will correct me.

If you’re really over quota, your email program will become really strident about it. Annoying even. You’ll know, oh lord, you’ll know. So strike five: email program is not warning you about being over quota

Now, let’s look at the URL behind “CLICK HERE”:

Nice try, but no

Okay, so while that’s a nice touch, the “fsueduhelpdesk” part, seriously, no one does that in a URL. You might get “fsuhelpdesk”, but even then, the “.weebly.com/” part blows it out of the water. The only way it could be more wrong would be fsudoteduhelpdesk. So now, we have two strikes (we’re up to strike seven at this point)in just one URL. What is weebly.com? A website that lets you easily build your own website. Kind of like Tumblr or any other similar service you’ve heard of. 

The site itself is a form, complete with the FSU logo, (easily pulled off the real FSU website.) Logo/graphic abuse is endemic on the internet. It conveys no status other than “I can copy/paste an image”. The best part, (for me) is the name of the page: KINDLY FILL FORM CORRECTLY

It’s like a bit from “The Critic”. Strike eight: website form is really unprofessional. Also, strike nine, a website that is supposedly for FSU is on a domain/host that has nothing to do with “fsu.edu”

Note, I did actually contact Weebly about this. They have a very nice contact form specifically for reporting this kind of nonsense, and good on them for doing so. (Also, they’re FAST. Less than 5 minutes after I’d submitted the contact form, they emailed me back to tell me they’d shut down the site, and damned if that’s not exactly what they did. Good Job Weebly!)


Okay, so that’s nine strikes in one email that’s less than a paragraph. Even allowing for two of them (over quota behavior and the email program warning you about being over quota) not being absolutely reliable, that’s still 7–9 reasons to not trust this email, and it’s not even a full paragraph in length. It’s a phishing attempt, delete it.

VERY IMPORTANT WARNING

I also want to provide a warning about two things I did in this post, namely researching uwo.ca and weebly.com: I am a professional, do not do this if you are not me or in my line of work. 

Seriously, this is like the warnings about snake handling and driving a car at 200MPH. I know what I’m doing, and I also kind of knew about uwo.ca and weebly.com ahead of time. I know how to verify a domain is not loaded with gobs of malware that will further try to hose you when you go to that site, and I know how to avoid it if it is. (Or repair from it if I make a mistake.) 

There is literally no need for you to click on links in an email to evaluate it as I did. Nothing I did required that, I was just being thorough because I like to be thorough. If you get more than 1–2 strikes like we saw in an email, don’t click on anything in it, because that could be part of the scam. 

But again, if you look at how I went over it, if you evaluate the entire email, you see there’s no need to click on anything. Just by hovering your email over the link, (or pressing and holding in iOS. I’ll assume Android works the same way, or very similarly), you can see what the link is in a safe manner. If it doesn’t match what you think it should, even if the email looks “official”, delete it. If it’s a work email, call your helpdesk and ask them to be sure. (if you want to hear a helpdesk person almost weep with joy tell them “Oh heck no, Ididn’t click on squat. I just hovered over the links, and they looked totally janky, so I called you to be sure.” They’ll love you. LOVE. YOU.) 

If it’s from a bank or a store, call the store/bank (NOT with the number in the email. Go to their website and get their support number there) and call their customer support number. 

But there’s no need to be afraid or freaked out or whatever. You are all smart people. You can all do the things in this post and deal with phishing attempts in a logical, rational fashion, and you will find that the logical, rational approach is far more effective in the long run than blind fear.

The next post in this series will deal with a more sophisticated email that looks really good. (Spoiler: the techniques are very similar to what we did in this article.)