SMTP Brute Forcing - SANS Internet Storm Center

SMTP Brute Forcing
Brute forcing SMTP credentials is hardly new. But I have seen a couple of odd patterns lately in one of my mail servers, and was wondering if anybody has any insight into these patterns. For this diary, I am using logs starting May 31st until today. First, the overall patterns shows very strong spikes with 2000-3000 attempts per hour. These "spikes" usually come from many different IP addresses, so they are likely caused by a botnet probing my system. The last spike on June 19th was caused by about 400 different IP addresses (I am running fail2ban, and they are blocked after a couple of attempts). The usernames are where it gets a bit more interesting. Here is a list of the top 20: 6096 leonelfetuscrosby 3595 dan 3399 ix444ejxvwda050 2763 176 83 ncoppen 82 info 56 spam 53 admin 47 sales 34 abuse 28 paul 28 pager 26 test 23 support 21 awilloughby 20 webmaster 18 hr 18 d573697 17 help The part that is of some concern is that a couple of the users are actual users of the server. The "ranking" goes somewhat by the amount of e-mail created by the user in general, so it is possible that spamers do try usernames they already have in their database against mail servers used by their domain. I don't capture passwords, but the number of attempts for most of the usernames is small, so I assume only a couple of passwords are used. The first and third name are odd as they look "random". Could they be used to detect if the mail server responds differently for users that do not exist? --- Johannes B. Ullrich, Ph.D. STI\|Twitter\|LinkedIn I will be teaching next: Application Security: Securing Web Apps, APIs, and Microservices - SANSFIRE 2022	Johannes 4511 Posts ISC Handler Jun 22nd 2015
Thread locked Subscribe	Jun 22nd 2015 7 years ago
Observed bit increase in DNSBL-blocked SMTP attempts from 10-30 to 90-130: date conn uniqueIP May 17 8 6 May 18 35 29 May 19 27 25 May 20 83 77 May 21 86 85 May 22 91 88 May 23 88 87 May 24 84 79 May 25 109 104 May 26 100 95 May 27 109 109 May 28 86 85 May 29 114 109 May 30 104 95 May 31 85 74 Jun 1 94 88 Jun 2 121 115 Jun 3 85 84 Jun 4 89 83 Jun 5 92 87 Jun 6 104 99 Jun 7 93 88 Jun 8 81 76 Jun 9 104 99 Jun 10 127 121 Jun 11 128 124 Jun 12 112 108 Jun 13 107 105 Jun 14 109 103 Jun 15 110 105 Jun 16 62 50 Jun 17 30 26 Jun 18 12 10 Jun 19 29 23 Jun 20 15 14 DNSBLs zen.spamhaus.org b.barracudacentral.org hostkarma.junkemailfilter.com MTA does not permit AUTH attempts by DNSBL blocked IPs so don't know if this is the same attack. Normal 0-5 per day that get past the DNSBLs and are blocked subsequently remained constant throughout.	Starlight 34 Posts
Quote	Jun 22nd 2015 7 years ago
I'm facing the same here against my SMTP relay... Huge peaks of attempts then temporary blacklisted by my OSSEC and starting again and again. A list of identified IP addresses is here: pastebin.com/… /x	Xme 697 Posts ISC Handler
Quote	Jun 22nd 2015 7 years ago
Most bots only support plain text brute-force. We disabled plain text authentication on port 25, and some bots still attempt to login without STARTTLS. Now we disable AUTH LOGIN; and the attempts have dropped by quite a bit. We do get some attempts via SMTPS on port 465; but the frequency is not as high.	Mike7 43 Posts
Quote	Jun 23rd 2015 7 years ago
I'm blocking somewhere around 75% of IPv4 IP space on my SMTP server, so I'm not seeing stuff like this any more. If I recall, the last time I saw this, the remote machine generating the destination addresses was creating them but using the rDNS of my server's IP address as the email address. For example, if my ISP is "acme.com", and the rDNS of my static IP is random-stuff.acme.com, then I was being hit with mail being addressed to what-ever@random-stuff.acme.com. I've been hit with pop3 login floods in the past, and have published the list of user names to alt.spam and news.admin.net-abuse.email. So now I have my router take inbound port 109 and route that to my mail server internally on port 110 and all external mail clients perform pop3 logins remotely on port 109. No more pop3 login floods.	SpamGuy 1 Posts
Quote	Jun 23rd 2015 7 years ago

Brute forcing SMTP credentials is hardly new. But I have seen a couple of odd patterns lately in one of my mail servers, and was wondering if anybody has any insight into these patterns. For this diary, I am using logs starting May 31st until today.

First, the overall patterns shows very strong spikes with 2000-3000 attempts per hour. These "spikes" usually come from many different IP addresses, so they are likely caused by a botnet probing my system. The last spike on June 19th was caused by about 400 different IP addresses (I am running fail2ban, and they are blocked after a couple of attempts).

SMTP brute force over time

The usernames are where it gets a bit more interesting. Here is a list of the top 20:

   6096 leonelfetuscrosby
   3595 dan
   3399 ix444ejxvwda050
   2763 
    176 
     83 ncoppen
     82 info
     56 spam
     53 admin
     47 sales
     34 abuse
     28 paul
     28 pager
     26 test
     23 support
     21 awilloughby
     20 webmaster
     18 hr
     18 d573697
     17 help

The part that is of some concern is that a couple of the users are actual users of the server. The "ranking" goes somewhat by the amount of e-mail created by the user in general, so it is possible that spamers do try usernames they already have in their database against mail servers used by their domain. I don't capture passwords, but the number of attempts for most of the usernames is small, so I assume only a couple of passwords are used. The first and third name are odd as they look "random". Could they be used to detect if the mail server responds differently for users that do not exist?

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

I will be teaching next: Application Security: Securing Web Apps, APIs, and Microservices - SANSFIRE 2022

Johannes

4511 Posts
ISC Handler

Jun 22nd 2015

Observed bit increase in DNSBL-blocked
SMTP attempts from 10-30 to 90-130:

date conn uniqueIP
May 17 8 6
May 18 35 29
May 19 27 25
May 20 83 77
May 21 86 85
May 22 91 88
May 23 88 87
May 24 84 79
May 25 109 104
May 26 100 95
May 27 109 109
May 28 86 85
May 29 114 109
May 30 104 95
May 31 85 74
Jun 1 94 88
Jun 2 121 115
Jun 3 85 84
Jun 4 89 83
Jun 5 92 87
Jun 6 104 99
Jun 7 93 88
Jun 8 81 76
Jun 9 104 99
Jun 10 127 121
Jun 11 128 124
Jun 12 112 108
Jun 13 107 105
Jun 14 109 103
Jun 15 110 105
Jun 16 62 50
Jun 17 30 26
Jun 18 12 10
Jun 19 29 23
Jun 20 15 14

DNSBLs
zen.spamhaus.org
b.barracudacentral.org
hostkarma.junkemailfilter.com

MTA does not permit AUTH attempts
by DNSBL blocked IPs so don't
know if this is the same attack.

Normal 0-5 per day that get
past the DNSBLs and are blocked
subsequently remained constant
throughout.

Starlight

34 Posts

I'm facing the same here against my SMTP relay...
Huge peaks of attempts then temporary blacklisted by my OSSEC and starting again and again.
A list of identified IP addresses is here: pastebin.com/…

/x

Xme

697 Posts
ISC Handler

Most bots only support plain text brute-force.
We disabled plain text authentication on port 25, and some bots still attempt to login without STARTTLS.
Now we disable AUTH LOGIN; and the attempts have dropped by quite a bit.

We do get some attempts via SMTPS on port 465; but the frequency is not as high.

Mike7

43 Posts

I'm blocking somewhere around 75% of IPv4 IP space on my SMTP server, so I'm not seeing stuff like this any more. If I recall, the last time I saw this, the remote machine generating the destination addresses was creating them but using the rDNS of my server's IP address as the email address. For example, if my ISP is "acme.com", and the rDNS of my static IP is random-stuff.acme.com, then I was being hit with mail being addressed to what-ever@random-stuff.acme.com.

I've been hit with pop3 login floods in the past, and have published the list of user names to alt.spam and news.admin.net-abuse.email. So now I have my router take inbound port 109 and route that to my mail server internally on port 110 and all external mail clients perform pop3 logins remotely on port 109. No more pop3 login floods.

SpamGuy

1 Posts