Attack against my Exchange 2013 lab server

I recently came across an attack on my Exchange 2013 lab server and want to share I saw. While this post isn’t directly related to EOP, it is certainly security related and a good reminder of what’s out there.

I have an Exchange 2013 lab server running in Microsoft Azure and was recently performing network captures on it. At the end of my work day I had a network capture running that was scoped to port 25 and forgot it running when I left the office.

In the evening I logged back in to the server to stop the network trace and was very surprised to see the network trace log scrolling very quickly with new traffic on port 25. The only traffic this server typically sees is from my own testing.

Just before 20:00 my server was connected to on port 25 from an IP that identifies itself with EHLO scanner.sslsonar.org (this seems to be a bogus domain). In this screenshot 10.0.0.5 is the private IP of my lab server.

It reaches out to my server on port 25 with an EHLO and my server responds with an SMTP Hello since I have not configured any restrictions on its Receive Connector. The above IP reverses to Amazon Web Services. It looks like someone has a VM in AWS that is running a port scanner.

Twenty-five minutes after the above connection, I start getting flooded with authentication attempts from a different IP (this IP resolves to the countries Antigua and Barbuda, however it could just be a proxy and not the actual origination of the attack). I currently have TLS turned off on my Receive Connector so all the data is clear in the network trace.

Here’s what I see in the trace :

1. Attacker connects and starts a session with EHLO 127.0.0.1.
2. My server responds and the attacker responds with AUTH LOGIN.
3. Attacker then uses various user names and passwords which are encoded in Base64. Decoding the usernames provide names of accounts that are typically default on non-Exchange SMTP server implementations.
4. After each login attempt my server responds with “Authentication unsuccessful.” After receiving this response, the attacking server resets the TCP connection and then establishes a new connection where a different username and password combination is used.

This pattern looped for 1.5 hours until I noticed it and blocked the IP. In that time, they had hit my server with almost 700 login attempts, each using a different username / password combination.

Typically mail servers will reject a RCPT TO address which would result in them being a relay, unless the sender is authenticated. If this attacker discovered a login that was accepted by my server, they very quickly would have turned my Exchange server into a relay to blast out spam and malicious messages.