Analysis of a spam message using extensive spoofing techniques

Today, I came across a spam message pushing Asian porn.  The body of the links contained a redirector from and yahoo sites to the sites containing the payload.  It’s a pretty standard technique for spammers to exploit known trusted sites like Google and Yahoo in hopes of evading content filters, since the assumption is that a content filter wouldn’t block on the domains whereas they would certainly block on where the sites point to.

I’m not going to go into that particular technique, instead, I will delve into the spam message headers and the extents the spammer has gone to in an attempt to mask his location.  Below are the headers with some parts redacted:

Received: from (unknown []) by (Postfix) with ESMTP id 2BAEA1BA8052;  Fri,  8 Jan
2010 15:33:08 +0000 (UTC)
Received: from S-Orangesky.Orangesky.local ( by ( with Microsoft SMTP Server (TLS) id
14.0.482.32; Fri, 8 Jan 2010 15:33:07 +0000
Received: from ( by
s-orangesky.orangesky.local ( with Microsoft SMTP Server
id 8.1.393.1; Fri, 8 Jan 2010 15:29:46 +0000
Received: from ( []) by  with
Microsoft SMTPSVC(5.0.2195.6824);       Tue, 12 Jan 2010 16:36:51 +0100
Message-ID: <>
Date: Tue, 12 Jan 2010 16:27:51 +0100
From: "???i?i???i?iFw: AV ?W?a????r??,DVD????,??????e!!"
Reply-To: "?D????x?????!!?C???u?n40??!!?f??~???I??,?w?????O??!!" <>
To: <redacted>
Subject: LANDY ??P ???????A
MIME-Version: 1.0

This can be a little hard to read, so let me describe the path this message purportedly took to get to the end user’s inbox:

  1. The message originated from a Yahoo web server somewhere.  This is evidenced by the fact that the Message-ID contains a portion and the From address points back to a Yahoo email alias…
  2. It arrived at a home user’s computer in China, on the ChinaNet Telecom ISP where…
  3. It was forwarded along to a computer running in the corporation OrangeSky’s network where…
  4. It was forwarded along to mail servers that our network is running in order to get back to the end user.

Below is a diagram of the path.




Click for ginormous image.

Of course, that is not what actually happened nor is it the route that actually occurred.  There is a whole heck of a lot of spoofing going on, below is an analysis of what is wrong with the above headers and how much effort the spammer has put into hiding his location.

  1. To begin with, the spammer claims that the originating mail server’s HELO and reverse DNS is  This domain does not actually exist in DNS (ie, it has no A-record), nor does the IP’s reverse DNS point to, ie, Yahoo didn’t accidentally set up a domain with no A-record but does have a PTR record for a particular IP.

  2. The IP address is reserved for the Internet Assigned Numbers Authority (IANA).  It does not send out email.  Combining this and the first point, the originating header (ie, the bottom one) is forged.
  3. When the spam message eventually gets to our servers, it comes from the IP  However, when it (purportedly) comes to the infected server from the Chinese computer, it HELO’s as that same IP address.  In other words, it HELO’ed with the IP address that it was eventually going to send out from.  Whether or not this ChinaNET Telecom Received header is forged or not, it’s hard to say since the time stamps look about right.
  4. This IP address that it HELO’ed as is the (static?) IP address of the sending IP that would eventually connect to our servers.  However, the internal server that received the message was  In other words, it ignored the internal IP of the server that received it and instead mapped it to the eventual public IP.
  5. The name of the internal server is the same as the HELO string of the spam message.  This means that the spamming software had to get the host’s internal name and store it for sending out the spam message.  This internal name is (likely) correct because this was an outbound spam message and the name of the company is contained within the HELO string.

    Of course, both this point and the previous point occur in headers that cannot necessarily be trusted.  However, it does illustrate the depths that the spammer will go to to hide where he is located by either including confusing information, or having access to information in order to make himself look more legitimate.

Below is a diagram containing what I just said.  I think it’s clear that OrangeSky has a problem on their system and it’s probably infected with a piece of malware that is able to harvest the name of the internal host as well as figure out what the public outbound IP will be when it eventually starts spamming.



Click for bigger image.

Comments (4)
  1. kjopc says:

    An interesting post. Spam is clearly a big business where the CAN-SPAM stuff has barely made a dent.

    Does anyone ever alert the owners of infected computers so they can do something about the abuse by spammers?

    Are the "victim" ISPs blissfully unaware or wilfully blind to spammers?

  2. Steve says:

    Yes, in Australia ISPs will try to contact a customer and if they can’t do that, the connection will be suspended. That way, the customer will phone and get the bad news.

    Also, some ISPs in Australia will, by default, block ports known to be exploited by spammers. Customers have the option of removing such blocks if they so desire.

    These methods seem to be quite effective.

  3. K.Kong says:

    I am still curious why purveyors of spam can still benefit from spam if it is illegal.

    If a spammed mail is trying to sell something, surely the seller must be contactable in order to sell that thing.  How then do they get away with it?

    If a bus-stop says "STICK NO BILLS", how do you put up a notice for a room to rent and still get away with it?

  4. Here is my take on the path this message had took.

    1. This spam originated at IP, which can be identified from the 3rd Received header.

    2. An NAT device with public IP, forwards its SMTP port to internal host s-orangesky.orangesky.local, which was an open relay.  The spammer didn’t know the internal name of the open relay.  He merely used the open relay’s IP as its own HELO string.  The 3rd Received was added by the host s-orangesky.orangesky.local.

    3. Then s-orangesky.orangesky.local forwards the message to its destination,, which might be the mx host for

    So only the 4th Received header was forged.

    Chih-Cherng Chin

Comments are closed.

Skip to main content