Business Email Compromised? Or not?

When it comes to Phishing attempts, email is the number 1 methodology to try and lure unsuspecting victims into traps that could result in various precarious scenarios with, most often, devastating consequences. It is therefore of the utmost importance to identify these attempts and prevent them from even reaching the email inbox of the recipient.

When your company assets are being used as part of a spam/phising attack where victims get emails with letterheads and logo’s of your company, the implications are far-reaching from brand damage via customer impact to financial burdens. So how do you do that?

There are a many options available, from free to high-end commercial solutions. Let’s first take a look at the free ones.

The DKIM/SPF/DMARC trifecta

SPF stands for Sender Policy Framework which is a solution where the receiver can check if the email that was received, was actually sent by an email server authorised to send emails from your domain. It does this by checking an SPF TXT record in your authoritative DNS server. It looks somewhat like this:

v=spf1 +a +mx +ip4:68.137.210.0/20 ip4:82.49.19.0/20 ip4:92.154.123.0/19 ip4:232.45.87.39 include:_spf.protonmail.ch ~all

This record will let the receiving email server verify if the email was sent from any IP address or subnet in this list or, sent from an email server that is listed in the “_spf.protonmail.ch” record. It then depends on the policy that has been set by the email administrator on what to do with that email. Some administrators are very strict and will immediately delete the email. Other options are to look at the “WHOIS” information of that domain and check if there is an “abuse” reporting option for that domain, in which case that email may be sent as an attachment to that address. This allows the actual owner of that domain to do some investigation and undertake subsequent actions.

DKIM or DomainKeys Identified Mail

This technology is designed to allow the verification and authenticity of the email that was received. What this entails is that the email server on the sending side has generated a PKI public and private key pair. The public key is published in the domain DNS server and the private key is stored on the email server itself. Every outgoing email is cryptographically signed against a few key factors of the email by using the private key. The recipient, or better the email server on the recipients’ side, can then check the DKIM record that has been set in the DNS server and validate with that public key, if the email has not been altered underway.

An example of a signature looks like this

DKIM-Signature: v=1; 
   a=rsa-sha256; 
   c=relaxed/simple; 
   d=erwinvanlonden.net;
   h=content-transfer-encoding:content-type:subject:from:to:content-language:user-agent:mime-version:date:message-id;
   s=dkim; 
   t=1679364774; 
   x=1681956775; 
   bh=Q+RHq4ey2E3iKzZG0sAhEhmFXjxhpSvaCj08qgqs9O0=;
   b=cLU3Lyn10aXAYBEIyE2PcN0v4dNr
	vVlxFI5v4QFMKkwGh4e3Iz3mBD6NrXuCCnhwM09c6UApytPJghEHHkHDofn3JNso
	5o+7hTKrqdEWkmIvf1ZgCkAac8vuRGr/YcfC2jXZqt9NIYJXUUf96PWM8HNKylvW
	Ace60w8anzoykmsb5FAP4AuGt3fv/wXn2j1nX41hi79LTLjSyd8z7WhWYNuKKITJ
	qRHafmRnzAwJpmyM0mzR+i6qXJXrH7XfI+PBFfTSkzYZOoi8T3Y21zm0rRyxa1KO
	BROV7YPuZdCm764FaCiHttz1TVZHnUlhpidHh+Ri5/wlE/9FxzPbh1T0cg==

There are more tokens that can be used depending on the system architecture and policies. In short, it shows how the signature was generated against which fields in the email. As the public key is available in DNS as a TXT record under “dkim._domainkey” (see the s= tag), the receiving side is then able to use that key to mathematically check if the email has been altered or not.

There are some restrictions and flaws with the approach, such as when an email gets forwarded. The headers of the email will change, and potentially the body, which will invalidate the signature. More exceptions are listed in the RFC under security considerations. (See here)

Domain-based Message Authentication Reporting and Conformance

Or DMARC in short, is the third option that can be used against spamming and phishing attacks. What DMARC basically does is giving the sender domain the option to inform the receiving side what to do when a SPF or DKIM email verification fails. Especially when email domains are new and still have to build a reputation, this can help against inappropriately flagging emails a spam or even trashing it.

v=DMARC1; p=reject; pct=100; rua=mailto:[email protected] ; ruf=mailto:[email protected]; adkim=s; aspf=s;sp=reject

The record that is entered in the “erwinvanlonden.net” domain instructs mail transport agents (email servers) to reject all emails that fail the SFP or DKIM test. Unless my mail server gets compromised, you can rest assure that emails that come from “erwinvanlonden.net” are valid.

This does already indicate one of the flaws of this architecture. If the exact source email server of the email itself cannot be validated as being authentic, the house of cards falls down. If a hacker is able to make his way into an account that either has access to an account that is allowed to send emails through that server, he can send whatever he wants, the emails get signed with a valid DKIM signature, and the SPF test will not fail. If the email server itself gets compromised, all bets are off.

End-to-end security

The only way to validate the end-to-end integrity of an email is a direct trust relationship between the sender and receiver where each have exchanged their public keys like with OpenPGP or sMIME.

I use OpenPGP as that is the easiest in a simple setup such as on a local workstation. You can obtain my public key via https://keyserver1.pgp.com or copy and paste it from the page over here.

Some email clients can directly interact with keyservers from https://keys.openpgp.org which enables to dynamically download and use public keys for verification and encryption of emails.

It depends on your email client software on how to set it up but when done correctly you would see that when you receive and email from me, a OpenPGP signature is used to sign the entire email as it was sent from my client. Many mail providers already have PGP verification solutions in place to check the email and the signature that comes with it and will show you the result.

The above example is from ProtonMail ¹ which display a green lock next to the From: address.

Other email clients such as Thunderbird show detailed information

Business email

Various cloud service providers have similar options, with automated policies in place that take care of the entire key management infrastructure and distribution amongst your personnel. The SPF/DKIM/DMARC setup is an almost automated procedure with DNS record generation as well as validation of email policies. It does however pay dividend to try and understand what actually happens when emails do not arrive or are marked as spam at the recipient side. Incorrect policies, or policies that are too restrictive, will have false negatives resulting in email being dropped.

Compromised servers and accounts

The importance of email verification is paramount when it comes to transactions that could have an impact on either party. There are examples where email accounts have been compromised, legitimate emails been altered with incorrect information, passed on to the original recipient and subsequent financial transactions ending up in hacker accounts. (See here). This can be prevented when the sender and recipient have the above measures in place and can verify the authenticity of the email. Businesses should provide their public keys to their customers and sign each for end-to-end verification and, even better, encryption of every email.

Customers should be able to upload their public key to their account, after which it should be used by the business/service provider that sends the email. This would also allow having the businesses encrypt the email so end-to-end privacy and authenticity can be assured. Any signed or encrypted email that is received by the business from that customer can then also be immediately validated for its authenticity.

In both ways this would also massively improve the security of in-transit emails as each server that routes an email is then no longer able to use the content of the email.

Encryption for end-to-end trust

An example below where I send an email from my “erwinvanlonden.net” domain to my Gmail address. As Google does not have my secret key from my personal pc, its servers and webclient cannot decrypt the email and you will see something like this

When you check the “encrypted.asc” file you will see a message body that looks like a lot of random stuf, believe me, its not…

—–BEGIN PGP MESSAGE—–

wcDMA8BT/XAlN8GjAQwAiDVMhlLsSvUNnCCjti+FuiRChCKAVTnOa1THjuGWa4Hq+ubbpeoP8qtH
N3AiS9UdGMxi+hsZxl4Oj8oe3R7qbjx/YxCBkyrPU/iWZyrvB2E+5shtwSWH8sCxtpMC1SikGtBg
AyqJKpxHqY5Z5Pn+AAdbwGN27MrfMcJqFqMMjR4XLZSd6Xn7616s/f0+53rIJq656IWhFkWMLua9
uSac7GRihPfAuRoddLhd8GshY5YYKlj01uVLVUqgEH+ytZIlZF6qzw4v0nBUIJOB+v5pbCw9jZbr
aiJPpP4UQKyhx76Pmq0o/8UDftU9ClwSfHe+CuHWDwmxyINSBp/W8aYgUtXAumM/RfZugzMXfvWa

RaAXNJVXiqPyLs2eAxEBrXDVCbSLI+F/zS1lfhbSwmAt6x5+A/8JpJcllvrj+oWWjRMSI6qd1cMd
dmduC0ooBkp5GUSzfqTjC+qEd39yWud+QAe7xLM9/pOz9KLsA34UHac0aCk1RdpyWjLY6SynEbJP
C/teJAcgdizlI1L0UfQ/RcUt8IexcEp6cQleZF9zfCyx8n9CE5z/RhVJ1Q==
=gtyy
-----END PGP MESSAGE-----

Only when I download the message to my local client, which has the secret key, and is able to decrypt the message, you will see the original content of the email

In addition to the encrypted email itself, the DKIM,SPF and DMARC policies are still in play here as the content itself is not important for this to work. You can see this in the above picture, where the DKIM signature is valid.

To close off

The DKIM/SPF/DMARC trifecta is a great way to get rid of a significant portion of spam and phishing emails when the settings are configured correctly. Having solutions that would allow an end-to-end encryption between sender and receiver is by far more superior. The main issue is that key management for email would need to follow in the same way as was done for web traffic. Public key verification methodology can be done pretty easily as the email address is already in the key itself. A verification like LetsEncrypt does with web certificates is one of the options. As s/MIME and OpenPGP already allow for keys to be signed, it is a pretty easy feat to do.

Even though the technology is there, a fair amount of common sense when it comes to interpreting the validity of email plays a crucial role. Check if your organisation is ready, both from a technical and human side.

Kind regards,
Erwin