[SANS ISC] Please fix your E-Mail Brute forcing tool!, (Wed, Oct 13th)

Recently, I am seeing a lot of identical failed login attempts against my mail server. Just today, about 130,000 of them. The vast majority (124k+) come from one subnet: 31.130.184.0/24

inetnum:        31.130.176.0 – 31.130.191.255
mnt-domains:    RER-MNT
netname:        RoshangaranErtebatatRayaneh
country:        IR
org:            ORG-RER3-RIPE
admin-c:        MRMG6-RIPE
tech-c:         MRMG6-RIPE

Brute force attempts by themselves are not that special, but these are in particular annoying as the tool they are using appears to be broken. Here is the complete login attempt (they all look exactly the same):

[Blue: data from server, Red: data from client]

It starts harmless enough with my mail server sending a standard banner

220 mail.localdomain ESMTP Postfix (Debian/GNU)

The “attacker” responds with an EHLO. The “localhost” is a bit odd, but well, I told them that I am mail.localdomain. So I will take that.

   EHLO localhost

As it should in response to an “EHLO”, my mail server will list its capabilities. Note that the client is not taking advantage of STARTTLS.

250-mail.localdomain
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 CHUNKING

Insert the Client “resets” the connect. Bit odd, and I probably should drop things here. But I am always interested in seeing where things go…

   RSET

So I am responding with a standard “OK”.

250 2.0.0 Ok

The client now attempts to “Login”

   AUTH LOGIN

As common for “AUTH LOGIN”, my mail server responds with a base64 encoded string “Username:”. I am sure the bot appreciates that my mail server tells it what to send next.

334 VXNlcm5hbWU6

The username, also base64 encoded, is “nan”.

   bmFu

For those of you familiar with Base64 (or standard logins), you will probably know what comes next: “Password:”

334 UGFzc3dvcmQ6

The password sent: Nan (upper case N unlike the username).

   TmFu

Sadly, this fails… and I send you an error telling you so.

535 5.7.8 Error: authentication failed: UGFzc3dvcmQ6

   QUIT

221 2.0.0 Bye

Ok. The attacker is going at this all day long, the strategy appears to be more “password spraying” than “brute forcing” as it does not attempt too many attempts on a particular account. I don’t believe they even bother with using leaked credentials of mine, but instead they just simply go for volume.

There are a number of ways how this attack could be a lot more effective:

Use more IP addresses. I long blocked that /24 and it still keeps coming.
Figure out if the usernames actually exist. It isn’t that hard. Don’t waste your time on nonexisting accounts
Use better password lists
Try this against a government network. They may (a) be not as well protected and (b) have more valuable data.


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Source: Read More (SANS Internet Storm Center, InfoCON: green)

You might be interested in …

[BleepingComputer] Angry Conti ransomware affiliate leaks gang’s attack playbook

A disgruntled Conti affiliate has leaked the gang’s training material when conducting attacks, including information about one of the ransomware’s operators. […] Source: Read More (BleepingComputer)

Read More

[ZDNet] Microsoft disrupted this large cloud-based business email scam operation

All posts, ZDNet

Microsoft uncovers how scammers used phishing and email-forwarding rules to target businesses’ financial information. Source: Read More (Latest topics for ZDNet in Security)

Read More

[BleepingComputer] Bot protection now generally available in Azure Web Application Firewall

Microsoft has announced that the Web Application Firewall (WAF) bot protection feature has reached general availability on Azure on Application Gateway starting this week. […] Source: Read More (BleepingComputer)

Read More