A nonce is a password for script tags the server put there. It stops an injected tag that cannot guess the value. It does nothing once attacker code is already running in the page and can read the attribute off a legitimate script element, which is exactly what this stager does before it appends its assembled JavaScript to the DOM [7]. The fallback branch is the interesting one. Where there is no nonce to copy, the stager calls `Function()` [7], and that is the branch a policy without `unsafe-eval` actually blocks [15]. A strict nonce-only CSP removes the fallback and keeps the path the stager wins.
Network-side, the WebRTC variant deletes most of what a detection rule usually keys on. There is no signaling server, because the stager generates its own response to open the data channel [6]. So no DNS lookup and no STUN or TURN exchange appear, and there may be no saved file [11]. What remains is DTLS traffic from the browser to a hardcoded external IP and UDP port [11], both baked into the stager along with the ICE password and the DTLS certificate fingerprint [6]. It answers its own offer, which makes it the only signaling server that never has an outage. If your egress records do not already include browser UDP destinations, you have no history to search.
On the site itself the checks are code appended to the end of legitimate JavaScript files, fake plugin directories, and JSON-RPC requests to the BSC Testnet RPC [9]. Note where that last one lives. The loader runs in the visitor's browser and issues the `eth_call` from there [4], so the RPC artefact shows up in client egress or in the injected script text, not in the compromised server's access log [17].
The 5,400 figure is someone else's telemetry: the dev.to summary attributes the report to BleepingComputer, dated 2026-09-05, with Netskope Threat Labs and its IOC repository listed as related sources [2], covering over 5,400 sites pulling next-stage components from BSC Testnet contracts [1]. For it to say anything about your estate, three things have to hold, and they are the same preconditions the source lists: your sites run WordPress or PrestaShop with somewhere an attacker can drop a loader disguised as a package [3], your visitors' browsers can reach the BSC Testnet RPC and the attacker contract, and outbound traffic to the specified IP and UDP port is permitted [13].
One thing the material does not claim is that the storage cannot be removed. It never calls the contracts immutable or the content untakedownable; it treats RPC reachability as a precondition and recommends blocking BSC Testnet RPC groups that no business function needs [16]. That is a routing answer rather than a takedown answer, and it cuts both vectors at the same joint. The alternative is chasing the ClickFix side, where the final payload is not fixed [5] and the initial compromise method has not been disclosed [3], so a cleaned site can be reinfected by whatever got in the first time.
