Detecting Suspicious Emails

This blog post is going to be somewhat longer and more technical than usual. It is intended as documentation for the use of IS staff, but may be more widely useful (at least in parts). To start with emails come in two parts – a header section, and one or more body parts.

You can do some analysis of the body of the email, but what can be done there is rather limited and has been covered before. However to go for a deep dive into the technicalities we need to have access to the full headers of the email.

Another thing to remember is that there is no guarantees on any of the signs in the headers (or the body) of faked/malicious emails; it’s a game of probabilities – if you get one or two indications that things are a bit “off” then it could well be legitimate; if you get many signs then it is most likely not legitimate.

The Raw View

This is a legitimate email … and the headers are rather scary :-

Received-SPF: pass (google.com: domain of bounce-1657185485459.475823232258128637708151@i.drop.com designates 147.253.215.244 as permitted sender) client-ip=147.253.215.244;
From: "Drop" <info@i.drop.com>
Message-ID: <05.EE.19583.7F4A6C26@gy.mta2vrest.cc.prd.sparkpost>
Subject: Drop + MiTo Serenity Desk Mat, Phangkey Amaterasu Desk Mat, Drop GMK White-on-Black Custom Keycap Set and more...
To: "Someone" <someone@port.ac.uk>
Date: Thu, 07 Jul 2022 09:18:09 +0000
Content-Type: multipart/alternative; boundary="_----cGGBgCxDlmJHT7JNSry5qA===_E0/C1-29399-27466C26"
MIME-Version: 1.0
Reply-To: support@drop.com

We’ll go through some of the more interesting parts of that shortly, but the key thing to remember is that the original sender (or any “hop” along the way) can insert anything it wants into those headers, so they cannot be trusted.

Or rather there are variable levels of trust.

The Headers

From: "Drop" <info@i.drop.com>

So the first thing to say is that the “From” header is likely to be the least trustworthy header in there. Whilst you probably can’t change where your emails “come from”, anyone using custom software (or crafting their own emails by hand) can put anything they like in there. So if it says “someone@port.ac.uk” there is no guarantee that it was really me that composed it (although there is some measures in place to make forging @port.ac.uk email addresses harder but not impossible).

One thing to look for are whether the two parts of the “From” header match or make some kind of sense – in this case we have “Drop” and <info@i.drop.com> which does match (in the loosest sense of the word). An example from a different email doesn’t look quite the same: “SleepConnection” <info@makeupfling.co> (taken from a real spam message).

Reply-To: support@drop.com

The next header to look at is the “Reply-To” header which may or may not be present – it effectively redirects replies to a different address. If the address included (support@drop.com) has a different domain (the bit after the “@”) then it becomes a bit more suspicious.

To: "Someone" <someone@port.ac.uk>

And onto the “To” header (and to a certain extent the “Cc” header). This doesn’t necessarily contain your email address; nor is the absence particularly suspicious – there is in addition to the “CC” header (which also contains email addresses the email is to be delivered to), there is also an invisible “Bcc” header.

Legitimate email takes the email addresses from the “To”, “CC”, and “Bcc” headers, and adds those addresses to the “envelope” (which isn’t shown in the headers). It will also remove the “Bcc” header to preserve privacy.

Malicious emails populate the “envelope” without reference to the headers; which basically means that if the “To” field contains a name you do not recognise there is a slightly more suspicious. But if it contains your own email address that doesn’t make it trustworthy – it’s neutral.

Date: Thu, 07 Jul 2022 09:18:09 +0000

Probably not the most significant header to inspect, but there is no harm checking for impossible dates – either in the future (watch out for time zones) or in the past.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=i.drop.com;
 s=scph0618; t=1657185527; i=@i.drop.com;
 bh=oMI0usDG210zNBNaRijk6ss9HEYFI5LreIegG7NV5VM=;
 h=From:Message-ID:Subject:To:Date:Content-Type:From:To:Cc:Subject;
 b=fZScuZfVPkO10/ytHgvYkX2WAWsxyqr5QejjTPzYZAwCFcUlGH014uocHgPrgS05I
  KxUT2cm2BPQSd1ikShdeswe8MptNWMkE4fqIna17w3+CDinB5hRJ426ojqUHORMjB7
  R0jADRfBZF+GDuRCMSKBOxKTCTEgPZzj/H+ddS0M=

The significance of this header becomes relevant later on … as it is, it is a claim that the listed headers and the body of the email message have been digitally signed. Of course it has to be verified which comes later …

Received-SPF: pass (google.com: domain of bounce-1657185485459.475823232258128637708151@i.drop.com designates 147.253.215.244 as permitted sender) client-ip=147.253.215.244;

This is quite similar to the DKIM signature in that it is a test of whether the email comes from a mail server that the associated mail domain designates as a legitimate source.

Authentication-Results: mx.google.com;
       dkim=pass header.i=@i.drop.com header.s=scph0618 header.b=fZScuZfV;
       spf=pass (google.com: domain of bounce-1657185485459.475823232258128637708151@i.drop.com designates 147.253.215.244 as permitted sender) smtp.mailfrom=bounce-1657185485459.475823232258128637708151@i.drop.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=drop.com

Now this claims to be a header added by Google (mx.google.com) giving the results of an authentication test – in this case we can see that the DKIM test passed – so the previous DKIM signature has been verified, the SPF test has passed, and the DMARC policy has passed – so there are good grounds for the sender of the domain is genuine.

This doesn’t mean that the email is genuine; just that the sender domain is valid.

Received: from mta-215-244.sparkpostmail.com (mta-215-244.sparkpostmail.com. [147.253.215.244])
        by mx.google.com with ESMTPS id s144-20020a632c96000000b0041160e45f31si305281pgs.97.2022.07.07.07.01.04
        for <someone@port.ac.uk>
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 07 Jul 2022 07:01:04 -0700 (PDT)

There’s quite a lot of information to be found in the “Received” headers – bearing in mind that headers can’t be totally trusted. In this example, the very first couple of lines claim that the message was received by mx.google.com (which looks legitimate) and was sent by mta-215-244.sparkpostmail.com.

The appearance of the hostname twice is because the first occurrence is what the sending mail server thinks it’s name is, and the second is Google’s (in this case) attempt at verification based on the network address. Matching is a good sign.

The Body

If you have read up to this point, you are probably already aware of the indications within the body of an email that make it look suspicious including but not limited to :-

Links to sites labelled as one thing, but with the address of something else (i.e. looks like https://foo.com/ but actually goes to https://foo.com.bad.place).
Impersonal salutations (“Dear Friend”) although personally addressed email isn’t a guarantee.
Offers to good to be true – when was the last time you won a prize in a competition you didn’t enter?
Strange wording. Either unnaturally good English or ridiculously bad English. Particularly from people you know or have corresponded with before.
“Unusual” requests – especially requests to bypass standard procedures.

Final Assessment

As hinted at previously, an email may have suspicious indications but still be legitimate and an email may have no suspicious indications yet still be malicious. Determining which emails are legitimate and which are not, is not an easy thing to do – or it would be done automatically with total accuracy.

In fact a certain amount of illegitimate email is detected automatically and blocked; probably far more than we’re aware of. So we’re usually stuck determining the legitimacy of “edge cases”.

In assessing an email we look at the number of suspicious elements – if high enough we can judge it to be illegitimate. In areas of doubt, it is advised to verify the email contents “out of band” – with a phone call, checking with a colleague, or contact via an email address pulled out of a contacts database (and not the email).

Detecting Suspicious Emails

The Raw View

The Headers

The Body

Final Assessment

Recent Posts

Recent Comments

Archives

Categories

Meta