634 contraseñas en 56 segundos
Un desarrollador pasó dos rondas de entrevistas con una empresa falsa. Sitio web real, caras reales, conversaciones técnicas reales. Luego pusieron a prueba el reto de programación. En menos de un minuto, todas las contraseñas de Chrome, el llavero de macOS y los datos de la cartera de criptomonedas habían desaparecido.
Un desarrollador —con conocimientos de seguridad, con experiencia, alguien que busca activamente señales de fraude— pasó por un proceso de entrevistas de varias fases con una empresa falsa. Llamada de RR. HH. Entrevista técnica con dos ingenieros. Sitio web real con fotos del equipo. Perfiles reales en LinkedIn. Semanas de construcción de confianza.
Después se le pidió que ejecutara un pequeño reto de programación mientras compartía pantalla.
56 segundos más tarde, los atacantes tenían 634 contraseñas guardadas en Chrome, el archivo del llavero de macOS (que contiene la clave para descifrarlas) y los datos de la cartera MetaMask.
Cómo funcionó el ataque
El repositorio de GitHub parecía limpio. Algunos archivos de backend, nada sospechoso. Pero una dependencia —winston-middleware, un paquete de registro de sonido totalmente normal— tenía a su vez otra dependencia: next-runtimejs.
Ahí estaba el arma.
En el momento en que se ejecutó npm install, un script de shell se ejecutó en silencio. Sin avisos, sin alertas. Descargó una puerta trasera escrita en Go y la registró para que se iniciara automáticamente en cada arranque.
No era una herramienta de aficionados. Protocolo C2 propio cifrado con RC4. Comandos para ejecución de shell, robo de archivos, extracción de contraseñas de Chrome, exfiltración del llavero y ataque a carteras de criptomonedas. Construida de forma profesional.
La puerta trasera se inició a las 16:16:37. Las contraseñas de Chrome se accedieron a las 16:17:33. El desarrollador detectó una ventana emergente de macOS sobre una conexión saliente y cortó el WiFi en menos de un minuto — pero el daño ya estaba hecho.
Por qué la entrevista fue determinante
Este ataque habría fracasado como correo en frío. «Ejecuta este repositorio» de un desconocido se ignora.
Pero ¿después de dos rondas de entrevistas? ¿Después de reírse juntos de la cantidad de ofertas de empleo falsas que se dirigen a los desarrolladores? ¿Después de que uno de los entrevistadores dijera «Siéntase libre de buscar puertas traseras» con una sonrisa?
Ahí es cuando baja la guardia. La confianza es la vulnerabilidad explotada. El malware es solo la carga útil.
El desarrollador lo expresó mejor que nadie: «Si me ha pasado a mí, puede pasarle a cualquiera en su equipo».
Qué significan realmente las contraseñas de Chrome
Chrome cifra las contraseñas guardadas con AES. La clave de descifrado se almacena en el llavero de macOS. Los atacantes robaron ambos archivos en menos de un minuto.
Todas las contraseñas guardadas —banca, correo, GitHub, consolas en la nube— eran legibles en su lado. El archivo del llavero puede descifrarse sin conexión y sin límites de intentos. El desarrollador tuvo que rotarlo todo.
Este es el secreto incómodo de las contraseñas guardadas en el navegador: están cifradas con una clave que reside en la misma máquina. Si se compromete la máquina, el «cifrado» es decorativo.
El patrón de la RPDC
El desarrollador comentó que su empresa anterior también había sido atacada por Corea del Norte tres meses antes. Se trata de la campaña «Contagious Interview» —atacantes patrocinados por el Estado de la RPDC que organizan entrevistas de trabajo falsas para instalar malware en las máquinas de los desarrolladores.
No es aleatorio. Se dirigen específicamente a los desarrolladores por el acceso que tienen: credenciales de producción, claves de firma, infraestructura en la nube y —cada vez más— tokens de agentes de IA que permiten acceder a todavía más cosas.
La escala es industrial. Empresas falsas con rostros generados. Sitios web impecables. Procesos de entrevistas de varias semanas. Invierten porque la rentabilidad está ahí.
«Los gestores de contraseñas no sirven»
El desarrollador hizo una afirmación interesante en el hilo: «Los gestores de contraseñas no sirven si tienen acceso a su ordenador mediante una puerta trasera como esta, porque pueden transmitir cualquier archivo más tarde, elaborar un exploit específico para usted, registrar pulsaciones de teclas, capturar pantallas».
Es parcialmente correcto y parcialmente incorrecto.
Un gestor de contraseñas que almacena su bóveda en el disco local, desbloqueada con una contraseña maestra que usted teclea — sí, una puerta trasera con registro de teclas y acceso a archivos puede comprometerlo.
Pero un gestor de contraseñas con claves vinculadas a hardware —donde la clave de descifrado se deriva de un autenticador físico y nunca existe como archivo en el disco— es radicalmente distinto. La puerta trasera puede robar archivos, registrar pulsaciones y capturar pantallas. Pero no puede extraer una clave que solo existe dentro de un módulo de seguridad de hardware durante una pulsación física.
Las 634 contraseñas de Chrome se robaron porque tanto los datos cifrados como la clave de descifrado eran archivos en el sistema de archivos. Si la clave de descifrado requiere la posesión física de un dispositivo, robar archivos solo le entrega bloques cifrados y nada más.
Qué hacer
- Nunca ejecute código de entrevistas en su máquina principal. Use una máquina virtual o un dispositivo separado.
- Ejecute
npm install --ignore-scriptsen cualquier repositorio que no conozca antes de ejecutarlo - Use un cortafuegos de salida (Little Snitch, LuLu) que avise de conexiones nuevas
- Deje de guardar contraseñas en Chrome. Sin excepciones.
- Mantenga las criptomonedas en carteras de hardware, no en extensiones de navegador
- Trate cualquier reto de programación procedente de un reclutador como potencialmente hostil, por muchas llamadas que haya tenido
El desarrollador se salvó porque una ventana emergente de macOS detectó a tiempo la conexión saliente. La mayoría de las personas habrían pulsado «Permitir» sin pensarlo dos veces.
56 segundos. Eso es todo lo que se necesita.