First off, thanks, Linda for replying. I wanted to follow up on this as James actually submitted a ticket about this back when he started the thread. This isn't a necessarily unique situation -- we see situations like this every once in awhile -- so I wanted to post a reply and let the Community know what we found out, plus answer James' questions, in case someone else sees something similar.
Indications are that someone with knowledge of mail servers in general, and possibly SmarterMail specifically, accessed the account in question. The content filters being created is one indication of this. Unfortunately, the admin logs had been deleted from the server -- not maliciously, but by a rule set. The admin logs are what would need to be looked at to determine who created the content filters and where that user came from as the admin log details include the IP address of the user. So those being deleted prevented us from being able to determine who created the content filters.
As to how the user got in, chances are that one of the following occurred:
1. The person was able to leverage a known set of compromised credentials to access the domain settings, or
2. The person used a device that had domain admin credentials logged in, or saved to a browser, to access the account.
It's also possible that this was done by someone inside the company. However, that's difficult to determine, much less admit. That said, it may NOT be internal since the type of emails being forwarded on the checkout process, and the lack of actionable info in those emails, points to someone unfamiliar with the business. (Or someone with a rudimentary understanding of the checkout process.)
As for "advanced services" or other safeguards, here are some suggestions:
1. If you're not using services such as XMPP, LDAP, etc., these can be disabled outright inside SmarterMail.
2. Keep logs for at least 30 days, if at all possible. Especially admin logs, delivery logs, etc.
3. Ensure password complexity falls in line with NIST's standards.
4. Configure abuse detection rules on the protocols being used (POP/SMTP) for DoS and Session Harvesting. Configure events to notify the administrative team when one of these rules is triggered.
5. Internal Spammer notifications are recommended in the event of a compromised account being used to send spam. These can be configured to either notify and/or automatically disable the user to prevent the spool from filling up.