Spam using SMTP while password changed

F

Fidelity

Verified User
Joined
May 6, 2015
Messages
13
I have some troubles with a user sending spam on my Directadmin server. Yesterday one of my users sending out 500 spam e-mails (send limit), mainly to @yahoo.com addresses. I checked the logs and it seemed as if it was send using SMTP. So my initial thought was that the users password probably had been compromised.

I notified the user, changed their e-mail password for the info@ account and just to be sure lowered the send limit for this e-mail account to 50 e-mails per day.

The next day (today), the send limit was again reached by 50 spam mails send out. To me this seems impossible since the user authenticated using SMTP details, I changed this yesterday and since then the password hasn't changed (back to the old value).

Am I missing something here? Was the mail NOT send using SMTP? Or how did this spammer manage to send out e-mails using an unauthenticated method?

One of the many entries in the 'SMTP out log' in the users account:
Code: 
2020-06-10 16:50:11 1jj23P-0000gp-Sz <= info@**** H=(localhost.localdomain) [45.77.***.**] P=esmtpsa X=TLS1:ECDHE-RSA-AES256-SHA:256 CV=no A=login:info@**** S=13749 [email protected] T="=?UTF-8?B?SW1wb3J0YW50IEluZm9ybWF0aW9uIC0gVFYgTGljZW5jZSBjb3VsZCBub3QgYmUgYXV0b21hdGljYWxseSBSZW5ld2" from <info@****> for ****@yahoo.com

Headers taken from above e-mail from the Directadmin admin account 'Mail Queue Administration':
Code: 
1jj23P-0000gp-Sz-H
mail 8 12
<info@****>
1591800611 0
-received_time_usec .898888
--helo_name localhost.localdomain
-host_address 45.77.***.**.34032
-host_auth login
-interface_address 149.***.***.**.587
-active_hostname ******
-received_protocol esmtpsa
-body_linecount 170
-max_received_linelength 216
--auth_id info@****
-host_lookup_failed
--tls_cipher TLS1:ECDHE-RSA-AES256-SHA:256
--tls_sni ****
-tls_ourcert -----BEGIN CERTIFICATE-----\nMIIGVTCCBT2gAwIBAgISAw0P/JI9/6hErzbA6MnyfTmQMA0GCSqGSIb3DQEBCwUA\nMEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD\nExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDA0MzAyMTEzNDJaFw0y\nMDA3MjkyMTEzNDJaMBoxGDAWBgNVBAMTD3NydjEuZmVkZWx0YS5tZTCCAiIwDQYJ\nKoZIhvcNAQEBBQADggIPADCCAgoCggIBAKtqvIAxy6r1pZRFp8pMoL0zl5zxa/oY\nNSivKD38yrrhhyIS8OvgYmF/n5TdM0vQzLkx57oHk7BdQj4L9QDwUrxgs7sDd2UZ\nnH28QlmOsmFLQEZQ4m8vNUSaAhXlLvR7RUl6TrHXiUtKekvKxzA32sar+fSfbfUo\nwymeOxAOZAcJiWTr4X77C5HtChV3QesOJprbJTN7P5qMv3nitQyH+Py6lErrs7/w\nRkFdHmeERs2bOB1+FcUGsWsDxTfYuFyoFcMpsDfm9PWzyfOeRfX4Z+lLTiE7+NvX\nEdDW1vzFHkyv4KE6u37xCZRFGKKRgxUOdnQ44QFS+d9Xrhf9gFJcxochkcmmU6DR\neLzz8xHFdb/YNsWlFSxOilY0VkEBcwEn855Vjv5bSGrVFEBYT+qEtyp6L2rRV3Pj\n4k238GdqbyuJNcG76bzKz9TbB8P7a/Tg/8+5KcfF9afQv8ZvehF0yCce2bbRv/vN\n4ARguNoJ4F/QIwLqt/EaPGqtW5B/nhQNJbhKe4tc2O8+GeDvNfSvHquNnIcbZLqQ\nsfutCXC6C5FnawnRQfv1pamrJjfJNPPu9wURCrvKVMyL2JLIO0wYctzDClG5CW6G\nHCTFwvGcT7i2VY6BOsSSf6/baY9P+M2oOTuP/BpnBfAVisF/LQBhqvgqI5pak0DX\n9Zy4semyoV7BAgMBAAGjggJjMIICXzAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYw\nFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFI2I\nSRjEnkG6x8k2yLpDe1ydyDDrMB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/z\nqOyhMG8GCCsGAQUFBwEBBGMwYTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AuaW50\nLXgzLmxldHNlbmNyeXB0Lm9yZzAvBggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50\nLXgzLmxldHNlbmNyeXB0Lm9yZy8wGgYDVR0RBBMwEYIPc3J2MS5mZWRlbHRhLm1l\nMEwGA1UdIARFMEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEBMCgwJgYIKwYBBQUH\nAgEWGmh0dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIIBAwYKKwYBBAHWeQIEAgSB\n9ASB8QDvAHUAsh4FzIuizYogTodm+Su5iiUgZ2va+nDnsklTLe+LkF4AAAFxzScV\nGQAABAMARjBEAiAuz29V64bEMzo/iV4ADHVXohkG6Lon+5hGvuaEGmZMbQIgX6pd\nnaDOJsT35xELK8hyR/Be3KD6tA9dO62sw5xVOpcAdgBvU3asMfAxGdiZAKRRFf93\nFRwR2QLBACkGjbIImjfZEwAAAXHNJxVnAAAEAwBHMEUCIA+ArQWVKHU8FmlyCbJX\npLaPXykgWtT6woOcIovD50qxAiEAudKuMCblVWErNdZLlbA1u+kGlIRkqALBfj7K\nWmZJ+TMwDQYJKoZIhvcNAQELBQADggEBAI15MPBWq9LtB0v2Dxy5XnyHFmYp7NoT\nGhMahmzqtUBEPwLOBsLI55yD3yanI4l8LPGIgDFfhPUbaNgFbWwU35cNzpainKCh\nbhPbH3SGD2AQPFOjY5i92YJ3Fdefn8fhgIJqz3OXbhMYY5++7ILctUrc9Tk9vA+w\n2bd1ppQIzI15BdkcG2y1iDDs/XnVccDKMlER0W6ZNAZpu91Ehl6gRKaGIYulQ7f/\nUPVd1XjfGxalbPJtSYokSJFBpyR+2wUzesPg5zufEIreZx//1vzfIRiXOFsenVp4\nfgSVpVXr84ybEnEzn/tvEIdl5sK0ArEZvN35xIaJSMSttkgLuX6rpig=\n-----END CERTIFICATE-----\n
--tls_ver TLS1
XX
1
****@yahoo.com

276P Received: from [45.77.***.**] (helo=localhost.localdomain)
    by **** with esmtpsa  (TLS1) tls TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
    (Exim 4.93.0.4)
    (envelope-from <info@****>)
    id 1jj23P-0000gp-Sz
    for ****@yahoo.com; Wed, 10 Jun 2020 16:50:11 +0200
038  Date: Wed, 10 Jun 2020 14:50:11 +0000
034* Return-Path: info@****
025T To: ****@yahoo.com
102F From: =?UTF-8?B?VFYgTGljZW5zaW5nIDxkb25vdHJlcGx5QHR2bGljZW5zaW5nLmNvLnVrPg==?= <info@****>
217  Subject: =?UTF-8?B?SW1wb3J0YW50IEluZm9ybWF0aW9uIC0gVFYgTGljZW5jZSBjb3VsZCBub3QgYmUgYXV0b21hdGljYWxseSBSZW5ld2VkIChZb3VyIGJhbmsgaGFzIGRlY2xpbmVkIHRoZSBsYXRlc3QgRGlyZWN0IERlYml0IHBheW1lbnQpIC8gUmVmVFZMOiA=?=ox8busueadh
069I Message-ID: <[email protected]>
014  X-Priority: 3
030  X-Mailer: PHPMailer 5.2.2-rc2
018  MIME-Version: 1.0
034  Content-Transfer-Encoding: base64
039  Content-Type: text/html; charset=utf-8

The 'interface_address' ends with port 587 which means SMTP should've been used, correct?
-interface_address 149.***.***.**.587

As far as I can see SMTP using port 587 has been used to send the e-mail and also authenticate the user. Even though I changed this users e-mail password yesterday, it's still sending out spam on the same address again today.
 
Is it possible that the email was in the queue before changing the password. After changing the password you have to also clean out the mail queue of the spam.
 
How can I check if there is mail left in the queue? The 'Mail Queue Administration' in the admin interface only shows a handful of e-mails, all are bounces.
 
Mail Queue Administration is where to check.

Also are there any open exim connections?
 
There is 1 open connection right now (exiwhat):
Code: 
  839 daemon(4.93.0.4): -q15m, listening for SMTP on port 25 (IPv4) port 587 (IPv4) and for SMTPS on port 465 (IPv4)

Also the mail queue is empty.

I didn't check the mail queue yesterday after changing the password, so that could be it. But I can only know this for sure tomorrow when the send limit resets or by increasing it now.

Any other stuff I can check or what this can be?
 
This will show all the email from or to info@****. Look for failed login attempts.

Code: 
exigrep info@**** /var/log/exim/mainlog
 
I actually see no login attempts at all. The log is filled with rejected messages, but other than that I see no other details.
 
To me this seems impossible since the user authenticated using SMTP details, I changed this yesterday and since then the password hasn't changed (back to the old value).
Click to expand...
There is another option. An infected computer with malware, had that a couple of times too. However, since the helo is localhost.localdomain this does not look like a Windows pc to me, and malware on linux is not that much. However not impossible.
 
Richard G said:
There is another option. An infected computer with malware, had that a couple of times too. However, since the helo is localhost.localdomain this does not look like a Windows pc to me, and malware on linux is not that much. However not impossible.
Click to expand...
But the password has been changed, so doesn't matter if there's malware on it or not right? Assuming the client didn't enter the new password in their PC yet.
 
Fidelity said:
But the password has been changed, so doesn't matter if there's malware on it or not right?
Click to expand...
Yes you would think that. But in a couple of cases I had, the password was mailed and catched by the malware (or was send plaintext) and in another case a keylogger was installed so the first time the new password was used, problem occured again.

It's hard to find another reason that newly created smtp passwords are abused again.
 
Richard G said:
Yes you would think that. But in a couple of cases I had, the password was mailed and catched by the malware (or was send plaintext) and in another case a keylogger was installed so the first time the new password was used, problem occured again.

It's hard to find another reason that newly created smtp passwords are abused again.
Click to expand...

Yup if hacked password change is often not the best solution, such mailaccounts are abused and on abuse lists, also on spam lists, on phising list a lot very lot.
I close them and give custommers an other mail account.
Set all the limits to 0.1 or so or 1 for that hacked account, eventually short times using for receiving mail, for the tiem new emailadres has to be known.

Also scan for login and sending mails then if you set limit to 1 then you get a error/warning message in log then you can see which ip's if belonging to custommer warn them to get that box of the web.

Still after years you see in log files lot of brute force attacks for those accounts, never go away even if account is not there.
 
You might also block the ip which is abusing the account and sending the mail.
Which would be:
Received: from [45.77.***.**]

Which is not a solution but can prevent spam for a little time so you can find a solution.
I always post unmasked ip's of abusers, if they want to spam, they lost the right to masking their ip imho.

However, if this is the ip of your customer, then you can be assured their system is infected.
 
Problem seems solved! :) Was probably some mail left in the queue, nothing has been sent out today
 
I think the email queue was empty only after all the spam was sent. The only reason he knows any spam was sent was because of the DirectAdmin message which he didn't get until it was all done.
 
floyd said:
I think the email queue was empty only after all the spam was sent. The only reason he knows any spam was sent was because of the DirectAdmin message which he didn't get until it was all done.
Click to expand...
Exactly haha... it probably wasn't empty before that. But when I posted here, it was. And after that the problem didn't appear again.
 
Richard G said:
You might also block the ip which is abusing the account and sending the mail.
Which would be:
Received: from [45.77.***.**]

Which is not a solution but can prevent spam for a little time so you can find a solution.
I always post unmasked ip's of abusers, if they want to spam, they lost the right to masking their ip imho.

However, if this is the ip of your customer, then you can be assured their system is infected.
Click to expand...

Richard makes sense if total mailsystem is infected there, but if only a part or one device, they don't want to be shut off for the rest of them haha. ;)

I inform to take that system down.

While setting limits send to 1 is ok then ( if the user fails to switch that system of they wil see and complain so you know who the user of that device is mostly) for that account or block that one emailadres
 
Last edited:
ikkeben said:
Richard makes sense if total mailsystem is infected there, but if only a part or one device, they don't want to be shut off for the rest of them haha. ;)
Click to expand...
I was talking about an abusing ip, not being the customer, for example chinese or russian ip or something else. They don't need to visit the rest of the server if they are spamming. :)

I also often inform, but also it's often users with dynamic ip's doing this and mostly nothing is done about them.
And writing those mails with logs takes time too so I rather block them. But as said, as log as it's not customer.
 
You must log in or register to reply here.
Back
Top