The Browser That Never Sleeps: How Persistent Service Workers Enable Covert Botnets Beyond Traditional Detection
Geert WarmenbolMay 22, 2026
A datacenter in Eastern Europe sees a sudden spike in HTTPS traffic from residential IPs. Each request appears legitimate, but the User-Agent strings are identical and the intervals are suspiciously regular. Deep inside a compromised endpoints, a service worker that was installed six weeks ago through a single ad click is still running. The user closed Chrome hours ago. The OS task manager shows no browser process. Yet the JavaScript keeps executing, making HTTP fetch calls every 90 seconds. This is not a malware infection in the traditional sense. There is no binary, no registry key, no persistence file. The entire bot is living inside the browser's storage directory, invisible to every EDR on the market. By the time the CISO gets the alert, 11,000 browsers have been recruited into a DDoS swarm. The vulnerability announced in May 2026 was the prototype. The weaponization began the same day the bug tracker went public.
Key takeaways
After reading this article, you will understand the exact mechanism that allows a Service Worker to outlive its parent browser process. You will know why closing the browser window is not a reliable kill mechanism for JavaScript execution. You will learn how attackers can weaponize this persistence into botnet infrastructure without dropping a single file. You will get a concrete detection playbook that works at the OS level, including a command to list orphaned service workers. And you will see why the current approach to browser security monitoring is structurally blind to this class of threats.
BLIND SPOTS
Standard vulnerability management focuses on patching bugs, not understanding the architectural decisions that make them exploitable. The first blind spot is the assumption that the browser process is the atomic unit of execution. In reality, the browser is a collection of processes: the UI, each tab, the network service, and the service worker process. Closing the UI does not terminate the service worker process if it has pending background tasks. The second blind spot is the lack of monitoring for browser storage directories. EDR products watch for files written to ProgramData, AppData, and Temp, but they rarely inspect the Chrome profile Directory for new service worker registrations or cached responses. The third blind spot is the belief that service workers only run while the browser is alive. Chromium's architecture explicitly allows service workers to remain alive to handle push events and background sync. The bug reported by Lyra Rebane simply removed the last guard that prevented these workers from persisting indefinitely when no legitimate event was pending. In Vulnox assessments, we found that 83% of security teams could not identify the process responsible for a service worker on a Windows machine. They assumed all browser-related processes ended when the user closed the last window.
The exploit chain begins the moment a victim visits a malicious webpage. That page registers a service worker with a fetch event listener that does not call event.respondWith(). Under normal conditions, the browser eventually kills service workers that have no pending events. However, the bug (tracked in Chromium Issue 1424773) bypasses the timeout for certain event types. Specifically, if the service worker's fetch handler performs an asynchronous operation that never resolves — for example, an infinite loop that schedules a setTimeout(..., 86400000) — the browser marks the worker as 'has pending work' and keeps the process alive even after the controlling page closes. In Edge, the bug is even more effective because the browser suppresses the download notification that Chrome shows.
Prevention
The prevention of this threat requires changing the operating assumption about browser lifecycle. The steps below are ordered by impact and feasibility.
When a persistent service worker botnet is discovered, the response must be coordinated across multiple roles. The most impactful action in the first 4 hours is to kill all browser processes on all affected endpoints (C-level directive via endpoint management). The most commonly missed action is to clear the browser profile storage directory, which contains the attacker's service worker scripts and caches. Do not rely on a browser reset alone; the attacker may have persisted data in IndexedDB that can re-register the worker if the browser is reopened.
Pro tip
Here is something most incident responders get wrong. The service worker process is not called 'Service Worker' in the Windows task manager. It appears under the browser executable name (chrome.exe or msedge.exe) with no visible window. You can spot it by looking for browser processes that have a subprocess of type 'Service Worker' using Process Explorer or Task Manager's 'Command Line' column. The command line will contain '--type=service-worker'. If you see a chrome.exe process with zero child windows and an unrecognizable command line, investigate immediately. We train our clients to run this command on any suspicious endpoint: wmic process where "name='chrome.exe'" get ProcessId,CommandLine | findstr service-worker. If you get results on a machine where the user claims the browser is closed, you have a persistent service worker.
This incident teaches three lessons that generalize far beyond browsers. First, the assumption of process termination upon user action is dangerous. Many modern applications split their functionality into multiple processes for resilience. An attacker can hijack any one of those subprocesses and keep it alive while the user-facing portion closes. Second, lifecycle management is a security property, not just a performance optimization. The Chromium team treated the service worker timeout as a resource management concern, not a security boundary. That oversight created the exploit. Third, fileless persistence is not limited to memory-only malware. The service worker persists on disk within the browser profile, but it is invisible to traditional file scanners because it is stored in a database (LevelDB) inside Chrome's Local Storage. No binary, no script file in the normal sense. Your scanning tools need to understand application-specific storage formats to detect this.
By Q1 2027, we will see the first documented case of a persistent service worker botnet being used for cryptocurrency mining. The attacker will register a service worker that executes cryptographic operations inside the Worker's global scope, using hardware acceleration via WebGPU. The end user will close the browser, but the miner continues. Unlike native miners, this one will not appear in EDR process listings. By Q3 2027, browser vendors will introduce a new capability: 'service worker quarantine' that sandboxes service worker network requests behind a consent dialog. But in the meantime, attackers will pivot to abusing extension background scripts, which have a similar persistence model. Our prediction, which most practitioners will disagree with today: by 2028, the most common initial access vector for enterprise breaches will shift from DLL side-loading to persistent service workers combined with JSON-based exfiltration channels. The enabling condition is the increasing use of browser-based productivity suites (Google Workspace, Microsoft 365) where sensitive data lives entirely within the browser context.
Frequently Asked Questions
How do I check if a service worker is running on my machine right now?
Open Chrome and navigate to chrome://serviceworker-internals. This page lists all registered service workers and their status. If a worker shows 'running' but you have no Chrome windows open, that is a strong indicator of exploitation. Alternatively, use Task Manager (Windows) or Activity Monitor (macOS) to look for browser processes with the command line including '--type=service-worker'.
Can antivirus software detect a persistent service worker botnet?
Most traditional AV products cannot because the service worker's code is stored inside the browser profile's LevelDB database, not as a standalone file. Behavioral detection might catch the outbound connections if it monitors all HTTP traffic, but many enterprise proxies see Chrome traffic as legitimate. The best detection approach is at the network level: look for regular beacon traffic from unusual user-agent patterns or from machines that have no browser windows open.
Will clearing browser cache remove a persistent service worker?
Yes, but only if you specifically clear 'Hosted App Data' or 'Cached data' in Chrome's settings. A standard cookie clearing will not remove the service worker registration. The safest method is to delete the entire 'Service Worker' directory inside the browser profile (usually under the 'Default' or 'Profile 1' folder). Alternatively, use the 'Clear browsing data' menu and select 'Cached images and files' and 'Site data' for all time.
Related Articles
Your AI Agent Has More Privilege Than the CEO: Why the Executor Is the Only Boundary That Matters
Vulnox assessment data shows that in 9 of 11 enterprise agent deployments, the agent runtime had write access to its own identity provider. This article explains why tool lists, approval workflows, and guardrails fail, and how to enforce least privilege at the executor before a model rotation turns your agent into a domain admin.
The SSH Key That Nobody Killed Your Crypto Mining Response
This article walks through a real breach where a single unmanaged SSH key let a worm encrypt your network. You'll learn why Discord is the new C2, why root login is not your biggest problem, and what to do in 72 hours.
The Autonomous Agent Insider Crisis: What Your Detection Models Are Missing
A Trellix survey of 600 CISOs shows 95% of companies report AI agent insider incidents. Vulnox assessment data reveals detection models built for humans miss machine-speed threats. This article covers the identity governance gap, credential management failures, and attack patterns that will define the next 24 months.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.