Placeholder domains can become ClickFix delivery paths at runtime

At a glance

What this is: This is a runtime-abuse case where a long-used placeholder domain was turned into a ClickFix delivery page for Windows users while remaining benign to other visitors.

Why it matters: It matters because docs, skills, and MCP content often hardcode example endpoints that can become live attack surfaces if the domain is not reserved or controlled.

Context

A documentation placeholder is only safe if it is reserved, controlled, or treated as disposable. When teams hardcode a plausible external domain into skills, docs, or integration examples, they create a trust assumption that can fail later when the domain changes hands or starts serving different content. That becomes an identity and access problem when agents, users, or tooling fetch and execute what the domain returns.

In this case, the risk sits at the intersection of NHI governance and runtime content trust. The article shows how a static URL embedded in public skills and MCP-server documentation can become active attacker infrastructure without any change in the consuming file. The result is a supply chain style exposure where the reference is stable but the target is not.

The key distinction is that the content looked harmless in static review but became hostile at request time. That makes MCP security relevant because the trust boundary is not the file alone, but the external endpoint the file causes an agent or user to contact.

Key questions

Q: What breaks when a documentation placeholder domain is no longer reserved?

A: The trust assumption breaks. A placeholder that used to be harmless can start serving attacker content, and every skill, doc, or integration example that hardcoded it now points users or agents at infrastructure you do not control. That turns a static reference into a runtime dependency and creates exposure without any visible change in the consuming file.

Q: Why do placeholder domains become risky in AI agent and MCP workflows?

A: Because those workflows often dereference URLs automatically, without a human stopping to inspect the destination. If the domain is not reserved and can be repurposed, the agent may fetch attacker content while the source file still looks legitimate. That is a governance problem, not just a phishing problem.

Q: How should security teams stop ClickFix attacks before the user reaches the endpoint?

A: Teams should focus on browser-layer controls that detect suspicious paste events, fake verification pages, and malicious command prompts before execution begins. That approach reduces dependence on EDR alone and gives defenders a chance to intervene before the user runs code that the browser and endpoint may interpret as legitimate interaction.

Q: Should teams allowlist domains that were once used as documentation examples?

A: Only if they are reserved, owned, and verified as permanently safe. If a domain is merely convenient or widely copied, allowlisting it can hide a future takeover or content change. The safer approach is to remove the reference or replace it with a reserved documentation domain.

Technical breakdown

Why placeholder domains become malicious dependencies

A placeholder domain behaves like a dependency when code, docs, or skills treat it as a real endpoint. If the domain is not reserved for documentation, anyone who registers or repurposes it can change what it serves without changing the consuming file. That creates a hidden trust boundary: the text looks inert, but the runtime request reaches infrastructure the author does not control. In identity terms, the consumer inherits the domain's state at request time, not at publication time. The failure is not just bad hygiene. It is an ownership gap between published content and the endpoint that content instructs a system to trust.

Practical implication: Treat non-reserved placeholder domains as governed external dependencies and inventory every place they appear.

How ClickFix turns the browser into the delivery mechanism

ClickFix is a social engineering chain that makes the victim run the payload. The page shows a fake verification prompt, silently writes a command to the clipboard, then instructs the user to open the Windows Run dialog and paste it. That bypasses many file-based detections because the command is executed by the user in a trusted shell, often using signed native tools such as PowerShell. The technique works especially well against Windows fleets because the attack path relies on user execution rather than malware delivery. The security problem is not the lure page alone. It is the combination of browser interaction, clipboard abuse, and native execution on the endpoint. See the Phishing Guide.

Practical implication: Harden Windows user-execution paths and monitor clipboard-to-shell abuse, not just downloaded binaries.

Why operating-system gated payloads defeat simple scanning

The domain behaves differently based on the visitor's user-agent, serving a benign decoy to some clients and a ClickFix lure to Windows users. That means reputation checks, sandbox crawlers, and casual reviews can all miss the malicious path if they do not present the right client profile. Static analysis sees one page, but the real victim sees another. This is a delivery pattern, not merely cloaking for novelty. It defeats controls that assume a single canonical response for every request and shows why runtime validation matters when web content is personalized by client characteristics. See the Infostealer Threat Guide.

Practical implication: Use multi-profile request simulation and treat client-gated content as suspicious until it is validated under victim-like conditions.

Threat narrative

Attacker objective: The attacker wants the victim to execute a remote PowerShell payload on a Windows endpoint and create a foothold for follow-on compromise.

1. Entry began when a user or agent followed a hardcoded placeholder domain that now resolved to attacker-controlled content.
2. Credential or command access followed when the page copied a PowerShell payload into the clipboard and induced Windows Run execution.
3. Impact came from remote script execution on the endpoint, creating a path to malware delivery or further compromise.

Breaches seen in the wild

• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static placeholder domains are now a governed identity risk, not a documentation convenience. When a skill, doc, or config hardcodes a non-reserved domain, the control assumption is that the endpoint will remain harmless. That assumption fails the moment the domain changes ownership or content, because the consumer has no way to distinguish a safe placeholder from attacker infrastructure at runtime. The implication is that teams must treat documentation endpoints as part of the trust model, not as throwaway text.

Runtime trust collapses faster than static review can detect it. This case shows that a file can remain unchanged while the domain it references becomes malicious. That creates a gap between content governance and execution governance, especially in AI-adjacent workflows where skills and MCP servers automatically dereference URLs. The named concept here is placeholder dependency drift: a stable reference whose security meaning changes after publication. Practitioners need to recognise that drift as a lifecycle problem, not a one-time review failure.

ClickFix works because it weaponises user execution, not malware delivery. The page does not need to drop an executable to create compromise conditions. It only needs to drive the user into a trusted shell with an attacker command already staged on the clipboard. That shifts the relevant control from download scanning to runtime interaction monitoring, which is where many endpoint programmes are still weakest.

Operationally trusted examples are a supply chain surface. Public skills, MCP documentation, and repository samples often borrow the same placeholder patterns across teams and ecosystems. Once one of those placeholders becomes live infrastructure, every copied example inherits that exposure. The lesson is not to ban examples, but to govern which examples are reserved, which are owned, and which are never safe to externalise.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: MCP Security Guide

What this signals

Teams should start treating documentation endpoints as mutable trust dependencies. Once a placeholder domain can be repurposed, the security question is no longer whether the text is benign, but whether the runtime destination can still be trusted when a browser, agent, or shell actually follows it.

The broader governance signal is that runtime validation now needs to sit beside static review. Static checks can confirm that a skill or doc contains a harmless-looking URL, but they cannot prove what the endpoint serves to a Windows client at execution time.

This is where identity authentication and endpoint governance intersect: if an automated system is allowed to fetch and act on external references, the organisation needs policy for which references are reserved, which are controlled, and which are never acceptable to embed.

For practitioners

• Inventory non-reserved placeholder domains Scan skills, MCP docs, test fixtures, and internal documentation for domains that look disposable but are not reserved for documentation use. Classify each one by ownership, registration status, and whether it is still referenced in published material.
• Replace squattable examples with reserved domains Use example.com, example.org, or example.net for published documentation and teaching material instead of plausible third-party-looking domains. Keep any real external endpoint under explicit governance and removal review.
• Validate web content from victim-like clients Test suspicious domains from Windows and non-Windows user-agents, not just from crawler infrastructure, so client-gated payloads do not pass as benign. Include clipboard, browser, and shell interaction paths in the validation workflow.
• Treat clipboard-to-shell execution as telemetry Monitor for browser-driven clipboard changes followed by Run dialog or shell execution, especially when the source is a verification page or documentation link. Those sequences are common in ClickFix delivery and deserve detection logic.
• Avoid allowlisting unowned domains Do not suppress alerts simply because a domain once looked like a placeholder. If you do not control the domain and cannot guarantee its current behaviour, it should stay visible to security review.

Key takeaways

• A placeholder domain can become a live attack surface when it is not reserved and later resolves to attacker-controlled content.
• The article shows a Windows-specific ClickFix chain that relies on clipboard poisoning and native shell execution rather than a downloadable payload.
• Governance needs to cover documentation endpoints, runtime validation, and client-specific testing, not just static scanning.

Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · Third-Party, B2B and Contractor Access Guide · Phishing Guide

Key terms

• Placeholder Domain Drift: The security change that happens when a domain used as an example or stand-in stops behaving like a harmless placeholder. In practice, the same string can keep appearing in code or documentation while the destination behind it changes ownership, content, or intent, creating runtime risk that static review will miss.
• ClickFix: A browser-delivered social engineering technique that persuades a user to paste and execute a malicious command, usually through clipboard manipulation and a fake instruction sequence. The key risk is that the endpoint may see a normal user action even though the payload originated from a hostile webpage.
• Client-Gated Payload: Malicious content that is only shown to a specific client profile, such as a Windows browser or a particular user-agent. The same URL can return a harmless decoy to scanners and a weaponised page to real victims, which makes basic reputation checks unreliable.
• Device Trust Boundary: The device trust boundary is the point where an endpoint is considered sufficiently verified to access systems, data, or services. It defines the security line between trusted and untrusted device states, based on posture, identity, integrity, and policy. In practice, it governs whether a device can authenticate, connect, or receive sensitive access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.