Falsas entrevistas técnicas: developers convertidos en puerta de entrada
Una oferta laboral, una videollamada real y un repositorio que funciona. Las falsas entrevistas técnicas están usando el flujo normal de desarrollo para instalar malware y robar credenciales. En 2026 la técnica se volvió bastante más difícil de detectar.
Estoy revisando un repositorio que alguien me mandó para una prueba técnica.
Hasta aquí, martes cualquiera para un developer.
Abres el README, miras la estructura, instalas lo necesario y ejecutas el proyecto para entender qué hace. Es exactamente el tipo de rutina que llevamos años haciendo sin pensarlo demasiado.
Y precisamente por eso funciona el ataque.
Durante 2026 varias empresas de seguridad han seguido documentando una campaña conocida como Contagious Interview, vinculada por distintos investigadores con actores relacionados con Corea del Norte. El objetivo son developers y profesionales tecnológicos a quienes contactan mediante procesos falsos de contratación. Microsoft señala que la actividad existe al menos desde diciembre de 2022 y continúa apareciendo en entornos actuales.
Lo preocupante ya no es que alguien mande un ejecutable sospechoso.
Ahora pueden mandarte trabajo.
El ataque parece una entrevista de verdad
El procedimiento tiene una ventaja enorme para el atacante: prácticamente todas las acciones solicitadas tienen sentido dentro de una entrevista técnica.
Puede comenzar con un recruiter en una red profesional. Después vienen mensajes sobre experiencia, salario o tecnologías.
Hay videollamada.
Hay proyecto.
Hay GitHub.
Y finalmente hay una prueba de código.
Microsoft documentó en marzo de 2026 procesos donde candidatos eran dirigidos a repositorios alojados incluso en servicios ampliamente conocidos como GitHub, GitLab o Bitbucket. Al ejecutar el proyecto, la víctima terminaba iniciando código controlado por el atacante.
Unit 42 describió además un caso de enero de 2026 donde atacantes se hicieron pasar por personal relacionado con Fireblocks. Realizaron entrevistas mediante Google Meet y posteriormente pidieron revisar un supuesto proyecto alojado en GitHub. La solicitud incluía acciones completamente normales para preparar un proyecto de JavaScript. El problema era que esas acciones disparaban el código malicioso.
Ese detalle me parece el más importante de toda esta historia.
No necesitas convencer a un developer de desactivar el antivirus o descargar un virus.exe.
Solo necesitas decirle:
“Aquí está el challenge. Levántalo y dime qué mejorarías.”
Eso sí lo hacemos.
El repositorio puede funcionar perfectamente
La evolución publicada por Elastic Security Labs en julio de 2026 lo vuelve todavía más interesante.
El 26 de mayo apareció una falsa oferta de trabajo dentro del propio Slack comunitario de Elastic. Las personas interesadas eran llevadas a mensajes privados y recibían un challenge relacionado con un proyecto de comercio electrónico.
La prueba funcionaba.
Pero también estaba preparada para robar información.
Elastic encontró componentes asociados con OTTERCOOKIE, incluyendo mecanismos para obtener credenciales del navegador, archivos, información del portapapeles y establecer acceso remoto.
La parte que más me llamó la atención fue cómo escondieron parte del código.
Utilizaron archivos SVG aparentemente normales —imágenes de banderas dentro del proyecto— para guardar fragmentos que después podían reconstruirse durante la ejecución.
Elastic señaló además que, en el momento de su análisis, ese proyecto no estaba siendo detectado por proveedores antivirus.
Eso rompe otra suposición bastante común:
“Si fuera malware, Defender lo detectaría.”
No necesariamente.
El README también puede mentir
Kudelski Security analizó en junio otro repositorio relacionado con estas campañas.
El proyecto imitaba a una empresa real y tenía una estructura suficientemente convincente para una evaluación técnica. Dentro encontraron código oculto entre archivos normales del proyecto e incluso configuraciones relacionadas con VS Code que podían participar en la ejecución del backdoor.
Hay algo particularmente efectivo en esto.
Cuando revisamos software desconocido solemos buscar exactamente lo contrario: un proyecto roto, nombres absurdos, código evidentemente sospechoso o instrucciones extrañas.
Aquí el atacante puede dedicar tiempo a que todo parezca correcto.
| Lo que ve el developer | Lo que puede estar viendo el atacante |
|---|---|
| Oferta de trabajo | Ingeniería social |
| Recruiter | Identidad falsa |
| Videollamada | Construcción de confianza |
| GitHub | Canal de distribución |
| Coding challenge | Vector de entrada |
| Dependencias | Punto de ejecución |
| Proyecto funcional | Cobertura del malware |
Esto ya tiene escala
Tampoco parece un experimento pequeño.
Socket informó en abril de 2026 que llevaba identificados más de 1,700 paquetes maliciosos relacionados con Contagious Interview.
Y no estaban concentrados únicamente en npm.
La actividad apareció en varios ecosistemas utilizados diariamente por developers: npm, PyPI, Go Modules, crates.io y Packagist.
Para quienes trabajamos con varias tecnologías esto importa bastante.
El problema dejó de poder resumirse como “los desarrolladores JavaScript deben tener cuidado con npm”.
El patrón es mucho más amplio.
¿Por qué atacar developers?
Porque nuestras computadoras suelen tener cosas bastante útiles.
Repositorios privados.
Credenciales.
Tokens.
Sesiones abiertas.
Accesos a servicios cloud.
Llaves para publicar paquetes.
Información de clientes.
Y, en ciertos casos, acceso a infraestructura de una empresa.
Comprometer a un developer puede servir para robar directamente información, pero también para alcanzar un objetivo mucho mayor.
Un caso documentado en 2026 muestra lo serio que puede volverse este escenario. Unit 42 recoge el ataque contra el mantenedor principal de Axios: después de una sofisticada interacción mediante un Slack preparado para parecer legítimo, el atacante consiguió acceso a su cuenta de npm y terminó publicando versiones comprometidas del paquete.
Ahí ya hablamos de supply chain.
En español simple: en lugar de atacar mil aplicaciones, atacas algo que esas mil aplicaciones utilizan.
Las señales que yo revisaría
No creo que la solución sea dejar de aceptar pruebas técnicas.
Sí cambiaría varias costumbres.
- Una empresa debería poder demostrar que realmente existe y que la persona que contacta trabaja ahí.
- Un repositorio recibido durante un proceso de contratación sigue siendo código de un tercero.
- Una videollamada por Google Meet o una conversación dentro de Slack no demuestran por sí mismas que la identidad sea legítima.
- Pedir instalar herramientas extrañas para continuar una entrevista merece revisión.
- Un proyecto desconocido debería inspeccionarse antes de ejecutarse.
- Las evaluaciones externas conviene tratarlas como software potencialmente hostil y mantenerlas separadas del entorno donde viven credenciales, repositorios de clientes o accesos importantes.
También revisaría la actividad de la cuenta que entrega el proyecto.
Unit 42 ya había señalado anteriormente perfiles de GitHub con muy poca historia, repositorios aislados y actividad extraña alrededor de proyectos utilizados en esta campaña.
Ninguna de estas señales demuestra por sí sola que exista un ataque.
Varias juntas sí deberían hacer ruido.
Lo que me llevo
Durante años relacionamos phishing con correos mal escritos, dominios raros y archivos adjuntos.
Este ataque tiene otra lógica.
Utiliza herramientas que conocemos y tareas que hacemos todos los días.
Una prueba de programación genera confianza precisamente porque parece trabajo real.
Por eso creo que los developers tenemos que empezar a aplicar al código recibido la misma desconfianza que hace años aprendimos a aplicar a los archivos adjuntos.
GitHub es una plataforma.
No un certificado de seguridad.
Una regla sencilla para la próxima entrevista
Si recibo mañana una prueba técnica de una empresa que no conozco, puedo revisar el código.
Puedo analizar la arquitectura.
Puedo hacer la evaluación.
Lo que ya no haría automáticamente es convertir mi computadora principal en el entorno donde descubro si el recruiter era quien decía ser.
La campaña lleva activa desde hace años y durante 2026 siguió evolucionando. Elastic encontró nuevas técnicas en julio y Unit 42 seguía documentando en agosto cómo los atacantes están aprovechando canales de colaboración legítimos para hacer más creíbles estas operaciones.
Ese pequeño cambio de hábito puede evitar que una entrevista técnica termine convirtiéndose en acceso inicial a algo mucho más grande.
Fuentes
Microsoft Security — Contagious Interview, marzo de 2026. Investigación de Microsoft Security
Elastic Security Labs — nueva campaña con malware oculto en SVG, julio de 2026. Investigación de Elastic Security Labs
Kudelski Security — análisis de repositorio utilizado en falsas entrevistas, junio de 2026. Investigación de Kudelski Security
Socket — expansión de Contagious Interview a cinco ecosistemas de paquetes, abril de 2026. Investigación de Socket
Palo Alto Networks Unit 42 — análisis de abuso de canales de colaboración, agosto de 2026. Investigación de Unit 42