SpamCopWiki : SpamWebsiteRedirectionRconneR

SpamCopWikiHome :: Categories :: PageIndex :: RecentChanges :: RecentlyCommented :: Login/Register

Spam Website Redirection

or, Getting Taken for a Ride by a Spammer

Warning: This page is under development and may be incomplete

NOTE: I'm assuming that you know at least a little bit about topics like HTTP, HTML, JavaScript, etc. If you don't, you may find this article a bit too abstruse to be helpful.

If you are a fan of old film noir crime movies, you will no doubt be familiar with the stereotypical scene where the hero gets blindfolded, shoved in a car, and driven across town via a purposely indirect route to a distant and unfamiliar location so that he can do business with "Mr. Big." The crooks in these movies go to these lengths because they don't want the hero to know where they are taking him, or exactly how he could get back there later on with the cops in tow.

It might not be surprising to learn that the same sort of thing goes on with many spam websites, which commonly "redirect" the visitor from a portal website to the "real" website (where the drugs, warez, watches, etc. are sold). Often, the portal appears to be an "innocuous" page on a popular free-web-hosting service, a blog site, or a friendly URL-shortening service. Sometimes, your browser may actually go through two or more such redirections before arriving at the payload site.

On this page, I'll describe in general terms how some of these redirections work.

What is 'redirection?'

By "redirection," I mean loading one URL (website link) in your browser (i.e., the one given in the spam message), and then having the web server at this URL use any of a number of techniques to send your browser to some other website somewhere else. The "real" website payload will be found not on the original URL, but on the one to which your browser is redirected. Sometimes (but not always), this new URL will appear in your browser's URL window after the dust settles from all the flying data, so that you can see that you ended up somewhere other than where you started.

Before we get started, I should point out that URL redirection is not necessarily evil or unethical; in fact, it is used every day by many popular and well-regarded internet operations.

Although URL redirection is thus in itself "morally neutral," it can be used by spammers for purposes that are perhaps not so innocent. That's why it can be useful to know how, and for what reasons, spammers make use of this technique.

Why do many spammers use redirection with their websites?

Redirection is one of the tools that spammers use to protect their websites against being traced, reported, and shut down. Spam websites require special protection not only because they must stay online for extended periods (in order to collect orders), but they are also at greater risk than the spammer's mail-sending resources since they must be more visible on the internet than the mail hosts (i.e., the suckers shoppers have to be able to reach them after the mail is sent).

Let's take a closer look:

The use of redirection, then, allows the spammer to hide his "real" website behind one or more expendable "portal" sites. The portal sites are like the heat shield on a space capsule; they bear the brunt of the heat, and are considered expendable in the protection of more valuable resources (i.e., the "real" website); if the portals are detected and closed (as they inevitably are), the "real" website remains, and it is a simple matter to set up more portals that can point to it.

Since few automated spam-tracking tools are equipped to deal with redirection in all its variations, they are usually unable to find the "real" websites and instead only target the portals (if, indeed, they even do this much). So, it will be the portal sites that get all the complaints, while the "real" sites behind them will remain relatively untouched. Generally, it takes some amount of human intelligence to find and trace URL redirections.

How do spammers redirect you to their sites?

Here are the four basic means (of which I'm aware) to redirect browsers to other websites (one of these really isn't redirection, but it amounts to the same thing insofar as protecting spam websites is concerned):

Redirection via HTTP status code

The most "natural" method for redirecting from one website to another is to include one of the 'redirect' status codes (and a new location URL) in the HTTP header of a web request. This provides the fastest, surest redirection because the visitor's browser is not required to interpret any of the HTML sent by the original site; it just looks in the HTTP header (which is not normally directly visible to web users) to find the redirection info.

HTTP redirection is more direct and conservative of resources than other redirection methods (which will be discussed here), but in order to use HTTP redirection the spammer requires a certain degree of control over the web server software at the portal site. In the case of the popular Apache web server software, for example, this is usually done by placing a Redirect directive in the server's configuration file, or in a local .htaccess file, either of which requires that the web server administrator (i.e., the guy or gal who "owns" the web server box) give up a certain amount of control to the individual website operator.

For this reason, HTTP redirection is usually done from a web server that is set up or controlled by the spammer. If the web server is tightly controlled by an outside service (e.g., Geocities or Blogger), then it is more difficult (perhaps impossible) for the spammer to set up HTTP redirection.

How do you know that you are being subjected to an HTTP redirection? Generally, you cannot tell from within your browser; I know of no way (surprisingly enough) to get standard web browsers to show the HTTP headers received during page fetches, which is the only way to tell for sure that an HTTP redirection has been perpetrated. It is therefore necessary to use a command-line HTTP client, like curl or wget which can display the HTTP headers.

NOTE: If you can speak HTTP, you can also telnet to the server in question on port 80 and send a "manual" GET query, but I won't cover that here.

For example, either of the following commands would print the HTTP headers before printing the contents of the URL http://foo.fum/.
curl -i http://foo.fum/
wget --save-headers http://foo.fum/

When you run one of these, you should see the HTTP headers printed first, followed by a blank line, then by the contents (if any) of the URL (which will probably begin with the usual <HTML ... > tag). Here's the header (only) for a typical spam website using HTTP redirection:

HTTP headers for redirected website
HTTP/1.1 301 Moved Permanently
Date: Thu, 17 Aug 2006 04:06:49 GMT
Server: Apache
X-Powered-By: PHP/5.1.1
Set-Cookie: PHPSESSID=cb4f68bd4d13108027b0d3294108c695; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 0
Content-Type: text/html; charset=iso-8859-1

We have two clues here: the status code of the HTTP query is given on the very first line; "301" means that the URL has moved "permanently" to another location. This new location is given in the Location field on line 9, and we see that it is a UK Geocities website. Your web browser, in order to be compliant with HTTP, is expected to automatically fetch the new URL given in the Location field, and generally will do so without alerting you to the redirection (i.e., you won't know you've been redirected unless you look closely at your browser's URL field, which will change to the new location).

Note also that the Content-Length on line 10 is zero, meaning that there were literally no data available at the requested URL; a Redirect directive kicked in and caused the return of these headers without including any actual data in the query. So, when HTTP redirection is used, the spammer doesn't even have to bother setting up a web page on the portal server, as long as a Redirect directive is put in the right spot on his file tree (e.g., in an .htaccess file on the directory pointed to by the URL).

Note that HTTP defines several redirect codes, all of them in the 3xx series:

301 and 302 are the ones I see most commonly in spam. Refer to the HTTP/1.1 definition at for further information on redirect codes.

Redirection via HTML <META> tags

If the spammer cannot (or doesn't want to) use HTTP redirection, then the redirect information can be placed in the <HEAD> element of an HTML page, specifically in a <META HTTP-EQUIV="REFRESH"> tag. I call this technique "META redirection" to distinguish it from HTTP redirection described above.

The advantage of META redirection is that it can be used with any web service that allows the user to write his own <HEAD> tags; even most free web-hosting services like Geocities allow this (blog servers, like Blogger, usually write the <HEAD> tags themselves, and so generally don't give the user opportunities to put things into them).

The disadvantage of META redirection is that the redirection becomes a bit more obvious to the site visitor; the visitor's browser may fully or partially load the portal page before getting around to the redirected page, and so the META redirection takes a bit longer in general than HTTP redirection (which is largely invisible to the visitor).

How can you tell if you're flying via META redirection? It's a bit easier than the case of HTTP redirection; you can, for example, try hitting the "back" button on your browser once you've moved to the "real" page, and you may then be able to examine the HTML source of the portal page to look for the offending <META> tag. Alternatively, you can use curl or wget as described above to fetch the URL and examine the META tags for yourself.

In either case, what you will see is likely to look like the following example (again, taken from an actual spam website redirection:

HTML markup showing META redirection
<meta http-equiv="refresh" content="0;URL=">
<a href="">_

Here, the <META> tag on line 3 tells your browser that it must "refresh" the page by fetching the URL given in the content field after zero seconds (i.e., immediately), this time being given just before the URL itself in the content field. The URL is likely to be the "real" website in this case, or perhaps another portal to yet another redirection. The URL given in the <BODY> element on line 6 is merely "decorative;" more than likely it leads nowhere, and even if this page stays up on your browser long enough for you to try to reach it, you probably won't notice it because it is anchored to a single underscore character (i.e., <a>_</a>) and is easily overlooked.

Note that as in the case of HTTP redirection, you should see the new URL in your browser's URL field when the redirection is complete. Unlike HTTP redirection, it is (usually) possible to return to the original portal page by hitting your browser's "back" button.

Redirection via embedded scripts

A third method for redirecting websites is to put the redirection info into a client-side script (a JavaScript, generally) within the HTML markup; the script is then to be executed by the user's browser in order to accomplish the redirection.

The simplest sort of scrpt-based redrection might look like this (taken from an actual spam):

HTML fragment showing redirection via JavaScript 'location' object
    location = "";

Believe it or not, line 3 is a complete JavaScript, one that simply causes the named URL to be substituted for the URL already stored in the browser window's location object. This change forces the window to referesh itself, which in turn forces it to load the new URL.

In the example above, the new URL is in plain view, and could be scanned by humans or software (e.g., spam investigators or their tools). Spammers can make these scripts MUCH more complicated in order to discourage such snooping (although you can't really prevent it). For example:

Obfuscated script-based redirection using URI-encoded string (line 1)
  1. <html><head><title>Mint Las Vegas</title><SCRIPT LANGUAGE="Javascript"><!--
  2. document.write(unescape("%3Cscript type%3D%22text%2Fjavascript%22%3E%3C%21%2D%2D%0D%0Awindow%2Efocus%28%29%3B%0D%0Atop%2Elocation%2Ehref%3D%22http%3A%2F%2Frhedrond%2Ecom%2Fmicro%2F34%22%3B%0D%0A%2F%2F%2D%2D%3E%3C%2Fscript%3E"));//--></SCRIPT></head><body bgcolor="#FFFFFF" text="#000000">
  3. LOADING...
  4. </body><SCRIPT LANGUAGE="JavaScript"><!--
  5. eval(unescape("%64%6F%63%75%6D%65%6E%74%2E%77%72%69%74%65%3D%6E%75%6C%6C%3B"));//--></SCRIPT></html>

This script really doesn't do anything different from the earlier example, it just does it with more handwaving and misdirection. Line 2 contains a long string full of percent signs ("%"); this is actually known as "URI-encoded data", and if we apply the Javascript unescape() function, it will convert the URL encoding back to plain text; in other words:

unescape ("%3Cscript type%3D%22text%2Fjavascript%22%3E%3C%21%2D%2D%0D%0Awindow%2Efocus%28%29%3B%0D%0Atop%2Elocation%2Ehref%3D%22http%3A%2F%2Frhedrond%2Ecom%2Fmicro%2F34%22%3B%0D%0A%2F%2F%2D%2D%3E%3C%2Fscript%3E")); 


String in code box above, unescaped and ready to write into the document
<script type="text/javascript"><!--

which is yet another bit of JavaScript. The document.write function calls for this bit of code to be stuck onto the end of the current document (web page). As soon as it is added, your browser will execute it, which will cause the document's window to take focus (move to the "top" of all your other browser windows), and then load the indicated URL using top.location.href (a more verbose way of simply calling location).

Yet another variation, this one using a "homebrew" encoding technique (simply convert the redirect code into a string of ordinal byte values, separated by exclamation points):

Variation on obfuscated redirection code
function Decode(){var temp="",i,c=0,out="";var str="60!115!99!114!105!112!116!32!116!121!112!101!61!34!116!101!120!116!47!106!97!118!97!115!99!114!105!112!116!34!62!13!10!105!102!32!40!116!111!112!46!108!111!99!97!116!105!111!110!32!33!61!32!108!111!99!97!116!105!111!110!41!32!123!13!10!32!32!32!116!111!112!46!108!111!99!97!116!105!111!110!46!104!114!101!102!32!61!32!100!111!99!117!109!101!110!116!46!108!111!99!97!116!105!111!110!46!104!114!101!102!32!59!13!10!125!13!10!119!105!110!100!111!119!46!108!111!99!97!116!105!111!110!32!61!32!34!104!116!116!112!58!47!47!101!97!115!114!111!46!99!111!109!34!13!10!60!47!115!99!114!105!112!116!62!";l=str.length;while(c<=str.length-1){while(str.charAt(c)!='!')temp=temp+str.charAt(c++);c++;out=out+String.fromCharCode(temp);temp="";}document.write(out);}

All of which writes the following very similar JavaScript into your browser window:

Redirection code extracted from above
<script type="text/javascript">
if (top.location != location) {
   top.location.href = document.location.href ;
window.location = ""

In fact, the possible variations on this scheme are nearly endless, limited only by the spammers' ability to find or think up kooky encryption or encoding schemes for their URLs and scripts. (I found another particularly obscure one just today, based on Microsoft's JScript.Encode feature, but don't want to belabor the point by posting it).

Script redirection can be used anywhere you could use HTML redirection; in other words, pretty much EVERYWHERE on the web. It is particularly popular among spammers who use Geocities pages as portals, since the code can simply be dropped right into the free Geocities page.

NOTE: Although you might think that Geocities (et. al.) would regard all this scripting as a possible security problem, this isn't the case; JavaScripts are executed on the visitor's computer and not on the servers, so the server has little or nothing to fear from them.

Script redirection won't work for readers who have turned off the automatic execution of JavaScripts in their browsers, but I daresay only a paranoid minority of users resort to this (including, sometimes, Your Humble Narrator). Anyway, these security-minded folks are not the kind of people that the spammer is after, since he knows he'll have a hard time getting them to buy anything from him.

How can you tell that you are being taken for a ride with a JavaScript in the driver's seat? Just fetch and inspect the raw HTML and look for strange looking code (particularly sandwiched in <SCRIPT> tags in the <HEAD> element). You can try to play with these scripts within your browser and/or text editor in order to decode the new URL (changing document.write(...) to alert(...) often helps, diverting the inserted code from the document window to an alert box, where it can be displayed but will not be executed). I won't kid you, however: this stuff takes a lot of time and work to fish through; also, the strange manner in which JavaScript is interwoven on HTML pages doesn't help at all. You may prefer just to report whatever SpamCop comes up with and leave it at that.

Using <FRAME> or <IFRAME> tags to pull content from another site

NOTE: This technique isn't "redirection" in the strict technical sense of the term, but it essentially does the same thing by forcing your browser to load a site other than the one you requested.

HTML provides two ways to embed one (or more) HTML document(s) within another HTML document: the <FRAME> and <IFRAME> tags. These tags let you load a "foreign" URL into a designated portion of your page. It's as if you are dividing one whole browser window into a number of sub-windows, each of which can get its content from a completely different URL.

For example, to embed a window to Google's main page into your own home page, you can insert the following HTML markup (starring the <IFRAME> tag).

Example of IFRAME tag
<iframe src="" width=500 height=300 align="center">
(Oops, your browser doesn't like IFRAME!)

<FRAME> tags work in much the same way, but I won't give an example here since they require a lot more markup.

Spammers can use frames to hide their websites from casual snooping. For example, a spammer might set up a portal website somewhere, with an HTML page that contains very little other than an appropriate <FRAME> set or <IFRAME> tag that gets its content from the "real" spam website (i.e, using the src="..." attribute).

Although it is not nearly as common as the other mechanisms described here, I do still see it used from time to time. It does have the significant advantage that the URL of the "real" website never appears in the visitor's browser URL field (although the accomplished HTML snooper can quickly dump source and find the link for himself).

Common URL redirection strategies

Now that we've gotten a taste of how redirection works, let's shift gears and see some examples of how spammers deploy it.

Redirecting from 'free' web services

One depressingly-common strategy for redirection involves the use of large "free" web hosting providers as portals for spam websites. Such behavior can be frustrating for spam investigators because it is often very difficult to get the big providers to recognize that they have a problem and to take care of it quickly enough to be of help.

These days, many spammers use free Geocities pages (at various of the national domains that Geocities runs) as spam portals; the redirection is encoded into these using META-based or script-based methods, since other types of redirection are generally difficult to set up with these providers. The spammer need only drop the Geocities link (which usually contains a big alphabet-soup string to identify the account) into the spam mailing.

Spam-portal complaints directed toward Geocities (at, for example) do eventually yield results, but the process can take several days (at least), by which time the spammer is probably pretty well done with the portal anyway (and may have moved on to others, probably also on Geocities).

Geocities, of course, is not the only free web provider; however, I see very few others in the spam that I get, so it seems that, for whatever reasons, Geocities is the redirecting spammer's friend.

Redirecting from 'free' web logs (blogs)

Another less frequent (but no less annoying) dodge is for the spammer to set up a web log on Google's Blogger service. This "blog" (some call them "splogs") simply contains a spam pitch plus a link referring you to the "real" website. The URL for the spammy blog will be dropped into the spam mailing.

Nearly all of these 'portal splogs' contain links that the visitor must click on in order to be sent to the "real" site; I've yet to see any (that I can recall) that use any of the forms of automatic redirection described above. This could be due to the fact that Blogger users do not have direct access to HTTP directives or to the <HEAD> elements of Blogger pages (i.e., the bloggers simply type up bits of text plus image links, etc., which are managed by Blogger and automatically inserted into the pages that Blogger serves). For the same sorts of reasons, the spammers may be also be unable to use JavaScript redirections.

Blogger disclaims any responsibility for the presence of spam portals on its service; in its own words, "Blogger is a provider of content creation tools, not a mediator of that content." On one hand, this is a perfectly fine example of unqualified support for lassiez-faire free speech (which I can applaud to some extent), but on the other hand it puts Blogger in the position of being a publisher for child pornographers, black-market pharmacists, con-artists, and the like. I sometimes wonder whether the folks at Blogger have trouble sleeping nights.

Wending your torturous way through Blogger's documentation to find the means for reporting spammy blogs can be very frustrating. Here's some of what I've been able to piece together:

NOTE: I have seen Google suspend some spam portal blogs, so perhaps the flagging process can really be an alternative to the traditional "abuse@" address in a few flagrant cases.

Here's a recent discussion on the SpamCop forums that further illustrates the frustrating lack of clarity of Google's policies with regard to Blogger (and the free Blog*Spot hosting service).

Using search engines and "URL shortening services" as redirectors

There are many internet services that specialize in turning very long and complicated URLs into very short ones. These are used by folks who want to

Reverse proxying of websites

What can (or should) be done about spam website redirection?

It isn't illegal, or even unethical, for even spammers to use website redirection. Even if we could make some kind of "law" against this practice, it would be a very silly law, one that would "criminalize" a whole range of perfectly innocent uses of the internet. However, if you are a spammer using redirection from a portal website, you may be in violation of the acceptable use policies or terms of service of the hosting services you use both for your portal site(s) and your "real" site. Furthermore, if you make illegal use of other people's computers to set up your sites (as the bot-net crowd does), then you are in clear violation of the law.

From my perspective, I believe that I am perfectly entitled to report the use of both portal websites and "real" websites in support of spam, so long as I am careful to do my research properly.

Typically, SpamCop does not attempt to track website redirection; it will only identify the IP address and contact information for the portal site (if, indeed, it even does this). Reporting the redirected-to sites, then, is something you'll have to undertake yourself via a "manual report."

When making such a report, you will want to collect the following data:

  1. The full URL of the redirected-to website(s);
  2. The IP address to which each of the URLs resolves; and,
  3. The abuse contact e-mail address for the organization (ISP) that controls the net block where the address is found.

You will want to state in your report that ...

There are no comments on this page. [Add comment]

Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by Wikka Wakka Wiki
Page was generated in 0.4347 seconds