APT and Sendmail Monitoring

APT 41, one of many groups that have targeted the NMRC servers. Picture is from an FBI Wanted poster.

If you’re curious about monitoring for APT actors in general, this approach may give you some ideas. Granted this particular monitoring effort certainly isn’t going to apply to everyone, but if you run your own email server (in my case Sendmail) for your mail services and wish to monitor your incoming email for known malicious actors then read on.

How This Started

In Sendmail there is a database located at /etc/mail/access.db. This database is used to make some decisions about incoming email including whether to allow or deny the email. You can specify certain email addresses as allowed or denied, but you can also block specific domains up to and including specific countries or even top level domains. This can also apply to IP addresses, and you can even block entire class Cs and class Bs. I’ve added to this file since last century, the source file to build the database (/etc/mail/access) is over 26k lines long at this point. Spam, scams, malware-attached emails, you name it - added to the database. I cover a lot of this in an old blog post.

As far as APT goes, I have a set of indicators that includes known domains and source IP addresses used by specific APT actors to send spear phishing emails, plus I have specific source email addresses associated with APT actors as well. I typically don’t want to “tip my hand” by rejecting the email outright as that lets the actor know I am specifically blocking that email. By doing a “DISCARD” instead of a “REJECT” simply discards the email after receipt instead of delivering to an inbox, whereas if it is rejected there is an error message returned to the sender. Most of the short list of indicators came from actual attacks, but as I used to work for MITRE and some of the attacks that my employer would see would also go after my home system, work did allow me to copy over extra ones for home monitoring, with the idea I’d let them know when something triggered. This even continued after I left MITRE, which I’ve blogged about before.

Every once in a while I will receive a message with some suspicious attachment or website link, and if I have extra time and I’m bored I might explore and investigate it. I do it because I find it fun and often rather educational. I did this recently and made an interesting discovery - the phishing email sender address was associated with a known APT group. In that bit of research, which covered APT-41, I found a list of indicators including email addresses so instead of just adding in the one that I got I added in all of them. Imagine my surprise when I discovered that I had “duplicates” when I was adding them into the /etc/mail/access database - I had apparently received others, noted they were just malicious and had added those email addresses in already without any research. Interesting indeed. I decided I wanted to try and set up notifications in some way, maybe add a note or reference to the /var/log/mail.log file and then set up some type of alerting process.

Setting Things Up

Sendmail does have a lot of ability to do all kinds of manipulations and whatnot at a low level within the SMTP stack, so to speak. Using a specific configuration file - the sendmail.mc file which is written in the m4 macro language - I could set up a new /etc/mail/apt-indicators file just like my /etc/mail/access file and have things search that as well, and maybe add some custom logging. Or I could use the field where I’d normally tag things with the DISCARD and REJECT values, and set up a customized thing to operate off of my specific tag. However, in my research for solutions in this area it was proving to be so utterly complex and I decided against it. It’s not like there are a ton of resources online that could help me anyway. I needed to find an easier way.

I really preferred the DISCARD method, which lets the sender think the email went through, when instead it simply just discarded it. I already discard thousands of email addresses, domains, countries, some entire ISPs, and IP ranges (again outlined in previous blogposts) due to tracking and noting spam, scams, malware attachments, phishing and whatnot going back to last century when I set up email for the nmrc.org domain. So the /etc/mail/access file is huge.

In this massive /etc/mail/access file there is an APT section, and I simply changed a couple of things. This (using an example from a decade ago):

# APT 18 - Wekby
104.233.133.43  DISCARD
avangils@adobe.com      DISCARD
bitcoininthenews.com    DISCARD

would become this:

# APT 18 - Wekby
104.233.133.43  ERROR:550 5.7.1 APT-18 blocked
avangils@adobe.com      ERROR:550 5.7.1 APT-18 blocked
bitcoininthenews.com    ERROR:550 5.7.1 APT-18 blocked

The APT actor is not alerted and thinks the email went through, the email is discarded, and it gives enough info in the logs so I can actually identify the triggering event as well as the associated APT group.

The Results

With a simple bash script running just past midnight via a cron job, I can see if any occurrences happened the previous day. I may in the near future set up near real-time tests, but considering it is often weeks between APT phish attempts I am not as concerned. At least now I get a daily report. For the curious I’ve put the bash script up online in case you are interested.

Hopefully this little scenario shows you some interesting techniques of getting an existing piece of tech to spit out useful information in a way that helps you stay slightly safer, or at least somewhat aware of security threats. I know for the few people out there still running their own Sendmail servers, they love this kind of stuff.