A Large-scale Analysis of Content Modification by
Open HTTP Proxies
Giorgos Tsirantonakis,∗ Panagiotis Ilia,∗ Sotiris Ioannidis,∗ Elias Athanasopoulos,† Michalis Polychronakis‡∗ FORTH, Greece† University of Cyprus, Cyprus‡ Stony Brook University, USA{tsirant, pilia, sotiris}@ics.forth.gr

eliasathan@cs.ucy.ac.cy

mikepo@stonybrook.edu

Abstract—Open HTTP proxies offer a quick and convenientsolution for routing web traffic towards a destination. In contrast
to more elaborate relaying systems, such as anonymity networks
or VPN services, users can freely connect to an open HTTP
proxy without the need to install any special software. Therefore,
open HTTP proxies are an attractive option for bypassing IPbased filters and geo-location restrictions, circumventing content
blocking and censorship, and in general, hiding the client’s IP
address when accessing a web server. Nevertheless, the consequences of routing traffic through an untrusted third party can besevere, while the operating incentives of the thousands of publicly
available HTTP proxies are questionable.
In this paper, we present the results of a large-scale analysis ofopen HTTP proxies, focusing on determining the extent to whichuser traffic is manipulated while being relayed. We have designed
a methodology for detecting proxies that, instead of passively
relaying traffic, actively modify the relayed content. Beyond
simple detection, our framework is capable of macroscopicallyattributing certain traffic modifications at the network level
to well-defined malicious actions, such as ad injection, user
fingerprinting, and redirection to malware landing pages.
We have applied our methodology on a large set of publicly
available HTTP proxies, which we monitored for a period of twomonths, and identified that 38% of them perform some formof content modification. The majority of these proxies can beconsidered benign, as they do not perform any harmful content
modification. However, 5.15% of the tested proxies were foundto perform modification or injection that can be considered as
malicious or unwanted. Specifically, 47% of the malicious proxies
injected ads, 39% injected code for collecting user informationthat can be used for tracking and fingerprinting, and 12%
attempted to redirect the user to pages that contain malware.
Our study reveals the true incentives of many of the publicly
available web proxies. Our findings raise several concerns, as we
uncover multiple cases where users can be severely affected byconnecting to an open proxy. As a step towards protecting users
against unwanted content modification, we built a service thatleverages our methodology to automatically collect and probe
public proxies, and generates a list of safe proxies that do not
perform any content modification, on a daily basis.

Permission to freely reproduce all or part of this paper for noncommercial
purposes is granted provided that copies bear this notice and the full citationon the first page. Reproduction for commercial purposes is strictly prohibitedwithout the prior written consent of the Internet Society, the first-named author(for reproduction of an entire paper only), and the author’s employer if thepaper was prepared within the scope of employment.
NDSS ’18, 18-21 February 2018, San Diego, CA, USA
Copyright 2018 Internet Society, ISBN 1-1891562-49-5
http://dx.doi.org/10.14722/ndss.2018.23244

I.

I NTRODUCTION

Internet users often place their trust on systems that are notunder their control. From a security and privacy perspective, aparticularly critical class of such systems is HTTP proxies thatact as “stepping stones” between web clients and servers. By
relaying their traffic through a proxy, users can access content
and services that are otherwise blocked due to geographicalrestrictions, content filtering policies, or censorship; and tosome extent preserve their anonymity, by hiding the originating
IP address from the final destination (although still exposing
it to the proxy).
Once the user traffic reaches the proxy towards its actual
destination, unless end-to-end encryption is used, a rogue orcompromised proxy can tamper with the transmitted content or
snoop for sensitive user data [27]. However, the problem is notalleviated even when end-to-end encryption is used, as man-inthe-middle attacks are still possible using fake or even valid—obtained through compromised CAs or generated by powerful
adversaries—certificates, or SSL-stripping attacks [20]. The
potential harm due to network traffic interception attacks canbe severe, ranging from mere annoyance and inconvenience tosystem compromise and theft of private information.
There has been a remarkable effort during the last years
by the community and some key organizations to make theweb more secure. The emergence of Certificate Authorities
that offer free TLS certificates such as Let’s Encrypt,1 andthe services launched by cloud providers such as CloudFlare2
and Amazon3 that enable certificate management without much
hassle, have resulted in increasing adoption of HTTPS. Only
recently the encrypted web traffic has surpassed the unencrypted traffic [11], but there is still a long distance to cover.
However, as a large volume of web content is still transmitted unencrypted over HTTP, rogue web proxy operators
can monetize their traffic by altering the relayed content toinject ads and affiliate links, prompt users to download spyware
and other unwanted software, or mount phishing attacks [16].
Even more deviously, instead of placing additional ads that
may annoy users, miscreants can replace existing ads in thepage with their own ads. This can be as simple as replacing
a website’s ad network identifier with the attacker’s own affiliate identifier, essentially stealing the revenue of the original
1 https://letsencrypt.org
2 https://www.cloudflare.com/ssl/
3 https://aws.amazon.com/certificate-manager/ads, the inclusion of tracking and fingerprinting libraries,
and the collection of data from social networking services
on which the user is already authenticated. Besides that, we
also discovered more severe and sophisticated instances ofmalicious behavior, such as SSL stripping and redirection toservers that have been reported to host malware.

website (i.e., publisher). A more severe form of network traffic
manipulation is the inclusion of malicious JavaScript code formounting XSS, CSRF, or DDoS attacks [18], the injection of
exploits against the browser or other client-side software [28],[33], or the infection of downloaded executables [24], which
can all result in full system compromise. In a proof-of-concept
implementation, Chema and Fernandez [7] deployed a malicious proxy that modifies the originally requested JavaScript
files to dynamically fetch and execute malicious code. This
allowed them not only to collect cookies and user sensitive
information, but also to take control of the infected hosts andbuild a botnet.

By identifying and analyzing multiple cases of content
injection and modification, this study provides insights about
the behavior of rogue web proxies and reveals many patterns
that exist between these modifications. This enabled us to build
a web service for assessing web proxies on a daily basis, andmaking publicly available a list of proxies that did not perform
any modification during our tests.

The proliferation and widespread use of web proxies necessitates an approach to detect, understand and measure theextent of content modification by rogue web proxies. The easeof setting up a free online proxy (e.g., on a cloud-hosted
virtual machine) and registering it on the numerous “proxy list”
websites, raises the question of whether miscreants employ
these tactics to attract and gain access to user traffic, and thenmonetize it or cause further harm. Sporadic evidence so far
has shown that this is indeed happening in various types of
network relays, including VPN servers and anonymity network
relays [1], [3], [6], [16], [24], [35], [36], but the extent of the
problem in the front of web proxies remains unknown.

In summary, our work makes the following contributions:• We present an approach for the detection of unwanted or
malicious content modification by rogue HTTP proxies,
based on the observation of discrepancies in the retrievalof content through the tested proxies. Our technique uses
decoy websites, dubbed honeysites, that have been designed with a different degree of complexity and external
content dependencies, to allow differentiating between
different types of content injection or alteration.
• We have performed a large-scale measurement study ofopen HTTP proxies retrieved from public “proxy list”
websites, and used our technique to assess the extent
of malicious content modification by rogue proxies. Ourfindings suggest that 5.15% of the tested proxies engaged
in some form of malicious content modification.
• We provide an in-depth analysis of indicative content
modification cases that we observed, which involved theinjection of ads, tracking and fingerprinting code, private
information collection, and malware distribution.
• We have implemented a service that automatically collects
and tests HTTP proxies on a daily basis, for generating
and publishing an up-to-date list of proxies that do not
perform any content modification or injection. The service
is available at http://proxyscan.ics.forth.gr.

To understand and measure the extent of content modification by rogue HTTP proxies, in this work, we have designed
a methodology for detecting and analyzing content alterationand code injection attempts. Specifically, we have built aframework that regularly collects HTTP proxies from several“proxy list” websites, and tests them using a novel techniquebased on decoy websites (dubbed honeysites) under our control. Furthermore, we have implemented a content modification
detection approach that operates at the level of a page’s DOM
tree, which can detect even slight object modifications. To
facilitate the analysis of content modification incidents, wehave implemented a clustering technique for grouping together
cases of content modification that follow similar patterns.
Instead of visiting real websites with and without a proxyand comparing the difference in the retrieved content, the useof honeysites allows us to avoid any false positive issues due tohighly dynamic content (e.g., news updates, rotating ads, andtime-related information), or content localization (e.g., due tothe proxy’s different location than the client). However, we
decided to also include one real website in our experiments(http://bbc.com), even though we employ honeysites of different complexity and content diversity. This allows us to verify
that the modifications observed in honeysites also occur in real
websites, and to investigate whether any sophisticated proxies
can distinguish real websites from honeysites and alter their
behavior accordingly to avoid being detected.

II.

BACKGROUND AND R ELATED W ORK

A. HTTP Proxies
Web proxies are one of the most widely used types of
network relays mainly due to their ease of use, especially forusers that simply want to bypass filtering restrictions or access
content that is not available in their country. Many web proxywebsites allow users to conveniently type in the URL of thepage they want to visit, which is then rendered directly, usually
within a frame. Legacy HTTP or SOCKS proxies require users
to manually configure their browser to explicitly use the proxyby entering the IP address and port of the proxy into thebrowser’s settings window. Many browser extensions facilitate
this process, offering the convenience of single-click buttons
for toggling a configured proxy on and off.

In this study, we monitored 15 public “proxy list” websites
for a period of two months, and systematically collected all theproxies they offered. This process resulted in 65,871 unique
HTTP proxies. By sending multiple probes to each proxy wefound that 16,427 never appeared to be alive, and that, interestingly, only 19,473 succeeded in fetching at least one of therequested testing websites. Our results suggest that 5.15% of
the tested proxies perform some form of modification that can
be clearly considered as malicious. The observed modifications
included the injection of extra (or the modification of existing)

Both types of web proxies are widely used, as it is evident
from the numerous websites dedicated to providing up-to-datelists of working web proxies around the world. Besides the
URL or the pair of IP address and port of each proxy, these lists
typically provide information about the geographic location of
the proxy (important for users who want to access content
2preserving network traffic integrity in general. Reis et al. [26]proposed “web tripwires,” a method that allows publishers toinclude a verification check in their page that compares the
DOM a user received with the DOM the publisher sent. Arshad
et al. [4] developed OriginTracer, a tool that notifies the user
about which party is responsible for any modifications in aloaded page’s content by tracking DOM element alterations(e.g., due to browser extensions). The same authors havedeveloped Excision [5], an in-browser mechanism that relies
on an enhanced version of the DOM tree to keep track of therelationships between the resources of a page in order to block
malicious third-party content.

available only in certain countries), its supported protocols,
the last time the proxy was checked for responsiveness, andeven statistics about its uptime and access latency.
It is common for a proxy list website to provide information
about hundreds or even thousands of recently checked proxies.
Considering that there are numerous independent proxy list
websites, we estimate the number of publicly accessible web
proxies to be in the order of tens of thousands. This conservative estimation is based on the number of proxies listed in justthe top ten proxy list websites returned by a Google searchfor “HTTP proxy list,” and is indeed, in line with the numbers
reported in our study.

Although individual websites can detect to a certain extent
modifications to their client-rendered content using the above
approaches, these mechanisms are not widely adopted. In contrast, our efforts focus on the detection of content modificationby scanning publicly accessible HTTP proxies to uncovervarious forms of traffic modification.

B. Detecting Content Alteration and Fraudulent Ad Traffic
A large body of prior work has focused on security issues
related to the ad serving ecosystem. Li et al. [29] shed lightto fraudulent activities in online ad exchanges. In the frontof click fraud, Dave et al. [9] proposed a methodology formeasuring the extent of click-spam, and proactively detecting
different simultaneous click-spam attacks. To counter click
fraud, Hamed Haddadi [14] proposed the concept of “Blufads,” which are ads meant to be detected and clicked only byautomated crawlers or click-fraud workers.

C. HTTP Proxy Studies
As discussed in the above, recent research has shown that
ad injection and hijacking has been impacting tens of millions
of users worldwide through malicious browser extensions andmalware infections [2], [30]. Therefore, it is natural to expect
miscreants to employ similar monetization strategies throughthe deployment of rogue network relays. Sporadic evidence so
far has shown that traffic interception by rogue network relays
is indeed happening [1], [3], [6], [16], [24], [35], [36].

Malvertising is also an important threat that has received
attention, mostly focusing on methods to detect and block malicious ads. Li et al. [19] performed a large-scale study of malicious ads, and built MadTracer, a defense that automaticallygenerates detection rules and uses them to block malicious ads.
Ford et al. [12] studied the particular class of malware delivery
that leverages malicious Flash advertisements to infect website visitors, and developed an automate Flash content analysis
technique for the detection of malicious behavior.

O’Neill et al. [23] developed a probing tool, which was
deployed through Google AdWords campaigns, and measured
the prevalence of TLS proxies. They found that one in 250 TLS
connections are TLS-proxied, and identified over 3,600 casesof malware intercepting a TLS communication. Holz et al. [17]developed the Crossbear system to discover TLS man-in-themiddle attacks by tracking IP routes and comparing certificateswith distributed nodes they have deployed across the Internet.
Carnavalet et al. [10] uncovered security vulnerabilities in TLS
proxies used by antivirus and parental control applications,allowing attackers to mount man-in-the-middle attacks. Weaver
et al. [34] leveraged the ICSI Netalyzr client base to measure
the prevalence of HTTP proxies, and found that 14% of thetested clients made use of a web proxy. Also, they detected
and classified several kinds of proxies, and observed cases ofcontent modification due to client-side security software (e.g.,
antivirus and firewall products) or server-side compression
and transcoding. Chung et al. [8] used a paid proxy service
whereby users can route their traffic via other users to uncovercontent manipulation in end-to-end connections.

Once malware has infected a user system, it often uses ad
injection to monetize the victim’s web browsing activity. In alarge-scale study of ad injection on infected machines, Thomas
et al. [30] followed a similar approach to ours, by inspecting apage’s DOM tree, to identify the injection of malicious content.
The actual identification was based on a whitelist of legitimate
content, similar in spirit to content secure policy (CSP) usedby modern browsers for whitelisting JavaScript code. Thisapproach has the limitation that if the injected code involves
domains that are included in the whitelist (e.g., when replacing
existing ads with malicious ads from the same ad network),then the injection will go unnoticed. Our content modification
detection approach does not rely on a whitelist, and thus canidentify any addition or alteration of an element in the DOM
tree, even if it involves the same ad network. Their results
indicated that 5% of unique IP addresses accessing Google
were infected with malware that injected ads. Operation Ghost
Click, one of the largest cybercriminal takedown efforts inhistory, took down an ad fraud infrastructure that affected 4
million users infected by the DNS changer malware, and madeits owners 14 million USD over a period of four years [2].

In contrast to the above studies, our research focuses on
publicly available HTTP proxies that users knowingly employ(for various reasons, such as to access otherwise blocked
content, seek protection when using untrusted networks, andpreserve their anonymity), and which are available via numerous “free proxy list” websites. Furthermore, our methodology
is different since we focus on detecting modifications in the
DOM tree of the web page served to the user. Besides some
limited evidence that open HTTP proxies are indeed involvedin suspicious activity [15], [16], our effort is the first to performa large-scale, systematic analysis of the extent and nature ofcontent modification performed by open HTTP proxies.

Many efforts have focused on designing solutions to detectand prevent content modification. Vratonjic et al. [32] anticipated the problem of in-line ad replacement or modification
through man-in-the-middle attacks, and proposed a collaborative technique to preserve the integrity of ads—our findings
highlight the need for such schemes, and the necessity of
3

III.

Lastly, in order to draw comparisons between public proxies and subscription-based ones, we purchased a one-monthsubscription in one such proxy list website, and collected every
five days all the proxies it offered. Our efforts, both automatedand manual, resulted in 65,871 unique proxies.

M ETHODOLOGY

In order to understand the behavior of open HTTP proxies
and measure the extent of content modification in the relayeduser traffic, we have designed a methodology for systematicallycollecting web proxies from several proxy list websites andtesting them using two honeysites under our control. We havealso implemented a content modification detection techniquethat compares the DOM tree of the web page fetched by aproxy to its static template. Furthermore, in order to facilitate
analysis and assessment of the behavior of content modifying
proxies, we have implemented a two-level clustering techniquethat groups together similar content modification incidents.

B. Probing and Testing the Proxies
As mentioned, our crawling module visits a set of proxylist websites and updates the set of proxies to be tested by ourframework on a daily basis. As the number of proxies in ourdataset increases every day, and as we intend to test them ona daily basis for three different websites, we need a scalable
architecture that can support multiple parallel tests.

As malicious behavior, in this work, we consider content
modifications and injections that (i) enable the proxy provider
to have monetary gain (ii) affect user privacy and (iii) can leadto browser/system compromise. More specifically, we consider
as malicious the injection of ads, the injection of JavaScript
code for cryptocurrency mining, the replacement of existing
ads, and cases where the rogue proxy replaces the website’s
ad network identifier with its own affiliate identifier for stealing
the website’s revenue. Furthermore, we consider as malicious
any attempt by a proxy to collect sensitive user informationand information regarding the user’s system (i.e., OS, browser)that can be used for user profiling and tracking, to set and readcookies, harvest credentials etc. In addition to the above, we
consider SSL-stripping, redirection to fake/phishing websites
and the delivery of malware and exploits. It should be noted
though that we do not consider as malicious the removal ofads by “privacy preserving” proxies, as this modification does
not negatively impact the user but aims to protect user privacy.

Through some preliminary experimentation we found thatmany proxies tend to be slow, mainly due to the high load they
have, and that sometimes they appear as non-responsive eventhough they are alive. Although this behavior is expected to acertain degree, as it can be explained by their public nature, it isimportant for our system to succeed in testing them. Thus, we
decided to attempt multiple times throughout a day to test eachproxy, and to set a rather high timeout interval (180 seconds).
However, the multiple attempts to test a proxy, in combination with the high timeout interval, impose a significant
overhead on the system, which becomes critical as the numberof proxies increases. A first step towards avoiding unnecessary latency overheads, is to identify which proxies are nonresponsive for a long time (i.e., not alive) and avoid attempting
to test them at that time. To accomplish that, we have designed
a module that sends a few TCP probes to each proxy in ourdataset on a regular basis, in order to identify which of them
are alive and responding to incoming connections.

A. Collecting a Set of Proxies

Our framework has been designed to send such probes toall the proxies in our dataset almost every hour, 22 times perday. However, for simplicity we decided to suspend probing
and testing during the crawling phase, and to resume it after
the dataset is updated. If a proxy is found to be alive by at least
one probe, it is included in the set of proxies to be tested thatday. In this way, we avoid testing proxies that continuously do
not respond to our probes, but attempt multiple times to test
proxies that appear to be alive, but possibly are temporarily
unavailable. This approach does not implicate that eventually
all these proxies will be found to work properly, but it allows
us to identify long-term non responsive proxies and focus ourefforts on the ones that appeared to be alive recently.

To gather a representative set of proxies, we first collected
a set of reliable proxy list websites, and then collected theproxies listed on each website. We began with a Google search
query for “HTTP proxy list” (in April 2017), and collected thefirst 50 results returned. We followed this approach, as a typicaluser will most likely use a search engine to find websites
offering proxies. Among these 50 websites, there were somethat offer their lists only with a paid subscription, which we leftout. Also, we identified a few cases of almost identical proxylist websites, which are actually managed by the same entity.
For each such case, we decided to only use the one websitethat offered the most proxies, as the great majority of the otherwebsites’ proxies were also included in the considered one.
After the above, we ended up with 15 different popular proxylist websites that included a representative set of the public
proxies available to users at the time of our experiment.

For testing a proxy, our system uses Selenium to configureand launch an instance of the Firefox browser, and requests
the three testing websites in parallel, by opening three different
tabs. If the testing websites are fetched and rendered correctly,
the framework saves the downloaded web pages for content
modification detection, as it is discussed in the following. If
a timeout occurs and the requested websites have not been
fetched, the proxy is added to a queue in order to be tested
again later. In that way we focus our attempts on re-testingproxies that did not succeed in fetching the test websites.

We managed to automatically crawl 10 of the above sites,
while we manually collected the proxies from the other five.
The crawler was visiting all the pages of each one of thesewebsites on a daily basis, for a period of two months (midApril – mid June, 2017), collecting all available proxies andupdating our dataset with any previously unseen ones. The
other five proxy list websites employed various techniques(e.g., user registration and CAPTCHAs) to prevent automatic
crawling, and thus we manually exported all the proxies they
provided in each of our visit. We performed the manual collection once every 10 days, for the duration of our experiment.

In order to achieve scalability and manage testing a large
number of proxies, our framework divides the set of proxies tobe tested into multiple distinct subsets and assigns a subset to adifferent machine. Each machine is responsible to send probes4Only once, initially

Every time a proxydownloads website A
Proxy
Downloads

Trusted
Downloads

DOM
COMPARISON

website A(1st instance)
STATIC DOM
MARKER
website A(2nd instance)

Proxy 1DOM A

STATIC TEMPLATE
for website A
Static DOM tree

New Element
OR
Modification

Proxy 2DOM A

Proxy N
DOM A

No Injection

Fig. 1. The methodology followed for detecting content modifications in websites fetched by a proxy. Initially, our framework downloads the target website(or honeysite) multiple times without a proxy, and compares the DOM tree of these downloads, to create a static template of the web page (left). For detecting
content modification, it fetches the website through a proxy and compares its DOM tree with the previously generated static template (right).

to the proxies in its subset, for generating its list of proxies
to be tested, and starts testing them by launching in parallelup to 60 instances of Firefox. As mentioned previously, eachbrowser instance corresponds to a specific proxy, and requests
for retrieving the three testing websites are sent in parallel.

prone to false positives. For this reason, we decided not torely on visiting real web pages, but to primarily focus on
an alternative approach that relies on decoy websites under
our control. Specifically, we deploy two honeysites of different
levels of complexity and dependence on (controllable) thirdparty content (e.g., ads).

For the purposes of this study, our experimental setup wascomprised of two commodity machines. This setup could test
up to almost 58 thousand proxies per day, and additional
machines could be easily included if needed, as the framework
was designed to scale. Since the number of alive proxies in asingle day never surpassed 22 thousands in our experiment, as
it will be discussed (see Figure 3), we were able to test them
multiple times per day, without needing additional resources.

The reason for using two honeysites of different complexity
and content, is that we do not only want to detect content
modification events, but also to examine whether the behaviorof the tested proxies changes according to the type of content
relayed through them (e.g., detect whether a proxy modifies
only JavaScript files). The main difference between our honeysites lies in the degree of dynamic content generated by
the server, and on the third party resources they use. The firsthoneysite (h1 ) consists of a simple, completely static web page.
The second one (h2 ) is a website created in WordPress,4 whichcontains some JavaScript elements and resources, an iframethat loads some external content, and three fake ads.

C. Use of Honeysites
Conceptually, a simple approach for detecting content
modification by rogue network relays is to visit a given public
web page twice, once connecting directly and once through therelay, and comparing the fetched content. In practice, however,this approach is not very effective for two main reasons. First,
parts of the page may change due to inherently dynamic content, such as news updates, time-related information, rotating
ads, and various forms of content personalization. Second, thegeographic distance between the client and the proxy may
also result in differences due to content localization, as many
websites switch to pages of different language (and possibly
region-specific content) based on the visitor’s origin. On theother hand, selecting only simple static pages for probing, may
miss rogue proxies that focus only on specific types of content
that can be monetized, i.e., ads that already exist in the page.

The fake ads included in h2 were created based on actual
source code provided by three popular ad networks: Google
AdSense,5 Media.net6 and BuySellAds.7 We did not actuallyregister for displaying ads from these networks, but just usedthe example ad inclusion code snippets they provide and set the
publisher’s ID to an invalid, non-existent value. This ensuresthat the included ads will not be rendered, as the requests forfetching them will typically fail. What is important, however,is that these fake ads look (from the perspective of theproxy) identical and indistinguishable from legitimate ones.
Having a honeysite with embedded ads (h2 ) allows us todifferentiate between proxies that perform unconditional con-

The complexity of having to distinguish between legitimate
content modification due to the inherent dynamic behavior ofa fetched web page, and any kind of content modification
performed by the web proxy itself, makes this simple approach

4 https://wordpress.com
5 https://www.google.com/adsense
6 http://www.media.net
7 https://www.buysellads.com

5

so that it is generated only in a predictable way. It is notedthat our approach takes into consideration the position ofeach dynamic element during the generation of the template,
and thus, during the comparison between the proxy fetched
web page with its template, our system expects to identify
specific dynamic elements at particular positions in the page’s
DOM tree. Furthermore, by specifically including dynamic
content that is generated in a predictable way, we are able toidentify any non-anticipated changes in this content. That is,
by carefully choosing dynamic content that is fetched froma particular source, we expect to observe dynamic content
from that source.The only case of modifications that can gounnoticed by our system is when a malicious proxy alters
a dynamic element in the expected way (e.g., replacing an
existing ad with a different ad, from the exact ad network).

tent modification, from proxies that inject content dependingon the presence of ad networks in the fetched web page(e.g., replacing the existing legitimate publisher’s ID with theattacker’s registered ID, injecting additional ads, or completely
replacing the honeysite’s fake ads).
For testing a given proxy, we automatically browse to
the honeysites through the proxy and compare the retrieved
content with the original content that was served by our web
server. A benefit of this approach is that, by having control
of both ends (i.e., client and server), we can precisely identify
whether any part of the page was modified, or whether new
additional content was injected. However, we cannot preclude
the possibility of malicious proxies that do not inject or modify
content on every web page they fetch, but somehow determine
which downloads to alter, in order to avoid being detected.

E. Clustering Content Modification Incidents

To prevent any potentially sophisticated malicious proxies
from suspecting the true purpose of our honeysites, and thus
avoid exhibiting any inappropriate behavior, as an initial measure we decided to use Amazon’s S3 cloud service for hosting
the honeysites, instead of using any other infrastructure (e.g.,servers hosted in our academic institution’s network). Towards
that direction, we also decided to visit a popular real web page,alongside with the honeysites we test regularly, in order todetect and further investigate the behavior of any such proxies.

After some initial experimentation using the methodology
described previously, we observed a very large number of proxies that modify the content of the honeysites they fetch, either
by injecting new elements or by modifying existing ones. In
particular, our methodology revealed DOM tree modificationsin thousands of cases from both honeysites. To facilitate theanalysis of all the content modification incidents detected, we
designed a two-level content modification clustering approach
for identifying injections that follow similar patterns andgrouping them together.

D. Detecting Content Modification
Detecting content modification by a proxy for the static
honeysite h1 is straightforward, given that its “ground truth”
content never changes. The dynamic content of h2 however,makes the detection of content modifications more challenging,as we have to distinguish between changes due to the dynamic
content itself and changes due to potential content injection
or modification by the tested proxy. To achieve that, we
initially download the dynamic honeysite multiple times froma trusted computer (without using a proxy) and compare its
content in order to generate a static template. Specifically, ourapproach constructs and traverses the DOM tree of the trusted
downloads, and compares the DOM elements to identify whichelements remain the same between different downloads. By
comparing the DOM elements and their values, we are able
to identify and mark the static and dynamic elements of
the honeysite, and therefore to create a static version of thehoneysite that can be used as a template.

At first, we traverse the DOM tree of each download and
we identify the position and type of all the injected elements.
Our initial clustering approach categorizes these downloads
according to the difference between the expected DOM element (at a specific position of the DOM tree according to
the template), and the occurring element. As an example, all
the cases where an iframe element is expected at a particular
position of the template’s DOM tree, but a script element
occurs at that particular position in the DOM tree of thedownloaded honeysite, end up in the same cluster.
After that, for implementing a more fine-grained clustering
we compare the DOM tree of every instance in each group (i.e.,
first-level cluster) with all the other modification instances inthat particular group. If the DOM tree of two such instances isexactly the same, which means that the same elements appear
in the same order and have the exact same content, we addthem in the same second-level cluster. It should be noted thatduring this process we do not take into account the dynamic
elements of the DOM tree, which legitimately change in thetrusted downloads, but as discussed previously, we use of formof whitelisting to detect changes in this elements. Our two-levelclustering approach minimizes the effort needed for manually
analyzing the observed content modification incidents, as weonly need to manually inspect a few downloads from eachcluster to understand that particular proxy behavior.

After creating the static template of each honeysite, we use
an approach similar to the process followed for generating thetemplates themselves, in order to compare the DOM tree ofthe websites fetched by proxy to the corresponding template.
An overview of our methodology is presented in Figure 1.
This approach can effectively identify content modification inmost cases, as the malicious proxies typically inject new rogue
elements or try to modify existing ones. Our system is able todetect changes in the DOM tree when new rogue elements areinserted, and when the value of the elements that are marked
as static in the template changes. A limitation, however, of
this approach is that it cannot detect changes in the value ofdynamic elements, as these values legitimately change between
different downloads.

The manual effort can be further reduced by comparing
a sequence of DOM tree elements between the different
clusters. By keeping track of the DOM tree elements and theirposition (and their order) in the template of the honeysite,and comparing them with the sequences of elements in every
other cluster, it becomes easy to identify proxies that do notinject any new rogue elements, but instead, modify the testing
websites by removing content (e.g., remove existing ads).

We can overcome this limitation by carefully selecting thetypes of dynamic content to be included in our honeysite,
6

TABLE I.

P ROXIES COLLECTED AND TESTED IN OUR EXPERIMENT

Total

Tested Proxies
Alive
Working

65,87149,444

19,473

Number of Proxies(x1000)25

Content Modifying Proxies
Total
Malicious
7,441(38.21%)

1,004(5.15%)

All Listed Proxies

Working Proxies

20
15
10
5
0
10

Malicious Proxies(%)

Additionally to the manual inspection of representative
content modification cases from each cluster, we employed asimple form of dynamic analysis to gain better understandingof the functionalities performed by the injected code. To that
end, we configured the Firefox browser with the Firebug
plugin, and rendered a few downloads from each cluster, while
monitoring all the outgoing requests and fetched resources. By
executing the injected code in a controlled environment andinspecting all the HTTP requests, we were able to detect andanalyze additional JavaScript files that are fetched dynamically,
and to understand the functionalities of obfuscated code.

6
4
2
0
A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 M1 M2 M3 M4 M5 S1
Proxy List Websites

Fig. 2. Total number of proxies collected from each proxy list website
during the two-month period of the study, through automated daily crawling(A1 –A10 ) and manual collection (M1 –M5 ), as well as the proxies collectedfrom a subscription-based website (S1 ). Additionally, information regarding
the number of proxies that successfully fetched the requested websites, andpercentage of proxies found to perform malicious content modification.

Our analysis revealed cases of malicious proxies that set
tracking pixels and cookies, inject ads, and perform browser
fingerprinting, among others. Also, we were able to determine
the nature of the ads shown to the user, and whether these ads
are inappropriate or intrusive (e.g., scareware). In that way,
we ensure that all the proxies we characterized as malicious,
indeed performed content injection or modification that cansignificantly affect, or even worse, threaten the user. A detailed
analysis of our findings is presented in Section V.
IV.

8after responding to some of our probes. However, this is not
surprising, as we decided to collect all the proxies that appear
in the crawled proxy list websites, and not only those having
good statistics such as high responsiveness.
By following the previously described methodology for
detecting content modification, we observed that 7,441 proxies(38.21% of the properly working ones) altered the content of
the retrieved web page in some way. As the HTML DOM treeof the fetched pages may be modified by a proxy for various
legitimate reasons, the observation of a modification event does
not necessarily mean that the tested proxy is malicious, orthat its actions can negatively impact a user. The main type ofcontent alteration we observed was due to “privacy-protecting”
proxies that block trackers and ads that exist in the retrieved
page. We also observed proxies that inject elements or iframesthat are empty, or modified the DOM of the page in such a
way that cannot be classified as malicious. After employing
our clustering method and manually inspecting all the clusters
we identified in total 1,004 (5.15%) proxies that performedsome form of malicious or unwanted modifications. A detailed
analysis of the malicious proxies is presented in Section V.

A NALYSIS OF P ROXY C HARACTERISTICS

As mentioned, we collected a set of proxies by crawling 10
popular proxy list websites on a daily basis, in an automatedway, and by systematically visiting five more proxy list websites, and a subscription-based one, and manually exporting all
the proxies they offered. This process resulted in the collectionof 65,871 unique HTTP proxies in total.
According to our methodology, once the crawling phase iscompleted, our system starts sending a few TCP probes every
hour to each proxy in the updated dataset, for determining
which of them are alive and accept incoming connections. We
do follow this probing technique in order to identify (temporarily) non responding proxies and thus avoid attempting totest them. When a previously non-responding proxy responds
to our probes, it is immediately included in the set of proxies
to be tested on that day. While the number of proxies thatappeared to be alive each day of the experiment was not high,we identified that in total 49,444 proxies responded to some ofour probes during the period of our experiment (see Table I).

A. All Proxies Collected and Tested
The total number of proxies we collected from each proxylist website, as well as the number of the properly working
ones is presented in Figure 2. During the collection process wenoticed that most of the sites ask for a money fee to generate
proxy lists in a more usable format, and on occasion claim toprovide even more proxies to paying users. Also, it became
apparent that some websites offer far less proxies than theyclaim to have, and less surprisingly, some of these proxies arelisted in multiple websites. Indicatively, the collection process
resulted to 144,349 proxies in total, from all the websites,
which correspond to only 65,871 unique proxies in our set.

Interestingly, from the 49,444 proxies that appeared atsome point to be alive, after responding to some of the probes,
only 19,473 (38.38%) succeeded in fetching the requested
testing websites when tested (we refer to them as “properly
working” proxies). As discussed in the following, many of theproxies we characterize as “non-working” provided information that indicate their type of failure. We observed that most ofthese proxies failed to fetch the testing websites due to network
and DNS errors. On the contrary, a large fraction of the nonworking proxies never fetched any of the requested websites
or provided any information about their type of failure, or ingeneral, any information indicating that they are still alive,

1) Public proxy list websites: As presented in Figure 2,
the websites that impose some restrictions with regards to
7

TABLE II.
C OMPARISON BETWEEN PROXIES COLLECTED FROMPUBLIC PROXY LIST WEBSITES AND A SUBSCRIPTION - BASED WEBSITE70
All Proxies Tested

Total

Working

Malicious

60

1.
2.

Free Publicly Available
Only Subscription Based

58,435
3,278

14,973 (25.62%)
990 (30.20%)

872 (5.82%)
61 (6.16%)

50

3.

Appeared in Both Categories

4,158

3,510 (84.41%)

71 (2.02%)

Number of Proxies(x1000)Category of Proxy Lists

automatic crawling, from which we collected proxies manually(i.e., M1 –M5 ), have a higher fraction of properly working
proxies, compared to the automatically crawled websites (i.e.,
A1 –A10 ). Our tests suggest that 53% to 63% of the proxies inthese websites succeeded in fetching the requested web pages,
and that around 2% to 4% of the proxies in these websites are
malicious. On the other hand, for the automatically crawled
proxy list websites, we observe lower percentages of working
proxies, in general, and proxy list websites such as A3 , A5
and A9 (i.e., https://hidemy.name, https://www.us-proxy.org andhttp://www.idcloak.com) that have very few malicious proxies(i.e., less than 1%), while others reach 6% and 7%.

Accepting Connections
Properly Working

40
30
20
10
0
0

10

20

30

40

50

60

Days of the ExperimentFig. 3. Total number of proxies in our set, once the daily collection process
is completed, and number of proxies found to be alive and properly working
on each day of the experiment.

20
All Proxies Crawled

Two notable cases of proxy list websites that interestingly
present contrary behavior are A1 and A9 . The former listed andprovided more proxies than any other visited website (23,262),
but had the lowest percentage of working proxies (26.4%),
and the highest percentage of malicious ones (7.08%). On theother hand, A9 offered only 2,354 proxy during the two month
period of our experiment (i.e., second lowest) but impressively,
88.9% of them were found to be working properly, and lessthan 1% were found to be malicious. These observations leadto the assumption that the former website focuses on having
a large volume of proxies, possibly by collecting and listingproxies that appear in other websites, while the latter makes
more efforts to only provide highly reliable proxies.

Unique Proxies
Newly Found Proxies

Number of Proxies(x1000)

16

12

8

4

0
0

2) Subscription-based proxy service: For being able todraw comparisons between free public web proxies and proxies
acquired from a paid service, and for detecting if they exhibit
significantly different behaviors, we bought a one-month subscription from a proxy list website that claims to own over
50 thousand proxies. As we gained access to the site’s proxylists for a month, we visited it six times in total, every fivedays, and collected all the proxies offered (S1 in Figure 2).
We discovered that, in reality, this website provided only about
two thousand proxies each time it was visited, and claimed that
only these proxies were available at the time of visit. In total,
we collected only 7,436 proxies from the subscription-based
website, and interestingly, only 3,278 of them were not alreadyincluded in our set.

10

20

30

40

50

60

Days of the ExperimentFig. 4. Number of proxies our crawler automatically collected from the 10
proxy list websites each day of the experiment (i.e., A1 –A10 in Figure 2).

the malicious proxies detected in the free and subscriptionbased websites, we did not identify any significant differencesin the modifications they perform, and in general, in the behavior they exhibit. Specifically, for the proxies collected fromthe subscription-based website, we identified modifications inaccordance to all the different high-level classes of malicious
behavior that are presented in Section V.
3) Daily statistics of proxies: In order to understand the
dynamics of the proxy collection process, and how our probing
mechanism affects the scalability and performance of thesystem, in Figure 3 we present the total number of proxies
in our dataset after the daily collection process is completed
and the set of proxies is updated. In this figure, we can spot
the contribution of the manual collection process, as a small
increase (i.e., a noticeable step) is observed for the sixth,
eleventh day etc. In addition, Figure 3 presents the number ofproxies that had been found to accept incoming connections(i.e., alive), each single day of the experiment, as well as
the number of the properly working proxies(i.e., retrieved therequested websites). An interesting observation is that, while

In Table II we present statistics for (1) the proxies collectedfrom public proxy list websites (2) the proxies offered only by
the subscription-based website and (3) the proxies appearedin lists of both the public websites and the subscription-based
one. As shown in Table II, the percentages of properly working
proxies in (1) and (2) are very similar, 25.62% and 30.20%
respectively. After testing and assessing the proxies in ourdataset, we identified that these two categories have a similar
percentage of malicious proxies, i.e., 5.82% and 6.16%. However, interestingly, we identified that the proxies found in bothgroups have a significantly higher working rate (84.41%) andthe smallest malicious rate (2.02%). Furthermore, regarding
8

1
0.8
Probes found a Proxy Alive (%)

All Proxies
(CDF)

1
0.8
0.6
0.4
Working Proxies
Non-working Proxies

0.20Working Proxies
(CDF)

1
0.8
0.6
0.4
Malicious Proxies

0.2

Alive Proxies
Working Proxies

0.6
0.4
0.2
0
1
Malicious Proxies

0.8

Legitimate Proxies

0.6
0.4
0.2

Legitimate Proxies

0

0
0

40

80

120

160

200

0

0.2

Number of Occurrences in Proxy List Websites

0.4

0.6

0.8

1

Cumulative Distribution of Proxies (CDF)

Fig. 5. Cumulative fraction of proxies in regards to the number of times
each proxy occurs in the crawled proxy list websites.

Fig. 6.

Cumulative fraction of proxies found to be alive by our probes.
10
Accepting Connections

the number of daily alive proxies increases, in general, it
increases in a much lower rate than the collected proxies, andwhile at the beginning of the experiment about half of theproxies were alive, only one third is alive in a given day after
two months. In addition, as depicted in this figure, the numberof working proxies per day is around four thousands, for thewhole duration of the experiment.

Properly Working

Number of Proxies(x1000)8

In Figure 4 we present the number of newly found proxies
per day, for the duration of our experiment. We collected close
to 10 thousand proxies each day from the sites we crawled
automatically (i.e., A1 - A10 ) and only about 4% to 6% ofthem were new to our set. It is noted that the two sharp drops
shown in Figure 4 are due to one proxy list website that was
inaccessible for these two days. Interestingly, this drop did notaffect the number of new proxies found, which indicates thatthe particular site does not update its list very often.

6

4

2

0
0

10

20

30

40

50

60

Days of the ExperimentFig. 7. Number of proxies found to be alive and working each day of theexperiment, from the initial set of proxies collected on the first day.

4) Occurrences in proxy list websites: Figure 5 presents
the cumulative fraction of proxies in regards to the number oftimes each proxy occurs in the crawled proxy list websites (A1- A10 ). This provides interesting insights about the persistenceof proxies in these websites, and how the proxies appear acrossmultiple different websites. Interestingly, we observe that thegreat majority on non-working proxies appear only very few
times in the proxy list websites. Specifically, we observe thataround 64% of the non working proxies appeared only once(in just a single website), and that 88% of them appeared only
up to five times. This suggests, that many proxy list websites
regularly update their lists by removing proxies that are nonworking. However, it is observed that about 10% of the nonworking proxies appear multiple times, which span up to thewhole duration of our experiment. On the other hand, only
20% of the working proxies appear only once, and about halfof them (53%) up to five times. Interestingly, we observe thatthe malicious and benign proxies follow similar distributions to
the working and non-working ones, respectively. Even though
the number of occurrences depends on the first time a proxy
was added to a list, this figure shows significant differences
regarding the persistence of proxies in the crawled websites.

every day, almost in every hour, in order to identify which
proxies are listening for incoming connections. As we sendprobes to all the proxies almost every hour, for the durationof the experiment, these probes can be used for estimating thefraction of time each proxy was alive. In Figure 6 we present
the CDF of proxies that were found to be alive by our probes.
As can be seen in Figure 6 (top), 15.66% of all the alive in ourdataset responded to very few of our probes (less than 0.1%),
around 50% of them were found to be alive less than 22% of
the times they were probed, and only around 10% responded
to more than 72% of the probes sent.
When focusing our analysis only on the properly working
proxies, we observe that the legitimate proxies respond to asignificantly large number of our probes, and that in generalthese proxies are alive for longer times. Specifically, weobserve that 50% of the legitimate proxies respond to morethat 64% of our probes, and that around 40% of them respondto more than 90% of the probes sent. Interestingly, the proxies
we identified as malicious appear to be alive significantly
fewer times. We observed that 50% of the malicious proxies
responded to less than 9% of our probes, and that only 20% ofthem were found to be alive by more than 37% of our probes.

5) Lifespan and reliability: As discussed in Section III-B,
our framework sends TCP probes to each proxy 22 times
9Not Blacklisted

1-2 Blacklists

TABLE IV.

3+ Blacklists

1

Percentage of Proxies

0.8

1
2
3
4
5
6
7
8
9
10

0.6

0.4

0.2

Non Working

Legitimate

Malicious

Fig. 8. Percentage of proxies that are included in DNS-based blackhole lists.
TABLE III.

1
2
3
4
5

E RROR MESSAGES COLLECTED FROM THE NON - WORKINGPROXIESType of Failure

Number of Proxies

Network Errors
Not Permitting Use
Misclassification
Partial downloads

15,133
1,087
89
27

Total

16,336Autonomous
SystemProxies

Country

OwnerAS4837
AS4134
AS13335
AS8048
AS17974
AS50896
AS200557
AS15169
AS15003
AS14061

6,834
4,887
2,578
2,372
1,830
1,399
1,399
1,272
1,076
1,043

CHN
CHN
USA
VEN
IDN
RUS
RUS
USA
USA
USA

China Unicom
China Telecom
CloudFlare
Cantv
PT Telkom Indonesia
MediaServicePlus LLC
Petersburg Internet Network
Google Cloud
SpeedVM Network Group
Digital Ocean

TABLE V.
AUTONOMOUS S YSTEMS IN WHICH MOST OF THE
MALICIOUS PROXIES ARE LOCATED ( TOP 5 AUTONOMOUS S YSTEMS ).

0

All Proxies

AUTONOMOUS S YSTEMS IN WHICH MOST HTTP PROXIESARE LOCATED ( TOP 10 AUTONOMOUS S YSTEMS ).

Autonomous
SystemMalicious
Proxies

Country

OwnerAS4837
AS17974
AS4134
AS56041
AS131269

433
234
61
16
14

CHN
IDN
CHN
CHN
IND

China Unicom
PT Telekomunikasi Indonesia
China Telecom
China Mobile Communications
Beam Telecom

also observe that 32.66% of the non properly working proxies
are not being included in any blacklist, which is significantly
higher than the percentages observed for the legitimate andmalicious proxies (i.e., working proxies in our dataset).
B. Non-Working Proxies

Furthermore, in order to examine the longterm lifespanof proxies, in Figure 7 we present the number of alive andproperly working proxies for each day of the experiment, byconsidering only the initial 12,078 proxies we discovered on
the first day of the experiment. We observe that the percentage
of alive proxies starts at 70.25%, then drops to 52.06% after
a month, and at the end of the experiment reaches 44.93%.
Also, it is clear that while 46.40% of the alive proxies were
properly working on the first day, after one and two months
only 21.40% and 23.08% of were found to be still working.

As mentioned earlier, only 38.38% of the alive proxies,
that responded to our probes, succeeded in fetching at least
one of the requested websites. In order to understand the main
reasons behind this high percentage of non-working proxies,
we examined the responses of Selenium and Firefox. In manycases there was no response or just a blank page. The absenceof a response can possibly means that the particular proxies
were not alive at that time, or that they were under heavy load.
These reasons seem very possible, after considering the low,in general, reliability of open web proxies.

6) Inclusion in blacklists: It is commonly believed that
open proxies are not only used for legitimate purposes such asaccessing blocked content and protecting a user’s privacy, butalso for other nefarious or questionable activities. Alonso etal. [7] examined the use of a proxy they set up, and observed
many cases where their proxy was used for fraud. A questionthat arises is whether the public use of proxies results in their
IP address to be blacklisted, and if this affects their availability.

However 16,336 of the non-working proxies generated
error messages related to their cause of failure. We wereable examine these messages, since many of them were very
similar across different proxies, and group them into genericcategories, which are presented in Table III. We discoveredthat most of the proxies (92.63%) were not working due to
network errors they encountered while trying to send/forward
our request. Among many different network errors, the mostcommon ones in this category were DNS-related errors. In
most cases, proxies had trouble getting an answer from the
DNS server regarding the website we were looking for.

To that end, we examined whether the proxies in our dataset
are included in any online blacklists that contain IP addresses
observed to engage in malicious activities. To accomplish that,
we leveraged dnsbllookup.com, a service that checks if an
IP address exists in 66 DNS-based blackhole lists (DNSBL).
These lists contain IP addresses associated with compromised
or otherwise malicious systems that perform illicit activities,
mainly related to spam distribution. As can be seen in Figure 8,
most of the proxies in our dataset are included in at least
one blacklist, with only 28.46% of them not being found inany of these lists. When focusing our analysis on the working
proxies, we observe that 18.1% of the legitimate proxies, and17.59% of the malicious, are not included in any blacklist. We

The second category (6.65%) consisted of responses indicating that we were not allowed to use these proxies, suchas “Authentication Required” and “Access Denied.” Typically,
the proxies in this category authenticate their users by their
IP address, and typically such proxy services are not for free.
The “misclassification” category is related to cases where thespecific IP-port pair listed in the proxy list websites does
not actually correspond to an HTTP proxy, but to a different
service (e.g Tor exit nodes). Finally, we have a category
10

160

Number of Injected External Domains

Cumulative Fraction of Proxies
(CDF)

1

0.8

0.6

0.4

0.2

Legitimate Proxies
Malicious Proxies
0
16

32

64

140
120
100
80
60
40
20
0

128

0

0.2

Size of Downloaded Website in KB

0.4

0.6

0.8

1

Percentage of Malicious Proxies

Fig. 9. Cumulative fraction of the downloaded content size when fetching
the dynamic honeysite h2 .

Fig. 10. Number of different domains contacted by the code injected bymalicious proxies.

called “Partial downloads” for proxies that started fetching
the requested website, but did not succeed in downloading it,probably due to network errors.

Figure 9 shows the distribution of the downloaded content
size when retrieving our most complex honeysite h2 , which
has dynamic content due to the inclusion of trackers and fakead networks. The expected download size for honeysite h2
ranges around 21KB. It can be seen that both legitimate andmalicious proxies have downloads falling within the expected
size of the page, while also both retrieve fewer content, mostly
due to proxies that block tracking and advertising content.
Approximately half of the malicious proxies have downloads
with bigger size than expected while about 20% of them double
or more the size of the page.

C. Differences between Benign and Malicious Proxies
1) Location: To get further insights about the proxies wecollected in this study, we used the geolocation service offered by ip-api.com, which provides information regarding thecountry an IP address is registered, the ISP and Autonomous
System (AS) it belongs to, and so on. In Table IV we present
the most common Autonomous Systems, in which many ofthe proxies we collected belong to. From the 65,871 proxies
we crawled in total, we found 60,708 unique IP addresses. We
identified that 11.25% of the proxies belong to a single AS
in China. Furthermore, as can be seen in Table IV, most of
the proxies in our dataset belong to Autonomous Systems in
China, USA and Russia.

V.

M ALICIOUS P ROXIESIn this section we focus our analysis on the malicious proxies we have detected and thoroughly discuss about the typesof content modification and injection these proxies perform
on users’ relayed traffic. We categorize content modification
incidents according to well-defined malicious behaviors andwe discuss the semantic nature of each injection, for shedding
more light to the mechanics of a malicious proxy’s operation.
The following analysis was not a trivial task as we had
to overcome many practical challenges, such as non-existing
links, obfuscated JavaScript code, etc.

As our main focus is on malicious proxies, we try toinvestigate if there is any correlation between the behavior ofproxies and their location. As can be seen in Table V, Chinese
Autonomous Systems dominate our list, specifically containing
50.79% of the malicious proxies we detected. Interestingly,
another big batch of malicious proxies (23.3%) belongs to an
Indonesian Autonomous System.

A. Resources Fetched from Third Parties

2) Fetched content size variation: A basic way malicious
proxies differ from legitimate ones is in relation to the sizeof the downloaded HTML file. Since new code is typicallyinjected, one would expect the size of the downloaded content
to always be larger than the original. As mentioned, however,proxies that only block certain kinds of content, such as trackers and ads, which cannot be considered as malicious, may
actually result in size reduction. Another type of proxies that
we observed are proxies that block trackers and ad networks
only to replace them with their own. Therefore, a downloaded
HTML file belonging to these types of proxies does not haveto differ much in size of that of the original page. This effectwould be more evident for rich web pages that already containtrackers and ads, similar to our own honeysite h2 (in order forthe proxy to be able to remove some content, and thus reduce
the size of the retrieved page)

In order to track the culprits of the identified injections andgain a better understanding of the behavior of injected content,
we executed the JavaScript code that was injected by malicious
proxies in the websites they fetched, in an automated way,
and monitored the resources fetched from third-party domains.
We ran this experiment locally, in a controlled environment,
and kept track of all the contacted IP addresses and external
domains. In order to accomplish that, we used our own trusted
proxy for logging and forwarding all the traffic generated byinjected/modified content.
In addition, we used a whitelist containing all the domains
we expected to be contacted by our honeysites, thus identifying
which requests were sent due to malicious injected code andwhich ones due to the legitimate dynamic functionality. Twolimitation we encountered during this analysis are: (1) some11

TABLE VI.

N UMBER OF MALICIOUS PROXIES THAT INJECT CODE FORSENDING INFORMATION AND FETCHING RESOURCES FROM SPECIFIC
THIRD PARTY DOMAINS .

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

DomainProxies

tongji.baidu.com
cfs.uzone.id
a01.uadexchange.com
up.filmkaynagi.com
a.akamaihd.net
urlvalidation.com
i.qkntjs.info
adnotbad.com
ratexchange.net
i.tonginjs.info
www.onclickcool.com
agm.abounddinged.com
yellow-elite.men
qnp.demisedcolonnaded.com
intext.nav-links.com
www.tr553.com
ruu.outputsteddy.com
s.lm15d.com
rtax.criteo.com
www.donation-tools.org

556
140
124
113
109
107
106
106
105
105
104
104
103
102
102
101
101
74
72
69

B. Generic Categorization of Rogue Behavior
Advertisements. Malicious proxies often inject ads in the websites they fetch. We visually inspected a random subset of themalicious proxies’ downloads for determining what type of ads
they inject. Several ads are displayed in a language compatible
with the proxy’s geographical location, while sometimes ads
can be displayed in a language compatible with the client’s
location. Certain ads exercise a legitimate behavior, without
tricking the user into clicking them. However, some of themcompletely cover the target website, while others are much
more aggressive, e.g., embedding videos from YouTube. For
example, Fyne.in covers the whole page and displays video
messages, while several others display fake rewards and alerts
instructing the users to fix their infected computer.
A fraction of the ads embed adult content and services formeeting people at the client’s geographical area. We randomly
clicked some of the injected ads and found that some of themredirect to malware distributing sites that have been alreadyblocked by Google safe browsing.
Tracking. As described in Section III, we recorded all therequests to third parties with Firefox and Firebug. We observedthat these parties typically set third party cookies to the users’
browser. In some cases, these cookies share the same ID,
which indicates that third parties are cooperating to track theuser through cookie syncing [13]. Also, malicious proxies were
found to inject JavaScript from Mixpanel [21], which are used
to track the actions of the user in the visited websites.

of the domains/resources were no longer available and (2) ourwhitelist had the domains of the fake ad networks we used,which means that requests from proxy-injected content to these
domains would be ignored.

Fingerprinting. Malicious proxies often attempt to maintaintabs open on the user’s browser for launching fingerprinting
attacks. We identified certain injected content that make requests to third parties such as advedia360.com, which emits
JavaScript in the HTML code of the page that uses fingerprintjs2 [31]. Fingerprintjs2 is a well known library for
identifying web browsers with a high accuracy. In a similar
fashion, proxies that perform canvas fingerprinting [22] werealso detected, like 104.238.146.90:80. This specific proxyredirects the user to a website that sells skin products, andclaims that the requested website could not be found.

By following this approach, we were able to collect information regarding all the domains to which the injectedcode sends requests, as well as the IP addresses that correspond to these domains. In Table VI we present a list that
contains the Top-20 most contacted domains, as a result ofmalicious injected code. In total we observed requests towards
more than 362 different domains. Additionally, we identified
that 181 domains were contacted by five or more malicious
proxies. We identified 98 domains that were contacted only
by a single proxy each, while for the most popular domain(tongji.baidu.com), requests were sent by content that was
injected from 556 different malicious proxies.

Privacy leakage. Malicious proxies inject scripts, which once
rendered, trigger requests to third-parties for exfiltrating sensitive user information. This information may include static
fields like geolocation data, or may be the outcome of afingerprinting methodology. For example, we found many
instances of an injection that emits requests to particular third
parties affiliated with the ad market, specifically to BlueKaiand Eyeota.com, which are a data management platform anda data supplier.

Figure 10 presents the number of unique domains that were
contacted by each malicious proxy, without considering thedomains originally included in our honeysites (i.e., whitelisted
domains). As can be seen in Figure 10, 12.94% of themalicious proxies do not fetch any third-party resource. In
reality, most of the aforementioned proxies try to fetch external
resources but the third parties hosting these resources are nolonger reachable. Also, we observed a few cases of proxies
that do not attempt to fetch any resource, but try to load themfrom the browsers local storage. Furthermore, we observedthat 4.08% of the malicious proxies fetch only one external
resource, and that 57.17% fetch resources from more than
two domains, while 8.56% of the proxies contact more than
20 different domains. Interestingly, the top 12 proxies issue
requests to more than 100 different domains. We discuss about
the purpose of these injected domains in detail in Section V-D.
It is observed that many different proxies contact the same
third-party domains in order to fetch particular libraries that
implement specific malicious or questionable functionalities(e.g., user fingerprinting).

We also uncovered injection libraries that target sensitive
user information that exists in certain pages the user possibly
visits, as well as JavaScript that harvests e-mails and phone
numbers. In rare cases, we identified scripts that search for
specific DOM elements of popular web pages (like QZone,a Chinese social network) for extracting personal information,such as the user’s blood type. Another example is given by theproxy 186.237.46.32:8080 which embeds a search form frombooking.com and google.com in the fetched website, and thentracks whatever information the user used them for. Therefore,
we can undoubtedly infer that malicious proxies, and theirinjections, are seriously affecting users’ privacy.
12

200

user agent, system language, platform, plugins, dimensionsof the screen, device pixel ratio, color depth and others. We
also include cases where the proxies use well known tools
like fingerprintjs. We discovered 392 proxies guilty ofthis behavior. We also identified JavaScript code for tracking
keyboard and mouse movements, and for setting and readingcookies, by 157 and 152 malicious proxies respectively. Moreover, we identified 118 proxies that make requests to sitesthat are blocked by Google’s safe browsing, potentially for
installing malware on the user’s machine.

100

C. Content-dependent Injections

Number of Proxies

500

400

Injecting advertisementsCollecting user information
Tracking mouse/keyboard
Tracking with cookies
Requesting unsafe sites

300

After following the methodology described in Section III
for detecting malicious proxies and documenting their behavior, we wanted to investigate if their behavior changes
according to the content of the website they fetch. By comparing the domains each proxy repeatedly (i.e., more thanonce) requests for each honeysite, we found that 37 proxies
request 63 domains in total for (h2 ) but not for (h1 ). Thisbehavior confirms our hypothesis that some proxies change
their behavior depending on the content they encounter. Morespecifically, we detected 10 proxies that injected a domain
inside the iframe of the AdSense ad for (h2 ) and the realsite (but not in the static honeysite h1 ). It seems that thisinjection tries to insert an ad at the specific place where the
AdSense ad should have normally been. Also, from the 362
domains injected in total in our honeysites, we found 48 thatwere not being injected in the real website we used for testing
the proxies. This behavior indicates that some proxies tend tochange their injection according to the content they fetch.

0
Malicious Behaviors

Fig. 11.

High-level categorization of observed malicious behaviors.

Malware. Several injected libraries contain JavaScript codethat triggers requests towards sites that are blacklisted andblocked by Google safe browsing. Upon inspection we foundthat malicious proxies often attempt to land malware on theuser’s host or redirect the browser to a drive-by download
page [25].
Unclassified behavior. We had some difficulties in understanding certain injections, in a small fraction of cases. This ismainly due to obfuscated/minified JavaScript code, and also
because some third party domains were no longer valid during
the analysis phase. This is not unexpected, as very often
the operators of servers that host malicious content change
domains to avoid being detected and blocked. In certain cases,
we identified proxies that inject a script or an iframe
element with no target (i.e., src is empty). This may be due toa templating framework used, which mistakenly or on purpose
adds this element, while a higher-level script chooses when to
include a payload or not. Also, in some other cases insteadof fetching data, the injected scripts tried to use resourcesfrom the browser’s local storage. Proxies that exhibit such
behaviors are marked as suspicious, but are not considered as
malicious. Any new information about these cases may result
in considering them malicious in the future.

In order to investigate in more detail the behavior of
malicious proxies in regards to the already existing ads, weused a script to automatically detect whether they attempt tomodify the advertising IDs of any of the fake ads we had in our
dynamic honeysite (h2 ). We detected two such proxies, whichtargeted our advertisement from Media.net, and successfullychanged our fake publisher’s ID with theirs. This modifications
performed 9 and 11 times respectively. The first proxy evenused two different publisher’s IDS, on different occasions.
Interestingly these proxies did not inject anything else on theparticular testing website, or the other two testing websites.
However, surprisingly, they did not always perform the ID
replacement in (h2 ). The first one injected the Media.net iframe
for nine days in a row and then, the next two days fetched thepage without any modifications. The second malicious proxy
was fetching an unmodified version of the testing website for18 days, without performing any content modification, andthen suddenly started modifying the ID of the existing ad. This
modification happened for 11 days in a row, and then, for theremaining period of our experiment, it was acting entirely as abenign proxy, not performing any modifications. To that end,
we investigated if any other proxies in our dataset act in asimilar way, and we detected that 41 (4.08%) of the malicious
proxies do not always perform injections or modifications, but
only exhibit such a malicious behavior sporadically.

We summarize all the different types of injections performed by malicious proxies in Figure 11. We have grouped
injections according to the high-level semantic goal of themalicious proxy. If the injections of a proxy belong to multiple
high-level categories, this proxy is counted in all the respective
categories in Figure 11. Also, it is noted, that suspicious
proxies are not counted at all, unless they simultaneously
perform attacks the belong to the aforementioned categories.
As shown in Figure 11, we have discovered 472 malicious
proxies that inject ads in the page served to the user. Someof these ads are fetched from legitimate ad networks, whileothers serve more devious purposes (e.g., redirect to unsafe
sites). We consider that a proxy is tracking user’s information
if it attempts to extract information regarding the device, theOS or the browser of the user, as well as user’s personal
information (e.g., name, e-mail, address). Such behavior canbe detected by looking for injected JavaScript code that extract
information about the language and timezone of the user, theD. Cases of Interesting Injections
As already discussed in the previous, in the majority ofcases, malicious proxies inject JavaScript code that interacts13easy, since we use the same set of honeysites hosted on asingle server, making them easily identifiable. A first stepfor mitigating this issue is to significantly expand our set ofhoneysites, and randomly expose only a few of them to eachproxy. Eventually, a more generic strategy is needed against
sophisticated proxies who may choose to target only a subsetof pages, e.g., only those containing ads from a certain ad
network, high-profile and popular websites, and websites ofcertain interests. Consequently, a broad, diverse, and constantly
evolving set of pages should be used as targets, to achieve therequired stealthiness and coverage.

with third-parties. It is interesting to explore the distribution
and popularity of the domains used by these third-parties. A listof the most commonly contacted domains is given in Table VI.
The most contacted third-party domain is owned bya popular Chinese search engine, namely Baidu. This istongji.baidu.com, which is a traffic analysis service similar
to Google analytics. In this case, a div element is injectedin the DOM tree of the fetched website and tries to load
tongji.baidu.com/logstat.swf. The allowscriptaccess tag
is set to always, meaning that the .sfw files are granted
access to the HTML DOM regardless of where they are hosted.
Almost half of the malicious proxies we detected were found to
be in contact with that domain. Furthermore, cfs.uzone.id anda01.uadexchange.com belong to the same cluster of injections.
In that case a script element is injected at the end of thewebsite’s DOM tree, for fetching and showing ads.

Although we used the proposed methodology as part of alarge-scale measurement effort, the core content modification
logic in conjunction with honeysites, can also be used asa standalone tool, for on-demand testing of any proxy thatusers are about to trust their traffic with. To that end, we
have implemented a web service that follows our methodology
for regularly crawling proxy list websites, detecting content
modification incidents, and generating on a daily basis alist of proxies that have not been found to perform any
modification or injection. As some rogue proxies may only
perform modifications selectively and sporadically, we keep
this list relatively short, for being able to re-test each proxymultiple times every day.

Many of the domains presented in Table VI are reached
due to a particular piece of JavaScript code that is injected in
the fetched website. We tracked this code and found it used in
injections by 141 different malicious proxies. Some of themused different variations of the code, resulting in a few different
domains to be requested, but the core remained the same. ThisJavaScript code, which can be used as a toolkit, allows theattacker to set and read cookies, to get information that canbe used for fingerprinting the user (i.e., device, browser), to
deploy ads, and to send AJAX requests among others.

VII.

Moreover, an interesting injection loads code from ratexchange.net, which behave differently depending on the site theuser visits. For example, if the user visits ok.ru (i.e., a russiansocial network) it injects ads from cdnpps.us with the attackers’
publisher ID. Alternatively, if it detects that the user is using
the Yahoo search engine it hijacks the URL and redirects tosugabit.net, which is a site that looks like a search engine, but
in reality, is a browser hijacker.

In this work, we carried out a large-scale analysis of open
HTTP proxies, focusing on the detection of rogue proxies
that engage in malicious or unwanted content modification.
We developed a DOM comparison technique for detecting
HTML alterations from third parties, and during a period of
two months, we made multiple requests to 65,871 proxies,
requesting honeysites under our control. Our findings suggestthat 38.21% of the working proxies modify the page they fetch
in some way, while 5.15% of the proxies we tested performedsome form of malicious content modification. We presented
a detailed analysis of the characteristics of legitimate andmalicious proxies, and identified and analyzed various forms ofmalicious injections. Our results indicate the important privacy
implications of trusting user traffic to unknown open proxies,
operated under questionable motives. Among the observed
behaviors, we encountered many privacy compromising incidents, with many proxies collecting and sharing private user
information with third parties, let alone making requests topages that deliver malware.

Another interesting cluster of malicious proxies fetches
JavaScript code from d.chaoliangyun.com. It strips all of theuser’s HTTPS connections and tries to extract information
about the user, as well as possible information the page may
contain like phone numbers or e-mails, by using specifically
crafted regexes. Additionally, it monitors all the sites the user
visits and searches for site specific information that could
reveal very sensitive user information.
VI.

C ONCLUSIOND ISCUSSION AND L IMITATIONSThis work is an initial attempt to assess the extent ofmalicious content modification by rogue HTTP proxies. While
it is possible that some popular proxies are not included in our
proxy set, we consider this as highly unlikely. We believe thatusers look for proxies in the same way we do – via Google
search of proxy lists. Thus, in order for a proxy to be popular,
it must be included in proxy lists that are highly ranked in
Google search results.

ACKNOWLEDGMENTS
We would like to thank our shepherd, Jelena Mirkovic,
and the anonymous reviewers for their valuable comments.
This work was supported by the H2020 project SHARCS,
under Grant Agreement No 644571, by the H2020 project
UNICORN, under Grant Agreement No 731846, and by the
H2020 project SMESEC, under Grant Agreement No 740787.
In addition, this project has received funding from the European Union’s Horizon 2020 research and innovation programme under the Marie Sklodowska-Curie Grant Agreement
No 690972. The paper reflects only the authors’ view and the
Agency is not responsible for any use that may be made of
the information it contains.

We opted for a simple but effective scheme that relies on
decoy websites under our control to detect content modification
without false positives. This approach, however, is not robust
against determined rogue proxy operators who may anticipate our attempts, and refrain for performing any suspicious
activity. Currently, detecting our testing efforts is relatively
14

R EFERENCES
[1]

[2]

[3]

[4]

[5]

[6]

[7]
[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]
[16]
[17]

[18]

[19]

“How hackers abused Tor to rob blockchain, steal bitcoin,target private email and get away with it,” February2015,
http://www.forbes.com/sites/thomasbrewster/2015/02/24/
blockchain-and-darknet-hacks-lead-to-epic-bitcoin-losses/.
S. A. Alrwais, A. Gerber, C. W. Dunn, O. Spatscheck, M. Gupta,
and E. Osterweil, “Dissecting ghost clicks: Ad fraud via misdirected
human clicks,” in Proceedings of the 28th Annual Computer Security
Applications Conference (ACSAC), 2012.
J. Appelbaum, M. Ray, K. Koscher, and I. Finder, “vpwns: Virtual
pwned networks,” in 2nd USENIX Workshop on Free and Open Communications on the Internet. USENIX Association, 2012.
S. Arshad, A. Kharraz, and W. Robertson, “Identifying extension-based
ad injection via fine-grained web content provenance,” in Research in
Attacks, Intrusions, and Defenses - 19th International Symposium, RAID
2016, Paris, France, September 19-21, 2016, Proceedings, 2016, pp.
415–436.
——, “Include me out: In-browser detection of malicious third-party
content inclusions,” in Proceedings of the 20th International Conference
on Financial Cryptography and Data Security (FC), 2016.
S. Chakravarty, G. Portokalidis, M. Polychronakis, and A. D. Keromytis,“Detecting traffic snooping in Tor using decoys,” in Proceedings ofthe 14th International Symposium on Recent Advances in Intrusion
Detection (RAID), September 2011, pp. 222–241.
A. Chema and M. Fernandez “The Sur“, “Owning bad guys {& mafia}
with javascript botnets.” DEFCON 20, 2012.
T. Chung, D. Choffnes, and A. Mislove, “Tunneling for transparency:
A large-scale analysis of end-to-end violations in the internet,” inProceedings of the 2016 ACM SIGCOMM Conference on Internet
Measurement Conference, ser. IMC ’16. ACM, 2016.
V. Dave, S. Guha, and Y. Zhang, “Measuring and fingerprinting
click-spam in ad networks,” SIGCOMM Comput. Commun. Rev.,
vol. 42, no. 4, pp. 175–186, Aug. 2012. [Online]. Available:
http://doi.acm.org/10.1145/2377677.2377715
X. d. C. de Carnavalet and M. Mannan, “Killed by proxy: Analyzing
client-end tls interception software,” in 23nd Annual Network andDistributed System Security Symposium, NDSS 2016, San Diego, California, USA, February 21-24, 2016.
K. Finley, “Wired - half the web is now encrypted. thatmakes everyone safer,” 2017, https://www.wired.com/2017/01/
half-web-now-encrypted-makes-everyone-safer.
S. Ford, M. Cova, C. Kruegel, and G. Vigna, “Analyzing anddetecting malicious flash advertisements,” in Proceedings of the 2009
Annual Computer Security Applications Conference, ser. ACSAC ’09.
Washington, DC, USA: IEEE Computer Society, 2009, pp. 363–372.
[Online]. Available: http://dx.doi.org/10.1109/ACSAC.2009.41
A. Ghosh and A. Roth, “Selling privacy at auction,” in Proceedings ofthe 12th ACM Conference on Electronic Commerce, ser. EC ’11, 2011,
pp. 199–208.
H. Haddadi, “Fighting online click-fraud using bluff ads,” SIGCOMM
Comput. Commun. Rev., vol. 40, no. 2, pp. 21–25, Apr. 2010. [Online].
Available: http://doi.acm.org/10.1145/1764873.1764877
C. Haschek, “Let’s analyze over twenty thousand proxies.” 2015, https://blog.haschek.at/2015-lets-analyze-twenty-thousand-proxies.
——, “Why are free proxies free?” 2015, https://blog.haschek.at/post/
fd9bc.
R. Holz, T. Riedmaier, N. Kammenhuber, and G. Carle, “X.509
forensics: Detecting and localising the SSL/TLS men-in-the-middle,”in Computer Security - ESORICS 2012 - 17th European Symposium
on Research in Computer Security, Pisa, Italy, September 10-12, 2012.
Proceedings, 2012, pp. 217–234. [Online]. Available: http://dx.doi.org/
10.1007/978-3-642-33167-1 13
V. T. Lam, S. Antonatos, P. Akritidis, and K. G. Anagnostakis, “Puppetnets: Misusing web browsers as a distributed attack infrastructure,”in Proceedings of the 13th ACM Conference on Computer and Communications Security (CCS), 2006, pp. 221–234.
Z. Li, K. Zhang, Y. Xie, F. Yu, and X. Wang,“Knowing your enemy: Understanding and detecting malicious
web advertising,” in Proceedings of the 2012 ACM Conference

[20]
[21]
[22]

[23]

[24]
[25]

[26]

[27]

[28]
[29]

[30]

[31]
[32]

[33]
[34]

[35]

[36]

15

on Computer and Communications Security, ser. CCS ’12. New
York, NY, USA: ACM, 2012, pp. 674–686. [Online]. Available:
http://doi.acm.org/10.1145/2382196.2382267
M. Marlinspike, “sslstrip,” http://www.thoughtcrime.org/software/
sslstrip/.
https://mixpanel.com/, mixpanel.
K. Mowery and H. Shacham, “Pixel perfect: Fingerprinting canvas in
HTML5,” in Proceedings of W2SP 2012, M. Fredrikson, Ed. IEEE
Computer Society, 2012.
M. O’Neill, S. Ruoti, K. E. Seamons, and D. Zappala, “TLS proxies:
Friend or foe?” CoRR, vol. abs/1407.7146, 2014. [Online]. Available:
http://arxiv.org/abs/1407.7146
J. Pitts, “The case of the modified binaries,” 2014, http://www.
leviathansecurity.com/blog/the-case-of-the-modified-binaries/.
N. Provos, P. Mavrommatis, M. A. Rajab, and F. Monrose, “All youriframes point to us,” in Proceedings of the 17th Conference on Security
Symposium, ser. SS’08. Berkeley, CA, USA: USENIX Association,
2008, pp. 1–15. [Online]. Available: http://dl.acm.org/citation.cfm?id=
1496711.1496712
C. Reis, S. D. Gribble, T. Kohno, and N. C. Weaver, “Detecting in-flight
page changes with web tripwires,” in Proceedings of the 5th USENIX
Symposium on Networked Systems Design and Implementation, ser.
NSDI’08. Berkeley, CA, USA: USENIX Association, 2008, pp. 31–44.
[Online]. Available: http://dl.acm.org/citation.cfm?id=1387589.1387592
L. Sassaman, “The faithless endpoint: How Tor puts certain users atgreater risk,” Katholieke Universiteit Leuven, Tech. Rep. ESAT-COSIC
2007-003, 2007.
B. Schneier, “The further democratization of QUANTUM,” April 2015,
https://www.schneier.com/blog/archives/2015/04/the further dem.html.
B. Stone-Gross, R. Stevens, A. Zarras, R. Kemmerer, C. Kruegel,and G. Vigna, “Understanding fraudulent activities in online ad
exchanges,” in Proceedings of the 2011 ACM SIGCOMM Conferenceon Internet Measurement Conference, ser. IMC ’11. New York,NY, USA: ACM, 2011, pp. 279–294. [Online]. Available: http://doi.acm.org/10.1145/2068816.2068843
K. Thomas, E. Bursztein, C. Grier, G. Ho, N. Jagpal, A. Kapravelos,
D. Mccoy, A. Nappa, V. Paxson, P. Pearce, N. Provos, and
M. A. Rajab, “Ad injection at scale: Assessing deceptive advertisement
modifications,” in Proceedings of the 2015 IEEE Symposium on Security
and Privacy, ser. SP ’15. Washington, DC, USA: IEEE Computer
Society, 2015, pp. 151–167. [Online]. Available: http://dx.doi.org/10.
1109/SP.2015.17
https://github.com/Valve/fingerprintjs2, Valentin Vasilyev.
N. Vratonjic, J. Freudiger, and J.-P. Hubaux, “Integrity of the web
content: The case of online advertising,” in Proceedings of the 2010
International Conference on Collaborative Methods for Security andPrivacy, ser. CollSec’10. Berkeley, CA, USA: USENIX Association,
2010, pp. 2–2. [Online]. Available: http://dl.acm.org/citation.cfm?id=
1929808.1929811
N. Weaver, “In contempt of bulk surveillance: It’s too easy,” September
2015, https://lawfareblog.com/contempt-bulk-surveillance-its-too-easy.
N. Weaver, C. Kreibich, M. Dam, and V. Paxson, “Here be
web proxies,” in Proceedings of the 15th International Conference on
Passive and Active Measurement - Volume 8362, ser. PAM 2014. New
York, NY, USA: Springer-Verlag New York, Inc., 2014, pp. 183–192.
[Online]. Available: http://dx.doi.org/10.1007/978-3-319-04918-2 18
P. Winter, R. Köwer, M. Mulazzani, M. Huber, S. Schrittwieser,
S. Lindskog, and E. Weippl, “Spoiled Onions: Exposing Malicious Tor
Exit Relays,” in Proceedings of the Privacy Enhancing Technologies
Symposium (PETS), 2014.
E. J. Zaborowski, “Malicious proxies.” DEF CON 17, 2009.