This brief provides a technical analysis of how threat actors repurpose client-side proxy frameworks like Ultraviolet and its successor Scramjet for phishing campaigns, the observable network and page-level artifacts, and detection strategies for these novel evasion techniques.
Contents
- Service workers - A brief overview
- Ultraviolet Proxy Framework
- Case Study: Microsoft Login Phishing via Ultraviolet
- Emerging Trends: Scramjet
- Why Threat Actors Use Proxy Frameworks
- Conclusion
- References and further reading
Service workers - A brief overview
What if a website could quietly place a programmable layer inside your browser that controls how network traffic is handled? A service worker is JavaScript code that a website downloads into the web browser. Once installed, it sits inside the browser and acts like a helper for that website, handling some of the communication between the browser and the web server. The service worker can control what information is sent back and forth, store data to retrieve later, and run background operations. Service workers operate in the background, without an obvious difference to the end user.
At its core, a service worker operates like a proxy server sitting between the web application, the browser, and the network. However, it is intentionally restricted: service workers have no DOM access, run asynchronously on a different thread, and cannot use certain synchronous APIs such as synchronous XHR or Web Storage. Further reference reading on service workers (Mozilla - Service Worker API).
What service workers can do:
- Intercept network requests and provide custom responses.
- Cache resources to enable effective offline experiences.
- Support capabilities such as push notifications and background synchronization.
What they cannot do:
- Access or manipulate the DOM.
- Run synchronous operations or certain blocking APIs.
- Intercept network requests from browser tabs/windows other than its own
Service Worker Diagram - Source: https://web.dev/articles/workers-overview
Threat actors benefit significantly from using service workers as a proxy layer in credential-phishing campaigns because these workers can intercept and modify network requests while operating persistently in the background. A malicious service worker could alter responses, inject harmful content, or redirect victims to phishing pages, enabling attackers to capture sensitive information without the user’s knowledge. Once compromised, a worker may intercept all requests made by a web application and steal data or manipulate sessions, effectively positioning the attacker in a man-in-the-middle role. Additionally, because service workers can cache and serve modified responses and continue running after installation, they provide attackers with durable control over traffic flows - a capability that can help deliver malicious payloads directly to the browser and potentially evade traditional inspection points such as SSL/TLS proxies. Setting up a service worker is not a simple task which is why there are pre-configured frameworks already built allowing for simple and quick deployments.
Ultraviolet Proxy Framework
Ultraviolet is an open-source browser-based proxy framework originally designed to bypass censorship by relaying web content through a service-worker sandbox. When run in a user’s browser, Ultraviolet intercepts all HTTP requests for that window and reroutes them through an Ultraviolet server. This allows users to access arbitrary sites as if the content were hosted on the proxy domain itself.
Key features include:
- Handling CAPTCHAs and cookies
- Full client-side request interception and content rewriting
- URL encoding/decoding to obscure navigation paths
While intended for censorship circumvention, these capabilities make Ultraviolet attractive to threat actors, enabling them to host phishing pages, malware, or redirects behind seemingly benign domains, thereby evading URL-based filtering and static content analysis.
Case Study: Microsoft Login Phishing via Ultraviolet
This case study is based on an Unlisted scan conducted by the urlscan Threat Research Team and approved for release.
In a recent investigation https://urlscan.io/result/019be0f3-2e36-7549-aff2-f3b27a575a72 the urlscan Threat Research Team noticed a redirect was being abused from the legitimate Microsoft login domain to the malicious phishing domain. This led the urlscan Threat Research Team to investigate this process further.
During analysis we observed the page’s HTML and scripts loaded components from an Ultraviolet proxy. Specifically, the page pulled down uv.bundle.js, uv.config.js, and uv.handler.js. These filenames and the presence of a __uv$config JavaScript object and UVClient JavaScript functions in the scan capture are hallmarks of the Ultraviolet framework.
These scripts are not part of any legitimate Microsoft login page - they are the Ultraviolet client scripts that bootstrap the service worker proxy. In effect, when a victim’s browser visited the phishing link, the Ultraviolet worker redirected requests behind the scenes to the real Microsoft login server. This lets the phishing site display a genuine-looking login page without hosting it on the attacker’s domain.
In general, any page that loads uv.handler.js, uv.config.js, and uv.bundle.js or similar from a nonstandard host is likely using Ultraviolet (or a derivative).
The configuration json file is used to adjust how the proxy operates. The structure of the file is shown below.
Prefix: The directory prefix users will see.
Bare: Bare servers can run on directories, e.g., http://example.org/bare/.
EncodeUrl: How you want the URL to be encoded (Examples: xor or base64).
DecodeURL: How you want the URL to be decoded (Should match EncodeUrl).
Handler: Path to the UV handler (Default: static/uv/uv.handler.js).
Bundle: Path to the UV bundle file (Default: static/uv/uv.bundle.js).
Config: Path to the UV config file (Default: static/uv/uv.bundle.js).
SW: Path to the UV Service Worker script (Default: static/uv/uv.sw.js).
Using the case study scan the config file can be seen in the responses:
self.__uv$config = {
prefix: '/s/',
bare: '/bare/',
encodeUrl: Ultraviolet.codec.xor.encode,
decodeUrl: Ultraviolet.codec.xor.decode,
handler: '/uv/uv.handler.js',
bundle: '/uv/uv.bundle.js',
config: '/uv/uv.config.js',
sw: '/uv/uv.sw.js',
};
Importantly, urlscan’s phishing‐detection engine flagged this scan as malicious and branded the scan as impersonating Microsoft.
Emerging Trends: Scramjet
Scramjet is the successor to Ultraviolet and functions similarly, with comparable client-side artifacts and fingerprinting opportunities. Proactive detection is recommended by using a search for the key items liked to Scramjet deployments.
Why Threat Actors Use Proxy Frameworks
-
Infrastructure hiding: Attackers often host phishing pages on compromised or throwaway domains. Proxy systems let them further obscure the origin by funneling traffic through a proxy domain. To a casual observer or naive filter, the site may simply appear as a normal hosted portal (Google or Discord via proxy), not a credential phishing page.
-
Content authenticity: Because the proxy relays live content from legitimate sites, the phishing page can embed genuine UI elements. In our case, the Microsoft login form was real Microsoft HTML, not a hand‑crafted fake. This reduces the chance of obvious typos or missing images.
-
Filter evasion: Many network defenses whitelist popular content providers or CDN domains. By bouncing through an allowed domain, the attacker can slip past domain‑based blocks.
-
Unified control: The service‑worker model of Ultraviolet and Scramjet means an attacker can configure proxy rules centrally. They can redirect all requests to chosen endpoints (e.g. credential phishing login pages) without modifying each page. This flexibility is appealing for maintaining phishing kits or redirect infrastructures.
Because Ultraviolet and Scramjet were designed to bypass censorship, it is inherently evasive. Threat actors repurpose that feature set for malicious anonymity and persistence.
To support detection of these systems we have added a new label to urlscan Pro to allow detection of proxy frameworks including Ultraviolet and Scramjet. These can be used to detect an underlying proxy framework on a scan or filter based upon these detections.
tech.proxy.ultraviolet and tech.proxy.scramjet
Conclusion
Client-side proxy frameworks such as Ultraviolet and Scramjet are being repurposed by threat actors to cloak phishing campaigns. The case study demonstrates how attackers can proxy legitimate content (e.g., Microsoft login pages) through their own infrastructure, evading traditional URL-based and static detection.
Detection is achievable by analyzing artifacts, global objects, and configuration patterns in the page source, highlighting the importance of hunting using framework elements and rendered images and hashes.
By proactively monitoring these frameworks and correlating proxy behaviors with open redirects, defenders can identify and mitigate high-fidelity phishing campaigns before they reach and impact end users.
References and further reading
If you would like to know more about service workers, their potential abuse and impact on detections take a look at the following resources which provide good oversights into this topic.
- GitHub - Scramjet
- GitHub - Ultraviolet
- Medium @ahaz1701 - EvilWorker: AiTM attack leveraging service workers
- Mux.com - Service workers are underrated, and building media proxies proves it
- Web.dev - Service workers
