Spammers Hijacking Email Accounts

[dolphyn]

Spammers seem to have found a new way to exploit mail servers. I'm seeing a pattern of spammers authenticating once and sending 2-3 messages, each to dozens of recipients, and then it stops.

Many of the messages contain a URL and no other content, often with somebody's name as the subject line. Many of these messages are rejected by Yahoo with a [PH01] error message.

The spammer's IP address varies, representing countries where we have no customers, including Morocco, Turkey, and Tunisia.

But in each case the spammer stops after 2-3 messages, leading me to wonder if the spammer "faked" authentication somehow or if they actually obtained the user's credentials.

The spammers have consistently used "mycomputer" as the HELO or EHLO name, so currently it's pretty easy to see if you've been affected. If your logs are in the usual place, just run

exigrep mycomputer /var/log/exim* | more

and look for mail going to multiple addresses.

I first noticed the problem on a Windows server running "SmarterMail," so the issue is not specific to CPanel or Exim. Many others have seen similar issues, as evidenced by responses to my post
here (SmarterTools Community Forums).

 

[robb3369]

We've definitely noticed a distinct uptick in the number of failed smtp auth attempts across several of our managed servers including cpanel...

 

[dalem]

this is not new but there has been a definite upswing in the amount of disturbed attacks the last couple of weeks

 

[kernow]

The spammers have consistently used "mycomputer" as the HELO or EHLO name,.

Yep, been seeing that also

 

[cPanelMichael]

The spammers have consistently used "mycomputer" as the HELO or EHLO name, so currently it's pretty easy to see if you've been affected.

The following options under "ACL Options" in "WHM Home » Service Configuration » Exim Configuration Manager" might help to block those emails:

"Require RFC-compliant HELO"

Thank you.

 

[kernow]

The default for that option is already "on"

 

[talk2prakash]

Check whether smtp restriction is on in your whm.

Also check the emails in the queue to determine the source of the spam. Whether the spam is sent from the website script or from outlook express etc using email headers...

 

[acenetgeorge]

We're seeing the same thing, and they are direct email logins. So somehow the email passwords were compromised. Maybe a Distributed brute force of the passwords. We see those every once in a while.

We are using the following command to pull out the compromised email addresses, and are randomizing the passwords. We then notify the client to login to cPanel and reset the passwords, but use more secure (and unique) passwords.

grep mycomputer /var/log/exim* | grep 'A=courier_' | awk -F'courier_' '{print $2}' | awk '{print $1 " " $3}' | awk -F':' '{print $2}'

Not the prettiest code, but it works.

 

[chrisbuk]

Anyone spoke to CPanel support about this?

 

[nxds]

Seeing this too on 3 different cPanel servers. It's quite alarming how many accounts have been compromised. Any ideas how they've done this?

This code will get a list of compromised addresses:

sed -n 's/^.*H=(mycomputer).*P=esmtpa A=courier_plain:\(.*\) S=.*$/\1/p' /var/log/exim_mainlog | sort | uniq

And this will get a list of IP addresses that you can append to csf.deny (e.g. by adding >> /etc/csf/csf.deny to the end of this command):

sed -n 's/^.*(mycomputer) \[\(.*\)\].*P=esmtpa.*$/\1 # do not delete/p' /var/log/exim_mainlog | sort | uniq

 

[serichards]

Most likely is weak and guessable passwords or using non encrypted means to send login credentials.

An SSL vulnerability has been published recently that is in macosx and ios. Latter has been patched. Apple Safari, Mail and more hit by SSL spying bug on OS X, fix 'soon' This would allow decrypting of SSL data so passwords could be stolen if the person were using public wifi.

 

[mtindor]

That subject line is misleading. There is no cPanel exploit causing this to happen. This is happening across all mail platforms.

Passwords are being stolen either via brute force (weak passwords), viruses on client computers (more often than you think) or by data leakage. For the latter, think about this -- a person re-uses their email password as the password for logging into various websites [ex: Adobe]. Email credentials are leaked via a website breach and people attempt to use those passwords against your other accounts, which is successful if you re-use your passwords all over the place.

Add to that the ability to leverage a botnet to slowly [sometimes] and methodically brute force POP3 / SMTP Auth and then send out low-volume spam from each hijacked account in an attempt to stay under the radar.

Rarely do I see a single email account get hijacked and then a single IP used to send a massive amount of spam anymore. Instead, I see multiple email accounts breached [ahead of time] and then a botnet of random remote IP addresses authenticating with those credentials and relaying low-volume, non-constant spam. One spammer sending 6,000 spam from one account gets noticed pretty quickly. One spammer, sending 30-60 emails from 100 hijacked accounts is much more successful. These incidents don't usually happenly constantly throughout the year. You'll notice lulls in this activity. The people doing it are busy collecting SMTP auth credentials from hijacked accounts. When they have enough stored up, then they pull the trigger and let loose. Then, suddenly out of nowhere, everyone starts reporting that email accounts are hijacked on their cPanel / Smartermail / Mailenable / Imail / Merak / Mdaemon / etc servers and think it's an exploit against the server.

I firmly believe [as has been the case for at least the 1+ years that we've seen this activity] that it's simply a case where clients (your customers and my customers) can't manage to (a) use secure passwords, (b) not get viruses, (c) not re-use passwords across accounts. Your / my clients are directly responsible for the vast majority of this.

M

 

[sparek-3]

I firmly believe [as has been the case for at least the 1+ years that we've seen this activity] that it's simply a case where clients (your customers and my customers) can't manage to (a) use secure passwords, (b) not get viruses, (c) not re-use passwords across accounts. Your / my clients are directly responsible for the vast majority of this.

Well said.

I initially thought this might be some kind of server-side exploit because I was seeing a larger than normal number of hijacked accounts. But I also wasn't seeing the number of hijacked accounts that I would expect if it was a server-level exploit.

I suppose the SSL vulnerability that was referenced earlier in this thread could be partly to blame. And that would put the blame more on the developers and vendors of that software than on the end-user.

But there is also just a very, very vast misunderstanding by end-users when it comes to security. End-users are way too casual with their passwords and overall security. Until this is solved (and I don't know what the solution is) you're going to continue to see "exploits" like this happening.

 

[vanessa]

I suppose the SSL vulnerability that was referenced earlier in this thread could be partly to blame. And that would put the blame more on the developers and vendors of that software than on the end-user.

But there is also just a very, very vast misunderstanding by end-users when it comes to security. End-users are way too casual with their passwords and overall security. Until this is solved (and I don't know what the solution is) you're going to continue to see "exploits" like this happening.

I disagree with this. There really isn't a cure for stupidity. cPanel/Apache/whateverdevelopersyourereferringto can continue to make their products more and more secure, but when you expose these items to end users that do dumb things, you can't put the responsibility back on the vendors. cPanel does let you set password security thresholds on passwords your users choose, so perhaps consider that a step forward.

This has happened on our servers countless times, and we by now have scripts that mass-change the affected email accounts and notify the customers. While this doesn't prevent what already happened, it at least helps ensure that those users are less likely have have the same problem again. You can also consider looking at outbound spam protection (also a feature you can enable through WHM) and creating custom SA rules to help minimize the impact the outgoing spam has on your entire server when these compromises occur.

 

[Infopro]

Thread title updated to be a bit more relevant.

 

[jols]

I've just made out a cpanel.net ticket for this one.

There is definitely something usual going on with this. Here's what we have observed so far:

The pattern has been consistent.

1-- The exim log always includes "(mycomputer)"

2-- The hosted email account apparent relaying the messages only contain "A=dovecot_plain:[email protected]" rather than what we normally see, for example:

"A=dovecot_login:[email protected]"

Note: "dovecot_plain" vs. "dovecot_login"

3-- The number of email addresses relayed in each burst, is usually about the same, 10 to 20 addresses (BCCed I believe).

4-- The originating IP addresses are nearly always from countries like Korea, Africa, Argentina, Ukraine, and so on, i.e. never from anywhere close to where the hosted customer does businesses.

Right now I am looking for a way to drop any connection attempt to Exim, if "mycomputer" is in the incoming header. Anyone?

 

[jols]

As it turns out, the "dovecot_plain" aspect signify plain text logins.

The upshot is, the email accounts in question, have simply had their passwords exploited.

Now, thanks to a pointer I received just now I am attempting to implement the following in the Advanced Exim Configuration, in custom_begin_smtp_helo, but when I did this, the server started rejecting all email as invalid helo:

deny condition = ${if match {$sender_helo_name}{mycomputer}}
message = "Your server is spamming!"
log_message = "Attempted spam message"

Anyone know how this could be improved?

 

[jols]

Hmmm, so far I've tried all of these in custom_begin_smtp_helo, and we still get all email rejected for invalid HELO as a result:

deny condition = ${if match {$sender_helo_name}{mycomputer}}

drop condition = ${if eq{[mycomputer]}{$sender_helo_name}}

drop message = Spam HELO: $sender_helo_name is suspicious
log_message = Spam HELO: $sender_helo_name
condition = ${if match{$sender_helo_name}\
{mycomputer}}


Anyone have a clue as to how to make this work? TIA.

 

[serichards]

Why do you allow plaintext logins? First thing I blocked... There are a few settings to only allow secure logins so anyone using basic scripts would hopefully be stopped. It also reduces ability to sniff passwords.

I also wonder whether only having smtp on a non standard port would also help?

 

[SageBrian]

So glad to see mtindor and sparek-3 state what I thought was obvious. Users are the weakest link.

I've been getting these 'hacks', which are nothing but bots using known credentials. No guessing, no brute-force. Simple login and send. I've been catching them quickly, but the problem is all on the users. Even when they are told/taught/educated to update their passwords, and not use the same login info for every website, they continue to ignore.

I've also been seeing direct access into cpanel. Just this weekend, I first got a spam from a webmaster of a client's website. It came from their account, so I just figured another victim of weak passwords. Then, later that day, the client's cpanel is accessed and a couple of sub-domains added.
Next, phishing pages were created.

I cannot be sure as I have no way of tracking, but my quess is that bots got the webmasters login for their email. Then, it might have quickly scanned their mail (Yahoo account, but it could be any mail service with stored messages). Looking for any messages that might have login info in it.

The client's cpanel password was a random generated, 12 digit secure pw.

That Adobe breach in September was HUGE, with a wealth of info for figuring out logins. And how many people do you think bothered to change their passwords even when told to?