El propio error del hacker abrió la puerta

Durante 22 meses, Vangelis Stykas observó desde dentro a un grupo de hackers estatales norcoreano, no porque hubiera irrumpido en sus sistemas, sino porque el propio malware del grupo infectó primero sus propios equipos de trabajo. Stykas, director de tecnología de la empresa de ciberseguridad Kumio, explicó en la conferencia Black Hat de Las Vegas, a principios de agosto de 2026, que los operadores se infectaron a sí mismos, abriéndole una ventana a sus canales internos de Slack y Discord.

Ese acceso accidental le dio una vista silenciosa de unos 5 terabytes de datos que el grupo había robado a sus propias víctimas, además de una mirada poco habitual al funcionamiento diario de la operación, completamente sin ser detectado por los propios hackers.

1.640 empresas, 57 países, una docena de nombres

Stykas afirmó que el grupo había comprometido 1.640 empresas en 57 países durante el periodo en que tuvo acceso. Entre 700 y 800 de esas intrusiones las clasificó como graves, es decir, los atacantes habían alcanzado acceso root a servidores, entornos de nube de AWS o carteras de criptomonedas, mucho más allá de un simple punto de apoyo en una sola máquina.

En su presentación, Stykas nombró públicamente a una docena aproximada de las organizaciones afectadas, entre ellas el fabricante de teléfonos Oppo, Coinbase, Uniswap Labs, el Boston Children's Hospital y varias agencias gubernamentales que no identificó por su nombre.

La entrada fue una entrevista de trabajo

Al margen de la investigación de Stykas, equipos de seguridad de Elastic Security Labs, Proofpoint y otras firmas llevan todo 2026 rastreando una campaña norcoreana activa conocida como Contagious Interview, vinculada al Lazarus Group. Los operadores se hacen pasar por reclutadores en plataformas como LinkedIn, contactan a desarrolladores de software con lo que parece una oferta de empleo genuina y luego envían una prueba de programación alojada en un repositorio de GitHub.

La trampa se aloja en la carpeta .githooks del repositorio como un hook de pre-commit, de modo que se activa automáticamente en cuanto el desarrollador hace commit de su código de prueba, sin descarga ni doble clic aparte. Otras variantes de la misma campaña han escondido la carga maliciosa dentro de archivos de imagen SVG mediante esteganografía, y Proofpoint rastreó más de 250 correos de reclutamiento maliciosos solo entre abril y mayo de 2026, concentrados en trabajadores de tecnología, educación y finanzas, con especial atención a roles cercanos a las criptomonedas.

Lo que realmente hace el malware

Las familias de malware usadas en estas campañas, entre ellas OTTERCOOKIE y herramientas relacionadas, están diseñadas para robar credenciales del navegador, carteras de criptomonedas y archivos, y para dar a los operadores acceso remoto al equipo infectado. En el caso de un desarrollador, ese acceso suele caer justo en el entorno que contiene los repositorios de la empresa, las credenciales de la nube y los datos de clientes.

Ahí está el vínculo entre los dos hilos. Un grupo capaz de sostener intrusiones a la escala que documentó Stykas, 1.640 empresas en 57 países, también ha demostrado sostener una parte significativa de su acceso a través del acto ordinario de contratar personal, lo que hace que esta vía sea relevante para cualquier empresa de la UE o el Reino Unido que contrate desarrolladores remotos o contratistas, y para cualquier desarrollador que esté buscando empleo ahora mismo.

Tres comprobaciones antes de clonar ese repositorio

La defensa práctica es específica, no un consejo genérico contra el phishing. Verifique la identidad de un reclutador de forma independiente, a través de la página de empleo propia de la empresa o de un empleado conocido, antes de ejecutar cualquier código que le envíe. Considere más sospechosa una prueba de programación que exija clonar un repositorio completo con hooks y scripts de configuración que una entregada mediante una plataforma aislada de tipo sandbox, ya que el sandbox elimina precisamente el mecanismo del que depende el truco de .githooks.

Trate un calendario de contratación inusualmente rápido y de alta presión como una señal de alarma mayor de lo que habría sido hace un año, y nunca ejecute un script de configuración, npm install ni un comando de compilación de un repositorio de prueba antes de completar esa verificación de identidad. Nada de esto requiere herramientas nuevas, solo una pausa antes de que se ejecute el primer comando.