0 Results Found
            Back To Results
              Threat Analysis

              Pay-per-Click Hijacking

              • Author: Joe Stewart

              Search hijackers are not a new phenomenon; however, their purveyors are becoming more and more aggressive in capturing clicks from web users.

              Often, attempting to find the entity behind the hijack becomes an endless task of following layer after layer of obfuscation. Below we attempt to peel back the layers of one major search hijack incident in a step-by-step illustration.

              The incident in question involves DNS hijacking, and was widely reported in the beginning of 2005. The hijack was simple, and the vulnerability old and well-known. It involved a rogue DNS server sending bogus authority records in a DNS reply packet, in which it claimed to be the authoritative server for all of the .com TLD. Vulnerable hosts would then direct queries for any .com sites to the rogue DNS server. See the incidents.org March 31 Handler's Diary for details.

              Update:

              Several people have asked how to stop the hijacking from occurring on their computer. End users may not be able to prevent cache poisoning - the problem lies with the user's ISP or company DNS servers. Users may direct the persons responsible for maintenance of the DNS servers to Microsoft's KnowledgeBase article 241352, which explains how to secure Windows DNS servers against this type of cache poisoning (or "cache pollution", as Microsoft calls it). Modern *nix-based DNS servers are not vulnerable to this type of attack. This vulnerability in Windows DNS services has been common knowledge for nearly four years now.

              At the time of this writing, the hostile websites and IP addresses were:

              www.abx4.com A 72.9.233.153www.abx4.com A 216.55.185.467sir7.com
              A 72.9.233.1537sir7.com A 216.55.185.46123xxl.com A
              72.9.233.153123xxl.com A 216.55.185.46

              We decided to follow along and see where the hijack would lead in the end. Since we're not vulnerable to the attack, we substituted the attacker's webserver IP 216.55.185.46 for the real IP of www.cnn.com on our machine by adding the following line to /etc/hosts:

              216.55.185.46 www.cnn.com

              We then began to follow the trail as if we were a victim user visiting www.cnn.com. We operated as if we were unknowingly hijacked and perhaps naive enough to click on the links presented to us, which is not unimaginable for a less-than-savvy websurfer.

              We will present the raw HTTP request headers and responses below in order to demonstrate layers that may be invisible to the user. Our requests are presented in green, and the remote webserver's replies are in red.

              Also, it is not recommended to visit any of the links below - it has been reported that remote malware installs on vulnerable IE installations have been associated with this scheme. We didn't encounter any exploit links in the path we followed, but that may be due to the use of Firefox as opposed to IE - some hostile sites actively check the User-Agent field and only deliver exploits to hosts they believe will be vulnerable. In any case we do have prior evidence of the initial hosts in the chain installing malware in the past.

              Starting up Firefox and typing in www.cnn.com:

              cnn-blank

              GET / HTTP/1.1
              Host: www.cnn.com
              User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)

              Our hijacker's webserver answers with the following:

              HTTP/1.1 302 Found
              Date: Fri, 01 Apr 2005 14:19:34 GMT
              Server: Apache/2.0.52 (FreeBSD) PHP/4.3.10
              Location: http://error404.web-search.la/error.html
              Content-Length: 313
              Connection: close
              Content-Type: text/html; charset=iso-8859-1

              <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
              <html><head>
              <title>302 Found</title>
              </head><body>
              <h1>Found</h1>
              <p>The document has moved <a href="http://error404.web-search.la/error.html">here</a>.</p>
              <hr>
              <address>Apache/2.0.52 (FreeBSD) PHP/4.3.10 Server at www.cnn.com Port 80</address>
              </body></html>

              We've been redirected now to error404.web-search.la/error.html. This happens invisibly, when our browser makes the following request for us:

              GET /error.html HTTP/1.1
              Host: error404.web-search.la
              User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)

              The hijacker's webserver responds with the following:

              HTTP/1.1 200 OK
              Date: Fri, 01 Apr 2005 13:50:02 GMT
              Server: Apache/2.0.48 (Unix)
              Last-Modified: Fri, 01 Apr 2005 09:19:45 GMT
              ETag: "68840e-14e-82d42e40"
              Content-Length: 334
              Connection: close
              Content-Type: text/html; charset=ISO-8859-1

              <html><head>
              <title>404 Not Found</title>
              </head><body>
              <script language="JavaScript" src="http://vparivalka.org/G7/anticheatsys.php?id=36381"
              type="text/JavaScript"></script>
              <h1>Not Found</h1>
              The requested URL was not found on this server.<p>
              </body></html>
              <iframe src="http://www.web-search.la/" width=700 height=570></iframe>

              So, a 404 error - but with an iframe that loads the content of http://www.web-search.la/ into the same page.

              GET / HTTP/1.1
              Host: www.web-search.la
              User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
              Referer: http://error404.web-search.la/error.html

              This returns a page resembling a search engine. It also includes javascript that loads www.lycos.la in another browser window automatically.

              GET / HTTP/1.1
              Host: www.lycos.la
              User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)

              www.lycos.la is another, slightly different search engine page (with no relation to Lycos.com as far as we can tell). Put together, the result so far looks like this:

              searchpages

              Now, we want to proceed as if we were actually interested in some of the links on the page. So, on the web-search.la page, we'll click on "New Cars":

              GET /iresults.php?qq=New+cars HTTP/1.1
              Host: www.web-search.la
              User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
              Referer: http://www.web-search.la/

               

              The search results:

              Ok, a well-known auto manufacturer is the top result. Let's click and watch what happens:

              GET /iresults.php?rd=1&qq=New+cars&subaff=&pos=1&go=aHR0cDovL3VzMDEueG1sc2VhcmNoLmZpbmR3aGF0L

              mNvbS9iaW4vZmluZHdoYXQuZGxsP2NsaWNrdGhyb3VnaCZ5PTQ3MTYxJng9OW5ZNEZ2WXc5dG0zNEI0UFkxcFQ

              6RWJ1MFRlVDlraXQzOWFpOVlBMlEyMUlTRVJOSllSQ2ZlaXRNejhISTFwZFhsQWhGRTFKRmpXMWZFdU5SRHJuTXR

              wSlRMZkpZOGFkVEQwbmp2VHpTOG1RdEVUaTlpWWNKVk1zSzR4RjR6QWlUMXJCZ2lXNWMxUmdrQnJqYWVoaztl

              O2w0dHhXa0REMXpnWUVPUjtKVGkkJFo=&b=MC4xMDY=&se=ZmluZHdoYXQ=&mode=&al=http://81.9.3.77/click.php HTTP/1.1
              Host: www.web-search.la
              User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
              Referer: http://www.web-search.la/iresults.php?qq=New+cars

              At this point we begin to be redirected through a series of servers and scripts:

              HTTP/1.1 302 Found
              Date: Fri, 01 Apr 2005 13:53:45 GMT
              Server: Apache/2.0.48 (Unix)
              X-Powered-By: PHP/4.3.8
              Location: http://81.9.3.77/click.php?surfer_ip=x.x.x.x&aff=4895&qq=New+cars&subaff=&pos=1&go=aHR0cDovL3VzMDEueG1sc2VhcmNoL

              mZpbmR3aGF0LmNvbS9iaW4vZmluZHdoYXQuZGxsP2NsaWNrdGhyb3VnaCZ5PTQ3MTYxJng9OW5Z

              NEZ2WXc5dG0zNEI0UFkxcFQ6RWJ1MFRlVDlraXQzOWFpOVlBMlEyMUlTRVJOSllSQ2ZlaXRNejhISTFw

              ZFhsQWhGRTFKRmpXMWZFdU5SRHJuTXRwSlRMZkpZOGFkVEQwbmp2VHpTOG1RdEVUaTlpWWNK

              Vk1zSzR4RjR6QWlUMXJCZ2lXNWMxUmdrQnJqYWVoaztlO2w0dHhXa0REMXpnWUVPUjtKVGkkJFo

              =&b=MC4xMDY=&se=ZmluZHdoYXQ=&mode=
              Content-Length: 0
              Connection: close
              Content-Type: text/html; charset=ISO-8859-1

              The redirect above sends us to 81.9.3.77 with a boatload of parameters. Looking at the parameters we can see they seem to resemble base-64 mime encoding. A simple Perl one-liner can show us what is hidden in the URL:

              perl -MMIME::Base64 -e 'print decode_base64
              ("aHR0cDovL3VzMDEueG1sc2VhcmNoLmZpbmR3aGF0LmNvbS9iaW4vZml
              uZHdoYXQuZGxsP2NsaWNrdGhyb3VnaCZ5PTQ3MTYxJng9OW5ZNEZ2WXc5
              dG0zNEI0UFkxcFQ6RWJ1MFRlVDlraXQzOWFpOVlBMlEyMUlTRVJOSllSQ
              2ZlaXRNejhISTFwZFhsQWhGRTFKRmpXMWZFdU5SRHJuTXRwSlRMZkpZOG
              FkVEQwbmp2VHpTOG1RdEVUaTlpWWNKVk1zSzR4RjR6QWlUMXJCZ2lXNWM
              xUmdrQnJqYWVoaztlO2w0dHhXa0REMXpnWUVPUjtKVGkkJFo="), "\n"'

              When run, it gives us:

              http://us01.xmlsearch.findwhat.com/bin/findwhat.dll?click
              through&y=47161&x=9nY4FvYw9tm34B4PY1pT:Ebu0TeT9kit39ai9YA
              2Q21ISERNJYRCfeitMz8HI1pdXlAhFE1JFjW1fEuNRDrnMtpJTLfJY8ad
              TD0njvTzS8mQtETi9iYcJVMsK4xF4zAiT1rBgiW5c1RgkBrjaehk;e;l4
              txWkDD1zgYEOR;JTi$$Z

              So, hidden in our URL is another URL, this time for findwhat.com. Let's see what happens when our browser follows it:

              GET /click.php?surfer_ip=x.x.x.x&aff=4895&qq=New+cars&subaff=&pos=1&go=a

              HR0cDovL3VzMDEueG1sc2VhcmNoLmZpbmR3aGF0LmNvbS9iaW4vZmluZHdoYX

              QuZGxsP2NsaWNrdGhyb3VnaCZ5PTQ3MTYxJng9OW5ZNEZ2WXc5dG0zNEI0UFk

              xcFQ6RWJ1MFRlVDlraXQzOWFpOVlBMlEyMUlTRVJOSllSQ2ZlaXRNejhISTFwZFhsQ

              WhGRTFKRmpXMWZFdU5SRHJuTXRwSlRMZkpZOGFkVEQwbmp2VHpTOG1RdEV

              UaTlpWWNKVk1zSzR4RjR6QWlUMXJCZ2lXNWMxUmdrQnJqYWVoaztlO2w0dHhXa

              0REMXpnWUVPUjtKVGkkJFo=&b=MC4xMDY=&se=ZmluZHdoYXQ=&mode= HTTP/1.1
              Host: 81.9.3.77
              User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
              Referer: http://www.web-search.la/iresults.php?qq=New+cars

              HTTP/1.1 302 Found
              Date: Fri, 01 Apr 2005 14:26:55 GMT
              Server: Apache/*.*.** (Unix) PHP/4.3.8
              X-Powered-By: PHP/4.3.8
              X-Accelerated-By: PHPA/1.3.3r2
              Set-Cookie: fwcl=1; expires=Sun, 03-Apr-2005 02:26:55 GMT
              Location: http://us01.xmlsearch.findwhat.com/bin/findwhat.dll?clickthrough&y=47161&x=9

              nY4FvYw9tm34B4PY1pT:Ebu0TeT9kit39ai9YA2Q21ISERNJYRCfeitMz8HI1pdXlAhFE1JFj

              W1fEuNRDrnMtpJTLfJY8adTD0njvTzS8mQtETi9iYcJVMsK4xF4zAiT1rBgiW5c1RgkBrjaeh

              k;e;l4txWkDD1zgYEOR;JTi$$Z
              Connection: close
              Transfer-Encoding: chunked
              Content-Type: text/html

              Well, we were redirected once again, this time to findwhat.com. Surprise, surprise. 

              What is FindWhat? It's a "Performance-Driven Marketing" company - meaning a pay-per-click search engine:

              Note the first parameter passed to FindWhat is "y=47161". This is likely the affiliate ID, passed in so the affiliate can get credit (any payment) for the click delivered. So far, no HTML has been displayed to the browser. It continues on, this time requesting the URL from findwhat.com:

              GET /bin/findwhat.dll?clickthrough&y=47161&x=9nY4FvYw9tm34B4PY1pT:Ebu0TeT9kit39a

              i9YA2Q21ISERNJYRCfeitMz8HI1pdXlAhFE1JFjW1fEuNRDrnMtpJTLfJY8adTD0njvTzS8mQtE

              Ti9iYcJVMsK4xF4zAiT1rBgiW5c1RgkBrjaehk;e;l4txWkDD1zgYEOR;JTi$$Z HTTP/1.1
              Host: us01.xmlsearch.findwhat.com
              User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
              Referer: http://www.web-search.la/iresults.php?qq=New+cars

              And now, (drum roll), yet another redirect:

              HTTP/1.1 302 Object Moved
              Location: http://redirect.findresolution.com/rdr/1728/number=10938471;z
              P3P: CP="NOI COM NAV"
              Content-Type: text/html
              Expires: Tue, 14 Mar 2000 05:00:00 GMT
              Cache-Control: Private
              Set-Cookie: uid=ap78uhy22MkZq:JJeJdMGq5c05Q%3BGMOvBHQg:fsZ5ayQVdQAZfL2WN

              PUZ; expires=Wednesday, 01-Jan-2020 00:00:01 GMT; path=/; domain=findwhat.com
              Connection: close

              <HEAD><TITLE>302 Moved Temporarily</TITLE>

              <META HTTP-EQUIV="Refresh" CONTENT="0;URL=http://redirect.findresolution.com/rdr/1728/number=10938471;z">

              </HEAD>

              <BODY bgcolor=#6666cc alink=#ffff99 vlink=#ffff99><font face=sans-serif,arial color=white><br>

              The website you are looking for is located below.<br>You are seeing this message because your web browser does not

              <br>properly support redirects. Please upgrade your browser to eliminate<br>this message while using FindWhat.com!<br>

              <P><font size=+2><b><A HREF="http://redirect.findresolution.com/rdr/1728/number=10938471;z">

              PLEASE CLICK HERE TO CONTINUE</A></b></P></font>

              </BODY>

              Ok, our browser is happily following along - still nothing has been displayed to the end user.

              GET /rdr/1728/number=10938471;z HTTP/1.1
              Host: redirect.findresolution.com
              User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
              Referer: http://www.web-search.la/iresults.php?qq=New+cars

              Another redirect - This time to ad.doubleclick.net:

              HTTP/1.1 302 Found
              Date: Fri, 01 Apr 2005 14:26:57 GMT
              Server: Apache/2.0.51 (Fedora)
              Location: http://ad.doubleclick.net/clk;13418303;10938471;z?http://www.mbusa.com/MBServlet/

              RedirectServlet?src=739&target=HOME&LEAD_TYPE=CORPB&site=%s
              Content-Length: 431
              Connection: close
              Content-Type: text/html; charset=iso-8859-1

              <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
              <html><head>
              <title>302 Found</title>
              </head><body>
              <h1>Found</h1>
              <p>The document has moved <a href="http://ad.doubleclick.net/clk;13418303;10938471;z?

              http://www.mbusa.com/MBServlet/RedirectServlet?src=739&target=HOME&LEAD_TYPE=CORPB&site=%s">here</a>.</p>
              <hr />
              <address>Apache/2.0.51 (Fedora) Server at redirect.findresolution.com Port 80</address>
              </body></html>

              Our browser follows the redirect from DoubleClick invisibly in the background:

              GET /clk;13418303;10938471;z?http://www.mbusa.com/MBServlet/RedirectServlet?src=739

              &target=HOME&LEAD_TYPE=CORPB&site=%s HTTP/1.1
              Host: ad.doubleclick.net
              User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
              Referer: http://www.web-search.la/iresults.php?qq=New+cars
              Cookie: id=8000004c65df440

              And now, we are finally at the end of the chain. Just kidding, it's another redirect:

              HTTP/1.0 302 Moved Temporarily
              Content-Length: 0
              Location: http://www.mbusa.com/MBServlet/RedirectServlet?src=739&target=HOME&LEAD_

              TYPE=CORPB&site=N2502.ResolutionMedia

              Hey, we're at least on mbusa.com finally:

              GET /MBServlet/RedirectServlet?src=739&target=HOME&LEAD_TYPE=CORPB&site=N2502.ResolutionMedia HTTP/1.1
              Host: www.mbusa.com
              User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
              Referer: http://www.web-search.la/iresults.php?qq=New+cars

              Well, ok, one more redirect, for old times' sake:

              HTTP/1.1 302 Found
              Server: Netscape-Enterprise/6.0
              Date: Fri, 01 Apr 2005 14:26:57 GMT
              Content-length: 0
              Content-type: text/html; charset=ISO-8859-1
              Set-cookie: JSESSIONID=0000FJojQ5iX7V3NzWiDpauaMdR:v13mn3gd;Path=/
              Set-cookie: UserOnMachine=37772616&36546905;Expires=Wed, 31-Mar-2010 14:26:58 GMT;Path=/
              Expires: Thu, 01 Dec 1994 16:00:00 GMT
              Set-cookie: SRCORIGIN=739;Path=/
              Cache-control: no-cache="set-cookie,set-cookie2"
              Location: http://www.mbusa.com/brand/index.jsp
              Content-language: en-US

              Now we are finally presented with a page, as if we had clicked on a legitimate advertisement for Mercedes:

              But what if we follow the links in the lycos.la page we were presented with?Lets choose "Air Travel":

              And let's follow the Travelocity link:

              GET /click.php?id=297d341bd64df475dcc962e88f33a805 HTTP/1.1
              Host: www.lycos.la
              User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
              Referer: http://www.lycos.la/search.php?q=Air%20Travel
              Cookie: PHPSESSID=aa783a83e8505b47da15d177b50615d1

              Similar to the click.php redirector above, we are sent to "go.php"with an encoded URL

               (although it doesn't seem to be base-64-encoded ascii):

              HTTP/1.1 302 Found
              Date: Fri, 01 Apr 2005 13:55:06 GMT
              Server: Apache/2.0.48 (Unix)
              X-Powered-By: PHP/4.3.8
              Set-Cookie: PHPSESSID=aa783a83e8505b47da15d177b50615d1; path=/
              Expires: Thu, 19 Nov 1981 08:52:00 GMT
              Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
              Pragma: no-cache
              Location: http://66.230.182.46/go.php?c=KZMjj80XATqyWBrQMptGL8yiuD9bOvU8YXYlgr6Or%2B5ExvqkHQSc4Z6WXL

              kcQS0jMQI3FkOK89WkrL02Rys0P3XXsn%2FjXIv6wQhwyg6e7Fc9UlibqQC22SqOzjIGjn

              R2J1fzJXm99C2EYeKgUJMEL4vt4F8k2ZqFhRAKwU6jkQVCNoBrvhNDD8czhD0KaKoHG

              ZYhCEhk5XenHk0B1P7PpE4PW0pms8Au8vrnpXoAfaRjPSjCSfMB%2BWmNoFuk%2F6s1u

              WPRogWapWCoBs4%2FZL0wwWip6Yh554WmzS9%2B95%2F3iA5unSBj1dDsgGcWuh7XE

              LqN84gXLqjNt%2BRCPE1jV%2BfLwE2syPjDwx3rwWeVTfrLFFTdHYtUqMgLB%2BFT7Jngru

              QnVNmOuNbN5JN7Tr7TcCK%2FMeg%2FTxWvZJI8WuPJNju7WKg%3D&v=2
              Content-Length: 0
              Connection: close
              Content-Type: text/html; charset=ISO-8859-1

              So our browser follows the redirect:

              GET /go.php?c=KZMjj80XATqyWBrQMptGL8yiuD9bOvU8YXYlgr6Or%2B5ExvqkHQSc4Z6WXLkcQS0jM

              QI3FkOK89WkrL02Rys0P3XXsn%2FjXIv6wQhwyg6e7Fc9UlibqQC22SqOzjIGjnR2J1fzJXm99C2EYeKgUJ

              MEL4vt4F8k2ZqFhRAKwU6jkQVCNoBrvhNDD8czhD0KaKoHGZYhCEhk5XenHk0B1P7PpE4PW0pms8Au

              8vrnpXoAfaRjPSjCSfMB%2BWmNoFuk%2F6s1uWPRogWapWCoBs4%2FZL0wwWip6Yh554WmzS9%2B95

              %2F3iA5unSBj1dDsgGcWuh7XELqN84gXLqjNt%2BRCPE1jV%2BfLwE2syPjDwx3rwWeVTfrLFFTdHYtUqMgL

              B%2BFT7JngruQnVNmOuNbN5JN7Tr7TcCK%2FMeg%2FTxWvZJI8WuPJNju7WKg%3D&v=2 HTTP/1.1

              Host: 66.230.182.46
              User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
              Referer: http://www.lycos.la/search.php?q=Air%20Travel

              Just like before, the result of the first redirect is a redirect to findwhat.com:

              HTTP/1.1 302 Found
              Date: Fri, 01 Apr 2005 14:28:17 GMT
              Server: Apache/2.0.52
              X-Powered-By: PHP/4.3.9
              Location: http://us01.xmlsearch.findwhat.com/bin/findwhat.dll?clickthrough&y=48052&x=QHGJxc2e6U:

              s45dVEpIKrhlPkAl;nO7RWaQoShQ51wdAwf2VAbyH50PkdyltQwJVCJ68xh34qSBHnq:U2IFdsSs;7H70Eb

              UNgh588c:FhAPLZbLhB:29prGo3FLdeK628AFrMy3q8SljC:73ObI47b5pWO:qc;OUxrU8xpkAZ
              Content-Length: 0
              Connection: close
              Content-Type: text/html

              This time our suspected affiliate ID is 48052 - multiple people? Or just the same rogue affiliate with multiple accounts?

              At this point, we know what happens - a redirect through ad.doubleclick.net, which finally brings us to:

              GET /flights HTTP/1.1
              Host: travelocity.com
              User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
              Referer: http://www.lycos.la/search.php?q=Air%20Travel

              At this point we can see clearly what is happening - the big-name companiesare advertising on legitimate networks that utilize pay-per-click search engines to drive traffic to the ads. Unfortunately, the pay-per-click model lends itself to abuse by rogue affiliates who will hijack users in order to drive up their click count and revenue.

              At the heart of the pay-per-click model is findwhat.com. While it is a legitimate enterprise itself, it is the entity that pays the affiliates who are actively employing trojans and dns cache poisoning to drive traffic to the advertisers. FindWhat has a policy prohibiting certain activities of this type, and will likely terminate any affiliate account reported to them for abuse. However, terminating the account only means that FindWhat benefits from the hijacker's activity without having to pay the hijacking affiliate. It's a win-win situation for them. FindWhat's estimated earnings for 2004 were between $167.5 and $179.5 million dollars. There is no way to determine how much of that revenue was generated by traffic from hijacked machines.

              This flowchart shows the flow of traffic and the flow of money in the scheme described above:

              It doesn't seem too far-fetched to imagine that the persons responsible for the DNS hijacking could be apprehended simply by serving FindWhat with a subpoena to find out where they've been sending the checks for the affiliate IDs being passed in the search redirects. However, this activity has persisted for years now without much law enforcement interest, and as each new affiliate comes on board they invent their own scheme to abuse the PPC system. Clearly it seems that through the chain of advertiser to consumer and back again, the end user is ultimately paying to have him or herself hijacked.

              Related Content