SmarterMail Compromised to Forward Emails
Problem reported by James Harris - April 11, 2017 at 2:50 PM
Submitted
I've been using SmarterMail for years, and recently we have been compromised. SmarterMail Enterprise Edition, Version 15.5.6222.
 
I take security pretty seriously, so the server does sit behind a firewall. It only handles email and SmarterMail, no other services. All remote ports are firewall blocked. IIS is even setup to Restrict IPs for the web service to specific allowed IPs only, so the web interface should be locked down and protected. All other mail services are wide open, but we do not use LDAP, IMAP, XMLL, etc (just POP and SMTP).
 
Yesterday, we started getting bounce reports that deliveries to a particular gmail account were failing (it actually was all gmail accounts, but one in particular repeated over and over).
 
Failed Recipient: gk8904@gmail.com
Reason: Remote host said: 601 Failed to connect to the recipients mail server. No MX records were found for the 'gmail.com' domain.
Status: 544 5.4.4 Host not found (not in DNS).Attempted to send the message to the following ip's:
216.58.193.197

After some investigation, it appears someone was able to configure 2 Content Filtering rules.
 
1: Delete all email containing "tucows"
2: Forward all emails containing "Checkout Notice" to gk8904@gmail.com.
 
It is my theory this was perhaps a targeted attack aimed at keeping us unaware of expiring domains they might be interested in. The second rule seems to be a rash decision to mine credit card data. The emails they were after contained some data on an e-commerce checkout process, but absolutely nothing of actual value. You would only assume this if you saw an email or two from this process and did not know the actual intent (cart abandonment).
 
Log checks show emails started going to this address on March 31st, so I have the date of the intrusion.
 
My questions are this:
 
1.) Given our security measures, what is the likely method of compromise, aka how was this ?
2.) What areas/logs can I check to help identify how this was done?
3.) What additional measures can we take to safeguard our system?
4.) What are some advanced services which we should disable? (our usage is pretty vanilla)
5.) I am not an expert email admin, so what else should I be aware of to better safeguard our system?

3 Replies

Reply to Thread
1
User Replied
Hi James. To answer your questions...
 
My questions are this:
 
1.) Given our security measures, what is the likely method of compromise, aka how was this ?
 
Where did they create these rules? Was it at the top level content filtering? The domain level? The user level?
 
2.) What areas/logs can I check to help identify how this was done?
 
Please answer question 1 first and then I can better help you with this question.
 
3.) What additional measures can we take to safeguard our system?
 
There are a few things you can do. Stronger passwords, virus and malware scanners on your customer's computers and your server. Don't save passwords in the browser.
 
4.) What are some advanced services which we should disable? (our usage is pretty vanilla)
 
What kind of advanced services do you currently have enabled?
 
5.) I am not an expert email admin, so what else should I be aware of to better safeguard our system?
 
Here is an article that my company wrote which gives plenty of great tips on how to prevent and handle compromised accounts: http://know.mailsbestfriend.com/papers/Handling-Compromised-Accounts.shtml
 
I hope this helps. Thanks.
1
Derek Curtis Replied
Employee Post
All
 
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.
 
We have a blog post about much of this. It was written awhile ago, but it's still relevant: 5 Ways to Avoid Being Blacklisted. That may offer some insight as well. 
 
EDIT: I just thought of this blog post as well: How to Find a Compromised Account. It may be useful as well. 
 
 
Derek Curtis
COO
SmarterTools Inc.
(877) 357-6278
0
James Harris Replied
The Content Filtering rules were created at the domain level. The delete rule affected all, but the latter "forward" rule in reality only affected one account.
 
I did speak with Derek about this for a time. We were unable to confirm HOW the content filtering rule was added. Our admin logs were set to delete after 2 weeks. At the time, this date butted right up against our timeframe. Derek believes the logs for admin access would have been deleted by this time, but I believe the logs were just in time to show a login. Either way, the message logs were turned on for much longer which supported the timeframe for when the rules were added.
 
Also checked IIS logs to look for any any access to Content Filtering through the admin panel. I could not find any evidence that the Smartermail Online Administration panel was used to add these rules (I saw the activity from the day it was discovered, but nothing within the past 2 years). Smartertools holds that the admin panel is the only means to add Content Filtering rules, and is unaware of any alternate means. IIS logs also did not show any unauthorized IP logging into the system, debunking the compromised credentials theory.
 
I reject the idea that a device with admin privileges was used (as a way to bypass our IP restrictions. My home office computer is the only one with such privileges. Someone would have to break into my home, during non-office and non-sleep hours, to do this. It's not reasonable. Leveraging other known credentials is not likely either given that IIS would show the access to Content Filtering rules, of which there was none.
 
Even after working with SmarterTools on this, we are both still at a loss to explain how these rules were even added in the first place.
 
Without solid information, we simply took some basic measures:
 
* Rechecked Hardware and Software Firewalls
* Explicitly Disabled several ports (161 - SNMP, 162 - SNMP Alt, 143 - IMAP, 993 - IMAP SSL, 389 - LDAP, 5222 - XMLL)
*Turned Admin Logging (and many others in Smartermail) to never delete, nor compress.
* Scanned server for all virus and malware threats (clean)
* Reviewed remote access logs, all clean
 
I have looked at OS level file monitoring for changes to the domain_Config.xml, but that is not viable due to frequent minor changes to this file almost every day.

Reply to Thread