Business Email Compromise (BEC) attacks are easy, cheap, and often very effective. This high Return on Investment makes BEC an extremely popular with attackers of any skill level—from low-level scammers to state-sponsored groups. BEC occurs when an attacker is able to access an email inbox within a business. From there, an attacker examine sensitive emails, insert themselves into email threads, and spread phishing emails from the trusted email account. While BEC can be devastating to the finances, reputation, and operations of any business, small businesses are particularly vulnerable. Fortunately. the defenses against BEC such as multi-factor authentication and user training are also simple, cheap and effective.
If you receive a fraudulent email, can be very useful to send a full forensic copy to an organization that is being spoofed, industry partners, and law enforcement.
When a user clicks forward in a mail client, the client copies the message’s content and attachments to a new message. The original message headers are not included.
In order to send a full forensic sample that includes the original message headers, the original message must be sent as an attachment in a new message. The process for doing this varies by mail client.
Email headers contain very useful information for tracing a message’s origin and troubleshooting its delivery. Email headers are written with the oldest headers at the bottom, and the newest headers at the top. By reading the headers in the correct order, you can see how the message was passed from one mail server to another, and the actions each mail server took along the way.
Most email clients have a function to display a message’s headers. The exact steps depends on the client.
I have written extensively about the DMARC email security standard, including publishing a comprehensive guide on how to implement it, with or without additional third party vendors. I also do a little consulting on DMARC deployment best practices. One of those consulting clients uses Proofpoint for their email gateway. They also use Dmarcian, a reasonably priced DMARC report analytics service that also publishes a ton of public content for the good of the community. We were considering moving the client’s DMARC policy from monitor only (p=none) to an enforced state (p=reject) after many hours of steadily improving the SPF and DKIM alignment of their email sources. As I took another look at the aggregate (rua) DMARC data in Dmarcian, I noticed something odd: Dmarcian was getting aggregate reports from all of the expected third party email recipients, like Google, Yahoo, Comcast, and the client’s industry partners, but I didn’t see any reporting from the client’s own Proofpoint gateways.