Email Security - How to Protect Against CFO Fraud

Everybody receives spam and phishing email. Most of the time they are easy to recognize and just annoying, but sometimes there’s phishing email that’s harder to detect by eye. Imagine you’re the CFO of a company and you receive an email from your CEO where he asks to transfer $ 50,000 to an account. And you cannot talk about it, because it is for an unannounced acquisition.

This happens and it happens more often than you think. According to an FBI investigation, this kind of scam accounted for approx. $12 Billion of exposed loss. Between December 2016 and May 2018, there was a 136% increase in identified global exposed losses.

There are numerous examples available on the Internet. Xoom Corporation from California, lost a whopping $ 30.1 million in fraudulent overseas transactions due to spoofed email accounts that were sent to the finance department.

Scoular Corporation, an Omaha based trading firm transferred large amounts of money to a bank account in China, based on a spoofed email from the CEO to the CFO regarding an upcoming acquisition. The email stated “We need the company to be funded properly and to show sufficient strength to the Chinese. Keith, I will not forget your professionalism in this deal, and I will show you my appreciation very shortly.” The FBI tracked it down to a bank in Shanghai, but the account was closed already and the money transferred somewhere else.

Ubiquity network transferred $46.7 Million to a strange bank account, and they were lucky enough to recover approx. $15 Million. This was based on an spoofed email message to the CFO, who was able to approve large money transfers.

Mattel was more lucky after they were targeted. After transferring approx. $3 Million  the FBI was able to track the money and return it back to Mattel.

Source: https://resources.infosecinstitute.com/5-real-world-examples-business-email-compromise/

So, what can you do to protect against phishing emails? It’s all about three things:

• People: Train your users, make them aware of phishing email and train them to identify phishing messages if one gets through your security measures. I see tons of phishing messages in quarantine and always tell people “the fancier it looks, the more likely it is phish” or “We don’t use voicemail in the cloud, why should you receive missed calls and voicemail messages?”
• Process: When transferring large amounts of money, make sure that more than one person needs to approve these to avoid fraudulent money transferred based on a single targeted employee.
• Technology: There are multiple ways to protect your domain and your users to protect from phishing email. Being an Exchange consultant I will dive deeper into this first.

Protect Your Domain

It is relatively easy to spoof your domain. I can setup an email server, configure your domain and start sending out email, on behalf of your domain. Nobody will notice, and it’s impossible for you to avoid bad guys trying this. And this is their advantage, it is up to the receiving mail servers to check if the sending mail server is a legitimate mail server.

Sender Policy Framework (SPF)

What do we know from sending SMTP Servers? Its domainname (like ams-exch03.exchangelabs.nl), its IP address (i.e. 178.251.192.4) and the email address of the sender. These three variables should be used in validating sending SMTP servers. It’s fairly easy, email coming from the @exchangelabs.nl domain can only come from the FQDN and IP address mentioned above. If it comes from a different IP address of a different FQDN it is most likely not authentic email, and thus spoofed.

This is what Sender Policy Framework (SFP) is all about. As the owner of the exchangelabs.nl domain, I enter the official SMTP servers in public DNS in a so called SPF record. This SPF record can contain A records, MX records, IP addresses (IPv4 and IPv6) or includes to other SPF records. For my exchangelabs.nl domain the SPF record is as follows:

v=spf1 include:spf.protection.outlook.com ip4:178.251.192.3 ip4:178.251.192.2 ip4:178.251.192.4 ip4:178.251.192.11 ip6:2a02:20b0:112:1::1 ip6:2a02:20b0:112:1::2 ip6:2a02:20b0:112:1::3 ip6:2a02:20b0:112:1::4 -all

Email that I send out to the Internet can only come from Exchange Online Protection (the first entry) or from the IP addresses in the subsequent entries. Any other IP address that sends out email on behalf of my domain can safely be discarded!

And this is what SPF capable SMTP servers do. When an email is received, the SPF record is retrieved from public DNS and the IP address where the message is coming from is compared against the SPF record.

Google is very strict with the use of SPF. If something is wrong with the SPF record, or coming from an unknown IP address the message is rejected immediately, and the sender gets an NDR message. Personally testing with Gmail is one of my favorites when it comes to SPF.

Domain Key Identified Mail (DKIM)

A second option in protecting your domain is the use of Domain Key Identified Mail or DKIM. DKIM is adding encrypted header information, and a private key is used for this encryption. My outbound mail servers are the only server that have access to the private key, and thus are the only server capable of officially adding a properly signed header.

As you most likely know, to decrypt signed information the public key is needed. And the public key for DKIM decryption is stored in public DNS for the domain. I’m the only one that has access to the private key for encryption, the entire world has access to the public key for decryption. Simple, right?

So, if I send out an email, my outbound Exchange servers (or Exchange Online Protection) add an encrypted header, and it is up to the receiving mail server to decrypt the header and authenticate the message.

The encrypted headers (that’s inserted into the outbound message) looks something like this:

v=1; a=rsa-sha256; c=relaxed/relaxed; d=exchangelabs.nl; s=safemail; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KeL95JJ/ICpid5yelJoE6cM/KdTKBnc2w1c1GABngxg=; b=boVc3c5YDXsWg6qFyqmLrbPeJaT2Mt9/T38B9yIu5Le8cNJXG6TqR3wG6N1SWOmX8ooeoz6rbAbstHT9HklkCVa+204ZV4Jrfcen7XkA/50UYwS3GPxB9KDNe7b6MN3wYGGuAnF/ULjUUSzOBNJ7zfvXIev0FwZTmyjSG5V79m4=

How does a DKIM public record look like? Not that exciting actually:

This key is used to decrypt the message header. One advantage of this encryption is that the message cannot be altered in transit. If it is altered (for example with a man in the middle scenario) then the DKIM signature is no longer valid, and the DKIM check will fail. As a result, the message can be seen as invalid.

Unfortunately, Exchange does not support DKIM natively, so you have to use a 3^rd party solution if you want to deploy this on-premises, or use Exchange Online Protection.

Domain based Message Authentication Reporting and Conformance (DMARC)

DMARC is a policy based validation mechanism, built on top of SPF and DKIM. The policy, which is stored in public DNS, tells the receiving mail server what to do if an email does not comply with SPF or DKIM, for example when it is not coming from an authenticated IP address, when a DKIM signature is missing or when it is altered in transit.

A DMARC policy can look something like this:

v=DMARC1;p=none;sp=reject;pct=100;rua=mailto:reporting@exchangelabs.nl

The p-tag is the action that should be taken when something is not right, and can be one of the following actions:

• p=none, do nothing and continue processing the message
• p=quarantine, place the message in quarantine
• p=reject, reject the message

p=none is typically used when still testing SPF, DKIM and DMARC and when successful it should be changed to preferably reject.

The sp-tag is for subdomains. Since I’m not using any subdomains, all messages coming from one of my subdomains can automatically be rejected since these are spoofed messages.

The rua-tag is also interesting. DMARC has a reporting possibility. DMARC capable servers can send reporting messages about the receivers messages to a predefined mailbox, in this example reporting@exchangelabs.nl. These message are sent both when DMARC fails or succeeds, so when analyzing the DMARC reports you get a good picture of your internet reputation when it comes to email.

Summary

In this blogpost, I tried to explain some details about SPF, DKIM and DMARC to secure your domain. When implemented properly it becomes much harder for hackers to spoof your email domain and try to impersonate your users.

For more technical details you can read my SenderID, SPF, DKIM and DMARC in Exchange 2016 and SPF, DKIM and DMARC in Exchange Online Protection blogposts which also cover implementation of these technologies.

Monitor Exchange with ENow