home | legal stuff | glossary | blog | search

 Legend:  new window    outside link    tools page  glossary link   

Spam analysis: example #6
Forged header and suspicious HTML anchors (beacons?)

As we see in example #2 and elsewhere, spammers frequently use “beacons” (also called “web bugs”) to get feedback on exactly which of their recipients have opened their messages (this tells them which addresses are available for future spamming, and which ones may be “dead” and should be dropped from their lists).

In the case of example #2, the spammer used an IMG link to fetch an invisible one-pixel graphic (with identifying information appended to the URL in a CGI call) as his web bug, but a web bug can actually be any sort of hyperlink that causes an HTTP fetch from the remote server; this transaction, together with whatever plain-text or encrypted information the spammer wants to save, gets recorded in the spammer’s web server logs for later review. In this particular example, the spammer may be using bogus anchor specs to transfer this information.

Anchors Aweigh!

To review some basic HTML: you can insert a named anchor in a web page at any point you think may be of interest to a reader; then, you can construct hyperlinks on other pages or other sites that will take the visitor directly to that spot, even if it is in the middle of a very long page. For example, if you created a page named “oceans.html”, you could plant the following anchor link in that page just before your discussion of the Pacific:

<A name="Pacific"></A>The Pacific is a big ocean...

Then, elsewhere on your site, you could put hyperlinks like the following to take the viewer directly to that section:

Click here to <A href="oceans.html#Pacific">read about the Pacific Ocean</A>

Note that the anchor’s spec (its name) goes after the page name, separated by a hash mark (“#”). Now, once a visitor actually uses that link, you can go to your web server’s logs and find a reference to the complete URL (plus the anchor spec, as “oceans.html#Pacific”), together with time, date, IP address, and other information of interest. Of course, you’ll only see the IP address of the machine that fetched the page (or possibly of the web proxy it hides behind), and not anything that would actually identify the user directly. Keep reading, though, we’re getting to the interesting part.

When your visitor clicks on that Pacific link, he or she will actually get the whole “oceans.html” page from your server, but the browser will automatically scroll down to the anchor named “Pacific” as soon as the page stops loading. But what happens if, for some reason, you forgot to put the named anchor <A name="Pacific"> on your oceans page, or if you misspelled it? If the browser can’t find the requested anchor on the page, it recovers “sliently” from this error by putting the user at the top of the page (not printing any sort of error message or warning, and in effect ignoring the busted anchor).

We now know the following two things about named anchors:

If you’re clever, perhaps you’ve already put two and two together:

Look carefully at the body of the message below, and you will see that every single URL (except the first) has an anchor spec (the part after the “#”). You will also see that the anchor spec is a very long string of seemingly-random gibberish (I deleted these strings for brevity and for my own protection, but I replaced them with the character counts <<in red>>).

Return-Path: < address hidden >
Received: from [24.33.129.95] ([24.232.221.33]) by
    mta019.verizon.net
    (InterMail vM.5.01.05.33 201-253-122-126-133-20030313)
    with SMTP id <20030525054622.
    TXDW25978.mta019.verizon.net@[24.33.129.95]>
    for address hidden; Sun, 25 May 2003 00:46:22 -0500
    Return-Path:
Received: from [14.42.188.81] by sydint1.microthin.com.au
    with asmtp; May, 25 2003 1:22:39 AM -0200
Received: from smtp-server6.tampabay.rr.com
    ([12.232.159.86]) by mailout2-eri1.midsouth.rr.com
    with asmtp; May, 25 2003 12:42:55 AM +0600
Received: from 87.15.78.89 ([87.15.78.89]) by pet.vosn.net
    with local; May, 24 2003 11:35:37 PM +1200
From: wmscBrian <address hidden>
To: address hidden>
Subject: Re: address hidden D1ET PATCH WE1GHT L0SS
    address hidden cuhov
Sender: wmscBrian <address hidden>
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Date: Sun, 25 May 2003 01:45:56 -0700
X-Mailer: AOL 7.0 for Windows US sub 118
Message-Id: <20030525054622.TXDW25978.
    mta019.verizon.net@[24.33.129.95]>

<body>
<p align="center">
<a href="http://<<84 chars>>@portspotz.com/KDC/logs/patch/
    index.php?WM_ID=<<67 chars>>">
<img border="0" src="http://<<73 chars>>@portspotz.com/KDC/
    logs/patch/999.gif#<<73 chars>>"></a></p>
<p align="center">
<img src="http://<<76 chars>>@portspotz.com/KDC/logs/patch/
    images/spacer.gif#<<66 chars>>" height="200" width="1">
</p>
<p align="center">
<a href="http://<<89 chars>>@portspotz.com/KDC/logs/o/
    index.html#<<71 chars>>">
<img border="0" src="http://<<84 chars>>@portspotz.com/KDC/
    logs/o/o.gif#<<73 chars>>"></a></p>
</body>

podxfdbyajnpgetgpwlxhbwgeaf

Another thing to note is that two of these hyperlinks are IMG links, which means that they get fetched whether I want them or not (i.e., I don’t have to click on anything in order for them to be fetched and loaded). Of course, it doesn’t make sense to have an anchor spec in an IMG tag as was done on the last link (you can’t anchor spots within a single image), but I imagine that the URL gets logged anyway, so the trick may serve its purpose.

Not only do we have funny numbers in the anchor specs, we have them in the host name as well, appearing as the little-used “user ID” field of the URL (separated from the actual host name by a “@” character). Since user IDs typically aren’t used in HTTP, these are usually ignored by web servers (but may be logged along with the anchor specs).

All but three of these funny number strings are of different size, and none of them looked the same to me at a glance. Therefore, it is possible that these might be (relatively) innocent hashbusters (long strings that are periodically permuted to defeat some server-side spam detection tools) just like the very last line below the </body> tag. On the other hand, these could also contain my e-mail address in an encrypted form. Possibly only one of them might contain this information, and the others might just be there for camouflage. Still, to my mind, any long random-looking character string that appears in an HTML spam mail hyperlink is worthy of the deepest suspicion.

Message transfer details

As for the header, the very first received-line is an obvious forgery (it contains two different IP addresses for the from-host, rather than the “[00.11.22.33] (host-name.com)” form that we expect to see. The authentic address 24.232.221.33 points to a host in the fibertel.com.ar domain, so the spammage was likely launched using an Argentine host. The rest of the received lines are very interesting (attempting to fix blame on the rr.com domain, and an Australian provider “microthin.com.au”), but quite fictitious. Going to http://www.vosn.net (registered by parties unknown in Colorado) takes us not to a corporate “splash” page as we might expect, but to a lengthy and conscientious-looking anti-spam policy (hmmm...Joe job?). The X-Mailer field in the header implies that the spam may have been originated by an AOL user (who relayed it through the Argentine host), but I wouldn’t lean on this very heavily (and we don’t know who that user is in any case).

The portspotz.com domain pointed to by all the web URLs was hosted somewhere in mainlnd China, and is no longer active. A whois on this domain yields the information that it is no longer registered.

Next example :: Previous example :: Back to sample analyses



 home | legal stuff | glossary | blog | search

 Legend:  new window    outside link    tools page  glossary link   

(c) 2003-2006, Richard C. Conner ( )

03959 hits since March 28 2009

Updated: Sat, 06 May 2006