Introduction

Date created: May 7, 2019
Last updated: May 7, 2019

Today I received an email titled “jhanley@www2.jhanley.com has been hacked, change your password ASAP”. The hacker claims to know my login and password, has full control over my account and has sent this email using my credentials.

I doubt that the email is legitimate, but I want to be certain. This email gave me the idea to write this article so you know how too.

I use Mailbird for my email accounts (and Outlook also).  Mailbird does not give me any warnings about this email. I like Mailbird because of the feature to combine multiple email accounts (identities) into one view.

Below is a screenshot showing this email in Mailbird. I am including a screenshot instead of the actual email for everyone’s safety.

A warning sign is spelling errors for critical words or phrases important to the sender’s message. Examples: fullccess and microphon

I fired up Chrome and logged into Gmail. Gmail showed a big red warning.

Thank you G Suite/Gmail, this warning is appreciated.

I use G Suite for the jhanley.com domain. I also have SPF, DKIM and DMARC enabled. This makes the job for a spammer much harder. However, I want to be certain that my credentials were not used to send this email.

One item I have noticed about G Suite is that when I send myself an email using the same G Suite organization, the email does not contain a lot of headers that are common when email traverses external email servers.

Let’s compose an email, send it to ourselves, and analyze the email headers.

Open the email in Gmail and click the three vertical dots menu at the right-hand side of the email and select “show original”.

Gmail will now display the raw text version of the email.

The part we are interested in begins with MIME-Version: 1.0 and continues to Content-Type: text/plain; charset="UTF-8". Everything in between is the Email headers. Notice that there is no mention of any exchanges between external servers. This means that G Suite internally managed this email. The email went from my account to my account without going out onto the Internet.

Now let’s look at the email headers for the ransom email:

I have truncated the email as the email body is large and is not important to this article.

If you look at the last line, which is the start of the email body, notice that this looks different from normal readable text. Look at the third line from the bottom: Content-Transfer-Encoding: base64. The spammer is trying to get past spam detectors. There is nothing wrong with encoding an email base64, but this is something to notice. All professional software will just decode the base64 text and process as usual.

I did take the time to decode the base64. This spammer tried to double hide their email body by filling the body with lines like this:

<!-- jhanley -->s&#8203;e<!-- jhanley -->

The email body comprises lots of comments, plus they encode every character. Again, professional software can handle this with no problem. Remember, in order for you to read their ransom demand, an email client must be able to decode this, therefore other well-written software can too.

As you scroll thru each header line, you can see the exchanges that occurred over the Internet. There is some activity that includes IP addresses. Now I am confident that this email originated outside of G Suite/Gmail and they did not use my account credentials to send this email.

Let’s analyze further to see if there are any more concerns.

Look for this line:

Return-Path: <koweaoj@xaae.com>

The header Return-Path is what an email server checks when verifying SPF. The spammer is not smart. To make this email look like it came from me (as stated in his email), then the Return-Path should be inside my domain.

Look for this line:

spf=neutral (google.com: 203.153.42.190 is neither permitted nor denied by best guess record for domain of koweaoj@xaae.com)

The domain xaae.com does not have an SPF record. Therefore Google cannot determine the SPF policy.

My domain has an SPF record of v=spf1 include:_spf.google.com ~all. The ~all means soft fail. If instead, the SPF record is v=spf1 include:_spf.google.com -all, the error would be Hard Fail. From this, we also now know that the sender is not inside my domain. The sender (which can be forged) is koweaoj@xaae.com. The spammer is not too bright …

I did look up xaae.com and it is a real domain registered to someone in Panama City, Panama. Do not place too much importance on this information. The validity depends on the email servers between the spammer and Google.

Look for this line:

dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=jhanley.com

Excellent, now our DMARC policy is kicking in and saying there is a problem with this email. I have my DMARC settings as v=DMARC1; p=none; rua=mailto:nvusw1e5@ag.dmarcian.com;. The p=none means detect problems but do not reject email. I should receive an email report at dmarcian.com to review. Most companies will want to use p=quarantine or p=reject.

Manage suspicious emails with DMARC

My domain also has DKIM enabled. I won’t go into details here about DKIM, but the spammer has no way of digitally signing this email, so this is another indicator that this email is bogus – the email is missing my domain’s DKIM signature.

In summary, this email demanded that I send bitcoins to his account. The spammer stated that he used my computer to record a video of me – oops; I don’t have a video camera attached to my computer. The email headers clearly indicate that this email was not sent using my G Suite/Gmail credentials.

It is safe to ignore this spammer and delete the email.

This email is a good example of why you want to set up SPF, DKIM, and DMARC for your domain. You do not want a spammer sending ransom emails using email addresses that look like you. You do not want spammers sending you, your employees, or your contacts harmful or inappropriate emails. Time is money. Let’s make a spammer’s job difficult, expensive and pointless.

 

Related Posts