Third-party[.]com, usado por desarrolladores como placeholder en código y tutoriales, fue registrado por atacantes y ahora distribuye payloads de PowerShell sin detección.
Manifold Security descubrió que el dominio third-party[.]com — utilizado habitualmente por desarrolladores web como sustituto genérico en ejemplos de código y documentación técnica — está sirviendo malware mediante ataques ClickFix dirigidos a máquinas Windows. A diferencia de example.com o example.org, que están reservados por IANA (Internet Assigned Numbers Authority) y no pueden ser registrados por terceros, third-party[.]com nunca fue protegido de esta manera. Alguien lo registró, y ahora cualquier empresa o desarrollador que haya seguido literalmente un tutorial o copiado un fragmento de código con ese dominio está enviando tráfico hacia infraestructura maliciosa. El dominio fue reportado a su registrador, Network Solutions, pero al momento de esta publicación sigue activo.
Cómo funciona el ataque que elude las defensas tradicionales
El sitio imita un check de verificación humana de Cloudflare — el típico «are you human?» que aparece antes de acceder a ciertos servicios. Cuando el usuario interactúa con la página, el malware envenena el portapapeles del sistema y despliega instrucciones que le piden presionar Win+R (el comando de ejecución rápida de Windows) y pegar el contenido. Lo que el usuario pega no es lo que ve en pantalla: es un comando de PowerShell que descarga y ejecuta un payload remoto sin ser detectado por las soluciones de seguridad convencionales.
La técnica ClickFix no es nueva — lleva al menos dos años en circulación con distintos señuelos — pero su efectividad está en ascenso. Según el último reporte de amenazas de ESET Security, las detecciones de ClickFix aumentaron 108 por ciento entre la segunda mitad de 2025 y la primera mitad de 2026. El reporte anterior había mostrado un salto de 517 por ciento. La curva de adopción por parte de atacantes es sostenida, y el uso de dominios que parecen legítimos por contexto — como third-party[.]com en documentación técnica — amplifica el radio de exposición.
Por qué un placeholder de documentación termina siendo vector de ataque
Los desarrolladores usan dominios como third-party[.]com en ejemplos de integración con APIs externas, configuraciones de CORS, políticas de CSP (Content Security Policy) o cualquier escenario donde se necesita representar un servicio de terceros sin nombrar uno real. La práctica es común en tutoriales, repositorios de código abierto y documentación interna de empresas. El problema es que, a diferencia de los placeholders oficiales reservados por IANA, third-party[.]com siempre estuvo disponible para registro público. Nadie lo protegió, y eventualmente alguien lo compró con intenciones maliciosas.
Esto significa que cualquier fragmento de código copiado sin revisión, cualquier configuración de prueba que pasó a producción sin cambiar el dominio de ejemplo, o cualquier empleado que siguió un tutorial paso a paso sin cuestionar la URL, puede haber terminado conectándose a infraestructura controlada por atacantes. No hay datos públicos sobre cuánto tráfico legítimo recibió el dominio antes de ser reportado, pero el hecho de que haya permanecido activo el tiempo suficiente para ser descubierto por una firma de seguridad sugiere que el volumen no fue despreciable.
Exposición en América Latina por dependencia de documentación en inglés
En América Latina, donde gran parte del desarrollo de software se apoya en documentación técnica en inglés — especialmente tutoriales de plataformas como Stack Overflow, GitHub o blogs de desarrolladores — la probabilidad de que equipos hayan usado third-party[.]com sin cuestionarlo es estructuralmente alta. No hay evidencia de que el ataque haya sido dirigido específicamente a la región, pero la dependencia de recursos externos sin validación local amplifica la superficie de exposición. Empresas en México, Brasil, Argentina y Colombia que adoptaron prácticas de DevOps aceleradas en los últimos dos años, muchas veces sin equipos de seguridad embebidos en el ciclo de desarrollo, son candidatas naturales a haber incorporado este tipo de referencias sin revisión.
El patrón se repite: la velocidad de adopción de tecnología en la región supera la madurez de los controles de seguridad en desarrollo. Un dominio que parece inofensivo porque aparece en un tutorial de integración con servicios externos termina siendo un punto ciego que nadie revisa hasta que el incidente ya ocurrió.
Qué falta para que este tipo de vector deje de ser viable
El reporte a Network Solutions no garantiza que el dominio sea dado de baja de inmediato — los procesos de registradores pueden tardar días o semanas, y mientras tanto el sitio sigue sirviendo malware. Más allá de este caso puntual, el problema de fondo es que no existe un estándar técnico que obligue a los desarrolladores a usar únicamente placeholders reservados por IANA. La práctica de inventar dominios de ejemplo sin verificar su disponibilidad es común, y la ausencia de validación automática en pipelines de CI/CD permite que esos dominios lleguen a producción.
ESET documentó el crecimiento sostenido de ClickFix, pero no hay indicios de que las defensas tradicionales estén cerrando la brecha. El ataque funciona porque explota comportamiento humano — la confianza en que un comando que aparece en un tutorial es seguro — y porque el payload de PowerShell se ejecuta sin tocar disco, evadiendo firmas de antivirus. Mientras el vector siga siendo efectivo y los atacantes puedan registrar dominios que parecen legítimos por contexto, la técnica va a seguir escalando.
Nuestro análisis
Este caso revela un patrón que ya vimos en otros incidentes de supply chain indirecto: la confianza implícita en recursos externos que nadie valida porque «siempre estuvieron ahí». Third-party[.]com no es un typosquatting de un dominio conocido — es un placeholder que los desarrolladores asumieron como neutral, de la misma manera que asumen que example.com es seguro. La diferencia es que example.com está protegido por diseño, y third-party[.]com nunca lo estuvo. El salto de 517 por ciento en detecciones de ClickFix en un período, seguido de otro 108 por ciento en el siguiente, no es ruido estadístico: es adopción acelerada de una técnica que funciona porque las defensas no están diseñadas para bloquear lo que parece legítimo por contexto.
Lo que todavía no sabemos es cuántos otros dominios de placeholder no reservados están en la misma situación — registrados por atacantes, esperando a que alguien siga un tutorial sin revisar la URL. La práctica de usar dominios inventados en documentación técnica es tan extendida que mapear todos los casos posibles es inviable. ¿Cuántos fragmentos de código en producción están apuntando a dominios que parecen ejemplos pero ya no lo son?