← whack.sh News

Brevo delivered KongTuke ClickFix to 51 customer sites

2026-09-17 · Threat Research

Brevo's own delivery infrastructure served malicious JavaScript to 51 customer page domains on September 14, 2026. The injected code drew a fake Cloudflare verification panel and walked visitors through a ClickFix sequence ending in a command shell. The window ran from 16:05 to 20:12 UTC, and by the following day every loader hostname it used had stopped resolving.

Kirk of ADAMnetworks published the technical analysis. Whack.sh took part in the shared investigation.

How the attack works

Two files Brevo serves to its customers carried appended code. The SDK loader at cdn.brevo[.]com/js/sdk-loader.js went from a clean 3,442 bytes to 3,615 or 3,616. The Sibforms bundle at sibforms[.]com/forms/end-form/build/main.js went from a clean 461,411 bytes to 461,584 or 461,585. The one-byte spread is the loader hostname: a page served by cdn11 carries a longer label than one served by cdn2. If you are checking a capture against these numbers, both values are modified.

The appended code is a script tag pointing at a loader host under sendibt1[.]com. That domain is the reason this reached so far: Brevo lists it among its own technical domains, so it is a name a customer following Brevo's own integration guidance would already have allowed. This was delivery through a vendor's genuine infrastructure, and a site owner reviewing their network log would have seen nothing out of place.

The panel the code drew imitated a Cloudflare verification step. It instructed visitors to press Win+R, then Ctrl+V, then Enter. The clipboard carried a command built around conhost.exe --headless and curl, piped into cmd.exe.

What the command retrieved is unknown. Every captured request to the four download servers returned an empty HTTP 444, and a Joe Sandbox run that executed the command on Windows 10 at 18:34:33 recorded the same thing. The tokens are single use: the servers answered the victim and nobody else. Anyone who completed the paste got a payload, and it was not captured.

The panel was served in an iframe requesting fullscreen and clipboard-write permissions, and carried a proof-of-work challenge before it would render. It reported telemetry events named vclick and copy_fail, so the operators were measuring how many visitors completed the paste and how many gave up.

Built ahead of time, and torn down fast

The certificate record dates the buildout well before the attack. Kirk's analysis records a certificate for cdn.sendibt1[.]com issued on August 25, twenty days ahead, and a wildcard for *.sendibt1[.]com on September 8. Certificates for cdn9, cdn10 and cdn11 were issued on September 14 between 16:09 and 16:12 UTC, four minutes after the window opened: capacity added while the campaign was already running.

Seven loader hosts served the campaign. By September 15 all seven returned NXDOMAIN. The whole operation lasted about four hours.

A separate thread in the same research connects the operator to MintsLoader, and it is worth being precise about the distance. The four download servers share a naming scheme with hosts that a MintsLoader sample from September 9 queried. That earlier sample reached a staging host, jg2n36pxkqjfqp7[.]top, and DNS and hosting records tie that host to 97 domains across three addresses on BL Networks' AS399629, all using 15-character lowercase labels under .top. That estate hangs off the September 9 staging host, not off the sendibt1 loaders: it is the same operator by inference, on different infrastructure.

How to stay safe

Treat any instruction to copy a command and paste it into the Run box, PowerShell, or Terminal as the attack itself. A verification step that asks you to run something is a lure. Cloudflare's real challenge never asks you to paste a command.

  • Close the tab. Nothing is repaired by completing the step.
  • If you already ran it, treat the machine as compromised and change passwords from a different device.

For teams running a site that loads third-party JavaScript:

  • Subresource Integrity on vendor scripts turns a modified file into a blocked file. It is the direct control for this attack, and it costs an attribute. A Content-Security-Policy would not have helped here: the malicious host was a domain the vendor documents, so a correctly written policy already trusted it.
  • Compare your vendor bundles against known-clean byte counts. Both modified sizes above differ from clean by fewer than 200 bytes in a 461 KB file.
  • Watch endpoints for a shell spawned shortly after browser activity, and specifically for conhost.exe --headless.
  • Certificate transparency carried the first record of this infrastructure, three weeks early. Watching CT for new names under your vendors' domains is cheap, though be honest about what it buys: a new cdn subdomain on a domain the vendor already documents is routine, so August 25 would have been a row in a log rather than an alarm. Its value here is retrospective, which is how the timeline above was built.

Credit and sources

The research and the writeup are Kirk's, at ADAMnetworks, published September 16, 2026. The report thanks Daniel Jones of Tuxxin LLC, who took part using Whack.sh, and Emiliano of The Matrix Project, for their work on the infrastructure records.