Auth SMTP Spam Attack

Analysis of MailScan Logs Period 28th May 2010 11:44AM to 28th May 2010 16:35 PM (5 hours of Logs)

Recently, when one of  India’s top MNCs, which used a leading Anti-Spam Solution, faced a problem with its outgoing e-mail server’s IP getting frequently blacklisted as a spammer IP, MicroWorld was called in to resolve the issue.

When we investigated, we found that this company did not have a password policy for e-mail users and the passwords were changed by the system admin as and when required. Now, this approach is not very secure and it usually gives rise to several password related issues. We theorized that if a second wave of Auth-Spam did not happen after the passwords were changed, we could safely assume that the end-points were secure. So, we changed the passwords across the network. Then, we deployed MailScan on the e-mail server and enabled Anti-Spam Scanning it. We also enabled the User id Validation to check whether the user id actually exists.

During the course of our investigation and subsequent deployment of MailScan, we came across a new form of spam attack—a new technique which utilizes the SMTP Authentication Mechanism and subsequently uses mail relay for authenticated users, a security feature provided by mail servers. The mail relay is a default behavior of mail servers, that was being exploited by Spammers to send out spam.

How the Spam attack took place

We started with an assumption that the computers were infected with a password stealing Trojan that stole the e-mail client settings, and extracted information such as the user name, password, email id, SMTP server address. Our assumption also included some facts such as the Trojan uploads all this information to the central repository after infecting a computer. In some cases, the Trojan also sends out spam from the infected machine by using these settings and credentials. These assumptions are based on the features provided by the USB-Hacksaw/USB-Switchblade virus generation application.

On inspection, we realized that the information was being collected from the central repository and an attack was coordinated by using botnets or zombie networks. This was evident from the fact that same user logged on to send email from different IP Addresses, which were located in different geographical locations. You can use any of the online tools to view the geographical location of an IP address. Here, the compromised user ids with their passwords and mail-server credentials were being utilized to send spam. Since the sender addresses in the spam e-mails were authenticated, they appeared to come from authentic users. We observed that the originating IP addresses of these authenticated users kept changing every minute.

The company’s e-mail servers were accepting the spam e-mails and allowed mail relay because the e-mails appeared to originate from authenticated users. The recipient mail servers gladly accepted e-mails as the sender’s company had valid SPF records and other e-mail-related DNS records. Thus, the spam e-mails were sent to recipients outside the organization and so, the company’s IP address was identified as a spammer IP and was blacklisted.

To get to the root of the problem, we did an in-depth analysis of the situation. There were two mail servers which were used by this organization to provide e-mail services, the first server (External Server) was used by roaming/Internet users and second server/internal server was used by WAN and LAN users. We realized that the user list was gathered from the mail server because only the authenticated user ids on the external server was compromised. The harvested user list was subsequently fed in to the botnet system and the attack was initiated.

Figure 1: The botnet affected systems may or may not be a part of the company’s network.

We mulled over the various alternatives, but came to the conclusion there are two possibilities as to how this list was being used by botnets. The first possibility is that one of the servers containing the list of users and passwords was compromised because the Anti-Spam Solution that was previously deployed stored userids and passwords in plain text format. However, we could not confirm the possibility of data pilferage as it was outside the purview of our task.

The second possibility presumes that the problem was an outcome of a large-scale virus infection that affected all the company’s Internet-based locations. This could have been the result of a password stealing malware or Trojan, which steals information from infected computers and uploads it to the central repository.

Since none of the Spam Auth IDs feature Microsoft® Exchange users i.e., those users who directly connect to Microsoft® Exchange Server, this raises a few doubts on the second possibility, hence we assumed that these computers in WAN/LAN locations are well-protected.

By looking at the type and nature of the attack, we were able to approximate the period for which spammers were busy configuring their computers to launch an attack from the harvested user list by deducting a maximum of 48 hours from the first spam attack. Then, we turned our attention to the password strength. As a part of our analysis and for testing the integrity of the password authentication process used to exchange information between MailScan and Exchange Server, we decrypted the passwords of some users. During this test, we found that some of the users used weak passwords.

For example,

Username: usr1, Password: Password1

Username: usr2, Password: MM152007

Username: usr3, Password: pass@321

Username: usr4, Password: h1y2d3

Please Note: All the passwords stored in MailScan Logs are in encrypted format.

Here is a sample log file.

Sample Log

28 May 2010 11:44:46 – SMTPIN: Entering into thread no: 1 (IP: 202.72.x.y)

28 May 2010 11:44:46 – SMTPIN: #helo 202.72.x.y

28 May 2010 11:44:47 – SMTPIN: #AUTH LOGIN

28 May 2010 11:44:47 – ROUTER-AUTH: MX-Records found for company.co.in in cache: 192.168.x.y:25

28 May 2010 11:44:47 – ROUTER-AUTH: Establishing connection to mx-host 192.168.x.y:25 …

28 May 2010 11:44:49 – ROUTER-AUTH: <<<< 220 subdomain.company.co.in Microsoft ESMTP MAIL Service, Version: 6.0.3790.4675 ready at  Fri, 28 May 2010 11:44:47 +0530

28 May 2010 11:44:49 – ROUTER-AUTH: >>>> EHLO company.co.in

28 May 2010 11:44:50 – ROUTER-AUTH: <<<< 250-subdomain.company.co.in Hello [192.168.9.103]

28 May 2010 11:44:50 – ROUTER-AUTH: <<<< 250-TURN

28 May 2010 11:44:50 – ROUTER-AUTH: <<<< 250-SIZE 12582912

28 May 2010 11:44:50 – ROUTER-AUTH: <<<< 250-ETRN

28 May 2010 11:44:50 – ROUTER-AUTH: <<<< 250-PIPELINING

28 May 2010 11:44:51 – ROUTER-AUTH: <<<< 250-DSN

28 May 2010 11:44:51 – ROUTER-AUTH: <<<< 250-ENHANCEDSTATUSCODES

28 May 2010 11:44:51 – ROUTER-AUTH: <<<< 250-8bitmime

28 May 2010 11:44:51 – ROUTER-AUTH: <<<< 250-BINARYMIME

28 May 2010 11:44:52 – ROUTER-AUTH: <<<< 250-CHUNKING

28 May 2010 11:44:52 – ROUTER-AUTH: <<<< 250-VRFY

28 May 2010 11:44:52 – ROUTER-AUTH: <<<< 250-X-EXPS GSSAPI NTLM LOGIN

28 May 2010 11:44:53 – ROUTER-AUTH: <<<< 250-X-EXPS=LOGIN

28 May 2010 11:44:53 – ROUTER-AUTH: <<<< 250-AUTH GSSAPI NTLM LOGIN

28 May 2010 11:44:53 – ROUTER-AUTH: <<<< 250-AUTH=LOGIN

28 May 2010 11:44:53 – ROUTER-AUTH: <<<< 250-X-LINK2STATE

28 May 2010 11:44:54 – ROUTER-AUTH: <<<< 250-XEXCH50

28 May 2010 11:44:54 – ROUTER-AUTH: <<<< 250 OK

28 May 2010 11:44:54 – ROUTER-AUTH: >>>> AUTH LOGIN

28 May 2010 11:44:54 – ROUTER-AUTH: <<<< 334 VXNlcm5hbWU6

28 May 2010 11:44:54 – SMTPIN: # EncryptedUserID-Removed

28 May 2010 11:44:54 – ROUTER-AUTH: >>>> EncryptedUserID-Removed

28 May 2010 11:44:55 – ROUTER-AUTH: <<<< 334 UGFzc3dvcmQ6

28 May 2010 11:44:55 – SMTPIN: #EncryptedPWD-Removed

28 May 2010 11:44:55 – ROUTER-AUTH: >>>> EncryptedPWD-Removed

28 May 2010 11:44:56 – ROUTER-AUTH: <<<< 235 2.7.0 Authentication successful.

28 May 2010 11:44:56 – ROUTER-AUTH: >>>> QUIT

28 May 2010 11:44:56 – SMTPIN: #mail from:<wkjxbetrayal@company.co.in>

28 May 2010 11:44:57 – SMTPIN: #rcpt to:<Kyle_bohnert@yahoo.com>

28 May 2010 11:44:57 – SMTPIN: #data

28 May 2010 11:44:57 – SMTPIN: Receiving data in SMT1175720159958.TMP file

28 May 2010 11:44:57 – SMTPIN: Data completed for SMT1175720159958.MSG file. Size of message 1291 bytes (1 kb).

28 May 2010 11:44:57 – SMTPIN: #quit

28 May 2010 11:44:57 – SMTPIN: Disconnecting client

28 May 2010 11:44:57 – SMTPIN: (Port:25): Client Session Completed from 202.72.218.222

28 May 2010 11:44:57 – SMTPIN: Exiting from thread no: 1

Note: Microsoft, Encarta, MSN, and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Share

Tweet

Share

Share

Share