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 google.com.tw 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 yahoo.com 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 VA3EHSMHS031.bigfish.com (unknown [10.7.14.247]) by
mail182-va3.bigfish.com (Postfix) with ESMTP id 2BAEA1BA8052; Fri, 8 Jan
2010 15:33:08 +0000 (UTC)
Received: from S-Orangesky.Orangesky.local (62.253.203.138) by
mail.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id
14.0.482.32; Fri, 8 Jan 2010 15:33:07 +0000
Received: from 62.253.203.138 (125.110.109.119) by
s-orangesky.orangesky.local (10.210.34.10) with Microsoft SMTP Server
id 8.1.393.1; Fri, 8 Jan 2010 15:29:46 +0000
Received: from smfxv.yahoo.com (smfxv.yahoo.com [225.110.237.42]) by with
Microsoft SMTPSVC(5.0.2195.6824); Tue, 12 Jan 2010 16:36:51 +0100
Message-ID: <rjphnvpmllktvwswgchpyn.01833659486395242036187@yahoo.com>
Date: Tue, 12 Jan 2010 16:27:51 +0100
From: "???i?i???i?iFw: AV ?W?a????r??,DVD????,??????e!!"
<dzccijukmtx@yahoo.com>
Reply-To: "?D????x?????!!?C???u?n40??!!?f??~???I??,?w?????O??!!" <dzccijukmtx@yahoo.com>
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:
- The message originated from a Yahoo web server somewhere. This is evidenced by the fact that the Message-ID contains a yahoo.com portion and the From address points back to a Yahoo email alias…
- It arrived at a home user’s computer in China, on the ChinaNet Telecom ISP where…
- It was forwarded along to a computer running in the corporation OrangeSky’s network where…
- 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.
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.
To begin with, the spammer claims that the originating mail server’s HELO and reverse DNS is smfxv.yahoo.com. This domain does not actually exist in DNS (ie, it has no A-record), nor does the IP 225.110.237.42’s reverse DNS point to smfxv.yahoo.com, ie, Yahoo didn’t accidentally set up a domain with no A-record but does have a PTR record for a particular IP.
The IP address 225.110.237.42 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.
When the spam message eventually gets to our servers, it comes from the IP 62.253.203.138. 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.
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 10.210.34.10. In other words, it ignored the internal IP of the server that received it and instead mapped it to the eventual public IP.
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.
