"Referer" Field Used in the Battle Against Online Fraud
The "referer" [sic] header is generallyused to track back-links in order to understand how a certain Web siteis being reached by its visitors (hyperlinks on other Web sites, searchengines, etc.) According to the RFC2616,“...the Referer request-header field allows the client to specify, forthe server's benefit, the address (URI) of the resource from which theRequest-URI was obtained (the "referrer", although the header field ismisspelled).”
In the online fraud arena, the referrer field can also be used todetect new phishing Web sites. Let’s use as an example the followingphishing site (which also happens to be a Rock Phish attack):
If a legitimate user visits this site and submits the form, thephishing site saves the credentials and then redirects the user to thereal Internet banking Web site. When the redirection takes place (inthis case with a standard HTTP 302 “Moved Temporarily” error), theuser’s browser requests the URL included in the “Location” field,including a referrer field in its HTTP request headers, which containsthe absolute uniform resource identifier (URI) of the phishing Web site.
On the server side it is trivial to log referrer fields for everyHTTP request (just give a look to the documentation of your Web server)and setup a notification system that sends out alerts when an unknownreferrer is found. The system would need a bit of fine-tuning initiallyin order to setup a proper whitelist of legitimate linking Web sites.Many phishing Web sites also load resources from the legitimate Websites (images, css files, JavaScript files, etc.), which will leave asimilar footprint in the logs as well.
This simple early warning mechanism can be easily circumvented byavoiding the loading of resources from the legitimate Web site and thenredirecting the user at the end of the phishing "session." However,this is actually almost always done in currently known phishing kits inorder to enhance the overall attack credibility.
One additional thing you should think about is that in the majorityof cases, when a phisher setups a new fraudulent Web site, what he/shedoes before sending out the phishing email is to test it. This meanstwo thing to us:
• The first referrer of a new active phishing Web site will probably beproduced by an IP used by the phisher, which would allow the financialinstitution to have good information for law enforcement agenciestrying to track and prosecute criminals;
• The financial institution would be able to know about a new phishingWeb site even before phishing emails are sent out, allowing a quicktrigger of the incident response process, which is something crucial to minimizing losses.
If the phisher is cautious and able to hide (for example, through ahijacked PC or server used as a proxy), this information will not beuseful for tracking purposes, but Symantec has noted that most of thetime they actually don’t do it. On the other hand, it is fairly simpleto tell which IP addresses look suspicious and which don’t.
Finally, counting the number of hits with a referrer field pointingto a verified phishing URL would provide information on how many usershave been visiting it and filling out the form. This would provideadditional information to help evaluate the risk of each attack, whichis something I have already been discussing in the past and a point on which I will return with more details in the near future.
