Email/Phishing

What is it?

Phishing is a form of email scam that is used to trick the victim into thinking that the email is from a legitimate or trusted source.

How to check messages

Using a free tool provided by Microsoft, anyone can analyse 'header' information. Headers are a small block of data that is sent at the top of every email, and provides information that is automatically generated by the server to show where it came from and where it goes to.

• The first step is to get the email headers. If you're on Outlook (desktop), simply double click on the email to open it up in a new window, then click on 'File' and 'Properties'. At the bottom of this new box will be a lot of text with the title "Internet Headers". (See below for an example)

• Next, copy this text and go to https://testconnectivity.microsoft.com/ and go to the Message Analyzer tab. Paste in the headers that you just copied from the email and press 'Analyze headers'. (See below for an example)

• The page should generate a table for you. This is basically a list of all the places that the email went to before it reached your inbox. The example below was from a message that was spoofed to make it look like it came from one of my colleagues, but if we look at the first (and in this case, second) hop, we can see that it was sent first from 127.0.0.1 to nowhere. This is a common starting tactic for phishing, and we can tell that something isn't right. The second hop is the more interesting one. As we can see, it comes from a website called 'kangurorental.com.mx' and is sent to 'mx2.rdg.ac.uk'. That first address is obviously not a Reading one, and seems to be some car rental company.

• One final point of interest is the 'Other Headers' tab. We can see in the screenshot below that the 'Return-Path' address is not my colleagues' email, or even a Reading email address at all. It is from the same kangurorental.com.mx website as before. This header means that any error messages that are generated by this message will be forwarded to that address, rather than informing the spoofed sender or IT. This makes these spoofed messages even harder for us to track.

• If you would like to know more about the Return-Path value, RFC5322 (section 3.6.7) and RFC 5321 (section 4.4) should be of more assistance.