Placeholder Domain third-party[.]com Now Serves ClickFix Malware — Detection and Remediation Guide | Security Arsenal

Security researchers at Manifold Security have confirmed that third-party[.]com — a domain that has served as a generic documentation placeholder for years, the same role example.com plays — is now serving malicious content. According to Manifold's Head of Research, Ax Sharma, the domain is referenced across more than 1,700 repositories, and it is now delivering a ClickFix social-engineering lure to Windows browsers while presenting a harmless decoy page to everyone else.

This is not a vulnerability in the classic sense. There is no CVE, no patch, and no vendor advisory coming. The risk here is structural: thousands of README files, API docs, config templates, tutorials, and Stack Overflow answers tell developers to point integrations at third-party.com as a stand-in. Some of those developers — and the end users following those docs — actually click the link or curl the endpoint. That habit just became an initial access vector.

For defenders, the urgency is twofold:

ClickFix is one of the most effective initial-access techniques in active use today. It bypasses nearly every perimeter control because the user executes the payload — typically by pasting a malicious command into the Windows Run dialog after being told it will "verify" their browser or "fix" a rendering problem.
The exposure is embedded in your own documentation and codebase. If any of your internal docs, wikis, runbooks, or code samples reference third-party.com, your engineers are one copy-paste away from executing attacker-controlled content or browsing to a live lure.

This post breaks down how the attack works, how to hunt for it, and what to change today.

Technical Analysis

What Happened

third-party.com has been used informally for years as a placeholder domain in technical documentation — the way RFC 2606 reserves example.com for that purpose, except third-party.com was never reserved by anyone. It was simply a real, privately owned domain that the industry collectively treated as safe filler text.

As Manifold Security observed, the domain now behaves conditionally:

Windows visitors receive a ClickFix lure — typically a fake CAPTCHA, a "Verify you are human" page, or a browser-error dialog that instructs the victim to press Win+R, paste a pre-staged command (which the page has already written to the clipboard via JavaScript), and hit Enter.
Non-Windows visitors, crawlers, and scanners receive a harmless decoy page, which is a deliberate evasion tactic. User-agent and platform fingerprinting keeps the malicious payload away from Linux/macOS sandboxes, security scanners, URL detonation services, and research infrastructure.

This dual-persona delivery is significant for SOC teams: your secure web gateway's URL categorization engine and your threat intel provider's crawler likely both saw the decoy, which means the domain may still carry a benign or "uncategorized" reputation score in your tooling.

How the ClickFix Attack Chain Works

From a defender's perspective, the kill chain looks like this:

Lure delivery: Victim follows a link to third-party.com — from documentation, a README, a tutorial, a chat message, or search results. The page fingerprinting confirms a Windows browser.
Clipboard poisoning: Malicious JavaScript on the page silently writes a command string to the victim's clipboard (navigator.clipboard.writeText or legacy equivalents). The victim never sees this happen.
Social engineering: The page instructs the user to open the Run dialog (Win+R), paste (Ctrl+V), and press Enter — framed as a verification step, a fix, or a required plugin installation.
Execution: The pasted command is typically a mshta.exe call to a remote URL, or a powershell.exe / pwsh.exe command with -w hidden, -enc (Base64), and a download cradle (IEX, Invoke-WebRequest, curl.exe) that pulls a second-stage payload.
Staging: The second stage commonly deploys an infostealer (credential and session-token theft), a RAT, or a loader that hands off to a ransomware affiliate.

Why This Technique Is So Dangerous

No exploit required. The user is the execution engine. EDR tools see a user-initiated process tree: explorer.exe → mshta.exe or explorer.exe → powershell.exe, which looks benign in isolation.
It evades email security. The lure doesn't need to arrive by email. In this campaign, it rides on links that have been sitting in trusted documentation for years.
The domain's history works against defenders. third-party.com appears in over 1,700 repositories. Any blocklist rule, DLP signature, or detection you write that references it may collide with legitimate documentation strings — so network-layer blocking plus behavior-based detection is the right combination.
Conditional serving defeats retro-hunting by URL. Simply querying proxy logs for the domain tells you who visited; it doesn't tell you who got the lure. You need endpoint telemetry around clipboard/Run-dialog behavior to identify actual victims.

Exploitation Status

Confirmed active in the wild: Yes — the domain is live and serving the ClickFix lure to Windows browsers as of publication.
CVE / CVSS: None. This is a social-engineering and domain-abuse campaign, not a software vulnerability.
CISA KEV: Not applicable.
MITRE ATT&CK mapping: T1204 (User Execution), T1204.002 (Malicious File), T1059 (Command and Scripting Interpreter), T1059.001 (PowerShell), T1218.005 (Mshta), T1566.002 (Spearphishing Link), T1027 (Obfuscation).

Detection & Response

The most reliable detections for ClickFix do not key on the domain at all — they key on the behavioral signature: an interactive Windows process spawning mshta.exe, powershell.exe, or curl.exe with characteristics consistent with a pasted command (long single-line command lines, hidden windows, download cradles), combined with evidence in the Run dialog's MRU (most-recently-used) registry key.

Sigma Rules

YAML

---
title: ClickFix - Run Dialog Execution of LOLBin Download Cradle
id: 8f2a1c44-7b3e-4d9a-bf12-6c5e9a0d1e47
status: experimental
description: Detects mshta, powershell, or curl spawned directly by explorer.exe with command lines consistent with commands pasted into the Windows Run dialog, the hallmark of ClickFix social-engineering lures such as the third-party.com campaign.
references:
  - https://thehackernews.com/2026/09/placeholder-third-partycom-referenced.html
  - https://attack.mitre.org/techniques/T1204/
  - https://attack.mitre.org/techniques/T1218/005/
author: Security Arsenal
date: 2026/09/25
tags:
  - attack.execution
  - attack.t1204
  - attack.t1218.005
  - attack.t1059.001
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith: '\explorer.exe'
  selection_image:
    Image|endswith:
      - '\mshta.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\curl.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\rundll32.exe'
  selection_cmdline:
    CommandLine|contains:
      - 'http://'
      - 'https://'
      - ' -enc'
      - ' -e '
      - 'IEX'
      - 'Invoke-'
      - 'DownloadString'
      - 'Start-BitsTransfer'
      - ' -w hidden'
      - ' -windowstyle hidden'
  condition: selection_parent and selection_image and selection_cmdline
falsepositives:
  - Rare legitimate admin one-liners launched from the Run dialog
  - Software deployment tools using explorer-launched scripts (uncommon)
level: high
---
title: ClickFix - RunMRU Registry Entry Containing Script Interpreter or URL
id: 3d9e7b21-5a4f-4c68-9d31-2b8f6e0c4a59
status: experimental
description: Detects entries written to the Windows Run dialog MRU registry key that contain script interpreters, LOLBins, or URLs, indicating a user pasted and executed a command via Win+R as instructed by a ClickFix lure.
references:
  - https://thehackernews.com/2026/09/placeholder-third-partycom-referenced.html
  - https://attack.mitre.org/techniques/T1204/
author: Security Arsenal
date: 2026/09/25
tags:
  - attack.execution
  - attack.t1204
  - attack.t1112
logsource:
  category: registry_set
  product: windows
detection:
  selection_key:
    TargetObject|contains: '\Explorer\RunMRU'
  selection_value:
    Details|contains:
      - 'mshta'
      - 'powershell'
      - 'pwsh'
      - 'http://'
      - 'https://'
      - 'curl.exe'
      - 'cmd /c'
      - 'wscript'
      - 'rundll32'
  condition: selection_key and selection_value
falsepositives:
  - Administrators legitimately running one-off commands from the Run dialog
level: medium
---
title: Network Connection to third-party.com Placeholder Domain
id: 61c4f8a2-9d2b-4e57-a8c0-5f3b1d7e6c28
status: experimental
description: Detects process-initiated network connections to third-party.com, a former documentation placeholder domain confirmed to be serving ClickFix lures to Windows browsers while displaying decoy content to scanners.
references:
  - https://thehackernews.com/2026/09/placeholder-third-partycom-referenced.html
  - https://attack.mitre.org/techniques/T1071/001/
author: Security Arsenal
date: 2026/09/25
tags:
  - attack.command_and_control
  - attack.t1071.001
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationHostname|contains:
      - 'third-party.com'
  filter_legit:
    Image|endswith:
      - '\svchost.exe'
  condition: selection and not filter_legit
falsepositives:
  - Developers testing code samples that still reference the placeholder domain
  - Documentation link-checking tools
level: high

Analyst note on fidelity: Rule 1 is your highest-signal detection — explorer.exe directly spawning mshta.exe with a URL on the command line is rare in well-managed environments and almost always warrants a phone call to the user. Rule 3 will generate hits from developers whose code samples still contain the placeholder string; treat those as documentation hygiene findings, not incidents, but do not tune them away — each hit identifies a doc or repo that needs remediation.

KQL Hunt — Microsoft Sentinel / Defender

This query correlates the two sides of the campaign: network visits to the domain (via proxy/firewall CEF ingestion and Defender network events) and the behavioral execution pattern (explorer-spawned LOLBins with download cradles). Run both legs and join on device to find users who visited the lure and executed something shortly after.

KQL — Microsoft Sentinel / Defender

// Leg 1: Identify endpoints that resolved or connected to the malicious placeholder domain
let DomainHits =
    union isfuzzy=true
    (DeviceNetworkEvents
     | where RemoteUrl has "third-party.com" or RemoteIP in ("<resolved-ips-if-known>")
     | project DeviceId, DeviceName, TimeGenerated, InitiatingProcessFileName, RemoteUrl),
    (CommonSecurityLog
     | where RequestURL has "third-party.com" or DestinationHostName has "third-party.com"
     | project DeviceName=DeviceName, TimeGenerated, SourceIP, RequestURL);
// Leg 2: ClickFix execution pattern — explorer spawning LOLBins with download cradles
let SuspiciousExec =
    DeviceProcessEvents
    | where InitiatingProcessFileName =~ "explorer.exe"
    | where FileName in~ ("mshta.exe","powershell.exe","pwsh.exe","curl.exe","wscript.exe","cscript.exe","rundll32.exe")
    | where ProcessCommandLine has_any ("http://","https://"," -enc","IEX","Invoke-","DownloadString","-w hidden","-windowstyle hidden","Start-BitsTransfer")
    | project DeviceId, DeviceName, ExecTime=TimeGenerated, FileName, ProcessCommandLine, AccountName;
// Join: execution within 15 minutes of visiting the domain
DomainHits
| join kind=inner SuspiciousExec on DeviceId
| where abs(datetime_diff('minute', ExecTime, TimeGenerated)) <= 15
| project TimeGenerated, ExecTime, DeviceName, AccountName, RemoteUrl, FileName, ProcessCommandLine
| sort by DeviceName asc, ExecTime asc

For a broader sweep across endpoints that may have been lured from other ClickFix domains, run Leg 2 standalone over a 7–14 day window and baseline the results — ClickFix campaigns share the same execution fingerprint regardless of the lure domain.

Velociraptor VQL — RunMRU Forensic Hunt

The Run dialog MRU key persists evidence of what a user pasted and executed even after process telemetry rolls off. This artifact hunts it across the fleet, along with any live processes matching the ClickFix pattern.

VQL — Velociraptor

-- Hunt for ClickFix execution artifacts: RunMRU registry entries and live LOLBin processes
LET runmru = SELECT
    FullPath AS RegistryKey,
    { SELECT Name, Data FROM stat(filename=FullPath) } AS Entry,
    Data.value AS Command
FROM glob(globs='HKEY_USERS/*/Software/Microsoft/Windows/CurrentVersion/Explorer/RunMRU/*',
          accessor='registry')
WHERE Command =~ '(?i)(mshta|powershell|pwsh|curl\.exe|https?://|wscript|rundll32)'

LET procs = SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(mshta.+https?://|powershell.+(-enc|-w hidden)|curl\.exe.+https?://)'

SELECT * FROM runmru
UNION ALL
SELECT NULL AS RegistryKey, NULL AS Entry, format(format='%v -> %v', args=[Name, CommandLine]) AS Command FROM procs

Remediation / Hardening Script

This PowerShell script does three things: (1) blocks the domain at the endpoint via the hosts file as a compensating control until your DNS/proxy block is confirmed, (2) scans local user hives for RunMRU evidence of prior execution, and (3) searches common documentation locations for references to the placeholder domain so they can be corrected. Run it elevated; adapt the documentation paths to your environment.

PowerShell

# Security Arsenal - third-party[.]com ClickFix Response Script
# Run as Administrator. Review output before taking destructive action.

$Domain = "third-party.com"
$Report = "C:\Windows\Temp\ClickFix_Response_$(Get-Date -Format 'yyyyMMdd_HHmmss').log"

# --- 1. Endpoint-level block via hosts file (compensating control) ---
$hostsPath = "$env:SystemRoot\System32\drivers\etc\hosts"
$blockEntry = "0.0.0.0`t$Domain`t# Blocked: ClickFix lure - Security Arsenal"
if (-not (Select-String -Path $hostsPath -Pattern $Domain -Quiet)) {
    Add-Content -Path $hostsPath -Value $blockEntry
    "[+] Hosts file block added for $Domain" | Out-File $Report -Append
} else {
    "[=] Hosts entry for $Domain already present" | Out-File $Report -Append
}

# --- 2. Scan RunMRU hives for evidence of prior ClickFix-style execution ---
"`n[*] RunMRU findings:" | Out-File $Report -Append
Get-ChildItem 'HKU:\' -ErrorAction SilentlyContinue | ForEach-Object {
    $runMruPath = "Registry::$($_.Name)\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU"
    if (Test-Path $runMruPath) {
        $props = Get-ItemProperty -Path $runMruPath
        $props.PSObject.Properties | Where-Object {
            $_.Value -match '(?i)(mshta|powershell|pwsh|curl\.exe|https?://|wscript|rundll32)'
        } | ForEach-Object {
            "[!] $($_.PSPath.Split('::')[2]) -> $($_.Name) = $($_.Value)" | Out-File $Report -Append
        }
    }
}

# --- 3. Find documentation/code referencing the placeholder domain ---
"`n[*] References to $Domain in documentation/code (review and replace):" | Out-File $Report -Append
$searchRoots = @("C:\repos", "C:\docs", "$env:USERPROFILE\Documents") | Where-Object { Test-Path $_ }
foreach ($root in $searchRoots) {
    Get-ChildItem -Path $root -Recurse -Include *.md,*.txt,*.json,*.yml,*.yaml,*.xml,*.ps1,*.py,*.cfg,*.conf,*.ini -ErrorAction SilentlyContinue |
        Select-String -Pattern ([regex]::Escape($Domain)) -List |
        ForEach-Object { "[>] $($_.Path):$($_.LineNumber)" | Out-File $Report -Append }
}

"`n[*] Complete. Review: $Report" | Out-File $Report -Append
Write-Output "Done. Report: $Report"

Remediation

Because there is no patch for a social-engineering campaign, remediation is layered. Prioritize in this order:

1. Block the domain everywhere, today (network layer).

Add third-party.com (and www.third-party.com) to your DNS sinkhole, secure web gateway blocklist, and firewall egress rules. Given the conditional serving, do not rely on your URL categorization vendor's verdict — enforce the block manually.
Add the domain to your threat intel platform with a high-confidence malicious designation so it propagates to EDR network protection (Microsoft Defender SmartScreen/network protection, CrowdStrike, etc.).

2. Purge the placeholder from your own content (hygiene layer).

Search your internal wikis, runbooks, README files, code repositories, Confluence/SharePoint, and developer onboarding docs for third-party.com. Replace every occurrence with a properly reserved placeholder: example.com, example.org, or example.net (RFC 2606), or an internal domain you actually control and sinkhole.
Add a linting/CI rule (a simple grep in your pipeline) that fails any commit introducing third-party.com going forward. This prevents reintroduction.

3. Disrupt the ClickFix execution path (endpoint layer).

Where operationally feasible, restrict or alert on mshta.exe making outbound network connections — there is almost no legitimate business reason for it in 2026.
Consider disabling the Run dialog for standard users via Group Policy (User Configuration → Administrative Templates → Start Menu and Taskbar → Remove Run menu from Start Menu) on high-risk populations (executives, finance, developers' non-admin accounts). This breaks the most common ClickFix instruction set entirely.
Enforce PowerShell Constrained Language Mode or script block logging with ASR rules where possible; at minimum ensure Script Block Logging and Module Logging are enabled so any paste-executed cradle leaves a full-fidelity trail (Event ID 4104).

4. Hunt retroactively.

Run the KQL and VQL hunts above over at least the last 14 days. Any hit on the RunMRU rule or the explorer→LOLBin pattern requires user contact and, if confirmed, credential resets and session-token revocation — ClickFix second stages are overwhelmingly infostealers.
Review proxy logs for visits to the domain, then check whether those endpoints show the execution pattern within 15 minutes (the join in the KQL query does this).

5. Educate the specific population at risk.

Your developers and power users are the audience most likely to encounter this lure via documentation. A targeted advisory — "never paste a command from a webpage into the Run dialog, terminal, or PowerShell prompt, ever; no legitimate site requires this" — is the single highest-ROI control against the entire ClickFix technique family, not just this domain.

6. Watch for the next placeholder.

third-party.com is not the only informal placeholder in circulation. Audit your docs for other non-reserved stand-in domains and hardcoded URLs. Any placeholder domain that someone can register, buy, or let expire is a latent supply-chain landing pad. Reserved names (example.com, .test, .invalid, .example TLDs per RFC 2606/6761) are the only safe placeholders.

The Bottom Line

This incident is a supply-chain lesson wearing a social-engineering costume. A string that thousands of engineers treated as harmless filler became a weaponized delivery mechanism the moment its owner decided to monetize it. The technical detections above will catch the execution, but the durable fix is cultural and procedural: treat every domain referenced in your documentation as attack surface you don't control — unless it's RFC-reserved or it is yours.

If your team needs help hunting this across a large estate, or wants the detection content here tuned and deployed into your SIEM/EDR stack, reach out.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Placeholder Domain third-party[.]com Now Serves ClickFix Malware — Detection and Remediation Guide