This type of attack requires a JavaScript file that contains the worker’s code. If this script is blocked, then the attack will fail. Yet, such a script may look innocent, and contain links to 3rd party domains. There are malware examples in the wild which are based on abusing Web Workers. But, this one is based on abusing Service Workers which can continue their work after closing the malicious webpage and cannot be monitored by web browser's extensions. This follows from the fact that Service Workers can be completely detached from the website (on the contrary to Web Workers).
The persistence of such attacks (via Push API) are not likely in most browsers, but can be probably obtained due to a kind of bug.
Defense:
- Restricting or Disabling Service Workers.
- Whitelist/blacklist, for example: "...service workers will be blocked, unless the domain of origin is whitelisted. These lists can initially include popular sites, which are typically considered more trusted".
- Forcing the user’s permission for registration and activation of a service worker — "similar to “Click to Play” mechanism ... that disables by default plug-ins, such as Flash, Java, Silverlight and others".
- Signature-based Detection. "For example, it could be easy to detect MarioNet messages that are exchanged between the service worker that lies in the browser and the back-end server, by monitoring the network traffic."
- Behavioral Analysis and Anomaly Detection via "suspicious behavior of JavaScript programs that are embedded in the web site or the service worker, ... monitoring of the utilized resources or the behavioral analysis of the executed code", comparing the suspicious code with normal code "based on heuristics for several attack types that apply code obfuscation."