Preventing Email Spoofing
I heard from one of our users that all of a sudden they were getting massive amounts of what appeared to be responses to emails allegedly coming from them. Looking at the emails they looked to be returns from unused email addresses, vacation, notices, out of office notices, etc.
I keep meaning to stay on top of this blog, but time keeps getting away from me and it gets neglected. Today I came across an issue at work that I hadn't previously dealt with (to this extent): Email Spoofing.
For our domain, we have set up all the records to prevent this - or so I thought. SPF, DKIM, DMARC all set up and testing and passing verification on email headers for our domain. These are all simple TXT records in your DNS that verify who the emails are coming from and in theory will be sent to a users spam folder if it appears to be coming from another source.
These records are fairly trivial to set up and increase deliverability and make sure your emails get where they need to go. Google has some easly to follow steps for defining SPF records, setting up DKIM, and setting up DMARC.
I heard from one of our users that all of a sudden they were getting massive amounts of what appeared to be responses to emails allegedly coming from them. Looking at the emails they looked to be returns from unused email addresses, vacation, notices, out of office notices, etc. Immediately our first course of action was to generate a new password for the account and ensure 2FA was enabled. After a new password is generated, all sessions become stale and require a re-login, so assuming this was coming from malware on the users computer, these emails should have stopped.
I had them run Malwarebytes to look for any malware infections, I've had the most success with their tools for finding and quarantining infections. I don't generally like to keep the software installed because it can get a bit annoying, but as a one-off for scans, it works great. It reported no infections and the email rejections were still coming so we knew they were still being sent.
I made sure that this account had no application passwords enabled and no sessions on any unknown devices, so that wasn't it... I was able to inspect one of the headers of the emails from a portion that was sent back as a response to a rejection of an email and I found a source IP - great, let's add it to a block list for our email provider.
First I wanted to find out more about the IP, so I threw it into Greynoise which always has great information on sketchy IP addresses, but it returned nothing. Odd.
Traceroute isn't much help either, it goes for 5 or 6 hops then dies out, no destination reached.
Adding this IP to a block list to reject email sent from it had no effect.
At this point, I'm getting a little stressed, I'm assuming we may just have to ride this out and hope that the validation records we put in place will direct most of these emails to people's spam folders. The report I'm getting from many of these rejections is showing a virus attached labeled as a CVE (sadly I can't recall which one it was at the moment) so I'd hate for people to actually get infected from this.
Finally, I asked for a second person to take a look and see what they thought - I'm running out of ideas here. Looking at our DMARC record more closely, I had set up DMARC and it was working properly, but only as far as I had defined it. I had the policy set to none, which effectively does nothing to the emails which don't pass the verification. Sure, these will be marked as suspicious and in many cases sent directly to spam, but it's not actively doing anything to prevent them from being sent out. Here's what a DMARC record looks like:
"v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"
What this specifies is v, version of DMARC, p, policy, and rua, the email address to send the reports to. none is the default policy setting and is good to start with when you're setting up SPF, DKIM and DMARC so that your normal emails aren't lost or rejected while things are propagating. HOWEVER, after your settings have been verified and you can see that your SPF and DKIM records are working properly, this policy should be set to reject so that anything that doesn't pass verification will actually be rejected and not sent through.
Live and learn.