Placeholder Domain "third-party.com" Now Serves ClickFix Attacks
The domain “third-party.com,” long treated as a benign placeholder in developer documentation, now hosts malicious ClickFix attacks. What used to be a harmless stand-in in countless code examples has quietly turned into a live security risk for Windows users.Developers frequently use “third-party.com” as a generic name for external services, similar to how IANA-reserved domains like “example.com” work. The difference is that “third-party.com” is an actual registered domain, not a protected placeholder, which means its content is fully controllable by whoever owns it. Security firm Manifold Security first reported its malicious use.

How the Attack Works

The domain now serves a fake Cloudflare verification page that impersonates a routine security check. It instructs Windows users to run PowerShell commands, using a technique known as ClickFix that relies entirely on tricking the user rather than exploiting a software flaw.

After clicking a “Verify you are human” box, the site secretly copies a malicious PowerShell command to the user’s clipboard. The page then prompts them to paste and run it. Because the malware installs through direct user action rather than a hidden exploit, it slips past traditional antivirus defenses that are built to catch code execution, not social engineering.

Documentation Turned the Placeholder Into a Trap

The core problem is how often “third-party.com” shows up in respected technical documentation. The W3C Geolocation specification uses it in its iframe permission examples, and Chromium’s Telemetry Extension API documentation features it in its code snippets too.

Developers have copied these examples directly into live projects over the years. One old Stack Overflow answer from 2015 shows a developer copying an asynchronous loading example that used the domain verbatim. Each copy-paste created another path for the attack to eventually reach a live application or test environment.

The Payload Is Currently Offline

At the time of testing, the payload URL elxxvvx[.]xyz/f no longer resolved, which currently breaks the attack chain. A VirusTotal scan from May 2026 showed the site distributing a PowerShell script configured to download a 131MB zip archive.

The original domain was registered back in 1996, and there’s no evidence it was registered for malicious intent. It remains unclear when or how control of the site changed hands. According to Manifold’s Ax Sharma, the attack specifically targets Windows users. Linux and Mac visitors instead receive an “operating system is unsupported” message.

Why This Keeps Happening

The incident highlights a gap that’s been sitting in plain sight for years. IANA reserves domains like “example.com” specifically to prevent this kind of hijacking, but “third-party.com” was never given that protection since it looked like a generic descriptor rather than something worth reserving.

No confirmed reports currently link these documentation references to actual ClickFix infections. But the domain remains live and fully under someone else’s control.

  • Its content could switch to a new active payload at any time
  • Any developer who copied the placeholder URL years ago may still have it embedded somewhere
  • Standard code review rarely flags an iframe pointing at “third-party.com” as suspicious

Hashlytics Take

The scary part isn’t the malware itself, since that got neutralized once the payload URL died. It’s how many codebases probably still reference this domain without anyone remembering why.

Documentation examples get copied once and then live in production for a decade, invisible until something like this forces a second look. If your team has ever grabbed a Geolocation or iframe snippet from Stack Overflow or official docs without swapping the placeholder, this is worth an actual grep through your codebase, not just a mental note.

Follow Hashlytics on Bluesky, Facebook, LinkedIn , Telegram and X to Get Instant Updates