Master of Web Puppets: Abusing Web Browsers
for Persistent and Stealthy Computation
Panagiotis Papadopoulos,∗ Panagiotis Ilia,∗ Michalis Polychronakis,† Evangelos P. Markatos,∗
Sotiris Ioannidis,∗ Giorgos Vasiliadis∗∗ FORTH, Greece, {panpap, pilia, markatos, sotiris, gvasil}@ics.forth.gr† Stony Brook University, USA, mikepo@cs.stonybrook.edu

Abstract—The proliferation of web applications has essentiallytransformed modern browsers into small but powerful operating
systems. Upon visiting a website, user devices run implicitly
trusted script code, the execution of which is confined within
the browser to prevent any interference with the user’s system.
Recent JavaScript APIs, however, provide advanced capabilities
that not only enable feature-rich web applications, but also allow
attackers to perform malicious operations despite the confined
nature of JavaScript code execution.
In this paper, we demonstrate the powerful capabilities
that modern browser APIs provide to attackers by presenting
MarioNet: a framework that allows a remote malicious entity tocontrol a visitor’s browser and abuse its resources for unwanted
computation or harmful operations, such as cryptocurrency
mining, password-cracking, and DDoS. MarioNet relies solely on
already available HTML5 APIs, without requiring the installationof any additional software. In contrast to previous browserbased botnets, the persistence and stealthiness characteristics ofMarioNet allow the malicious computations to continue in the
background of the browser even after the user closes the window
or tab of the initially visited malicious website. We present thedesign, implementation, and evaluation of our prototype system,
which is compatible with all major browsers, and discuss potential
defense strategies to counter the threat of such persistent inbrowser attacks. Our main goal is to raise awareness about thisnew class of attacks, and inform the design of future browser
APIs so that they provide a more secure client-side environment
for web applications.

I.

I NTRODUCTION

Our increasing reliance on the web has resulted in sophisticated browsing software that essentially behaves as an integrated
operating system for web applications. Indeed, contemporarybrowsers provide an abundance of APIs and sensors (e.g.,gyroscope, location, battery status) that can be easily usedby web applications through locally-running JavaScript code.
The constantly expanding JavaScript interfaces available inmodern browsers enable users to receive timely updates, renderinteractive maps and 3D graphics, or even directly connect toother browsers for peer-to-peer audio or video communication(e.g., through WebRTC).
In the era of edge computing, the capabilities offered by theavailable APIs have pushed a significant part of web application
Network and Distributed Systems Security (NDSS) Symposium 201924-27 February 2019, San Diego, CA, USA
ISBN 1-891562-55-X
https://dx.doi.org/10.14722/ndss.2019.23070
www.ndss-symposium.org

logic to the endpoints. Web publishers transfer parts of thecritical computations on the user side, thus minimizing latency,
providing satisfactory user experience and usability, while atthe same time increasing the scalability of the service. Despite
all these advancements, the web largely works in the very same
way since its initial inception: whenever a user visits a website,
the browser requests from the remote web server (and typicallyfrom other third-party servers) all the necessary components(e.g., HTML, CCS, JavaScript and image files), executes any
script code received, and renders the website locally. That is,whenever a user visits a website, the browser blindly executes
any received JavaScript code on the user’s machine.
From a security perspective, a fundamental problem of web
applications is that by default their publisher is considered astrusted, and thus allowed to run JavaScript code (even fromthird parties) on the user side without any restrictions (as longas it is allowed by the website’s content security policy, ifany). More importantly, users remain oblivious about the actual
operations performed by this code. This problem has became
evident lately with the widespread surreptitious deploymentof cryptocurrency mining scripts in thousands of websites,
exploiting the visitors’ browsers without their consent [18],[66]. Although there are some blacklist-based extensions andtools that can protect users to some extent, such as Google’s
safe browsing, these do not offer complete protection.
On the other hand, disabling entirely the execution of
JavaScript code often breaks intended legitimate functionality
and affects the overall user experience. In general, the highly
dynamic nature of JavaScript, the lack of mechanisms for
informing users about the implemented functionality, and theinstant execution of script code, which does not leave roomfor extensive security checks before invocation, are facilitatorsfor malicious or unwanted in-browser code execution.
On the positive side, unwanted JavaScript execution so far
has been constrained chronologically to the lifetime of thebrowser window or tab that rendered the compromised or malicious website. Consequently, cryptocurrency mining or othermalicious JavaScript code can affect users only temporarily,
typically for just a few minutes [53], depending on the time auser spends on a given website. Unfortunately, however, somerecently introduced web technologies—already supported by
the most popular browsers—can severely exacerbate the threatof unwanted JavaScript computation in terms of stealthiness,
persistence, and scale, and the support of such capabilities has
already started raising concerns of the community [29].
In this paper, we present MarioNet: a system that enables

a remote attacker to control users’ browsers and hijack device
resources. Upon visiting a website that employs MarioNet, theuser’s browser joins a centrally orchestrated swarm that exploits
user machines for unwanted computation, and launching awide variety of distributed network attacks. By leveraging
the technologies offered by HTML5, MarioNet goes beyond
existing approaches and demonstrates how malicious publishers
can launch persistent and stealthy attacks. This is possible byallowing malicious actors to continue having control of thevictim’s browser even after the user browses away from amalicious or infected website, and by bypassing most of theexisting in-browser detection mechanisms.

We also discuss the capabilities of web browser extensions,especially with regards to these HTML5 features, and finally,for each feature, we analyze its security aspects, access policies,
permissions, and threat vectors that may open.
A. HTML5 features
1) Web Workers: Browsers typically have one thread thatis shared for both the execution of JavaScript and for page
rendering processing. As a result, page updates are blocked
while the JavaScript interpreter executes code, and vice versa.
In such cases browsers typically ask the user whether to kill
the unresponsive page or wait until the execution of such longrunning scripts is over. HTML5 solves this limitation with the
Web Workers API [46], which enables web applications tospawn background workers for executing processing-intensive
code in separate threads from the browser window’s UI thread.

MarioNet consists of two main parts: (a) an in-browser
component, and (b) a remote command and control system.
Although MarioNet enables the attacker to perform attacks
similar to those carried out by typical botnets [32], there aresome fundamental differences. First and foremost, MarioNet
does not exploit any implementation flaw on the victim’s
system and does not require the installation of any software.
In contrast, MarioNet, leverages the provided capabilities of
JavaScript and relies on some already available HTML5 APIs.
Consequently, MarioNet is compatible with the vast majorityof both desktop and mobile browsers. In contrast to previous
approaches for browser hijacking (e.g., Puppetnets [4]), a key
feature of MarioNet is that it remains operational even after
the user browses away from the malicious webpage.

Since web workers run as separate threads, isolated from thepage’s window, they do not have access to the Dynamic Object
Model (DOM) of the webpage, global variables, and the parent
object variables and functions. More specifically, neither the
web worker can access its parent object, nor the parent object
can access the web worker. Instead, web workers communicate
with each other and with their parent object via message passing.
Web workers continue to listen for messages until the parent
object terminates them, or until the user navigates away fromthe main webpage. Furthermore, there are two types of web
workers: dedicated and shared workers. Dedicated web workers
are alive as long as the parent webpage is alive, while shared
web workers can communicate with multiple webpages, andthey cease to exist only when all the connections to thesewebpages are closed.

In particular, our system fulfills three important objectives:(i) isolation from the visited website, allowing fine-grained
control of the utilized resources; (ii) persistence, by continuing
its operation uninterruptedly on the background even after
closing the parent tab; and (iii) evasiveness, avoiding detection
by browser extensions that try to monitor the webpage’s activity
or outgoing communication. Besides malicious computationsome of the attacks the infected browsers can perform include
DDoS, darknet creation, and malicious file hosting and sharing.

Typically, web workers are suitable for tasks that requirecomputationally intensive processing in an asynchronous andparallel fashion, such as parsing large volumes of data andperforming computations on arrays, processing images andvideo, data compression, encryption etc. Indeed, during therecent outbreak of web-based cryptocurrency mining, we haveobserved that typically these scripts utilize web workers formining, and that they deploy multiple such workers to utilize
all available CPU cores of the user’s system.

Overall, in this paper, we make the following contributions:
1) Present MarioNet: a novel multi-attack framework to allow
persistent and stealthy bot operation through web browsers.
MarioNet is based on an in-browser execution environmentthat provides isolated execution, totally independent fromany open browsing session (i.e., browser tab). Therefore,
it is able to withstand any tab crashes and shutdowns,
significantly increasing the attacker’s firepower by morethan an order of magnitude.
2) Demonstrate and assess the feasibility of our approach witha proof of concept implementation of MarioNet for themost common web browsers (i.e., Chrome, Firefox, Opera,
and Safari). To measure its effectiveness, we thoroughly
evaluate MarioNet for various attack scenarios.
3) Discuss in detail various defense mechanisms that can beapplied as countermeasures against MarioNet-like attacks.

2) Service Workers: Service workers are non-blocking(i.e., fully asynchronous) modules that reside in the user’s
browser, in between of the webpage and the publisher’s web
server. Unlike web workers, a service worker, once registeredand activated, can live and run in the background, without
requiring the user to continue browsing through the publisher’s
website—service workers run in a separate thread and theirlifecycle is completely independent from the parent page’s
lifecycle. The characteristics of service workers enable theprovision of functionality that cannot be implemented using
web workers, such as push notifications and background syncing
with the publisher. Furthermore, another core feature of service
workers is their ability to intercept and handle network requests,
including programmatically managing the caching of responses.
This allows developers to use service workers as programmablenetwork proxies, thus enriching the offline user experience bycontrolling how network requests from a webpage are handled.

The main goal of this work is to raise awareness about thepowerful capabilities that modern browser APIs provide to
attackers, so that a more secure client-side environment can beprovided for web applications in the future.
II.

BACKGROUND

In this section, we discuss several features that have been
recently introduced as part of HTML5 and influence our design.

A service worker can be registered only over HTTPS via
the serviceWorkerContainer.register() function,2

which takes as argument the URL of the remote JavaScript
file that contains the worker’s script. This URL is passed tothe internal browser’s engine and is fetched from there. For
security purposes, this JavaScript file can be fetched only fromthe first-party domain (i.e., cannot be hosted in a CDN orother third-party servers). Also, no iframe or third-party script
can register its own service worker. Importantly, no browser
extension or any in-browser entity can have access either in thebrowser’s C++ implementation that handles the retrieval andregistration of the service worker or in the first-party domain.

B. Web Extensions
The current design of modern browsers’ extensions allows
two types of JavaScript scripts within a browser extension:(a) content scripts and (b) background scripts. Content scripts
run in the context of the websites visited by the user, thus
they can read and modify the content of these websites using
the standard DOM API, similarly to the websites’ scripts (i.e.,
those JavaScript scripts that were included in the website by
the publisher). Furthermore, content scripts can access directlya small subset of the WebExtension JavaScript APIs.

When the user browses away from a website, the service
worker of that website is typically paused by the browser;
it is then restarted and reactivated once the parent domain
is visited again. However, it is possible for the publisher ofa website to keep its service worker alive by implementing
periodic synchronization. It should be noted though that theregistration of a service worker is entirely non transparent to theuser, as the website does not require the user’s permission toregister and maintain a service worker. Furthermore, similarly to
web workers, service workers cannot access the DOM directly.
Instead, they communicate with their parent webpages by
responding to messages sent via the postMessage interface.

On the other hand, background scripts run as long as thebrowser is open (and the extension is enabled), and typically
implement functionalities independent from the lifetime of any
particular website or browser window, and maintain a longterm state. These background scripts cannot access directly
the content of the websites visited by the user. However,background scripts can access all the WebExtension JavaScript
APIs (or chrome.* APIs for Google Chrome), if the user’s
permission is granted during the installation of the extension.
Indicatively, the large set of WebExtension JavaScript APIs
contains the bookmarks, cookies, history and storage APIs,
which allow access on various types of user data, the tabs
and windows APIs, browserSettings and the webRequest API
among many others. However, even though content scripts
cannot access all WebExtension APIs directly, and background
scripts cannot access the content of the visited website, thiscan be achieved indirectly since the content and background
scripts of an extension can communicate with each other.

3) WebRTC: Popular web-based communication applications (such as Web Skype, Google Meet, Google Hangouts,
Amazon Chime, Facebook Messenger) nowadays are based on
Web Real-Time Communication (WebRTC) API [23], whichenables the establishment of peer-to-peer connections between
browsers. The WebRTC technology enables browsers to perform
real-time audio and video communication and exchange data
between peers, without the need of any intermediary.

In addition to the above mentioned APIs, Google Chrome
also supports some HTML5 and other emerging APIs for its
extensions (e.g., application cache, local storage, geolocation,
canvas, notifications, etc.). However, it is important with regards
to this work to emphasize that none of the browsers allow
extensions to use HTML5 APIs such as the Service Workers
API or the Push API. Consequently, browser extensions cannot
interact with possible deployed service workers in any way(e.g., modify their code, monitor their outgoing traffic, etc.).

As in every peer-to-peer protocol, a challenge of WebRTC
is to locate and establish bidirectional network connections
with remote peers residing behind a NAT. To address this,
WebRTC uses STUN (Session Traversal Utilities for NAT)
and TURN (Traversal Using Relays around NAT) servers
for resolving the network address of the remote peer andreliably establishing a connection. There are several such servers
publicly available [21], maintained either by organizations (e.g.,
Universities) or companies (e.g., Google).

C. Security Analysis

4) Cross-Origin Resource Sharing: Before HTML5, sending
AJAX requests to external domains was impossible due to therestrictions imposed by the same-origin policy, which restricts
scripts running as part of a page in accessing only the DOM
and resources of the same domain. This means that a web
application using AJAX APIs (i.e., XMLHttpRequest andthe Fetch API) can only request resources from the same
domain it was loaded.

Table I summarizes the characteristics of various APIs ofinterest. We categorize them along four axes related to theefficiency of a distributed botnet: (i) the execution model (i.e.,
whether it can run in parallel to the main webpage or in the
background), (ii) if direct network access is possible, (iii) theability to use persistent storage, and (iv) the ability to accessthe DOM of the webpage.
JavaScript code (running either as part of the webpage, orin a web worker or service worker) has access to persistentstorage (e.g., using WebStorage), as well as the ability tocommunicate with other servers or peers (e.g., using XHR
requests, WebSockets, or WebRTC). However, local JavaScript
code embedded in the webpage also has direct access to thepage’s DOM and therefore, the ability to access or manipulate
any element of the webpage, as well as any network requestor response that is sent or received. Page-resident JavaScript
code cannot be detached from the webpage, neither run
without blocking the rendering process. This results to a major
limitation (for the purposes of malicious scripts), as longrunning operations would affect the user experience. Also,

However, the Cross-Origin Resource Sharing (CORS) [43]capabilities introduced in HTML5, allow scripts to make crossorigin AJAX requests to other domains. To enable this feature,
CORS uses extra HTTP headers to permit a user agent to accessselected resources from a server on a different domain (origin)than the parent sits. Additionally, for HTTP request methods
that can cause side-effects on server-side data (in particular,
for HTTP methods other than GET, or for POST usage withcertain MIME types), the specification mandates browsers to“preflight” the request, soliciting supported methods from theserver with an HTTP OPTIONS request method, to determine
whether the actual request is safe to send.
3

TABLE I: Analysis of HTML5 JavaScript execution methods.
FeatureLocal JavaScript code
Web Worker (Shared)
Web Worker (Dedicated)
Service Worker

Concurrent
Execution
3
3
3

Background
Execution

Webpage
Detached

3

Persistent
Storage

DOM
AccessNetwork
Access

3

3
3
3
3

3

3
3
3
3

3

a suspicious code snippet could be detected easily by browser
extensions, since it needs to be embedded in the main website,and extensions’ JavaScript code can access, inspect and ingeneral, interfere with the content of the visited website.

3of shady reputation, and even to trustworthy and reputablewebsites that aim to increase their revenue without actuallyintending to conduct any illegal activities or harm the user.
There are also several cases where a website can end up
hosting such malicious content unintentionally. Those cases
include: (i) the website registers a benign service worker that
includes untrusted dynamic third-party scripts [35], which inturn possibly load malicious code; (ii) the website includes thirdparty libraries,1 one of which can turn rogue or be compromised,
and then divert the user to a new tab (e.g., using popunders [22]or clickjacking [64]) where it can register its own service worker
bound to a third-party domain; (iii) the website is compromised
and attackers plant their malicious JavaScript code directly into
the page, thus registering their malicious service worker—ascenario that we see quite often in recent years [40], [36]; or(iv) the website includes iframes with dynamic content, which
are typically auctioned at real-time [57] and loaded with content
from third parties.

Web workers, on the other hand, can perform resourceintensive operations without affecting the user’s browsing
experience, as they run in separate threads. This allows utilizing
all different available CPU cores of the user’s machine, by
spawning a sufficient number of web workers. Service workers
behave in a similar fashion, but have the important advantage
of being completely detached from the main webpage, runningin the background even after the user has navigated away.
Moreover, service workers can intercept the HTTP requests
sent by the webpage to the back-end web server. Importantly,
since service workers are completely detached from the page’s
window, extensions cannot monitor or interfere with them.
Finally, using the CORS capabilities of HTML5, it is possible to send multiple GET or POST requests to third-party websites. However, the Access-Control-Allow-Origin:*header has to be set by the server, in order for the request to
be able to fetch any content. Besides sending HTTP requests,
WebRTC allows the peer-to-peer transfer of arbitrary data,audio, or video—or any combination thereof. This feature canopen the window for malicious actions such as illegal hostingand delivery of files, and anonymous communication througha network of compromised browsers, as we showcase later on.
III.

Intercept
HTTP Requests

In the latter case, malicious actors can use a variety ofmethods (e.g., redirect scripts [28], [37] or social engineering)to break out of the iframe and open a new tab on the user’s
browser for registering their own service worker. The important
advantage of this latter approach is that the user does not needto re-visit the website for the service worker to be activated.
After registration, just an iframe loaded from the malicious
third party is enough to trigger the malicious service worker,
regardless of the visited first-party website. This relieves theattackers from the burden of maintaining websites with content
attractive enough to lure a large number of visitors. Instead,attackers can activate their bots just by running malvertising
campaigns, purchasing iframes in ad-auctions [67].

T HREAT M ODEL AND O BJECTIVES

The motivation behind this work is to design a system capable of turning users’ browsers into a multi-purpose “marionette”
controlled by a malicious remote entity. Our goal is to leveragesolely existing HTML5 features in order to highlight the lackof adequate security controls in modern browsers that would
have prevented the abuse of these advanced features.

To summarize, our threat model considers that such an
attack can be launched intentionally by a malicious or “shady”
website that includes malicious content, unintentionally, by ahijacked/compromised website or a website that includes acompromised library, and also by third-party dynamic content
loaded in iframes (typically used for real-time ad auctions).

A. Threat Model
We assume a website that delivers malicious content toexecute unwanted or malicious background operations invisitors’ browsers. Once the website is rendered, this malicious
content is loaded in a service worker that is capable ofcontinuing its operation even after the victim browses awayfrom the website.

B. Challenges
The greatest challenge for systems like MarioNet is to keep
the user’s device under control for as long as possible. This is achallenging task given that a connection with the server may bepossible only for the duration of a website visit; recent studies
have estimated the average duration of a typical website visit
to be less than one minute [53]. In addition, there is a plethora

Websites can deliver such malicious or unwanted content
intentionally, to gain profit directly (e.g., by attracting visitors
and thus advertisers), or indirectly, by infecting as many
user browsers as possible to carry out distributed (malicious)
computations or mount large-scale attacks. The websites in thiscategory can range from typically malicious ones, to websites

1 Modern websites often include numerous third-party scripts [55], [14] foranalytics or user tracking purposes, aiming to gain insight, improve performance,or collect user data for targeted advertising.

4Web Browser(1) Webpage fetch (HTTPS)Blocking
Extensions

Web server(2) Webpage
renderingStandard Web Site

Service Worker(3) Communication channel(WebSocket)

PuppeteerFig. 1: High level overview of MarioNet. The in-browser component (Servant), embedded in a Service Worker, gets delivered
together with the actual content of a website. After its registration on the user’s browser, it establishes a communication channel
with its remote command and control server (Pupeteer) to receive tasks.

of sophisticated browser extensions [20], [39] that monitor
the incoming and outgoing traffic of in-browser components.
Consequently, another challenge for MarioNet is to evade any
such deployed countermeasure installed in the browser. Finally,
it is apparent that the malicious or unwanted computation of
MarioNet must not impede the normal execution of the browser,
and avoid degrading the user experience. Otherwise, the risk ofbeing detected by a vigilant user or at least raising suspicion
due to reduced performance is high.

time, instructing for instance an unsuspecting user’s browser
to switch from illicit file hosting to distributed web-based
cryptocurrency mining.
Our system, which is OS agnostic, assumes no assistancefrom the user (e.g., there is no need to install any browser
extension). On the contrary, it assumes a “hostile” environment
with possibly more than one deployed anti-malware browser
extensions and anti-mining countermeasures. We also assume
that MarioNet targets off-the-shelf web browsers. Hence, theexecution environment of MarioNet is the JavaScript engine of
the user’s web browser. Breaking out of the JIT engine [5] isbeyond the scope of this paper.

To summarize, in order to overcome the above challenges,
a MarioNet-like system should have the following properties:
1) Isolation: the system’s operation must be independent froma browsing session’s thread or process. This isolation willallow a malicious actor to perform more heavyweightcomputation without affecting the main functionality ofthe browser.
2) Persistence: the operation must be completely detachedfrom any ephemeral browsing session, so that the browser
can remain under the attacker’s control for a period longer
than a short website visit.
3) Evasiveness: operations must be performed in a stealthy
way in order to remain undetected and keep the browser
infected as long as possible.
IV.

A. System components
Figure 1 presents an overview of MarioNet, which consistsof three main components:
1) Distributor: a website under the attacker’s control (e.g.,through the means discussed in Section III-A), which
delivers to users the MarioNet’s Servant component, alongwith the regular content of the webpage. It should be notedthat the attacker does not need to worry about the time auser will spend on the website. It takes only one visit to
invoke MarioNet and run on the background as long as
the victim’s browser is open.
2) Servant: the in-browser component of MarioNet, embedded in a service worker. It gets delivered and planted
inside the user’s web browser by the Distributor. Upon
deployment, the Servant establishes a connection with its
Puppeteer through which it sends heartbeats and receives
the script of malicious tasks it has to perform. The Servant
runs in a separate process and thereby it continues its
operation uninterruptedly even after its parent tab closes.
3) Puppeteer: the remote command and control component.
This component sends tasks to the Servant to be executed,

S YSTEM OVERVIEW

In this section, we describe the design and implementationof MarioNet, a multi-purpose web browser abuse infrastructure,and present in detail how we address the challenges outlined
earlier. Upon installation, MarioNet allows a malicious actor
to abuse computational power from users’ systems throughtheir browsers, and perform a variety of unwanted or malicious
activities. By maintaining an open connection with the infectedbrowser, the malicious actor can change the abuse model at any
5and orchestrates the performed malicious operations. The
Puppeteer is responsible for controlling the intensity ofresources utilization (CPU, memory, etc.) on the user side,
by tuning the computation rate of the planted Servant.

the service worker API [19]), ensuring the integrity andconfidentiality of the transmitted data. Consequently the C&C
communication channel cannot be inspected by any eavesdropping third party sitting either (i) inside (e.g., browser extension)or (ii) outside (e.g., ISP) of the browser.

As illustrated in Figure 1, MarioNet is deployed in threemain steps: First, (step 1) the user visits the website (i.e.,
the Distributor) to get content that they are interested in. The
Distributor delivers the JavaScript code of the Servant alongwith the rest of the webpage’s resources. During the phasewebpage rendering (step 2), the Servant is deployed in the user’s
browser. As part of its initialization, the Servant establishes acommunication channel with its remote command and control
server (Pupeteer) and requests the initial set of tasks (step 3).
The Pupeteer, which is maintained by the attacker, respondswith the malicious script (e.g., DDoS, password cracking,cryptocurrency mining) the Servant has to execute.

The only request that reveals the existence of the service
worker is the initial GET request at the time of the user’s firstwebsite visit, when the service worker gets initially registered.
Although during that GET request a monitoring extension canobserve the contents of the service worker, it will still notobserve any suspicious code—the code that will carry out themalicious tasks is delivered to the Servant only after its firstcommunication with the Puppeteer, and this communication is
hidden from browser extensions (as discussed in Section II-B)
Along with the evasiveness of MarioNet against monitoring
and blocking extensions, it is also important to maintain its
stealthiness to avoid detection from users themselves. Existing
web-based botnet approaches [13], [54] follow an opportunistic
approach, utilizing greedily all available resources on the device
during their limited period of activity. When browsers run sucha malicious script, the louder noise of the fans, the sudden
power drainage, or the sluggish responsiveness of their system,
alerts users who are likely to close the associated browser tab,or even report the website to their blocker extension.

B. Detailed Design
MarioNet leverages existing features of HTML5 to achieve
the objectives presented in Section III: isolation, persistence,and evasiveness. In-browser attacks that involve computationallyheavy workloads require isolation in order to avoid interferingwith a webpage’s core functionality. Previous approaches [13],[54] rely on web workers to carry out heavy computation in
the background (in a separate thread from the user’s interface
scripts). Although this isolation also prevents the code of the
web worker from having access to the DOM of the parent
page, it has the benefit of allowing multi-core utilization. As aresult, attackers can utilize multiple cores for their malicious
computations. However, web workers run in the same browser
tab as the website, and consequently, their execution is tightly
coupled with the parent tab: whenever the tab closes, the web
worker terminates as well. In addition, security-related browser
extensions can (i) monitor all traffic and (ii) tamper with thescript running in the web worker.

In contrast to existing in-browser attacks, MarioNet aims toprolong its presence on a user’s device by allowing the attacker
to monitor the device’s state at real time, and adjust accordingly
the resources utilization to minimize the possibility of getting
detected. To that end, the Servant monitors the device’s current
status (e.g., CPU utilization, battery status) and by utilizing
HTML5’s high-resolution performance timers [72], throttles
or even pauses the execution of the malicious workload. This
allows it to minimize the risk of self-exposure in case there isa CPU capping mechanism in the browser [8].
Persistence across Browser Reboots: MarioNet runs in the
background as long as the browser is open. After that, the victim
has to re-visit the malicious domain or render the malicious
iframe where the malicious domain resides, in order to reactivate the service worker and allow the Servant to continue
its operation. To increase persistence even further, we havedeveloped a technique that allows MarioNet to persist evenafter the browser has been restarted. This can be achieved byutilizing the Push API [44]. This feature allows a web server
to deliver asynchronous notifications and updates to service
workers, in an attempt to provide users with better engagement
and timely new content. By abusing this mechanism, MarioNet
can enable the Puppeteer to periodically probe its Servants andre-activate them after the browser restarts.

To remedy these shortcomings, MarioNet leverages adifferent component of HTML5, namely service workers. As
described in Section II-A2, service workers are typically used
as an in-browser caching proxy, serving the user during offline
periods. In contrast to web workers, service workers run
in a separate process, completely detached from the parent
tab. In addition to service workers, we use the SyncManager
interface [45] to register background “sync registrations” forthe service worker, to keep the Servant always alive. The
tab independence and indefinite lifetime properties of theServant provide MarioNet with persistence, allowing attackers
to carry out their malicious computation for the entire periodthat a browser remains open—a major benefit over existing
approaches based on web workers, which remain operational
only for the duration of a browsing session (open tab).

In contrast to the non-transparent to user process of service
worker registration, security policies in modern browsers restrict
the use of the Push notifications feature only after the user’s
permission. Of course, some users may get suspicious onthat behavior, depending on the website they visit. However,an advanced attacker can convince reluctant users to give
their consent for push notifications by advertising enticing
offers (e.g., virtual points or participation to contests) or by
performing more advanced types of social engineering using
custom permission requesting popups. Recent studies haveshown that 12% of users give such permissions when they are

Another advantage of leveraging service workers is thatthey conceptually operate between the browser and the remote
server. As a consequence, any security monitoring performedby browser extensions cannot monitor the activity and network
communication of the service worker, allowing the Servant
to operate in a stealthy way. Consequently, the Servant canestablish a communication channel with the remote Puppeteer
that no browser extension can snoop. In addition, the establishedcommunication channel is TLS-encrypted (as required by6

Puppeteer

Puppeteer

Puppeteer
Host A

Host B

do

vi

si

t

Target

visi

t Ta

rget

talk
with A

do c
ompu
te
retu
rn r
esul
t

Ta

rg

et

talk
with B

BotnetBotnetHost C

Botnet(a)(b)

fetch fileusing magnet(c)Fig. 2: Different use cases of MarioNet. After victims get compromised, the attacker can instrument them to perform (a) visits toa selected server or URL, for DDoS attack or fake ad-impressions, (b) requested computations, such as cryptocurrency mining or
password cracking, and (c) illegal services, such as illicit file hosting or hidden/anonymized communications.

asked to [3], which constitutes a fairly large number of nodes,
sufficient for deploying a persistent botnet that is capable tosurvive browser reboots.
V.

as some HTTP request headers (e.g., the request contenttype). One concern though, that we already mentioned in
Section II-A4, is that if the target web server does not enable theAccess-Control-Allow-Origin:* header, the request
will not fetch any content. Even in that case though, the attack
can still succeed, as it does not necessarily rely on forcing the
web server to send a response. As long as the requests aresent, the incoming network link is filling up and also the serverneeds to spend resources to handle the incoming requests.

ATTACK V ECTORS

Our design, described in Section IV, opens the space fora diverse set of attacks in users’ web browsers, which can be
categorized in three models, as shown in Figure 2.

Apart from HTTP fetching mechanisms, HTML5’s WebSockets API [47] provide additional opportunities. WebSockets
can be used to send messages to a WebSocket-enabled server
over TCP and receive event-driven responses. Obviously, tomount a DoS attack using WebSockets, the targeted serverneeds to implement this protocol; this is indeed the case formany popular web sites, as well as for smaller ones, which
increasingly adopt the WebSockets protocol. Besides that, as
already has been shown in [58], malicious JavaScript code may
still misuse the handshake by requesting resources even bytargeting a non-WebSocket web server. Although the targeted
web server may ignore the characteristic WebSocket HTTP
headers (as it is not supported), it can still accept WebSocket
handshake HTTP requests as normal HTTP requests [58]. As aresult, the web browser will start the WebSocket handshake withthe target, while the non-WebSocket web server will process
the HTTP request as a valid request. In MarioNet, we use
the WebSocket() method to initiate connections with web
servers, and then the send() method to send a flood of data
to the targeted server.

A. DDoS Attacks
A simple yet powerful attack that can be launched with thedevices the attacker controls is a Distributed Denial-of-Service
attack. In MarioNet we implemented a DDoS attack module
enabling the Puppeteer to instruct the Servants to connect toa specific Internet host. As a result, the targeted host will getoverwhelmed by the large amount of connections and thus
become non-responsive to benign users.
A limitation of using a high-level language, such as
JavaScript, to initiate a DoS attack is that it does not provide
low level networking access. Directly manipulating the network
packets to be sent is thus not an option (e.g., force TCP-SYN
packets only, or spoof source network address). In addition, it
results to much higher latency, due to the extra memory copies
and context switches that are caused from the resulting system
calls. Instead, JavaScript offers more high-level approaches,such as XMLHttpRequest objects [48] or methods provided
by cross-platform libraries (e.g., the get(), post(), andajax() methods provided by jQuery). These methods canbe used to perform HTTP GET and POST requests, either
synchronously (i.e., in a blocking fashion, waiting for theconnection to be established) or asynchronously. In addition,some methods may return cached responses (e.g., the get()method provided by jQuery).

Using XMLHttpRequest.send(), jQuery’s ajax()
and WebSocket’s send() methods, we can continuously senda flood of messages to a targeted host. Each approach allows
MarioNet to connect to any host, by specifying the hostname
or IP address and the corresponding port number. By doing so,
JavaScript code can misuse the TCP handshake by requesting
connections even to non-HTTP or non-WebSocket servers. In
those cases, the targeted servers will either receive only the
TCP SYN packets (e.g., when the destination port is in a closed,
reject, or drop state), or the full HTTP request. Furthermore,

In order to increase the DDoS fire power of MarioNet,
we use the XMLHttpRequest API, which can be used
to perform AJAX (asynchronous HTTP) requests, and does
not cache any responses. Moreover, it allows to control therequest method, and set an arbitrary HTTP body, as well7the WebSocket API allows to open many different connections,which enables attackers to orchestrate different styles of attacks(e.g., stealthy, low-volume, etc.). For instance, it allows to
perform Slowloris-like attacks, by keeping many connections
to the target server open as long as possible [9].

server contains a list of the hashes to be cracked and gives
each node a range of character combinations along with thehash to be cracked. Each node then hashes these combinations
and checks if it matches the original hash; if it matches, thenode reports the recovered password back to the Puppeteer. A
major advantage of MarioNet is that it can be agnostic to thehashing function used, since the function code is transferredfrom the Puppeteer and executed from the MarioNet nodes
through eval(). As a matter of fact, in Figure 7 we show theperformance achieved by MarioNet for executing two popularhashing algorithms, namely SHA-256 and MD5.

Of course, MarioNet cannot send messages to any port at
the targeted host. To avoid Cross-protocol Scripting [69], whichallowed the transmission of arbitrary data to any TCP port,
modern browsers block by default outgoing messages to a list ofreserved ports [42]. Finally, we note that the resulting network
performance of JavaScript is not that high, compared to DoS
attack tools that can leverage direct access to OS internals (i.e.,
memory map techniques between the network interface and theapplication) and low-level APIs (i.e., raw sockets). However,this is not a serious limitation, as it has been shown that short,
low-volume DDoS attacks pose a great security and availability
threat to businesses [71].

D. Malicious or Illegal Data Hosting
Having a large network of MarioNet nodes can also enable
the delivery of illegal or otherwise unwelcome content. The
advantages of MarioNet is not only that the content can beserved by unsuspecting users, making it hard to track down thereal culprits behind it, but also allows efficient data distribution
between the MarioNet nodes.

B. Cryptocurrency Mining
The rise of lightweight cryptocurrencies, such as JSEcoin
and Monero, together with the features of Web Workers API
that have been described in Section II, have recently enabled
the widespread adoption of cryptocurrency mining on the Web.
As a result, attackers have started migrating mining algorithms
to JavaScript and embed them to regular websites, in the formof web worker tasks. By doing so, the website visitors becomemining bots unwittingly every time they access these websites.

Indeed, the release of WebRTC (Web Real-Time Communications) protocol in the browser a few years ago, enables peer-topeer networking communications. In particular, WebRTC allows
web applications and sites to capture and optionally stream
audio and/or video media, as well as to exchange arbitrary
data between browsers without requiring an intermediary. Even
though this technology opens new opportunities for distributed
networking to the web, it also brings some significant security
concerns when used maliciously. In the case of MarioNet, forinstance, it could be easily used as an illegal content provider,leveraging the distributed nature and persistence that offers. As
a proof-of-concept, similar to [13] we used the WebTorrent
API [16] to implement a simple, yet flexible, data hostingmechanism over WebRTC which allows the sharing of torrent
files through the infected MarioNet nodes. WebTorrent allows
users to seed and leech files with other peers entirely throughtheir web browsers. A new torrent file can easily be createdusing the seed() function which creates a new torrent andstarts seeding it. The file can then be downloaded and further
seeded from other nodes, using the returned magnetURI.

However, the short website visiting times make the profitability of the web workers approach questionable [65]. Instead,
MarioNet increases the potential profits of web cryptocurrency
mining, due to the background execution it offers, completely
detached from the website. As a matter of fact, we have
implemented a service worker module that computes hashes ofthe popular CryptoNight algorithm [11]. CryptoNight is a proofof-work (PoW) algorithm used in several cryptocurrencies,
such as Electroneum (ETN) and Monero (XMR). The service
worker that we have implemented within MarioNet, connectswith Coinhive [10], which is a web service that provides an
API for users to embed a JavaScript miner on their websites.
Alternatively, the cryptocurrency miner can connect to any
mining pools, through the HTTP stratum proxy, using a
registered account, as shown in previous works [54]. By doing
so, attackers will be credited the payout directly to their wallets.
Finally, we notice that other hash algorithms that are used for
cryptocurrency mining, such as Scrypt-based miners [7], canbe implemented in a straightforward way by porting theirimplementations to JavaScript.

E. Other Attacks
1) Relay Proxies: Fully anonymous and transparent relay
proxies that can route data between two peers, are an important
asset for criminal use, making it difficult for the authorities totrack down the perpetrators. Large groups of such proxies canform a hidden network (i.e., Darknet), where people buy andsell illicit products like weapons and drugs [12].
The MarioNet infrastructure can provide a platform forestablishing such networks. Specifically, an infected browser
can be used as an intermediate proxy to fetch illegal content
from services in the Darknet on behalf of an anonymous
user. Indeed, building upon the previous illegal data hosting
scenario, MarioNet could form anonymous circuits (similar tomixnets), through which users could route their web traffic.
Such chain could be created by bots connected with encrypted
peer-to-peer channels with each other by using WebRTC.2

C. Distributed Password Cracking
The idea of distributed password hash cracking on the
web is not new [4]. Orthogonal to other approaches that try
to boost the sustained performance by either increasing theparallelism using different web workers [13], or exploiting
the computational capabilities of modern GPUs using the WebGL/WebCL API [52], MarioNet can help towards increasing
the uptime of hash cracking techniques, and as a result theoverall performance.

2 WebRTC traffic is always encrypted. Transmitted data is protected by
Datagram Transport Layer Security (DTLS) [49] and Secure Real-time
Transport Protocol (SRTP) [41].

The basic concept in MarioNet is to have the Puppeteer
distribute the computation between the infected browsers. The
8

There are already such browser-based proxies implemented
over WebRTC, like Stanford’s Flash Proxies [17] and Tor
Project’s Snowflake [26]. Apparently, a solid implementationof such a service within a service worker, capable of providing
strong anonymity guarantees (e.g., similar or close to Tor), is
not a trivial task and requires deeper analysis. Hence, such an
exploration is beyond the scope of this paper.

TABLE II: MarioNet’s browser compatibility
DeviceSW compatibility
since v40
since v44
since v26
since v17
since v11.1
NoSupport

Samsung Internet
Chrome Android
UC Browser
iOS Safari
Firefox Android
Android Browser
Opera Mobile
Opera Mini
Blackberry

since v4
since v64
since v11.8
since v11.3
since v57
Partially since v62
Partially since v37
NoSupport
NoSupport

Desktop2) Click Fraud: Having a large botnet can become profitablein many ways. One such way is to abuse the digital advertising
ecosystem, by having bots rather than humans view or click on
online advertisements. It is estimated that online advertisingfraud will cost advertisers $19 billion in 2018, which represents
9% of total digital advertising spend [31].
MarioNet can be easily used to generate clicks, as wellas surf targeted websites for a period of time, stream online
videos to increase views, manipulate online polls, and possibly
sign up for newsletters. To achieve that, the service worker canobtain periodically a list of online links that is requested to visit,
possibly combined with metadata such as visit duration, numberof clicks, etc. In addition, due to the rich programming featuresthat JavaScript offers, MarioNet can be easily programmed tofollow a human-centric online behavioral model (e.g., similar tothe one proposed by Baldi et al. [6]) to evade countermeasuresthat seek to block users with unusual activity (e.g., clicking
too many links in a short period of time).

Mobile

10000

HTTP requests/sec

VI.

Browser
ChromeFirefoxOpera
Edge
SafariIE

E VALUATION

A. Prototype Setup
To assess the feasibility and effectiveness of our approach,and also to check the existence of possible code protection andrestriction mechanisms, we build a real world deployment of
our MarioNet prototype. Our prototype consists of two servers;
the first server is an Apache web server that hosts a simple
webpage, and the second one is a command and control server(i.e., Puppeteer), delivering tasks to the Servants. Upon thefirst website visit, the webpage registers a service worker in
the Servant and a sync manager that is responsible to keep theservice worker alive in the background. After its registration, theServant opens a full-duplex connection—using the WebSocket
API [47]—with the Puppeteer and retrieves a JavaScript codesnippet that executes through eval(). In order to be able touse eval() from within the service worker, the collaborating
web server gives the needed permission through the HTTP
Content Security Policy (CSP).

Firefox
Chrome
Opera

1000

100

10

1

1G

W

bi

t

iF
i

DS

L

Re
G
R
G
R
G
gu ood egu ood egu PR
S
la
l
l
3
2
a
a
G
G
r4
r3
r2
G
G
G

Network Connection

Fig. 3: Rate of asynchronous outgoing HTTP OPTION requests
for different browsers and network connections in the DDoS
scenario. An orchestrated DoS attack in MarioNet can achieverates of up to 1632 reqs/sec per infected device.

functionality is provided by Safari, we experienced several
performance glitches. We believe that this behavior is dueto the recently adaptation of service workers in Safari (2018).
Even for simple workloads, i.e., a simple counting example, theperformance achieved by the service worker is extremely slow
(i.e., 20 − 50× lower) compared to the performance achievedby the other three browsers.

Browser Compatibility: As discussed in Section IV, ourapproach is based on existing components of HTML5 suchas Service Workers and its interface SyncManager. Table IIsummarizes the browser compatibility of these components,
and thus the compatibility of our framework. As we can see,some vendors like Google, started supporting service workers
quite early (2016), while others caught up only until recently,
i.e., Safari (2018). Still, MarioNet is compatible with the mostpopular browsers in both desktop and mobiles.

B. Performance Evaluation
In order to demonstrate the effectiveness of MarioNet, we
conduct several experiments with various popular browsers
and hardware settings, which allow us to make useful andinteresting comparisons. However, it is noted that in this paper
we do not aim to provide an optimal implementation in termsof performance, but rather to demonstrate the feasibility of
the aforementioned attacks. To that end, the performance ofthe system can be further improved by using WebAssembly.
Furthermore, all the experiments presented in this section were

In our experiments we tested MarioNet with four popular
desktop browsers, namely Chrome, Firefox, Opera and Safari.
However, we chose to exclude Safari from the performance
evaluation results, due to its bad performance sustained in all
the experiments conducted. Even though the service worker
9

15

10

5

20

High Performance
Balanced
Power Saver

20

Hashrate (Hashes/sec)Intel i7-4790, 3.6GHz
Intel i7-4770, 3.4GHz
Intel i7-5557U, 3.1GHzIntel i5-5200U, 2.2GHz

Hashrate (Hashes/sec)

Hashrate (Hashes/sec)

20

15

10

5

Firefox
Chrome
Opera

15

10

5

0
10% 20% 30% 40% 50% 60% 70% 80% 90% 100%0
10% 20% 30% 40% 50% 60% 70% 80% 90% 100%0
10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

CPU utilization threshold

CPU utilization threshold

CPU utilization threshold

Fig. 4: Hashrate for different equipped Fig. 5: Hashrate for different utilization Fig. 6: Hashrate for different infected
CPUs and utilization levels in the cryp- levels and Power modes in the cryptojack- browsers and utilization levels in the cryptojacking scenario. As expected, victim’s ing scenario. The OS may slow down clock tojacking scenario. Firefox browser canhardware affects significantly the compu- speed of the victim’s device, reducing up calculate up to 1.51× more hashes pertation power that MarioNet may obtain. to 78.41% the computation power.
second than Chrome and Opera.

conducted in a controlled environment, without reaching any
host outside our local network (see Section VIII).

Cracking speed (KHashes/sec)

7001) Abuse of network resources: In the first experiment,
we measure the rate of HTTP requests that the MarioNet
framework can achieve from a single browser. As describedin Section V-A, the Puppeteer instructs the Servant to continuously send multiple HTTP requests to a remote server,
via XMLHttpRequest.send(). Figure 3 shows the rateachieved for different browsers and different types of networks.
To measure the rate, we ran tcpdump at the targeted serverand captured all the incoming HTTP traffic. As can be seen in
Figure 3, even devices over inferior network connections arecapable of contributing a fair share in such a distributed attack(e.g., an average of 214 reqs/sec on Good3G networks). For
high network bandwidth, i.e., 1 GbE, Opera tends to achieve
higher rates (up to 1632 reqs/sec on average).

MD5
SHA-256

600
500
400
300
200
100
0
ChromeFirefoxOpera

Fig. 7: Cracking speed of different browsers in the distributed
password-cracking scenario. MarioNet can brute-force per
victim around 500K MD5 hashes per second or around 300K
SHA-256 hashes, irrespective of the infected browser.

2) Abuse of computation power: The next experiment
explores the computation capacity that the infected browsers
can provide. Figure 4 presents the hashrate achieved whenmining Monero coins in Chrome, for different CPU models
and various utilization thresholds. As expected, the performancegain is highly affected by the equipped hardware. Specifically,
we see that Intel i7-4790 can give 29% more hashes per second
than Intel i5-5200U, when fully utilized.

achieved for different browsers, when using a Intel i7-5557U
CPU. We observe that Firefox can calculate up to 34.55% morehashes per second than Chrome and Opera, which are both
based on Chromium and the V8 JavaScript engine.
The earnings of an attacker that launches a distributed
MarioNet-like Monero mining attack can be estimated withthe following equation: Earnings = ((total hashrate ×block reward)/current dif f iculty) × time. For this estimation we consider a scenario of an attacker that controls a
website that attracts on average 10000 unique visitors per day,that the visitors of the malicious site have mid-range devices,and that the attacker utilizes only a single core of their devices
at a utilization level of 60%-70% (i.e., user hashrate of 10h/s). According to the current difficulty of Monero mining,
the attacker will earn around 0.5 monero every 12 hours,
which is easily achievable when considering the persistence
characteristics of a MarioNet-like attack. It should be noticed
though, that this is a very conservative estimation, since weonly assume that the attacker infects a relatively small numberof users, and that the victims’ devices are only slightly utilized.

After experimenting with different operating systems, we noticed that the different power mode characteristics they provide
can drastically affect the sustained performance of CryptoNight
execution. Figure 5 shows the performance achieved on a
Windows 7 desktop computer that is equipped with an Intel
i7-4790K, at 4.0GHz, under 3 different power modes (namelyHigh Performance, Balanced and Power Saver). When fully
utilized, the Power Saver mode forces the CPU to reduce thevoltage and clock speed, which causes a decrease of up to
78.41% compared to the High Performance mode. In addition,in the Balanced mode, when CPU utilization exceeds 50% theoperating system allows the CPU to run in full speed in order
to cover the increased computation needs, thus verging thehashrate of High Performance mode.
Next, we explore how different infected browsers affect thecomputation gain of MarioNet. Figure 6 shows the hash-rate

In our last experiment, we explore the performance sustained
10

108

Accumulated SHA256 KHashes

for password cracking. Figure 7 plots the achieved rate forhashing 10-digit alphanumerical passwords on a brute-force
manner, for both MD5 and SHA-256 algorithms. As we cansee, all browsers achieve similar and comparable performance.
This means that a single browser can brute-force around 500K
MD5 hashes per second or 300K SHA-256 hashes, irrespectiveof the infected browser.
3) Persistent and Evasive abuse: In order to assess thepersistence and evasiveness of our approach, we deliver
MarioNet within a webpage destined to perform cryptojacking.
Before fetching the webpage in a Chrome browser, (i) we open
tcpdump and (ii) we deploy in our browser the following extensions/tools: Tamper Chrome HTTP capturing extension [20],Chrome’s default DevTools, WebSniffer [2], and HTTP Spy [1]to explore in the real world, the stealthiness of MarioNet against
state-of-the-art monitoring and blocking extensions. After fully
rendering the webpage and planting the Servant, we close theassociated browser tab. Then, from the Puppeteer, (iii) we push
a cryptocurrency mining task to the Servant and let it run for
3 consecutive days. We see that although the Servant regularly
communicated with the Puppeteer to obtain PoW tasks, as
tcpdump correctly captured, none of the employed extensions
was able to monitor any Servant-related traffic other than thevery first GET request of the webpage, right before infection.

107
106
105

106
105

10

4

10

3

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

0

100

200

300

400

500

600

700

Time (minutes)

Fig. 8: Number of SHA256 hashes brute-forced by MarioNet
and previous Web-botnet approaches that utilize Web Workers,
in the lapse of time. The persistence of MarioNet makes a single
infected browser compute hashes as long as the browser is open
and thus be more efficient than opportunistic Web-Botnets.

We present various defense strategies and discuss thecorresponding tradeoffs they bring. We categorize the defenses
in two classes: (i) those that can be deployed inside a vanillabrowser (e.g., via an extension), and (ii) those that can be
deployed in the host (through anti-virus tools, IDS/IPS, firewalls,etc.) or by modifying the browser.

Comparison to state-of-the-art web botnets: In order tocompare MarioNet with the state-of-the-art web-botnets, weload our password cracking algorithm in a set of web workers as
described in related approaches [13], [54]. Given that these webbotnets run only for as long as the victim is surfing the webpage,
they need to fully utilize the resources of the infected device inorder to scrounge a meaningful gain from this short infection
window. As a consequence, they usually occupy concurrently
all system cores across the entire period of a website visit,
which studies have shown that it is 1 minute on average [53].

A. In-browser Mechanisms
1) Restricting or Disabling Service Workers: Service workers have been introduced to enable rich offline user experience, such as periodic background synchronization and push
notifications, embedded content fallback, caching, message
relaying across pages, offline fallback, and user-side loadbalancing. Traditionally, these types of functionality requireda native application. However, the window of opportunity forabuse by attackers, makes for a difficult tradeoff between
rich user experience and security. In the case of MarioNet,
disabling service workers could indeed prevent the persistence
and stealthiness of in-browser malicious computation. Towards
a similar direction, one could suggest to restrict the liveness ofservice workers, making it proportionate to the user presencein the website that hosts them (i.e., the service worker issuspended after the user leaves the website) or apply a timecap (i.e., a service worker gets terminated if it keeps running for
an unreasonable amount of time). By doing so, the persistence
characteristic of our attack will no longer be available. Service
workers will still be able to intercept and modify navigation
and resource requests, as well as cache resources, using thestorage API for example, to allow applications to run evenwhen the network is not available.

In Figure 8, we plot the total number of SHA-256 hashes
brute-forced by the 2 approaches in an infected browser for aperiod of 12 hours. For MarioNet, we measure two cases: (i)the best case, where the password cracker runs uninterruptedly
in the victim’s device, and (ii) the worst case, where alongwith the malicious computations there is heavy utilization fromother processes too. In the second case, to simulate this heavyload, we concurrently run a multi-threaded pi digit calculator
that fully utilizes all 8 system’s cores. As we can see, although
web-botnet utilizes greedily 8× more resources, MarioNet
due to its persistence, enjoys a higher efficiency after the
18th minute of an open browser, even under extreme heavy
concurrent interference. Consequently, while until today, thebusiness model of malicious websites were to deploy a webbotnet and find a way to keep the user on the website (byproviding free movie streaming, online games or include popunder windows [70]), with MarioNet it takes only a momentary
visit to infect the user and take control of their browser.
VII.

MarioNet (best case)
MarioNet (worst case)Web-botnet (w/ Web Workers)

D EFENSES

However, service workers were designed to provide important functionalities to long-running web applications (e.g.,
Google Docs, Gmail, Twitter, LinkedIn, Whatsapp web client)even after tab closing [50]. By forcing restrictions, service
workers will not be able to provide the above backgroundprocessing, thus significantly limiting the capabilities of contemporary web applications, resulting in a severe degradation

In this section we examine potential defense mechanismsthat could detect and mitigate MarioNet type of attacks. The
goal is to determine whether it is feasible to detect the general
methodology of the attack vectors that are opened through themisuse of the service worker mechanisms, rather than mitigating
the specific use cases studied in this paper.
11

of user experience. To mitigate that, a better solution would be
to selectively enable service workers only for some “trusted”
websites, possibly via a browser extension that prevents theunconditional registration of service workers.

mechanisms. For example, by installing end-to-end encryption
with the back-end server can sufficiently hide the content of
the messages. Given that a host-based approach can havefull control of the client side though, the SSL connection
can be intercepted to acquire the decrypted data. Besides, themessages still need to be transferred, which can be a good
hint for detection mechanisms that are based on network flow
statistics (e.g., number of packets exchanged, packet size). Even
though covert channels and steganography may potentiallyhelp attackers, there are works that try to detect web-based
botnets, by performing anomaly detection on features like
communication patterns and payload size [30].

A step towards striking stealthiness is to disable the eval()family functions. By doing so, the attacker would need toship the malicious functionalities together with the service
worker, which would facilitate the signature-based content
filtering browser extensions to detect them easier. Obviously,
this would be an arm race between attackers and defenders,given the obfuscation and code scrambling techniques thatare in use for similar cases. In addition, service workers can
include minimal ISA emulators in order to execute malicious
instructions received from the attacker. A more aggressive
option would be to limit the functionality offered by service
workers, by making only a subset of JavaScript available for use(e.g., allowing only the sending/receiving of data between thewebsite and the server). Clearly, such a data-driven approach
would require much more careful consideration and design.

2) Behavioral Analysis and Anomaly Detection: A more
drastic solution would be to develop techniques that try to detectsuspicious behavior of JavaScript programs that are embeddedin the web site or the service worker. Obviously, this would
require more sophisticated analysis than simple fixed string
searching and regular expression matching, due to the fact thatthe obfuscation of the malicious JavaScript code snippets canevade static analysis techniques. Instead, more advanced andcomplex analyzers should be used, such as the monitoring of
the utilized resources or the behavioral analysis of the executed
code. Even though this can be quite challenging, several works
have been proposed in the past [25], [62], [27]. For instance,
one of the first anomaly detection approaches is JaSPIn [62],which creates a profile of the application usage of JavaScriptand enforces it later. IceShield [27] uses a linear decisionfunction that differentiates malicious code from normal code
based on heuristics for several attack types that apply code
obfuscation. Finally, in [25] the authors audit the executionof JavaScript code, and compare it to high-level policies, inorder to detect malicious code behavior. Although all theseapproaches are not trivial, they are a prominent step towards
protecting against malicious JavaScript programs in general.

2) Whitelists/Blacklists: Another possible defense strategy is
to restrict the browser, with fine-grained policies, from fetchingand deploying service workers. The simplest approach is the useof whitelists; i.e., service workers will be blocked, unless thedomain of origin is whitelisted. These lists can initially include
popular sites, which are typically considered more trusted, andenriched by web crawling and analysis platforms, such as [61],that perform web-wide analysis to detect malicious websites
and JavaScript files.
3) Click to Activate: Another mitigation would be to require
the user’s permission for registration and activation of aservice worker—similar to “Click to Play” mechanism [51] that
disables by default plug-ins, such as Flash, Java, Silverlightand others. By doing so, the service worker functionality will
be disabled by default, and users would need to explicitly
give permission for the service worker to run. Currently, thisuser consent is needed only for the Push Notifications [44].
However, given the variation of attack vectors that can beachieved through a malicious service worker, we believe that
explicit permission would raise user suspicion—in the sameway it does for location, microphone, etc.—especially whenbrowsing unreliable websites. One may say that these proposed
permission-based defenses may be not practical to constitutethe perfect mitigation for the presented attack. However, recent
developments such as GDPR, mobile or browser permissions
model etc., have demonstrated that user consent can be forced.

VIII.

D ISCUSSION

Ethical considerations. In this paper, we implemented anddeployed MarioNet in a strictly controlled environment. During
our experimentation with attack scenarios, no user or web
server outside this controlled environment were contacted or
harmed in any way. As such, we constrained the evaluation of
our system to a limited set of nodes, thus avoiding any attempt
to measure our system on a larger scale, in the real world.
Attack difficulty. Based on our threat model (Section III-A) a
MarioNet attack can be launched (a) intentionally, by a malicious or “shady” website; (b) unintentionally, by a hijacked orcompromised website, or a website that includes a compromised
library; and (c) through third-party dynamic content in iframes.
Since our attack does not rely solely on a legitimate website
or third-party library to be compromised, but it can also be
performed by first-party websites that include such content,
and also triggered by dynamic content in iframes, according
to (a) and (c), it seems that such an attack can be practicallylaunched quite easily (by actors with different incentives or
intentions). Essentially, it requires only a contemporary webbrowser (all popular browsers are vulnerable—see Table II) andjust accessing a webpage that provides such malicious content,
either from first or third parties.

B. Host-based Approaches
1) Signature-based Detection: Traditional tools such as
firewalls, anti-virus, and intrusion detection/prevention systems,
are always a prominent methodology for the detection ofmalicious activities. The majority of these tools are typicallyusing signatures to detect suspicious data or code that entersor leaves a user’s computer. The creation of such signatures
for the case of MarioNet may be trivial for some attack cases.
For example, it could be easy to detect MarioNet messages
that are exchanged between the service worker that lies in thebrowser and the back-end server, by monitoring the network
traffic. A sophisticated attacker can obviously employ several
techniques to raise the bar against signature-based detection

Attack impact. Aside from the cases of malicious or shadywebsites that can straightforwardly launch our attack, and web12

sites or third party libraries being compromised, the presented
attack can be also launched by loading malicious third-party
dynamic content in iframes residing in entirely legitimate
websites. For instance, attackers can exploit the ad ecosystem’s
real-time auctioning mechanism to load their malicious content
in iframes [57]. It has been already demonstrated in previous
works [13] how programmatic ad delivery can be exploited to
distribute malicious content. The ease of launching such an
attack, and the ability of attackers to utilize legitimate, and more
importantly, popular and trustworthy websites with possibly
hundreds of thousands visitors, demonstrate the enormous impact our attack can potentially have. In addition, the stealthinessproperty of MarioNet, which can evade effectively monitoring
extensions by design, and the fact that all major browsers are
currently vulnerable to such attacks, as shown in the previous
sections, make the number of potential victims even larger, andhighlight the need for careful design and adequate protection
mechanisms.

rise recently [33]. Provos et al. [61] present the threat of webbased malware infections, in which the infected browsers pullcommands from a server controlled by the attacker. Contrary
to traditional botnet-like attacks, web-based malware does
not spread via remote exploitation but rather via web-based
infection. In [4], the authors craft malicious webpages whereusers get infected upon visit. The attackers can then abuse users’
browsers to perform attacks like DDoS, worm propagation, andnode reconnaissance. Grossmann and Johansen [24] leverageads to deliver malicious JavaScript to users, forcing browsers
to establish connections with a victim server, thus performing
a DoS attack. A major limitation of these approaches though,is that the corresponding malicious JavaScript snippets need tobe embedded in the main webpage. As a result, long-running
operations would block the rendering procedure and executionof the web application, making it practical only for short-lived
attacks.
To overcome this limitation, many approaches started
recently to use web workers—a feature that was introducedwith HTML5. Web workers run as separate threads, and thus
being isolated from the page’s window. This allows the parallel
execution of operations, without affecting the normal renderingof the web application, leading to the rise of more advanced
web-based botnets. Kuppan [34] demonstrate this ability ofusing web workers to perform DDoS attacks. Rushanan et al.
in [63], also use web workers to perform stealthy computations
on the user side and launch not only attacks like DoS andresource depletion but also covert channel using CPU andmemory throttling. Pellegrino et al. [58] also present different
techniques to orchestrate web-based DoS attacks, by utilizing
web workers among other HTML5 features, and provide an
economic analysis and costs of browser-based botnets.

Registration of multiple service workers. Service workers
are associated with specific scopes during registration and eachservice worker can only control pages that fall under its scope.
If more than one service workers are registered (while the user
is navigating throughout a website), then the browser enables
only the service worker with the broader scope (typically theservice worker registered at the root domain). However, during
our experimentation we observed that a publisher can design
its website on purpose so that multiple service workers can beregistered in non-overlapping scopes (i.e., in file paths at thesame level of the URI). As a consequence, this could allow
MarioNet to have multiple Servants simultaneously active andutilize them for running its malicious tasks in multiple threads.
Cross-origin service workers. The cross-origin service worker(or foreign-fetch [60]) is an experimental feature of Chrome
54, to enable registration of third-party service workers. The
motivation behind that, is to enable developers to implement
advanced functionality, such as client-side caching of CDNbased third party content. However, this feature broadens thethreat model of MarioNet-like approaches, enabling third-parties
to misuse the service workers of the domains that include
them. Even though this feature was discontinued one year after
its announcement [68], mostly due to applicability issues, it
still shows that such new functionality should be considered
carefully in terms of security, before being applied.

Similarly, Pan et al. [54] explore the possibility of using
web workers for performing application-layer DDoS attacks,
cryptocurrency mining and password cracking. Their results
show that although DDoS attacks and password cracking arefeasible and with comparable financial cost, cryptocurrency
mining is not profitable for the attacker given the limited timea user spends in a website. Dorsey presented an in-browser
botnet using web workers as well [13]. The user browser,
after infection, participates in a swarm of bots performing
various malicious operations like DDoS attacks, torrent sharing,
cryptocurrency mining, and distributed hash cracking. To infectas many users as possible, Dorsey embedded his malware in a
malicious advertisement and let the ad network to distributeit to the users browsers. Similar to MarioNet, all the above
approaches do not require any software installation on theuser side. However, the browser remains under the control of
the attacker only for the duration that the user is browsing
the malicious website, making it impractical for long-runningbotnet operations. Instead, MarioNet provides persistence thatallows the attacker to perform malicious computations for aperiod longer than a website visit.

Towards this direction, the aim of this work is to increase
the awareness of developers and browser vendors about theprovided powerful (but also potentially risky) capabilities ofmodern HTML, and hopefully lead to the deployment of
restrictive policies that will adequately secure the user-side
environments of future web applications.
IX.

R ELATED W ORK

Web browsers are a core part of our everyday life, being
the door to the gigantic world of the web. As a result, they
have become a valuable target for attackers, that try to exploit
them in many different ways.

Besides the crypto-mining and crypto-jacking attacks, inwhich a website unintentionally hosts web-mining code snippets [40], [36], there are publishers that intentionally use mining
to monetize their websites. Eskandari et al. analyze the existing
in-browser mining approaches and their profitability [15].
Similar to web-based botnets, in-browser miners maintain aconnection with a remote server to obtain PoW tasks and abuse

For instance, several approaches try to abuse the richfeatures of modern web applications, in order to form webbased botnets, the existence of which has seen a significant
13web workers to achieve the highest possible CPU utilization on
the user side. However, the short website visiting times make theprofitability of this approach questionable [65], [56]. MarioNet
also uses crypto-jacking as a possible scenario, however insteadof web workers we leverage service workers to enable an entity
to gain much higher profits due to the provided persistence.

the Commission are not responsible for any use that may bemade of the information it contains.
R EFERENCES[1] “HTTP spy,” https://chrome.google.com/webstore/detail/http-spy/agnoocojkneiphkobpcfoaenhpjnmifb.
[2] 5ms.ru, “Web Sniffer,” https://chrome.google.com/webstore/detail/websniffer/ndfgffclcpdbgghfgkmooklaendohaef.
[3] Accengage, “Push notification benchmark press release 2017,” https://www.accengage.com/press-release-accengage-releases-the-pushnotification-benchmark-2017-including-for-the-first-time-web-pushfacebook-messenger-metrics-in-addition-to-stats-for-mobile-apps/,
2017.
[4] S. Antonatos, P. Akritidis, V. T. Lam, and K. G. Anagnostakis,“Puppetnets: Misusing web browsers as a distributed attack infrastructure,”
ACM Trans. Inf. Syst. Secur., vol. 12, no. 2, pp. 12:1–12:38, Dec. 2008.
[5] M. Athanasakis, E. Athanasopoulos, M. Polychronakis, G. Portokalidis,
and S. Ioannidis, “The devil is in the constants: Bypassing defenses inbrowser JIT engines.” in Proceedings of Annual Network and Distributed
System Security Symposium, ser. NDSS’15, 2015.
[6] P. Baldi, P. Frasconi, and P. Smyth, Modeling the Internet and the Web:
Probabilistic Methods and Algorithms. Wiley Online Library, 2003,
ch. 7. Modeling and Understanding Human Behavior on the Web.
[7] D. Bradbury, “Scrypt-based miners and the new cryptocurrency arms
race,” https://www.coindesk.com/scrypt-miners-cryptocurrency-armsrace/, 2013.
[8] C. Cimpanu, “Firefox working on protection against in-browser
cryptojacking
scripts,”
https://www.bleepingcomputer.com/
news/software/firefox-working-on-protection-against-in-browsercryptojacking-scripts/, 2018.
[9] Cloudflare, “Slowloris DDoS Attack,” https://www.cloudflare.com/
learning/ddos/ddos-attack-tools/slowloris/.
[10] Coinhive, “A Crypto Miner for your Website,” https://coinhive.com.
[11] CryptoNote Technology, “Egalitarian proof of work,” https://cryptonote.org/inside.php#equal-proof-of-work, 2015.
[12] M. Dittus, J. Wright, and M. Graham, “Platform criminalism: The ’lastmile’ geography of the darknet market supply chain,” in Proceedings ofthe 2018 World Wide Web Conference, ser. WWW, 2018.
[13] B. Dorsey, “Browser as botnet, or the coming war on your web
browser,” https://medium.com/@brannondorsey/browser-as-botnet-orthe-coming-war-on-your-web-browser-be920c4f718, 2018.
[14] S. Englehardt and A. Narayanan, “Online tracking: A 1-million-sitemeasurement and analysis,” in Proceedings of the 2016 ACM SIGSAC
Conference on Computer and Communications Security, ser. CCS, 2016.
[15] S. Eskandari, A. Leoutsarakos, T. Mursch, and J. Clark, “A first look atbrowser-based cryptojacking,” CoRR, vol. abs/1803.02887, 2018.
[16] F. Aboukhadijeh and WebTorrent, LLC., “Torrents on the web,” https://webtorrent.io/, 2017.
[17] D. Fifield, N. Hardison, J. Ellithorpe, E. Stark, D. Boneh, R. Dingledine,and P. Porras, “Evading censorship with browser-based proxies,” in International Symposium on Privacy Enhancing Technologies Symposium,ser. PETS, 2012.
[18] D. Goodin, “Cryptojacking craze that drains your cpu now done by
2,500 sites,” https://arstechnica.com/information-technology/2017/11/
drive-by-cryptomining-that-drains-cpus-picks-up-steam-with-aid-of2500-sites/, ArsTechnica.
[19] Google Developers, “Introduction to service worker,” https://developers.google.com/web/ilt/pwa/introduction-to-service-worker,
2018.
[20] Google Open Source, “Tamper Chrome browser application,”
https://chrome.google.com/webstore/detail/tamper-chrome-extension/
hifhgpdkfodlpnlmlnmhchnkepplebkb, 2017.
[21] P. Gregoire, “Public STUN server list,” https://gist.github.com/mondain/b0ec1cf5f60ae726202e, 2016.
[22] G. Grigoreva, “What is a popunder ad & how to use it (explained),”https://www.mobidea.com/academy/popunder-ad/, 2018.
[23] I. Grigorik, “Browser APIs and protocols: WebRTC,” https://hpbn.co/
webrtc/, 2013.

Finally, several attacks are based on malicious browser extensions that a user downloads and deploys in the browser [38],[59]. For instance, Liu et al. propose a botnet framework that
exploits the browser extension update mechanism to issue
batch commands [38]. By doing so, they are able to perform
DDoS attacks, spam emails and passwords sniffing. Similarly,
Perrotta et al. exploit the over-privileged capabilities of browser
extensions to check the effectiveness of botnet attacks incontemporary desktop and mobile browsers [59]. Their results
show that different attacks are feasible in different browsers.
A major difference of these approaches with MarioNet, is that
all the above approaches require the installation of software(i.e., browser extension) on the user side.
X.

C ONCLUSION

In this work, we presented MarioNet: a novel multi-attack
framework to allow persistent and stealthy bot operation throughweb browsers. Contrary to traditional botnet-like approaches,
our framework does not require any installation of malicious
software on the user side. Instead, it leverages the existing
technologies and capabilities provided by HTML5 APIs ofcontemporary browsers.
We demonstrate the effectiveness of this system by designing a large set of attack scenarios where the user’s system
resources are abused to perform malicious actions including
DDoS attacks to remote targets, cryptojacking, malicious/illegal
data hosting, and darknet deployment. Two important characteristics of MarioNet, that further highlight the severity of theaforementioned attacks, is that it provides persistence, thus
allowing an attacker to continue their malicious computationeven after the user navigates away from the malicious website.
In addition, MarioNet provides evasiveness, performing all
operations in a completely stealthy way, thus bypassing theexisting in-browser detection mechanisms.
Essentially, our work demonstrates that the trust model ofweb, which considers web publishers as trusted and allows themto execute code on the client-side without any restrictions isflawed and needs reconsideration. Furthermore, this work aims
to increase the awareness regarding the powerful capabilities
that modern browser APIs provide to attackers, and to initiate
a serious discussion about implementing restrictions while
offering such capabilities that can be easily abused.
ACKNOWLEDGMENTS
We thank our shepherd, Adam Doupé, and the anonymous
reviewers for their valuable feedback. The research leading tothese results has received funding from European Union’s Marie
Sklodowska-Curie grant agreement 690972 (PROTASIS); theHorizon 2020 Research & Innovation Programme under grant
agreements 786669 (REACT), 740787 (SMESEC), 700378(CIPSEC), and 786890 (THREAT-ARREST); and by the
National Science Foundation (NSF) under grant CNS-1617902.
The paper reflects only the authors’ view and the Agency and
14

[24]
[25]

[26]
[27]

[28]
[29]
[30]

[31]

[32]

[33]
[34]
[35]

[36]

[37]

[38]

[39]
[40]

[41]
[42]
[43]
[44]
[45]

[46]
[47]
[48]
[49]
[50]

[51] Mozilla Support, “Why do I have to click to activate plugins?” https://support.mozilla.org/en-US/kb/why-do-i-have-click-activateplugins, 2018.
[52] MWR InfoSecurity, “Distributed hash cracking on the web,” https://labs.mwrinfosecurity.com/blog/distributed-hash-cracking-on-the-web/,2012.
[53] J. Nielsen, “How long do users stay on web pages?” https://www.nngroup.com/articles/how-long-do-users-stay-on-web-pages/,
Nielsen Norman Group, 2011.
[54] Y. Pan, J. White, and Y. Sun, “Assessing the threat of web worker
distributed attacks,” in Communications and Network Security (CNS),
2016 IEEE Conference on, ser. CNS, 2016.
[55] E. P. Papadopoulos, M. Diamantaris, P. Papadopoulos, T. Petsas, S. Ioannidis, and E. P. Markatos, “The Long-Standing Privacy Debate: Mobile
Websites vs Mobile Apps,” in Proceedings of the 26th International
Conference on World Wide Web, ser. WWW, 2017.
[56] P. Papadopoulos, P. Ilia, and E. P. Markatos, “Truth in web mining: Measuring the profitability and cost of cryptominers as a web monetization
model,” CoRR, vol. abs/1806.01994, 2018.
[57] P. Papadopoulos, N. Kourtellis, P. R. Rodriguez, and N. Laoutaris,“If You Are Not Paying for It, You Are the Product: How Much Do
Advertisers Pay to Reach You?” in Proceedings of the 2017 Internet
Measurement Conference, ser. IMC, 2017.
[58] G. Pellegrino, C. Rossow, F. J. Ryba, T. C. Schmidt, and M. Wählisch,“Cashing Out the Great Cannon? On Browser-Based DDoS Attacks
and Economics,” in 9th USENIX Workshop on Offensive Technologies(WOOT 15), ser. WOOT, 2015.
[59] R. Perrotta and F. Hao, “Botnet in the browser: Understanding threatscaused by malicious browser extensions,” CoRR, vol. abs/1709.09577,
2017. [Online]. Available: http://arxiv.org/abs/1709.09577[60] J. Posnick, “Cross-origin Service Workers: Experimenting with Foreign Fetch,” https://developers.google.com/web/updates/2016/09/foreignfetch, 2016.
[61] N. Provos, D. McNamee, P. Mavrommatis, K. Wang, and N. Modadugu,“The Ghost in the Browser Analysis of Web-based Malware,” inProceedings of the First Conference on First Workshop on Hot Topics
in Understanding Botnets, ser. HotBots, 2007.
[62] P. Raman, “JaSPIn: JavaScript based Anomaly Detection of Cross-site
scripting attacks,” Ph.D. dissertation, Carleton University, 2008.
[63] M. Rushanan, D. Russell, and A. D. Rubin, “Malloryworker: stealthy
computation and covert channels using web workers,” in International
Workshop on Security and Trust Management. Springer, 2016, pp.
196–211.
[64] G. Rydstedt, E. Bursztein, D. Boneh, and C. Jackson, “Busting framebusting: a study of clickjacking vulnerabilities at popular sites,” IEEE
Oakland Web, vol. 2, no. 6, 2010.
[65] K. Sedgwick, “Mining Crypto In a Browser Is a Complete Waste
of Time,” https://news.bitcoin.com/mining-crypto-in-a-browser-is-acomplete-waste-of-time/.
[66] T. Soulo, “How many websites are mining cryptocurrency? we analyzed
175m+ domains to find out.” https://ahrefs.com/blog/cryptominingstudy/.
[67] The European Union Agency for Network and Information Security(ENISA), “Malvertising,” https://www.enisa.europa.eu/publications/infonotes/malvertising, 2016.
[68] The World Wide Web Consortium (W3C), “Remove foreign fetch,”https://github.com/w3c/ServiceWorker/issues/1188, 2017.
[69] J. Topf, “Vulnerability note vu#476267,” https://www.kb.cert.org/vuls/
id/476267, 2001.
[70] L. Tung, “Windows: This sneaky cryptominer hides behind taskbar
even after you exit browser,” https://www.zdnet.com/article/windowsthis-sneaky-cryptominer-hides-behind-taskbar-even-after-you-exitbrowser/, 2017.
[71] S.
Weagle,“Short,low-volume
DDoS
attackspose
greatest security and availability threat to businesses,”
https://www.itproportal.com/features/short-low-volume-ddos-attackspose-greatest-security-and-availability-threat-to-businesses/.
[72] World Wide Web Consortium (W3C), “High resolution time level 2,”
https://www.w3.org/TR/hr-time-2/, 2018.

J. Grossman and M. Johansen, “Million Browser Botnet,” Presentation
at Black Hat USA, 2013.
O. Hallaraker and G. Vigna, “Detecting Malicious JavaScript Code in
Mozilla,” in Proceedings of the 10th IEEE International Conference on
Engineering of Complex Computer Systems, ser. ICECCS, 2005.
S. Han, “Snowflake Technical Overview,” https://keroserene.net/
snowflake/technical/, The Tor Project, 2017.
M. Heiderich, T. Frosch, and T. Holz, “IceShield: Detection and
Mitigation of Malicious Websites with a Frozen DOM,” in Proceedingsof the 14th International Conference on Recent Advances in Intrusion
Detection, ser. RAID, 2011.
B. Hillmer, “URL redirect: Breaking out of an iframe,” https://
help.surveygizmo.com/help/break-out-of-iframe, 2017.
E. Homakov, “Building botnet on serviceworkers,” https://sakurity.com/
blog/2016/12/10/serviceworker botnet.html, 2016.
F.-H. Hsu, C.-W. Ou, Y.-L. Hwang, Y.-C. Chang, and P.-C. Lin, “Detecting Web-Based Botnets Using Bot Communication Traffic Features,”
Security and Communication Networks, vol. 2017, 2017.
Juniper Research, “Ad fraud to cost advertisers $19 billion
in 2018, representing 9% of total digital advertising spend,”
https://www.juniperresearch.com/press/press-releases/ad-fraud-to-costadvertisers-$19-billion-in-2018, 2018.
S. Khattak, N. R. Ramay, K. R. Khan, A. A. Syed, and S. A.
Khayam, “A taxonomy of botnet behavior, detection, and defense,” IEEE
Communications Surveys Tutorials, vol. 16, no. 2, pp. 898–924, 2014.
KrebsOnSecurity, “The Rise of Point-and-Click Botnets,” https://krebsonsecurity.com/tag/web-based-botnets/.
L. Kuppan, “Attacking with html5,” Presentation at Black Hat, 2010.
S. Lekies, B. Stock, M. Wentzel, and M. Johns, “The Unexpected
Dangers of Dynamic JavaScript,” in Proceedings of the 24th USENIX
Conference on Security Symposium, ser. USENIX Security, 2015.
J. Leyden, “Real mad-quid: Murky cryptojacking menace thatsmacked ronaldo site grows,” http://www.theregister.co.uk/2017/10/10/
cryptojacking/, The Register, 2017.
Z. Li, S. Alrwais, X. Wang, and E. Alowaisheq, “Hunting the Red Fox
Online: Understanding and Detection of Mass Redirect-Script Injections,”
in 2014 IEEE Symposium on Security and Privacy, ser. IEEE S&P, May
2014.
L. Liu, X. Zhang, and S. Chen, “Botnet with browser extensions,”in Privacy, Security, Risk and Trust (PASSAT) and 2011 IEEE Third
Inernational Conference on Social Computing (SocialCom), 2011 IEEE
Third International Conference on, ser. PASSAT/SocialCom, 2011.
L.
McAfee,“Mcafeesecuresafebrowsing,”
https://www.mcafeesecure.com/safe-browsing, 2018.
K. McCarthy, “CBS’s Showtime caught mining crypto-coins in viewers’
web browsers,” http://www.theregister.co.uk/2017/09/25/showtime hit
with coinmining script/, The Register, 2017.
D. A. McGrew and K. Norrman, “The secure real-time transport protocol(srtp),” 2004.
MDN web docs, “Mozilla port blocking,” https://developer.mozilla.org/
en-US/docs/Mozilla/Mozilla Port Blocking, 2014.
——,“Cross-Origin
Resource
Sharing(CORS),”
https://developer.mozilla.org/en-US/docs/Web/http/CORS, 2018.
——, “Push API,” https://developer.mozilla.org/en-US/docs/Web/API/
Push API, 2018.
——,“ServiceWorkerRegistration.periodicSync,”
https://developer.mozilla.org/en-US/docs/Web/API/
ServiceWorkerRegistration/periodicSync, 2018.
——, “Using Web Workers,” https://developer.mozilla.org/en-US/docs/
Web/API/Web Workers API/Using web workers, 2018.
——, “WebSockets,” https://developer.mozilla.org/en-US/docs/Web/API/
WebSockets API, 2018.
——, “XMLHttpRequest,” https://developer.mozilla.org/en-US/docs/
Web/API/XMLhttpRequest, 2018.
N. Modadugu and E. Rescorla, “Datagram transport layer security,”
2006.
Mozilla Corporation, “Serviceworker cookbook,” https://serviceworke.rs/,
2018.

15