PermaLink Anatomy of a Phish
Have you ever wondered why it is that apparent phishing emails sometimes appear as raw HTML?

Anatomy of a phish

Well I have, and curiosity finally got the better of me so I decided to take a few minutes to delve into one recent sample.

Let's get the obvious part out of the way first.

The entire body of the email is double spaced. That is, it has additional blank lines between every line of HTML.

(That <script...> tag you can see is all on a single line and has wrapped, which is why no blank lines appear within it.)

What would cause these additional blank lines? Could it be our old friend line termination, which differs between Windows and Unix systems. Windows text files use <CR><LF> to separate lines, where Unix and like systems use only <LF>. This type of double spacing of text files typically occurs when a text file originates on a Windows system and is transferred without modification to a Unix system.

The author of the phish seems to be using Windows, but has chosen a Unix host to transport his mail for him.

A quick look at the headers confirms this. There is only a single received header and it was written by a host which is currently running qmail. There being no Windows version of qmail, at least not one which is in common use, it seems reasonable to assume that this is a Unix host. Further digging reveals Apache and PHP on the same server, as you will see, so the diagnosis of a Windows text file on a Unix host seems very sound.

RFC5322 and its predecessors say that the structure of an email is, very broadly

  • headers,
  • blank line,
  • body

If an unintended blank line creeps in where the headers should continue, then the remaining headers and body all appear as body, as we see here.

The next mystery is why did that Unix host relay the email for the phisher?

This time, the clue is in the SMTP envelopes, which are of course not present in the message source but are recorded in the log of our inbound MTA.

The sender envelope is:

<php-sender-[mule]@qualified.host.name.of.unix.host>

Mule, here, is the name of an organisation which I have chosen not to name and whose PHP based web site is hosted on that very server.

This is most probably an XSS exploit against the PHP content management system in use by that organisation. It is not clear from the content of the HTML served by the web site in question which CMS it is, if there is one, or if the site has been implemented entirely in PHP by its author. However, there being no form of any kind on this web site, it seems likely that it is does use a CMS which incorporates standard forms and that the phisher (or more probably his tech supplier) has worked out where these are and how to exploit them.

So, the Unix host did not relay the phish it all. The phish originated locally at that server using a PHP script to write SMTP envelopes and the first few headers and then merge that Windows text file, which was either pulled from some remote location or submitted as the body of the exploited form.

Now, how was the text file made?

Here things take on a darkly comic hue.

The HTML delivered as the message body still bears Javascript above <HTML> and below </HTML> and this Javascript is clearly commented with:

<!-- text above generated by server. PLEASE REMOVE -->

and

<!-- text below generated by server. PLEASE REMOVE -->

Both of these were added to the original phish HTML by Yahoo! Geocities, a free web hosting service operated by Yahoo!. The Javascript at the top causes a frame to open on the right hand side of the browser window and attempts to populate it with contextual advertising. The Javascript at the bottom implements a hit counter.

While there may be some logic in retaining the hit counter, the retention of the Yahoo! contextual advertising demonstrates that the phisher doesn't really understand what he is doing and is simply following a recipe. Rather badly.

Indeed, the Yahoo! advertising Javascript contains a number of other attributes which the phisher probably did not mean to divulge, including:

  • His IP address
  • His Yahoo! Geocities username

And finally, that IP address gives us the phisher's location.

He's in Lagos, Nigeria on a dial-up connection.

Why does this not surprise me?

So, in summary:

  • The Phisher is not the sharpest tool in the box, so has clearly acquired the technique he has used from someone else.

  • He is in Lagos. Is phishing the new 419?

  • The Phisher crafted his phish using Yahoo! Geocities PageBuilder.

  • He downloaded the raw HTML of his creation using Internet Explorer and used that downloaded HTML without modification.

    (The original HTML for the phish may still be seen at the original Yahoo! Geocities location, also revealed in the HTML source of the phish.)

  • He used an XSS exploit acquired from a third party against a PHP/Apache/Unix server to send the phish.

Move along now. Nothing more to see here.


See also: Road Kill




Category: Phish
Technorati:

Comments :

1. Stephan H. Wissel26/11/2008 17:50:39
Homepage: http://www.wissel.net/


Nice one. A good lesson in forensics.
A friend of mine works in the Nigerian embassy. He confirmed, that the scamming still finds regular victims.
stw




Unable to post a comment? Please read this for a possible explanation...
Add Manual Trackback
Please enter the details of the trackback post. Your trackback will not appear on the site until it has been verified. This won't be immediate, as trackbacks are validated on a scheduled basis. Be patient.











Search
Hot Categories
Monthly Archive
Links
Contact Me
Subscribe
Subscribe to articlesArticles

Subscribe to commentsComments

Visitor Locations
Hosted by