0 Results Found
              Back To Results
                Fundamentals

                Pay-per-Click Hijacking

                By: Joe Stewart
                • 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