Overview
SourTrade is a large-scale malvertising campaign running since late 2024, targeting crypto investors and traders in 12 countries across 25 languages. The attacker impersonates three trusted platforms in the financial community: TradingView, Solana, and Luno to lure victims to malicious landing pages through programmatic ads on Google, Meta, and Twitter/X.
What makes SourTrade special is not its scale but its distribution technique: no complete malware files exist online. The server sends the victim browser a set of "assembly instructions", the browser downloads a clean runtime file from a valid CDN, automatically generates additional random bytes according to AES-CTR code, and assembles it into a malicious executable file right in RAM memory.
With this design, each victim receives a file with a different SHA256 hash. File fingerprinting-based detection — which makes up the majority of endpoint protection mechanisms deployed — is disabled by design. Organizations need to monitor network behavior and browser runtime, not the file layer.
Event Timeline
| Time |
Event |
| Late 2024 |
SourTrade began running fraudulent programmatic ads impersonating TradingView, Solana, and Luno. |
| September 2025 |
Bitdefender identified an earlier variant that used StreamSaver.js hosted on GitHub. |
| By April 30, 2026 |
The Mark-of-the-Web (MotW) signature referenced jimmywarting[.]github.io/StreamSaver.js and nwitassistnow[.]com/.... |
| After April 30, 2026 |
SourTrade updated its campaign by switching to a self-hosted Service Worker, removing GitHub references from the MotW. |
| July 23, 2026 |
Confiant published a comprehensive technical report detailing the four-stage assembly pipeline. |
| July 30, 2026 |
BleepingComputer reported on the campaign, bringing it to broader public attention. |
Attack Chain
SourTrade's difference from any regular malvertising campaign lies in this: no complete malware files are sent over the network. Instead, the website turns the victim's browser into a factory — collecting individual pieces from multiple sources, then assembling them into malware right in the computer's memory.
The entire process takes place in four stages, automatically, without the victim doing anything else other than clicking on the ad.
Stage 1 — Fake Page Silently Installs "Worker" Into Browser
As the landing page loads — while you're looking at the convincing TradingView interface — the page's JavaScript starts installing two things in your browser, without any clicks required.
The first is a background process (called ServiceWorker — a completely valid browser feature, often used to make web apps work offline). Here it is misused: its role is that of a gatekeeper, waiting to receive the assembled file and hand it out as a download.
The second is a hidden “worker” — also running in the background, generated entirely from JavaScript code embedded in the page. No need to download anything from outside, no URLs left behind to be blocked. This is what will coordinate the entire assembly process in the next steps.
Stage 2 — Server Sends Design, Not Product
The newly installed hidden "worker" now contacts the attacker's server. It asks: what do I need to do next?
The server does not return a virus file. It returns a small piece of data — which looks like any response from a normal web API — containing three pieces of information:
Address to download Bun software — a completely valid, open-source JavaScript runtime, used by many programmers every day. Scan for viruses and find it clean.
A random number "seed" — varying per user, used to generate unique random bytes for this session. This is why each victim receives a file with a different digital "fingerprint", making it impossible for anti-virus software to identify the file hash.
Assembly blueprint — a list of instructions: which parts to get from where, what order to put together to create the finished file at the end.
Picture this: this isn't a pre-assembled IKEA cabinet — this is an assembly instruction sheet. Each person received an instruction sheet with a few different details, but the end result was the same.
Stage 3 — Browser Assembles Malware In Memory
Now your browser — following the instructions it received — starts collecting ingredients:
Step 3a: Download the Bun software from the address provided. This file is clean, nothing malicious. This will be the "cover" and "engine" of the complete malware.
Step 3b: Use the digital "seed" to generate hundreds of megabytes of random, unique data for your session. This is the filling part, ensuring the final file has digital fingerprints that have never appeared in the world.
Step 3c: Put everything together according to the design. The truly malicious part — the malware's code — is already encrypted and embedded in the blueprint received from the server from the beginning, just waiting to be installed in the right place.
The result: a complete Windows executable file that exists only in your computer's RAM. It has never been present as a complete file on any server on the internet.
Stage 4 — File Is "Delivered" As If It Came From a Normal Website
This is the most sophisticated step. The newly assembled file needs to be exported — to your desktop as a download.
The page creates a hidden iframe (an invisible web window) pointing to the landing page's address itself. The background process installed from Stage 1 catches that request, and returns the newly assembled file — as an attachment for download.
The browser behaves like any normal download file: TradingView-Premium.exe appears in your Downloads folder.
Windows records the file's origin — called the Mark-of-the-Web, which SmartScreen uses to decide whether to raise a warning. And what it writes in is the address of the landing page: noxani.info. Not the server address containing the Bun software. Not C2 address. Just a strange website with no bad history.
SmartScreen finds: files from this website, not yet on the blacklist. Not enough reason to block.
You see: TradingView-Premium.exe — downloaded.
Additional Technical Analysis
Cloaking Kit — Filtering Victims Before Delivery
Before any stage runs, the page fingerprints the visitor. Cloaking kit checks IP, time zone, browser version, VPN, and security researcher signatures. Bots and analysts see blank pages. Only victims who pass will see the money page.
The attack group also embedded Google Ads conversion pixel, Meta pixel, and Twitter/X pixel into the landing page — measuring and optimizing victim conversion rate like a real marketing campaign.
Network Data Flow — What Does It Look Like?
| Request |
Response |
What it Looks Like on the Wire |
| GET / |
React JS bundle |
A normal HTTPS web page |
| GET /sw.js |
Service Worker script |
Script served from the same origin — appears benign |
| GET /config |
JSON containing the template, seed, and URL |
The only notable detection point: large Base64-encoded blobs embedded in the JSON |
| GET /static/*.exe |
Bun runtime (gzip-compressed) |
Binary downloaded from a little-known CDN |
| GET /[filename].exe |
Assembled executable stream |
.exe downloaded from the landing domain — this is the only file that receives a Mark-of-the-Web (MotW) tag |
The /config step is the only detection opportunity on the wire — but only if there is SSL inspection and the rule checks that the response body has all three fields standaloneUrl + template + random.
Why Are All Common Protection Layers Missing?
| Security Tool |
Why It Fails Against SourTrade |
| Hash-based Antivirus (AV) |
AES-CTR seed rotation generates a unique hash for each victim, rendering hash-based detection ineffective. |
| Signature-based Intrusion Detection System (IDS) |
Dynamic assembly prevents the presence of consistent static byte patterns for signature matching. |
| URL Blocklist |
No URL directly hosts the complete malware payload, making URL-based blocking ineffective. |
| VirusTotal |
The final executable does not exist until runtime assembly, so it cannot be uploaded or scanned in advance. |
| SmartScreen / Mark-of-the-Web (MotW) |
The MotW records only the landing domain, not the actual C2 server or CDN involved in payload delivery. |
| Endpoint Detection and Response (EDR) File Write Alerts |
The files written to disk consist of the legitimate Bun runtime and the assembled payload, making it difficult for EDR solutions to distinguish malicious activity. |
| Browser Download Warnings |
The executable is downloaded from a same-origin URL, so the browser does not consider it suspicious and does not display a warning. |
SourTrade does not go through layers of protection one by one. It redesigned the entire attack chain to bypass them all — because they were all built for the old threat model: a static malware file traveling across the network.
IOC & Artifacts
SHA-256 File Hashes
9a29d26b94b708830c6eaea8a6c17616ec677adaf09114190d0e129564b2ca1b
05c0d056a6b3e76736d4f378541d28f24ecdf40060eeed24d8aa283d2f0120f6
ad542ed44df306bdcbb022ae210da74abad74e978cc1e3992016976282f31976
Network IOC — Domain
noxani[.]info greensite[.]digital yuntaro[.]digital
nexlisa[.]info vashiro[.]info campainter[.]digital
riovera[.]info lunavo[.]club hanzoa[.]digital
authcom[.]digital fererro[.]digital zythera[.]info
angelxc[.]digital toushere[.]digital auronix[.]digital
quorivamesh[.]digital junora[.]digital savanhe[.]digital
tenderi[.]digital dexarionrte[.]info zuvex[.]digital
minaro[.]club praxnova[.]info zuvex[.]club
kalviorix[.]info thaivex[.]digital form-engine[.]digital
solventa[.]club form-networktool[.]digital electmu[.]digital
zenovapc[.]site qumoro[.]site insightcores[.]digital
pulsewave-glow[.]digital ignite-spark[.]digital riberaz[.]com
polvexa[.]site viewsafc[.]online insightmetrix[.]digital
webnity[.]site cirevia1[.]digital tvviewreach[.]digital
alteira[.]digital dalasu[.]digital parixaxj[.]com
trustconnect[.]digital torvianet[.]site nebive[.]site
forecastlogiccore[.]digital netkorava[.]digital forecasthub[.]digital
dotlor[.]site koravaje[.]digital signalmetrics[.]digital
forecastbridge[.]digital lakorava[.]digital pustou[.]site
insightorbithub[.]digital dataroutehub[.]digital datasyncengine[.]digital
forecastdeltaflow[.]digital forecastlogicflow[.]digital metricforge[.]digital
forecastpulsegrid[.]digital robejj[.]com predictcore[.]digital
dataplanehub[.]site oneclickme[.]site prolega[.]site
nameprod[.]site transoe[.]site orientstrategypartners[.]digital
beamoramag[.]digital beammaybea[.]digital urbanleafy[.]info
brightmosaic[.]info forthlira[.]digital sobeamora[.]digital
topbeamora[.]digital mortarora[.]digital lunarohub[.]info
worldsol[.]site mindflowbase[.]info insight-radiant[.]digital
nordexastudio[.]info cognitionpipeline[.]digital cognitionnodehub[.]digital
acuitycore[.]digital radiantsynaptic[.]digital sapience-flare[.]digital
engineclaritynode[.]digital flare-hub[.]digital beacon-net[.]digital
brainyclevercore[.]digital syscodeapi[.]digital asiadataintelligencelab[.]digital
MITRE ATT&CK Mapping
| MITRE ATT&CK Technique ID |
Technique Name |
Observed in SourTrade |
| T1583.001 |
Acquire Infrastructure: Domains |
Used more than 80 domains for phishing landing pages and runtime hosting. |
| T1036.005 |
Masquerading: Match Legitimate Name or Location |
Impersonated legitimate services such as TradingView, Solana, and Luno. |
| T1566 |
Phishing |
Used programmatic malvertising campaigns to redirect victims to fraudulent landing pages. |
| T1027 |
Obfuscated Files or Information |
Encoded the payload in Base64 and split it into multiple chunks within the /config response. |
| T1027.011 |
Fileless Storage |
Performed the entire payload assembly process in browser memory without storing the complete executable on disk. |
| T1204.002 |
User Execution: Malicious File |
Relied on the victim to execute the downloaded executable. |
| T1553.005 |
Subvert Trust Controls: Mark-of-the-Web (MotW) Bypass |
The MotW recorded only the landing domain and did not include the actual C2 server or CDN. |
| T1059.007 |
Command and Scripting Interpreter: JavaScript |
Used JavaScriptCore bytecode as the final-stage payload. |
| T1071.001 |
Application Layer Protocol: Web Protocols |
Retrieved the /config data and communicated with infrastructure over HTTPS. |
| T1102 |
Web Service |
Downloaded the Bun runtime from CDN-like external infrastructure. |
Traditional fileless malware still requires a stage loader running on the endpoint — PowerShell, WMI, or reflective injection. SourTrade pushes the entire assembly stage to the browser layer, leveraging valid Web APIs (ServiceWorker, SharedWorker, Web Crypto API, ReadableStream) to do so without the need for any malicious code to execute at the OS layer before the victim actively runs the file.
Practical consequence: if the SOC is relying on EDR alerts from write event files or AV signatures to detect inbound malware, then with SourTrade, that alert will never trigger. The file written to disk is the final result of the assembly process — and at that point, the file has a unique hash that has never appeared in any threat database.
This model is reusable. The same pipeline can be applied to any vertical that has software download traction: fintech, gaming, remote work tools. And very few organizations currently have enough browser-level telemetry to detect the SharedWorker-from-blob or /config-assembly-response pattern.
For the Vietnamese market: Vietnam is continuously in the top 10 countries with the highest crypto adoption rate globally (Chainalysis 2024-2025). Large trading community, many users of TradingView — target profile matches SourTrade. [NEEDS VERIFICATION: 12 target countries according to Confiant does not include Vietnam, but the campaign can expand or have SEA targeting variations]
Recommendation
Block domain IOC — priority
Threat Hunt — EDR testing:
Check download history of machines using TradingView, Solana, Luno — find .exe from strange .digital, .club, .info, .site domains.
Short-term (1-7 day)
Detection rule cho /config assembly pattern (Splunk SPL):
index=proxy OR index=network
| where uri_path="/config"
| eval suspicious=if(
match(response_body,"standaloneUrl")
AND match(response_body,"template")
AND match(response_body,"random"), 1, 0)
| where suspicious=1
| table src_ip, dest_domain, response_body
Chrome Enterprise policy restricts ServiceWorker:
Inform employees — especially finance team, trading desk, crypto desk: do not download software from advertisements.
Long-term
Browser telemetry: Implement Chrome Enterprise Reporting or MDE browser extension. Monitor SharedWorker creation from Blob URL and ServiceWorker registration from non-whitelisted origins.
CSP policy for internal apps: worker-src 'self' (no blob:) to prevent similar techniques if injected into an internal surface.
Download vetting: Requires verification hash from vendor official page before running any .exe downloaded from the web — breaking the attack chain at the end.
References
Malicious sites use JavaScript to build malware in browser memory
SourTrade: Browser-Assembled Malware Delivered Through Malvertising
Malicious Sites Use JavaScript to Build Malware in Browser Memory
