How the Compromise of a User Account Lead to a Spam Incident

Published: 2014-03-22
Last Updated: 2014-03-22 15:34:20 UTC
by Guy Bruneau (Version: 1)
3 comment(s)

ISC contributor Simon transmitted the following results of their investigation to the local users of their forum highlighting how a safety lapse on a user machine resulted into some dramatic consequences. It highlights the IR steps taken by the response team to cleanup, return the mail service in operation and dealing with the aftermath of the spam campaign.


Late last night we had an occurrence that raised a red alert on one of our servers indicating it might have been compromised. We received notification from the abuse department of our ISP, that our servers were transmitting spams.

We immediately shut down all e-mail services then started to analyse the log files.

We found that all spams had been sent using a particular user account on this very server, that user enjoying the privilege of an e-mail account on this server. A whole botnet was participating in "delivering" the spams for distribution by our servers.

Further analysis of log files as well as packet captures showed that there had been no occurrence prior to the first login to the user's account, no attempts to break into that account was registered. The first attempt to log into that account already used the correct password.

We changed the password of that user, effectively taking control of that account away from that user, removed more than 17,000 spams still waiting to be delivered from the server's mail transmit queue, and began to partially restart the mail services until all mail servers were operating in full again with no further anomalies.

While we are waiting for reply from that particular user, who had instantly been notified about the issue as well, we can only assume what may have happened: we believe the user's computer has been compromised and the credentials for this server as well as possibly other sites (including telebanking etc.) have been stolen. That way the spammer then could use the correct password for the correct account a short while later and started his spam campaign.

In the meantime we are continuing to work on that affair to ensure, that ISPs affected by the spam campaign get to know about the result of our analysis (the whole spam campaign was stopped within one hour), also in the attempt to limit the impact of spam protection which might blocklist our e-mail servers.

The occurrence highlights the dangers of the highly networked environment we are operating in. A user's PC being compromised is not just a local event, it affects the user's ISPs and mail service providers, the banks the user works with. A compromised PC thus provides not only headache to the owner of that PC for exposing private and confidential details to others, but also a lot of headache to other people who provide service and trust in the PCs being handled securely.


Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

3 comment(s)


It could easily have been something much simpler, a phishing email that the user responded to and gave up their own credentials. We had this happen a few times despite repeated advisories regarding phishing emails and in those cases the attacker used our own web mail server to send spam. Changing the user's password was insufficient as subsequent attempts would result in the account being locked, we had to give the user new logon credentials.
I would agree with the other poster about the source being as simple as Phishing. We see this hundreds of times per year. Prior to implementing a rate-limiting system, an authorized user could easily send millions (yes, millions) of messages within a *very* short period of time. Resetting the password is not sufficient. Typically the application has authenticated against the password store already and the cache for that application is used instead of re-authenticating to the store. Therefore, the unauthorized user probably still has an active session to your mail interface. When we see this happen, we typically reset password, disable the account, and kill all active sessions and authentication tokens. Once the new password has propagated through all caches (a few hours), we allow the account to be re-enabled. However, we will not enable the account until we talk (by phone) to the user (and yes, we verify this user by information we have on this user). Any other form of communication could easily be intercepted by the unauthorized person who has the credentials. The account is question is reviewed for activity and is monitored going forward to identify any new anomalous activity.
It's actually most likely 'same password everywhere syndrome'. And they didn't follow Adobe/Linkdn/Sony/Target/whomever's advice to change their passwords EVERYWHERE not just there.

I've had users with no indication of a virus, using TLS to connect, that swear up and down they never have answered a phish mail or other social attack, but hey they shop online at Target, or maybe they had an Adobe account, or whatever. And they use the same password everywhere.

One thing I will do with a compromised account is grab the password hash and throw it at my cracker and see how long it takes to get it. (We do not store an unhashed copy of the user's password in plain text anywhere). It's always fairly low hanging fruit, taking less than a day to recover using rules based dictionary attacks in olc hashcat (the system has 3 video cards that are a couple of years old and were ~$200 each new). Several of them have looked good at first glance but since the rockyou compromise taught them a lot about how people do passwords (their database was plain text) it's much easier to recover more these days. 12Pa$$W0Rd#$ isn't enough anymore.

(I hashed that particular string using a half dozen or more different popular salted and unsalted methods and ran the cracker on it. I got it within a day each time).

The Email password is the key to the kingdom. I have a different one on each email account I use and that's the only place they are used.

I generally have between 4 and 6 of these a month. Rate limit, virus, and spam check outbound. Monitor login activity for unusual IP addresses or sudden bursts of lots of logins from many IP addresses. If you are just getting into the mail sending business force the from address to match the sender's account email or aliases and force logins for any relay. Makes it easier to track and clean up. Depending on your authentication stack, you may need to restart all the parts of your mail server (smtp, imap/pop, store, and or authentication) to clear cached credentials. On our mail server if I login via pop, imap, or smtp, close the connection, then use the management console to change the account's password the smtp server will still accept the old credentials for up to 6 hours (that I've tested, it may go longer). Pop and imap will stop accepting the old password within 30-40 minutes. I've found that doing a restart on just part of the system is not enough and will do /etc/init.d/etc stop's on everything then start them back up in the right order for an orderly full mail stack restart.

Diary Archives