My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

SMTP Brute Forcing

Published: 2015-06-22. Last Updated: 2015-06-22 16:34:20 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

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

4 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

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.
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: http://pastebin.com/FPiFiiUD

/x
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.
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.

Diary Archives