I have been waiting patiently for someone to mail one of these to me. Now I can use it as an example. I’ll show you how to uncover it as a fraud.
A while back I posted an article about tracing an email. This is especially useful when the email FROM address may have been forged. This one was a particularly clumsy forgery.
As described in the email tracing article, every email contains two parts: a text header section, followed by a single blank line, followed by the email’s contents.
The sender’s email client creates the first part:
Message-ID: <003901d4a5a5$0336c699$28344ca5@rhnidb> From: <email@example.com> To: <firstname.lastname@example.org> Subject: email@example.com was under attack! Change your access data! Date: 6 Jan 2019 15:18:51 +0600 MIME-Version: 1.0 Content-Type: text/plain; charset="cp-850" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Anything created by the client may be forged. Anything. This claims to me from MIcrosoft Outlook Express, but we have no real proof.
Email usually travels through several email servers as it makes its way from sender to recipient. Each server adds one or more headers to the beginning of the email starting with a “Received:” header. Reading from the top, we see the headers last-to-first. Reading upwards from the “Message-ID:” header shown above, here is the first Received header:
Received: from adsl.viettel.vn (unknown [22.214.171.124]) by wmx2.messagingengine.com (Postfix) with ESMTP for <firstname.lastname@example.org>; Sat, 5 Jan 2019 21:49:52 -0500 (EST)
This confirms for me that I didn’t send the email. The domain name and numerical host addresses are both from Vietnam. I don’t have access to email clients in Vietnam. I may have still been hacked. The header doesn’t show whether people at this address had themselves accessed my account.
The next header, “Received-SPF:” shows that they did not have access to my account:
Received-SPF: neutral (smat.us: Domain does not state whether sender is authorized to use 'email@example.com' in 'mfrom' identity (mechanism '?all' matched)) receiver=wmx2.messagingengine.com; identity=mailfrom; envelope-from="firstname.lastname@example.org"; helo=adsl.viettel.vn; client-ip=126.96.36.199
SPF stands for “Sender Policy Framework,” an email security feature that, among other things, checks if the sender is allowed to use the “From” address in the email header. The answer “neutral” means that it can’t tell. If the client had accessed my email account, the answer would be “pass.” Here is an SPF header from a legitimate email I sent:
Received-SPF: pass (smat.us: Sender is authorized to use 'email@example.com' in 'mfrom' identity (mechanism 'include:spf.messagingengine.com' matched)) receiver=wmx2.messagingengine.com; identity=mailfrom; envelope-from="firstname.lastname@example.org"; helo=wout2-smtp.messagingengine.com; client-ip=188.8.131.52
This email was sent from a legitimate “smat.us” email address. My account doesn’t even allow the “postmaster” address to send email.
Why Not Received-SPF: fail?
A security geek might ask why the wrong From address produces a “neutral” answer instead of a “fail.” The neutral answer provides a vital bit of flexibility. Until everyone uses SPF the same way, I might find myself sending email through a different email server: one that doesn’t handle my email authentication correctly.
If I tighten down the email policy, I might prevent myself from sending email in some circumstances.
More Bitcoin Extortion
The email’s text makes an extortion claim similar to one I described last summer. Unlike the previous one, this one asked for the following:
If you want to prevent this, transfer the amount of $589 to my bitcoin address (if you do not know how to do this, write to Google: "Buy Bitcoin"). My bitcoin address (BTC Wallet) is: 1UKR6XVqWCfS7jLDjijxKapU3UX6U3Nh6
I’m including the Bitcoin wallet because it’s a unique identifier that lets us track specific instances of this scam.