Your browser is obsolete!

The page may not load correctly.

  • add to favourites
    Add to Bookmarks

Spammers and blacklists

Read: 14593 Comments: 2 Rating: 42

Thursday, February 9, 2017

In the issue "We can only warn you", we already discussed how site owners and those who compile lists of non-recommended sites could have different views as to what constitutes malicious content. To understand why this is, let's see how a site can end up on this kind of list.

Let's assume that a certain site is involved in spamming activities. Here, we’re not going to consider the possibility that the site’s owners are deliberately doing this (although spammers claim they’re not violating the law, most users disagree), and we are also going to assume that the spamming is happening through no fault of the owners. A site can get involved in spamming activities when:

  1. It has been compromised, its routines have been altered, or special scripts have been deployed on the server. Perhaps, the most obvious option: the quite logical thing to do would be to block access to the compromised site until the issue is resolved. The only problem with this is that the site’s owners can quickly fix the problem and start claiming that it never existed.

How complex can spam routines be on a server? Here’s one story about spam.

And then I saw a full-fledged file manager in PHP. It was so impeccably done that:

  1. It had a beautiful dark grey UI with a dark green font. Some characters were gray and yellow.
  2. It featured 2 panels. Just like far, nc, vc, etc.;
  3. It had different view layouts. Lists and detailed tables showing properties and permissions;
  4. It supported commands like copy, move, delete, and change permissions;
  5. It enabled users to view and edit text files;
  6. It also had administrator privileges in the system.

The last feature really shocked me. Because no users were logged in on the server. And there were no corresponding configuration files. I don't know how they did it.

It is also worth mentioning that the administrator permission issue persisted regardless of the web server involved (both IIS and Apache).

  1. Email accounts compromised due to a lack of verification routines for user-created passwords, or the existence of flaws in the default security settings. This is a more difficult case. Ideally, only addresses related to the compromised email accounts should be blacklisted, but adding several million addresses to the list per week (we all know about leaked mail databases) would bloat it to unimaginable proportions. That's why blocking access to a site and adding trusted addresses to a whitelist is a reasonable solution if multiple security breaches have occurred since analysts checking the site can't determine which email accounts have been compromised.
  2. Email account passwords have been leaked. This incident is similar to the previous one. Blocking the site and adding trusted addresses to the whitelist is the most logical step.
  3. A lack of experience or errors made during the site’s development can enable perpetrators to use a feedback form that doesn't feature CAPTCHA verification to send out emails. This incident is similar to the previous one, but here it’s easier to prove that a problem exists because it is obvious.
  4. Another error in site development can allow perpetrators to register a large number of accounts which will result in bulk messages being sent out to a large number of users who have supposedly registered on the site.
  5. Exploit site routines to send notifications. For example, attackers can use mail server delivery-failure notifications like Non-Delivery Report (NDR), Delivery Status Notification (DSN), Non-Delivery Notification (NDN), and bounce messages. They alter sender addresses to make sure that bounce messages are sent to specific addresses.

The Dr.Web anti-spam filters out technical spam, including bounce messages, automatically. Find out more at

  1. Forward received messages. OpenRelay is the most tempting morsel for spammers. The feature used to be legally available to everyone, but thanks to spammers abusing it, it’s fallen out of use. Nowadays relaying messages without authorisation is considered to be a configuration flaw caused by site administrator negligence. In such cases, sites definitively end up on blacklists.

We can keep enumerating situations for you, and we haven’t examined the more unusual situations when attackers compromise servers that relay emails and spoof messages.

As you can see, many reasons exist as to why sites can get involved in sending out spam, ranging from vulnerabilities in the sites' code to flaws in their configuration. Unfortunately, most mistakes play into attackers' hands.

#spam #non-recommended_sites

The Anti-virus Times recommends

  1. You will never be able to verify that every site you receive spam from is safe. That's why you need an anti-spam.
  2. An email containing uninteresting or incomprehensible content is reason not just to become wary but also to head to and submit the email to Doctor Web's anti-virus laboratory for analysis.


Tell us what you think

To leave a comment, you need to log in under your Doctor Web site account. If you don't have an account yet, you can create one.