Open source y phishing masivo: qué pasó

Un proyecto open source no solo puede ser útil para la comunidad. También puede convertirse en una pieza de infraestructura para fraude, si alguien lo toma, lo empaqueta o lo usa como fachada para engañar a usuarios reales. Eso fue lo que pasó en el caso que inspira este artículo: un proyecto legítimo terminó siendo parte de una campaña de phishing que alcanzó a 14.000 personas.

El punto no es solo que alguien “abusó” de software libre. El punto es más incómodo: cuando publicas código, documentación y artefactos reutilizables, también estás publicando confianza. Y esa confianza se puede copiar, clonar y poner al servicio de una campaña maliciosa sin que tú te enteres a tiempo. La historia completa está contada por Andrej Karpathy en su blog personal, donde explica cómo descubrió que su proyecto había sido usado para phishing: https://andrej.sh/posts/phishing-through-my-open-source-project

Qué pasó y por qué importa

El caso parte de un proyecto open source que, en principio, no estaba pensado para estafar a nadie. Alguien tomó esa base, la adaptó y la usó para montar una experiencia convincente de phishing. El resultado fue una campaña a escala: 14.000 personas terminaron expuestas a un flujo diseñado para robar credenciales o datos sensibles.

La cifra importa porque rompe una idea cómoda: que el abuso de un proyecto pequeño o especializado solo afecta a unos pocos. No. Si el proyecto resuelve una pieza concreta de automatización, autenticación, formularios, plantillas o despliegue, puede convertirse en un componente de una operación masiva. En phishing, la escala no depende tanto de la originalidad del ataque como de lo fácil que sea replicarlo.

También importa porque este tipo de abuso no siempre se ve como un ataque a la cadena de suministro en el sentido clásico. No hablamos necesariamente de malware inyectado en un paquete npm o de una dependencia comprometida. A veces el problema es más simple y más difícil de detectar: alguien reutiliza el proyecto como infraestructura, le cambia la cara y lo pone a trabajar para un fraude.

La diferencia entre uso legítimo y abuso

Open source se publica para que otros lo usen, lo estudien y lo modifiquen. Esa es la gracia. Pero esa misma apertura hace que el límite entre reutilización legítima y abuso sea difuso. Si publicas una plantilla para autenticación, un panel de administración, un bot o un flujo de onboarding, un atacante puede copiar el diseño, la lógica o incluso el repositorio completo para montar una página falsa más creíble.

En este caso, el problema no fue que el código fuera inseguro por sí mismo. El problema fue que la reputación del proyecto ayudó a dar legitimidad a una campaña fraudulenta. Para el usuario final, ver una interfaz conocida o un flujo parecido reduce la sospecha. Para el atacante, eso mejora la tasa de conversión.

La lección es directa: cuando un proyecto gana tracción, deja de ser solo código. También pasa a ser una señal de confianza. Y las señales de confianza son exactamente lo que el phishing intenta copiar.

Cómo un proyecto open source se convierte en infraestructura de fraude

No hace falta que el atacante comprometa el repositorio original. Le basta con entender qué parte del proyecto aporta valor: el frontend, la lógica de validación, la apariencia, la automatización de formularios, la integración con servicios externos o el flujo de redirección. Después puede replicar eso en un entorno controlado por él.

Hay varias rutas comunes. Una es clonar el proyecto y modificarlo mínimamente para que parezca una copia legítima. Otra es reutilizar componentes, estilos o incluso documentación para que la víctima vea una experiencia familiar. También puede ocurrir que el proyecto original tenga una demo pública, un ejemplo funcional o una plantilla fácil de desplegar. Todo eso reduce la fricción para el atacante.

La parte más delicada es que el abuso no siempre deja una huella obvia en el repositorio original. Tú puedes revisar issues, pull requests y releases y no encontrar nada raro. Pero tu proyecto ya fue absorbido por un tercero que lo está usando como base para una operación de engaño. Eso obliga a pensar en seguridad más allá del código fuente.

Señales técnicas que deberían ponerte en alerta

Si mantienes un proyecto con adopción real, hay patrones que conviene monitorear. No porque indiquen siempre abuso, sino porque suelen aparecer cuando alguien está intentando convertir tu trabajo en algo más turbio.

1. Aparición de forks o mirrors con cambios mínimos y despliegues rápidos.
2. Uso del mismo nombre visual, colores, copy o estructura de navegación para simular legitimidad.
3. Repositorios o sitios que copian readmes, screenshots o assets sin atribución clara.
4. Dominios parecidos al original, con typos o TLD distintos.
5. Picos de tráfico desde regiones o referers que no encajan con tu audiencia habitual.
6. Reportes de usuarios que dicen haber visto una versión “igual” a la tuya en un contexto sospechoso.

No necesitas ver las seis señales a la vez para actuar. Con una sola, ya vale la pena investigar. En seguridad operativa, esperar confirmación total suele ser tarde.

Una tabla simple para distinguir uso legítimo de abuso

Qué deberían vigilar mantenedores y equipos de seguridad

Si mantienes un proyecto, no puedes controlar cómo lo usa todo el mundo. Pero sí puedes reducir el abuso, detectarlo antes y responder mejor. El enfoque no es paranoico. Es operativo.

Primero, define qué partes de tu proyecto son más fáciles de copiar para montar una experiencia falsa. Puede ser una pantalla de login, un formulario de recuperación, una plantilla de onboarding o una página de pago. Si sabes cuál es la superficie de abuso, puedes priorizar alertas y documentación.

Segundo, piensa en observabilidad. Si tu proyecto tiene hosting propio, una demo o una API, registra métricas básicas: dominios de origen, volumen de accesos, países, user agents y patrones de errores. No necesitas un SIEM caro para empezar. A veces un dashboard sencillo ya te permite detectar que alguien está automatizando algo con tu marca.

Qué revisar en los primeros 30 minutos

Cuando sospechas que tu proyecto está siendo usado en phishing, estos pasos te ayudan a ordenar la respuesta:

1. Verifica si existe un fork, mirror o despliegue que copie tu proyecto.
2. Revisa si hay dominios parecidos al tuyo en WHOIS, DNS o buscadores.
3. Busca capturas, videos o posts donde aparezca tu interfaz fuera de contexto.
4. Comprueba si tus assets están siendo reutilizados sin permiso.
5. Identifica si el abuso afecta solo reputación o también credenciales, tokens o datos.
6. Documenta fechas, URLs, screenshots y hashes de archivos si los tienes.

Con esa información ya puedes decidir si conviene avisar a tu comunidad, contactar al hosting, abrir un reporte de abuso o escalar a tu equipo legal o de respuesta a incidentes.

Cómo reducir el daño sin matar la apertura

No hace falta cerrar el proyecto ni volverlo opaco. De hecho, eso suele castigar a los usuarios legítimos más que a los atacantes. Lo que sí puedes hacer es endurecer algunas piezas.

Por ejemplo, añade marcas de agua discretas en demos públicas, usa dominios oficiales claros, publica firmas o checksums de releases y documenta cómo verificar artefactos. Si tu proyecto incluye plantillas de UI o páginas de autenticación, deja explícito qué elementos son tuyos y cuáles no deben reutilizarse para suplantación. No va a detener a todos, pero sí sube el costo del abuso.

También ayuda tener un canal de reporte visible para uso fraudulento. Un correo o formulario para abuse reports puede parecer trivial, pero acelera la respuesta. Si alguien detecta que tu proyecto aparece en una campaña de phishing, no debería tener que adivinar a quién escribir.

Lo que este caso dice sobre supply chain y confianza

Cuando hablamos de supply chain security, muchas veces pensamos en dependencias comprometidas, paquetes maliciosos o credenciales filtradas en CI/CD. Todo eso sigue siendo real. Pero este caso te obliga a ampliar el mapa: la cadena de suministro también incluye la confianza que genera tu proyecto en la mente de quien lo ve.

Un atacante no siempre necesita insertar código en tu release. A veces le basta con usar tu nombre, tu interfaz o tu documentación como cebo. En otras palabras, la supply chain no termina en el artefacto. Sigue en la percepción del usuario y en la facilidad con la que alguien puede replicar tu trabajo.

Eso afecta tanto a mantenedores individuales como a equipos de seguridad en empresas que dependen de open source. Si tú usas proyectos externos en producción, no solo deberías auditar dependencias. También conviene saber cómo se presentan esos proyectos al público, qué superficie de imitación ofrecen y si ya han sido asociados a abuso en el pasado.

Qué puede hacer un equipo de seguridad en una empresa

Si trabajas en defensa, no te quedes solo con SBOMs y escáneres de vulnerabilidades. Úsalos, claro, pero agrega una capa de inteligencia sobre reputación y abuso.

• Monitorea menciones de los proyectos críticos en reportes de fraude o phishing.
• Revisa si el proveedor o mantenedor publica avisos de abuso o dominios falsos.
• Evalúa si la experiencia de usuario del proyecto es fácil de clonar para engañar a empleados o clientes.
• Incluye en tus playbooks la posibilidad de que una herramienta legítima sea usada como fachada por terceros.

Esto es especialmente útil en equipos de soporte y fraude, donde muchas veces la primera alerta no llega desde ingeniería, sino desde un usuario confundido o un cliente que recibió un correo sospechoso.

Qué puedes aprender si mantienes un proyecto open source

Si tú mantienes software abierto, este caso no debería leerse como una invitación a cerrar todo. Debería leerse como una razón para diseñar mejor la confianza. La apertura sigue siendo buena, pero ya no alcanza con publicar código limpio y esperar buena fe.

Te conviene pensar en tres capas: identidad, rastreo y respuesta. La identidad incluye tu dominio, tus firmas, tus releases y tu documentación oficial. El rastreo incluye métricas, reportes, menciones y alertas. La respuesta incluye qué haces cuando alguien usa tu proyecto para engañar a otros.

Si quieres una referencia práctica sobre cómo manejar vulnerabilidades y reportes en proyectos abiertos, la documentación de GitHub sobre security advisories es un buen punto de partida: https://docs.github.com/en/code-security/security-advisories. Y si tu proyecto distribuye paquetes, también vale la pena revisar las guías oficiales del ecosistema que uses, porque cada registry tiene su propio mecanismo de reporte y verificación.

No necesitas convertirte en un equipo de inteligencia para reaccionar mejor. Pero sí necesitas aceptar que, una vez que tu proyecto gana visibilidad, también gana valor para actores que no tienen buenas intenciones.

Tabla resumen

Si tu proyecto open source ya tiene usuarios reales, asume que también puede tener imitadores. No todos van a ser benignos. Y cuanto antes aceptes eso, más fácil será detectar cuando alguien intente convertir tu trabajo en infraestructura para fraude.