E-mails on Thin Ice

The devil might be in the details, but a man is in the mail

There are some concepts to keep in mind while doing e-mail forensics, or while managing e-mail messaging systems.

Nowadays, e-mails are still the main vector for communications, being it for simple notices and greetings, for business contracts, or payments. It follows that they are also the main attack vector for malicious actors.

We are at a point in time in which the tendency is to look for sophisticated protection solutions, from next-gen AV endpoints, anti-spam, ATP, IPS and sandboxes, to the more imaginative custom rules and approaches.

While all of the above are powerful and useful, we need to remember that e-mails have been around for quite some time, and have greatly evolved ever since.

Security wise, the main focus when managing messaging systems is to make sure that unsafe content will not be delivered to the destination. After that, comes the harsh reality that some malicious e-mails will be received anyway, so you want the recipients to avoid opening links and attachments, or to not follow-up scam attempts. Once you tought your users how to try and recognize “bad e-mails”, usually you want to help them in the process, and the ball is in your court.

E-mail messages handling and falsification

Lately, a vastly abused technique in scams consists in directly accessing a compromised IMAP account, to then edit existing e-mails, forging content as desired. This might be a different attachment, a new bank account, or an arbitrary link.

So when your users follow up on that forged payment request, and the money goes to some other third party, and then you report to the authorities, you need to have proof that the message ever existed. Some forensics expert might want to inspect the victim’s inbox, looking for evidence of forging and compromise.

Sadly, most of the times this might not be easily doable, as in the above example the poor analyst could be left with EVERY message to be tampered with.

Waste not, want not

Within e-mail’s standard RFC, there already is some protection mechanism, by the means of SPF, DKIM and DMARC.

In short:

SPF record is a DNS record containing a list of allowed senders IP.

DKIM (DomainKeys Identified Mail) is a signing method for e-mails, which uses key cryptography to ensure that the message hasn’t been tampered with in the delivery process.

DMARC record (when enforced) validates an e-mail based on a match between the From: field with either the Return-Path: of the SPF record or DKIM’s signature domain, so it needs one of them to pass authentication to properly apply enforcement.

With all the above correctly in place and running, you should already have a good level of security on your messaging system, at least in terms of anti-spoofing capabilities.

Alas, in most realities this isn’t the case, as these settings get frequently misconfigured, if not completely ignored. If you want to further read about it, I am linking at the end of the article one of my sources about 7 common mistakes people make with DMARC.

Stepping on your feet

What happens when you apply a filter before the mail server, like sandboxes, ATP or the insertions of tags and banners inside the subject or body of a message?

To demonstrate this, I created a test e-mail account on GMX, giving myself IMAP access to use DKIM Verifier add-on on Thunderbird.

Upon registration, I received the first welcome message:

As you can see, DKIM signature is valid, even if I get the notice “From does not match the user identifier”, and my pal up there is quite happy about that.

Now, what happens if I edit the e-mail just a bit, something like this:

Pal is not amused…DKIM Verifier notices the message has been modified and this could be a trigger for some kind of alert.

This goes for attachment filtering and replacing too, as they are a part of the message body.

This means, if we had some kind of solution indiscriminately filtering and tampering our e-mails, every message received should be treated as untrusted. Or trusted…or…wait! If every message is trusted, then every message will be untrusted…or vice-versa?!

The moral

Advanced solutions are good, but only if applied with reasoning AFTER the basic configurations available by design in the protocols and software in use.

These should not be applied like a tank on EVERYTHING, they are far better if precisely aimed and tailored on specific flows.

If not, by trying to implement a cool helping solution, you are only helping end users to be more likely “clicky & scammy”.

Well, as always, this is just my 2 cents on the topic…here you can find 7 common mistakes people make with DMARC.

And, might be useful to some of you, Anti-spam message headers in Microsoft 365.