Windows IT Pro is the leading independent community for IT professionals deploying Microsoft Windows server and client applications and technologies.
  
  
  Advanced Search 


December 22, 2006

Preventing Directory Harvest Attacks

Foil spammers with these simple techniques
RSS
Subscribe to Windows IT Pro | See More Exchange Server and Outlook Articles Here | Reprints | Or get the Monthly Online Pass—only $5.95 a month!

Spammers use many techniques to flood your Exchange server with unwanted garbage. One technique that can be especially problematic for the recipient is a directory harvest attack (DHA). In these attacks, spammers send messages to mailboxes that may or may not exist in order to discover legitimate addresses. There are techniques you can use to protect your Exchange organization against these attacks, but first you need to understand how DHAs work.

Anatomy of a DHA
The basic idea behind a DHA is that there are many common names. If your company has many employees, chances are you have employees named John, Bob, Mary, and so forth. Spammers have therefore compiled long lists of common names. A mail-generating program attaches each name on the list to a known domain name. For example, if a spammer were targeting the contoso.com domain and had the names John, Bob, and Mary on a list, spam messages would be sent to john@contoso.com, bob@contoso.com, and mary@contoso.com.

Keep in mind that there might not be a John, Bob, or Mary working at Contoso. The spammer sends messages to these addresses anyway, using common names in an effort to figure out which email addresses are valid. In addition to names, the spammer will also use words that are often found in email addresses; for example, the spammer might try sales@contoso.com, service@contoso.com, or info@contoso.com.

When spammers launch DHAs, they know that most of the addresses they're trying will be invalid. However, they also know that if they try enough names, some messages will go through. Spammers often have thousands of names on their lists.

In the example of spam being sent to John, Bob, and Mary, I showed you how the name from the list could be attached to a target domain name. In the real world, companies rarely use an employee's first name as the sole basis for an email address. More often, email addresses are made up of a combination of the employee's first and last name. Spammers know this, so they send messages to many different combinations of the names on their lists. For example, if a spammer wanted to target the name John Smith, some possible combinations might include JSMITH, John.Smith, or JohnS.

If the spammer's list contains thousands of names, you can imagine how many messages have been sent by the time the spammer has attempted every possible combination of names. Typically, first and last names would be separate lists, greatly increasing the overall number of combinations to try. A DHA sometimes produces the same symptoms as a Denial of Service (DoS) attack. The spammer might flood the recipient's email server with so many messages that legitimate messages can't get through.

Of course, this technique has many variations. Some spammers don't worry about using lists of names but instead perform a brute-force attack in which they try every possible combination of numbers and letters within a predetermined length of username in conjunction with a known domain name. This technique is extremely resource- and time-consuming for the spammer because of its brute-force nature. Some spammers prefer to use a less thorough, less time-consuming method.

Other spammers use spam databases to find a few known addresses associated with the domain, so that they can determine the email-address format that a company uses. If spammers know the address format, they can launch a much more efficient DHA. But because millions of domains exist, spammers are spending less and less time fine-tuning attacks against individual domains, preferring instead to send out millions of messages to a variety of address formats to find a few valid ones.

Sending messages to countless email addresses is only half the battle. Remember that the purpose of the DHA is to determine which email addresses are valid so that more spam can be sent to those addresses. Spammers can find valid email addresses in two different ways.

The most common technique that spammers use to find valid addresses is to look at the nondelivery reports (NDRs) that are generated. As you probably know, most mail servers are configured so that when a message is sent to a nonexistent email address, an NDR is returned to the sender. Spammers cross-reference NDRs against the list of email addresses that they sent messages to. Any address for which an NDR was returned is considered to be invalid and is therefore removed from the list.

Originally, spammers treated the absence of an NDR as confirmation that an address was valid. Today, however, spammers can't be completely certain that an email address is valid just because they didn't get an NDR. If a spammer floods a domain with directory-harvest messages and no NDRs are returned, the spammer knows that the company has disabled NDRs.

Spammers can still figure out legitimate email addresses, although not as many as they could if NDRs were enabled. To do so, spammers look for clues such as out-of-office messages. Spammers might also include a request for delivery receipts within directory-harvest messages.

Because of the way DHAs work, it's possible that even new email addresses that haven't been used could start receiving spam within hours of creation. Fortunately, there are several ways that you can fight this type of attack. The techniques I describe are intended for Exchange Server 2003, but most should also work with Exchange 2000 Server.

Disabling Delivery Receipts
One method to combat DHAs is to disable delivery receipts for the Exchange organization. The primary advantage of disabling delivery receipts is that doing so makes DHAs much less effective. Disabling delivery receipts might also save you bandwidth and other system resources. Think about it for a minute. If your mail server has to generate a delivery receipt for every message that a spammer sends, you could be wasting a lot of system resources. A single delivery receipt consumes a negligible amount of bandwidth, CPU time, memory, and other resources; cumulatively, however, generating large numbers of delivery receipts can have an impact on available system resources. The downside to this technique is that if a legitimate user asks for a delivery receipt and you've disabled delivery receipts, the user will think that his or her message wasn't delivered.

Disabling NDRs
Just as the process of generating and sending large numbers of delivery receipts can affect available system resources, so too can generating NDRs. A DHA sends messages to thousands (if not millions) of nonexistent mailboxes. The impact of these messages on your bandwidth and other system resources is bad enough, but the effect is compounded when your server replies to each invalid message with an NDR.

In some organizations, the thought of recovering bandwidth and system resources that were previously used in producing NDRs might be appealing enough to justify disabling them. But before you do, there are a couple of negative aspects that you need to consider.

One problem involves people who send legitimate email messages to your organization. If a client enters an email address incorrectly, the message won't reach its recipient. Without an NDR, senders never know that their message wasn't delivered and might think they're being ignored.

Another problem with disabling NDRs as a countermeasure to DHAs is that the technique can backfire on you. Remember how a DHA works: In the attack's simplest form, the list of names is compared with the list of NDRs to determine which email addresses are valid. Some of the less-sophisticated spam generators automatically assume that an email address is good if no NDR is returned for it. Once spammers have a valid address, they send a lot more spam to it.

   Previous  [1]  2  Next 


Top Viewed ArticlesView all articles
Command Prompt Tricks

One reader shares his tip for setting up the command prompt to reflect a remote path. ...

WinInfo Short Takes: Week of November 23, 2009

An often irreverent look at some of the week's other news, including some post-PDC some soul searching, a Google Chrome OS announcement and a Microsoft response, Windows 7 off to a supposedly strong start, the Jonas Brothers and Xbox 360, and so much more ...

2009 Windows IT Pro Editors' Best and Community Choice Awards

Picking a favorite product from an impressive crowd of competitive offerings is never an easy task, and such was the case with our Editors' Best and Community Choice awards this year. ...


Exchange Server and Outlook Whitepapers Email Controls and Regulatory Compliance

Take Control of Your Email: Understand the Business Reasons for Email Storage Management

Related Events The Easiest Way to Save Time and Money on E-mail and SharePoint Management

Bail Out Your Exchange Environment

Check out our list of Free Email Newsletters!

Exchange Server and Outlook eBooks Spam Fighting and Email Security for the 21st Century

Understanding and Leveraging Code Signing Technologies

The Expert's Guide for Exchange 2003: Preparing for, Moving to, and Supporting Exchange Server 2003

Related Exchange Server and Outlook Resources Introducing Left-Brain.com, the online IT bookstore
Looking for books, CDs, toolkits, eBooks? Prime your mind at Left-Brain.com

Discover Windows IT Pro eLearning Series!
Clear & detailed technical information and helpful how-to's, all in our trademark no-nonsense format

Exchange & Outlook UPDATE eNewsletter
News, strategies, products, and developments in Exchange Server and Outlook messaging.

Windows IT Pro Home Register FAQ for Windows WinInfo News
Europe Edition About Us Contact Us/Customer Service Media Kit Affiliates / Licensing  
SQL Server Magazine Office & SharePoint Pro DevProConnections IT Job Hound
Left-Brain.com Technology Resource Directory asp.netPRO ITTV Windows SuperSite 
 
 Windows IT Pro is a Division of Penton Media Inc.
 © 2009 Penton Media, Inc. Terms of Use | Privacy Statement