S30,000 equipos infectados con una oferta de trabajo: el reclutamiento se volvió vector de ataque
// syswork LOG · categoríaNoticiaslectura6 MIN

30,000 equipos infectados con una oferta de trabajo: el reclutamiento se volvió vector de ataque

Una campaña ligada a Corea del Norte se hizo pasar por reclutador de empresas de IA y blockchain para infectar a profesionales de TI en más de 100 países. Por qué funciona tan bien y qué control le toca a una empresa mediana.

Mensaje de reclutamiento en una red profesional con un archivo adjunto de prueba técnica
Mensaje de reclutamiento en una red profesional con un archivo adjunto de prueba técnica

Durante años, el correo de phishing más efectivo fue el de la factura pendiente. Después vino el del paquete que no llegó. Ahora es la oferta de trabajo, y los números explican por qué.

La campaña —identificada como WaterPlum, vinculada a operadores ligados a Corea del Norte— comprometió más de 30,000 dispositivos en más de 100 países entre diciembre de 2025 y julio de 2026, afectando más de 7,000 monederos de criptomonedas. Las cifras de dinero sustraído que circulan rondan los 10.7 millones de dólares; conviene tratarlas como estimación, porque varían entre reportes.

El guion

Los operadores posan como reclutadores de empresas de inteligencia artificial o blockchain y contactan a profesionales de TI. El proceso avanza con toda normalidad —conversación, entrevista, interés genuino— hasta que llega el momento en que hay que ejecutar algo: una prueba técnica, un repositorio que hay que clonar y correr, una herramienta de videollamada propia de la empresa, o el clásico "se escucha mal, instala este arreglo de audio". Ese es el único paso malicioso de toda la cadena.

Lo que hace que funcione no es sofisticación técnica. Es que todo lo demás del proceso es real, y que ejecutar código es exactamente lo que un candidato técnico espera que le pidan.

Por qué van por el profesional, no por la empresa

Esta es la parte que conviene entender en la dirección, porque cambia dónde se pone el control.

La laptop de un desarrollador o de un administrador de sistemas suele tener, todo junto:

  • Llaves de acceso a servicios en la nube, muchas veces con permisos amplios.
  • Credenciales de repositorios de código con la propiedad intelectual de la empresa.
  • Sesiones abiertas de consolas de administración, paneles de proveedores y herramientas internas.
  • Acceso a producción, a veces directo, a veces a un paso.

Comprometer esa máquina entrega en un solo movimiento lo que atacar la infraestructura de frente costaría semanas. Es el mismo razonamiento que hizo que la laptop de un exempleado terminara en la copia de repositorios privados en otro caso reciente: el punto débil es el equipo de quien tiene las llaves, no el servidor.

El factor que casi nadie considera: el silencio

Hay una razón por la que este vector es especialmente difícil de detectar dentro de una empresa, y no es técnica.

Nadie reporta que está haciendo entrevistas. Si alguien de tu equipo cayó en esto, cayó mientras exploraba una oferta que no le había contado a nadie. Y cuando algo empieza a verse raro, la reacción natural es no decir nada, porque hablar implica admitir que estaba buscando trabajo.

Ese silencio es lo que hace que estas infecciones duren meses.

La contramedida es incómoda pero simple: decirlo en voz alta. Algo del estilo "buscar trabajo es normal y no es problema nuestro; ejecutar código de un desconocido en el equipo de la empresa sí lo es, y si te pasó, avísanos sin consecuencias". Una empresa que no puede decir esa frase con honestidad va a enterarse tarde.

Los controles que sí aplican a una empresa mediana

1. Separar dónde viven las credenciales. La regla práctica: las llaves de producción y los accesos administrativos no deberían estar disponibles en la misma sesión donde alguien clona repositorios desconocidos, abre adjuntos o prueba herramientas nuevas. Un gestor de contraseñas con desbloqueo explícito, credenciales de corta duración y perfiles separados hacen casi todo el trabajo.

2. Entorno aislado para código de terceros. Cualquier cosa que venga de fuera —una prueba técnica, una biblioteca nueva, un proyecto de ejemplo— se ejecuta en una máquina virtual o en un contenedor desechable. Es una disciplina de desarrollo, no una compra.

3. Rotación y revocación reales. Si mañana te dicen que una laptop estuvo comprometida durante tres semanas, ¿sabes qué credenciales había en ella y puedes revocarlas hoy? Esa pregunta, contestada con honestidad, suele ser el mejor diagnóstico que existe.

4. Detección en los equipos de la gente técnica, no solo en los servidores. Es exactamente al revés de como se invierte habitualmente.

Lo que hay que llevarse

La ingeniería social dejó de apuntar al eslabón desprevenido y empezó a apuntar al eslabón capacitado, con un pretexto que su propia profesión vuelve creíble. Un contador no ejecuta repositorios; un desarrollador sí, todos los días, y por eso el ataque le queda a la medida.

Si estás armando la capacitación anual, vale la pena que tu simulacro de phishing incluya al menos un escenario de reclutamiento. Es el que nadie está probando, y es el que está funcionando.

Accesos que no se van con una laptop

¿Sabes qué credenciales viven en los equipos de tu gente técnica?

Mapeamos dónde están tus accesos, los segmentamos y dejamos el procedimiento de revocación probado.

Pedir revisión de accesos

// FAQ

Preguntas frecuentes

// Temas relacionados

#ciberseguridad#ingeniería social#recursos humanos#malware

// Autor

Especialista en Ciberseguridad e Infraestructura

Diego Herrera

Ingeniero en ciberseguridad e infraestructura IT. Protege la operación de empresas mexicanas contra amenazas y caídas de servicio.

¿Te fue útil? Compártelo

// Sigue leyendo

Artículos relacionados

Ver todos

// Consultoría gratuita

¿Qué pasa si se compromete la laptop de tu desarrollador?

Revisamos dónde viven las credenciales de tu empresa, segmentamos accesos y dejamos el plan de respuesta listo.

Ver ciberseguridad