Spammers Hijacking Email Accounts

dolphyn

Well-Known Member
Nov 27, 2001
64
0
306
cPanel Access Level
Root Administrator
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
Code:
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

Well-Known Member
Mar 1, 2008
122
1
66
cPanel Access Level
Root Administrator
We've definitely noticed a distinct uptick in the number of failed smtp auth attempts across several of our managed servers including cpanel...
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,913
2,202
363
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.
 

talk2prakash

Member
Sep 29, 2013
14
0
1
cPanel Access Level
Root Administrator
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

Well-Known Member
PartnerNOC
Mar 6, 2008
68
4
58
Southfield, MI
cPanel Access Level
DataCenter Provider
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.

Code:
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.
 

nxds

Well-Known Member
Jan 6, 2006
53
0
156
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:

Code:
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):

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

mtindor

Well-Known Member
Sep 14, 2004
1,363
65
178
inside a catfish
cPanel Access Level
Root Administrator
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

Well-Known Member
Aug 10, 2002
1,983
218
343
cPanel Access Level
Root Administrator
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

Well-Known Member
PartnerNOC
Sep 26, 2006
833
28
178
Virginia Beach, VA
cPanel Access Level
DataCenter Provider
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.
 

jols

Well-Known Member
Mar 13, 2004
1,110
3
168
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

Well-Known Member
Mar 13, 2004
1,110
3
168
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

Well-Known Member
Mar 13, 2004
1,110
3
168
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

Well-Known Member
Dec 11, 2012
48
0
6
cPanel Access Level
Website Owner
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?
 
Last edited:

SageBrian

Well-Known Member
Jun 1, 2002
416
2
318
NY/CT (US)
cPanel Access Level
Root Administrator
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?
 
  • Like
Reactions: HOTNET