Subscribe to RSS News Feed
About Spamhaus  |  Press Office  |  FAQs   
Spam through compromised passwords: can it be stopped?

2012-05-09 21:58:00 UTC, by Natale Maria Bianchi
Recent News Articles

Network Hijacking on the Rise

Subscription Bombing: COI, CAPTCHA, and the Next Generation of Mail Bombs

More Domain Stats: The 10 Most Abused Registrars

SBL/ZEN DNS lookups to return DROP/eDROP status

Spamhaus Presents: The World's Worst Top Level Domains

Verizon Routing Millions of IP Addresses for Cybercrime Gangs

Brazilian internet users suffer SoftLayer's security fail

Network under attack? You might be surprised where that's coming from!

Older News Articles:
Spamhaus News INDEX

Any account on a legitimate mail server is a valuable resource to a spammer or cybercriminal because it gives access to a server that is unlikely to be blocked from sending email. A spammer can use an account on a legitimate mail server to spam, and reach many more people than if he sent email from an IP that does not host a legitimate mail server. A cybercriminal can use an account on a legitimate server to send spam, host web sites, or provide other services that contribute to the distribution of malware, phishes, and scams such as the Nigerian "419" scams that we are all familiar with.

The volume of criminal spam that is sent through compromised user accounts on legitimate mail servers that use SMTP AUTH authentication, and should theoretically be secure, has grown precipitously in the past two or three years. It is currently a major vector for criminal spam.

Worse, it is difficult to block this spam without also blocking email from legitimate users whose email is also sent from the same mail servers. Companies and ISPs can take only limited security measures on mail servers that carry important business email. The automated blocking methods that many ISPs use to detect and block infected machines on residential/consumer networks cannot be used on business networks because they risk blocking legitimate email and can cause major service disruptions.

Spamhaus and other blocklists are also limited in the measures they can take to block this spam because of the risk of false positives. While Spamhaus blocks low traffic mail servers when they are detected sending a significant amount of spam, we are usually unwilling to list a busy outbound mail server because, even when one account on it is spamming, it also sends large volumes of legitimate email. We list such servers only when the spam volumes are heavy and other measures, such as emergency notifications to the ISP or company, have failed for a period of hours or days to halt the spam. Meanwhile, the spammer abusing the server can continue to bombard Internet users with malware, phish, scams, and other types of high-volume spam.

We all need a solution, and we need it quickly.


There are three major avenues that criminals use to obtain user logins and passwords on legitimate mail servers: guessing, phishing, and malware. The following sections discuss each in detail.

Method 1: Guessing

Many email users use insecure passwords. Weak passwords leave the door to the mailserver that hosts the user's email account open to cybercriminals and spammers. It is as if the user parked his automobile in a public location, and then left the doors unlocked and the keys in the ignition.

By now most users have repeatedly seen warnings against using their logon, their first or last name, their birthdate, their phone number, or any other personal information as their password. Most users have heard that passwords such as "password", "test", the infamous "123456", or a simple word that can be found in the dictionary are also insecure. Many users ignore this information, however, leaving their accounts vulnerable to the gangs of cybercriminals and hackers who run automated programs to guess weak passwords. At present, many weak passwords can be cracked in a matter of minutes.

Method 2: Phishing

Cybercriminals deceive users into revealing the logon and password to their email accounts in exactly the same way as they trick users into revealing online banking credentials or credit card information. Normally users are sent a fake email from their ISP (or IT department of their company or educational institution) that requests them to log onto their account at the supplied URL. The URL points, not to the real logon page, but to a fake page that is carefully designed to look like the real logon page. The fake page then transmits the login and password to the criminal.

This is often due partly to failure to educate users in proper online security. Nobody should ever trust an email that claims to come from their bank, credit card issuer, their ISP or any other company where they have a private account. Users should NEVER follow links or fill out forms found in such an email message. By 2012, all users should know these basic security precautions. That so many do not and phishing still works with them suggests to us, not that education efforts have been lacking, but that some users are unable or unwilling to practice basic security online.

Unfortunately not all types of phishing require an uneducated, careless or gullible user. Malware on a compromised personal computer can also change the DNS resolution of the hostname of a banking, credit card, or ISP site where users log on, sending the user to a fake logon page even when they type the URL directly into the browser or use a bookmark to access it. Practicing good internet security reduces the chances that a user will be deceived; it does not eliminate them.

Method 3: Malware

Finally, cybercriminals can discover a user's logons and passwords by infecting the user's personal computer with a type of malware called a keystroke logger. A keystroke logger logs each thing the user types, including logons and passwords when the user logs on to email, to his bank account, or to his credit card issuer's customer portal. The malware then transmits this information to the cybercriminal.

Some countries, such as Japan, pursue the issue of malware infection aggressively through public-funded projects that, in cooperation with ISPs, detect malware-infected computers and block them until their owners have been notified and the malware removed. Most countries and most ISPs do not pursue malware infection aggressively, however, which results in high infection rates. It is obvious that malware capable of carrying on various criminal activities, such as password stealing, will continue to be a problem for quite a while.


Unfortunately, while the problem of compromised passwords often starts with user error, it doesn't end there. Those responsible for managing mail servers and preventing them from being used to send spam are also responsible, and so are the ISPs providing connectivity to those servers.

In our correspondence with mail server administrators about spam sent through compromised user accounts, Spamhaus has noticed that - despite our FAQs and warnings in bold, red and (!) blinking characters on the SBL listing page - many system administrators do not even consider the possibility of a compromised account when spam is sent through their mail server. Instead, they often assume that a malware infection must be responsible, and immediately scan the server and all the client PCs and laptops with their antivirus software. If their virus scanning software finds nothing (as is often the case), the system administrator often assumes that the SBL listing was a mistake. If some malware is detected and removed, system administrators often assume that the problem is fixed.

When additional spam is detected from the server, the system administrators are often at a loss as to what to do, and try a number of ineffective and often extreme measures to stop the spam. We have even seen cases where the system administrator wipes the mail server hard disk and reinstalls the operating systems and software from original media while failing to solve the spam problem. Why? They kept the old password file without forcing users to change their passwords, and a compromised user account was the problem all along.

As with many other issues, educating system administrators about compromised passwords and documenting how passwords are compromised and what to do about it might help alleviate the problem in the long run. In our experience, though, these measures will not prevent compromised passwords. First, some of what is required to prevent easy password compromises is not popular with users. Without strong buy-in and support from management, a system administrator simply cannot implement appropriate password complexity rules. The issue is not technical, but human. Means exist to enforce proper password complexity, but some users who "outrank" the system administrator in the company hierarchy will strenuously resist any requirement to use secure passwords. The issues increase with implementing even stronger measures, such as two-factor authentication, client certificates, and so on.

Second, the Internet is still expanding to new parts of the world, where technical expertise is scarce and language barriers are often present. ISPs in these regions are often unaware that, to solve security issues, they must often work together with customers and with organizations whose function is to make the Internet more secure.

This failure to involve users and security organizations means that the often-inexperienced system administrators of small business servers are left completely on their own when a spammer compromises their mail system. The system administrator must understand how the cybercriminal got access to the mail server, find the user account that was compromised, and deactivate it until the user changes the password, all without much support or help.

Until the system administrator determines which user account was compromised and deactivate or secure the account, their mail server acts as a powerful spam cannon, often with surprisingly high intensities thanks to good hardware and bandwidth. Fixing the problem usually takes several days, and we have often observed compromised mail servers continuing to emit spam for weeks or even months.

For these reasons, Spamhaus views efforts to document how to detect accounts with compromised passwords and secure those accounts as a good investment for the future, but believes that these efforts are unlikely to to help prevent or quickly resolve spam problems caused by compromised user accounts in the short term.


The paradigm that all passwords "must always" be secure, so that even a single compromised account on a server may have catastrophic consequences, is simply inadequate to today's reality. It is a bit like making cars without seat belts or air bags because accidents would not happen if everyone just drove safely and followed the rules. We should move to a new, more realistic paradigm, recognizing as a fact of life that a few passwords on any mail server may be in the hands of cybercriminals. Recognizing this means that mail server software must be equipped to deal with and mitigate damage from compromised passwords as a normal part of everyday operation.

Previous experience with similar situations, such as the spam problems caused by open relays between 1997-2002, suggests that software developers may hold the key to solving the spam problem caused by compromised user passwords. In particular, those software companies and developers who are responsible for developing and maintaining Mail Submission Agents (MSAs), the component of a mail server system that receives emails submitted for distribution by users, could reduce this spam vector to insignificance if they develop a technical means of detecting compromised accounts and blocking them from sending email until they are secured.

Spamhaus believes that the currently common approach of letting authenticated users send unlimited or extremely large amounts of email is a serious security hole. We suggest that it is past time that MSA developers regarded this as a serious security issue, and issued security patches for all existing supported products that allow emission of massive outgoing email from authenticated users.

In particular, we suggest that MSA software developers focus on the following:

  1. Implement default per-account limits on numbers of outgoing emails. By default, an authenticated user account should be allowed to send only a relatively small amount of email in a given time period. Most users never send thousands of emails per day (or hour), as a compromised account often does. A default limit of one to two hundred emails per day is more than enough for most users, and would render their accounts largely useless to cybercriminals. Limits should be configurable on a per-user basis, so that those few users who need to send more email can be explicitly allowed to do so.

  2. Log the authenticated user account for each email sent. When authenticated email is sent, the account name used to authenticate should always be included in the SMTP protocol logs. A few popular mail servers, such as Microsoft Exchange, require the system administrator to modify the default log settings to do this: by default the account name is not logged. This should be fixed ASAP: it is a design mistake that makes diagnosis and cure much more difficult.

  3. Include the authenticated user account name in the email headers. MSA software should include the name of the user account used to authenticate in the email header, so that the system administrator can extract it from a spam sample. A configuration option should allow the authenticated user account name to be encrypted for privacy as needed.

  4. Monitor the mail flow from each account! Mail flow should be monitored per-account, and anomalous emission peaks from a single account should generate an alarm to system administrators as soon as they occur.

  5. Check for and reject weak passwords. Mail servers should inspect passwords, and refuse to accept extremely simple passwords. Even if components of the operating systems may be already in charge of password strength checking, MSA software should independently check passwords used to authenticate outgoing email.

  6. Rate limit authentication attempts to prevent password cracking. MSA, POP, and IMAP software should monitor authentication requests for signs of attempts to guess passwords, and slow down or entirely block IP addresses that try to access an account using several different passwords, or access different accounts using the same passwords or password patterns. In the case of IPv6 access, this measure should probably be applied to /64 networks rather than to individual IPv6 addresses.

Spamhaus believes that, if all major mail server MSAs would implement these changes and backport them to popular previous versions of the software via security patches, spam sent through compromised user accounts via SMTP authentication could be virtually eliminated from sites that use the new MSA software, and reduced significantly on the Internet as a whole within the next three to five years.

Spamhaus Information

Press Office
Spamhaus News Index
Spamhaus in the media
About Spamhaus
Spamhaus Official Statements
Article Information

Permanent link to this news article:
Spam through compromised passwords: can it be stopped?

Subscribe to RSS News Feed
Spamhaus News Quotes

Permission to quote from or reproduce Spamhaus News articles is granted automatically providing you state the source as Spamhaus and link to the news record.
© 1998-2016 The Spamhaus Project Ltd. All rights reserved.
Legal  |  Privacy