Skip to content

SourTrade browser-assembled malware malvertising

Summary

SourTrade is a persistent malvertising operation that impersonates TradingView, Solana, and Luno to reach retail traders and cryptocurrency users. Confiant reports activity since late 2024 across 12 countries and 25 languages, with targeting concentrated in APAC and Latin America and additional activity in Australia, Great Britain, Nigeria, South Africa, and Turkey.

The campaign's durable technical distinction is browser-side executable assembly. A cloaked landing page does not retrieve one finished malicious executable. It registers ServiceWorker and SharedWorker components, requests a session-specific /config recipe, fetches a clean compressed Bun runtime from separate infrastructure, generates pseudorandom bytes locally with AES-CTR, and combines those inputs with actor-supplied PE structures and malicious JavaScriptCore bytecode. The browser then exposes the assembled stream as a same-origin attachment.

Confiant documents delivery of the assembled Windows file, not automatic execution. Public reporting does not establish a browser vulnerability, a Mark-of-the-Web bypass, or whether execution follows a click or another user action.

Tags

Why this matters

  • Network and file-centric controls can see individually benign-looking components rather than the final malicious binary created in the browser.
  • Per-session random seeds and sizes produce variable output, reducing the durability of hash-only blocking.
  • The clean Bun runtime is only an input. Reputation or signature checks on that component alone do not describe the final file written to disk.
  • The final download is served through a ServiceWorker-controlled path on the landing-page origin, so ordinary download telemetry can omit the secondary origin that supplied the runtime.
  • The campaign combines broad ad distribution, multilingual brand impersonation, victim fingerprinting, and server-controlled assembly instructions, allowing rapid payload and infrastructure changes.

Reported operation

  • Activity window: Confiant reports ads since late 2024 and observed the browser-assembly technique continuing through 2026.
  • Impersonated brands: TradingView, Solana, and Luno.
  • Geography: Japan, Thailand, South Korea, Taiwan, Hong Kong, Bolivia, Brazil, Nigeria, Turkey, South Africa, Australia, and Great Britain.
  • Advertising surfaces: Landing-page artifacts included Google Ads configuration, Meta/Facebook pixels, and X/Twitter tracking logic. Confiant says this indicates the operators can measure traffic across those ecosystems; it is not proof that every platform carried every campaign.
  • Cloaking: Fingerprinting separates likely victims from bots and analysts. Selected targets see a convincing impersonation page while other visitors receive a blank or benign page.
  • Earlier lineage: Confiant links the current chain technically to the Bun-standalone and StreamSaver-based TradingView malvertising documented by Bitdefender in September 2025. Current variants no longer rely on the GitHub-hosted StreamSaver URL used by variants observed through April 2026.

Browser assembly chain

  1. The landing page registers /sw.js as a page-scoped ServiceWorker and creates a SharedWorker from JavaScript embedded in the page.
  2. The SharedWorker requests /config with victim-fingerprinting details.
  3. /config returns a template, a standaloneUrl, and session-specific random seed and size values instead of a completed executable.
  4. The browser retrieves and decompresses a clean Bun runtime from the secondary URL.
  5. Client-side code uses AES-CTR to generate a pseudorandom stream, then walks the template as a byte-copy recipe.
  6. Actor-supplied base64 blobs provide the PE header, section table, and a .bun section containing malicious JavaScriptCore bytecode for app.js; large ranges come from the clean runtime and generated byte stream.
  7. The page registers the assembled ReadableStream with the ServiceWorker under a same-origin URL and opens it through a hidden iframe.
  8. The ServiceWorker responds with application/octet-stream and attachment semantics, completing delivery of the assembled file.

The model means there is no stable, finished malicious binary in a single network response. It does not mean the activity is fileless: the chain ultimately delivers a Windows executable to the victim.

Defender actions

  1. Block ad-originated software installs. Require trading, wallet, and cryptocurrency software to come from verified vendor URLs or managed software catalogs, not sponsored search or social-media ads.
  2. Correlate the full browser chain. Join page visits, ServiceWorker registration, /config responses, secondary compressed executable retrieval, hidden-iframe downloads, and newly written PE files. Do not judge the clean Bun response in isolation.
  3. Inspect service-worker behavior. Hunt unfamiliar sites that register /sw.js, create workers from blob: URLs, maintain stream maps, and return attachment responses from page-controlled ReadableStream objects.
  4. Detect assembly recipes. Look for JSON responses combining random.seed, random.size, template, and standaloneUrl, especially where the page decodes large base64 PE fragments or generates unusually large AES-CTR streams.
  5. Use behavior and provenance over hashes. Alert when a browser writes a large executable whose bytes cannot be reconstructed from one download response, particularly after a trading or cryptocurrency ad click.
  6. Preserve browser evidence. Capture history, service-worker registrations and caches, page and worker scripts, HAR/proxy logs, downloaded-file MotW data, DNS, and memory where feasible before clearing the profile.
  7. Triage execution separately. If the assembled file ran, isolate the endpoint and investigate its child processes, persistence, credential and wallet access, browser data, outbound connections, and secondary payloads. Rotate exposed wallet or service credentials based on evidence.

Indicators and pivots

Published sample hashes

  • 9a29d26b94b708830c6eaea8a6c17616ec677adaf09114190d0e129564b2ca1b
  • 05c0d056a6b3e76736d4f378541d28f24ecdf40060eeed24d8aa283d2f0120f6
  • ad542ed44df306bdcbb022ae210da74abad74e978cc1e3992016976282f31976

High-signal technical pivots

  • Paths and keys: /sw.js, /config, standaloneUrl, random.seed, random.size, template.
  • PE section / payload: .bun, JavaScriptCore bytecode, app.js.
  • Published runtime-source example: purelogicbox[.]org.
  • Representative SourTrade domains from Confiant's published set: noxani[.]info, greensite[.]digital, yuntaro[.]digital, nexlisa[.]info, vashiro[.]info, lunavo[.]club, hanzoa[.]digital, authcom[.]digital, zuvex[.]digital, form-engine[.]digital, insightcores[.]digital, forecastlogiccore[.]digital, metricforge[.]digital, cognitionpipeline[.]digital, and syscodeapi[.]digital.

Treat domains and hashes as investigation pivots, not standalone attribution. Confiant's source contains the complete published domain list; the campaign's per-session assembly and infrastructure rotation make behavioral correlation more durable.

Analytical caveats

  • Confiant's report establishes browser-side construction and delivery, but not the final execution trigger or victim compromise count.
  • No browser exploit or MotW removal was reported. The current chain changes what source URL is recorded and what network controls observe; it does not eliminate MotW.
  • Advertising and tracking artifacts show campaign measurement capability and possible platform use, not platform attribution or proof that all listed ad ecosystems approved malicious content.
  • The relationship to earlier TradingView activity is based on shared delivery and executable characteristics; SourTrade is an operational cluster name, not a publicly identified actor.

Sources