Una nueva campaña vinculada a FAMOUS CHOLLIMA escondió infraestructura C2 en textos de Pastebin y desplegó un kit de robo orientado a desarrolladores. Qué implica para equipos de SysAdmin, DevOps y Seguridad, y cómo responder con controles prácticos.
Bajada. Una campaña reciente detectada en npm muestra una evolución técnica en ataques de cadena de suministro contra desarrolladores: uso de esteganografía en texto para resolver C2, infraestructura distribuida en Vercel y despliegue modular de robo de credenciales y secretos. Para equipos de SysAdmin, DevOps y Seguridad, el incidente refuerza una realidad incómoda: el riesgo ya no está solo en producción, también en el proceso de desarrollo.
Qué pasó y por qué importa
Entre el 25 y 26 de febrero de 2026 se publicaron en npm al menos 26 paquetes maliciosos que imitaban librerías conocidas. El objetivo no era romper builds ni generar ruido inmediato: los paquetes estaban diseñados para parecer verosímiles, mantener el flujo de trabajo funcional y ejecutar código malicioso durante la instalación mediante hooks de install.
El punto más relevante del caso no es solo el typosquatting. Es la combinación de técnicas para evadir detección temprana:
- Uso de nombres de paquetes similares a dependencias legítimas de alto uso.
- Ejecución automática de
install.jsal instalar. - Carga de un payload ofuscado desde una ruta aparentemente inocua (
vendor/scrypt-js/version.js). - Resolución del C2 desde textos “benignos” en Pastebin mediante extracción de caracteres en posiciones calculadas.
- Descarga de payload por plataforma (Linux, macOS y Windows) y conexión a infraestructura remota para control posterior.
Para operación diaria esto significa algo concreto: un solo npm install accidental puede convertir una estación de desarrollo en un punto de exfiltración de secretos, claves SSH, credenciales de navegador, tokens y repositorios internos.
Lo técnico: del paquete “normal” al robo de secretos
La investigación publicada por Socket describe una cadena en cinco etapas. Primero, el paquete ejecuta un script de instalación; luego deobfusca y consulta Pastebin para obtener dominios de mando y control; después descarga stagers específicos por sistema operativo; finalmente instala componentes que permiten persistencia, robo y control remoto.
Entre los módulos observados, el impacto para equipos técnicos es directo:
- Persistencia en VS Code mediante manipulación de
tasks.jsony gatillos al abrir carpetas. - Robo de credenciales y secretos de navegadores, wallets y repositorios.
- Exfiltración de llaves SSH y material Git, crítica para movimiento lateral en pipelines.
- Escaneo de secretos en host comprometido para capturar tokens y credenciales reutilizables.
El análisis independiente de kmsec coincide en la mecánica central y aporta IOCs útiles para hunting, incluyendo hash compartido y trazas de publicación en cuentas desechables. Esa convergencia entre investigaciones separadas aumenta la confianza de que no se trata de un evento aislado sino de una táctica madura y repetible.
Riesgo operativo para SysAdmin y DevOps
Este tipo de campaña afecta tres capas al mismo tiempo:
- Endpoints de desarrollo: si el equipo local cae, el atacante hereda acceso al contexto real de trabajo.
- Cadena CI/CD: secretos expuestos pueden habilitar acceso a registries, artefactos y despliegues.
- Gobernanza de dependencias: sin controles de procedencia, el error humano en nombre de paquete basta para comprometer el entorno.
En términos prácticos, el riesgo no se limita a “robo de datos del developer”. Puede derivar en publicación de paquetes internos alterados, inyección en imágenes de contenedor y abuso de credenciales de automatización con privilegios excesivos.
Señales de aprendizaje del atacante
Comparado con olas previas de campañas asociadas a Contagious Interview, hay un salto en resiliencia operativa:
- Infraestructura redundante (múltiples dominios y rutas de fallback).
- Evasión semántica (texto aparentemente legítimo en servicios públicos).
- Enfoque en desarrolladores como vía de acceso de alto retorno.
La lección es clara: las defensas centradas solo en bloqueo por firma o reputación puntual pierden eficacia cuando el atacante usa servicios legítimos y rotación rápida de infraestructura.
Plan de respuesta recomendado (48 horas)
Para equipos de infraestructura y seguridad, una respuesta efectiva combina contención, verificación y endurecimiento:
1) Contención inmediata
- Bloquear en proxies/EDR los IOCs publicados (dominios y endpoints asociados a la campaña).
- Revisar historiales de instalación npm en estaciones de desarrollo y runners.
- Forzar rotación de secretos de alto impacto: tokens CI, SSH deploy keys, credenciales cloud y PATs.
2) Detección y hunting
- Buscar ejecución de hooks de instalación inusuales y scripts desde rutas no esperadas en
node_modules. - Auditar cambios en configuración de VS Code, especialmente tareas autoejecutables.
- Monitorear conexiones salientes desde equipos de dev a dominios de reciente creación o patrones anómalos.
3) Endurecimiento de la cadena de suministro
- Restringir instalación directa desde internet en entornos corporativos; usar mirror/proxy de dependencias con políticas.
- Aplicar allowlist por namespace/proveedor para paquetes críticos.
- Habilitar escaneo de dependencias en PR y en pipeline con bloqueo por riesgo, no solo alerta.
- Adoptar controles de integridad (lockfiles estrictos, revisión de cambios de dependencia y firmas cuando estén disponibles).
4) Reducción de impacto por compromiso de endpoint
- Separar cuentas de desarrollo y cuentas con privilegios de infraestructura.
- Reducir tiempo de vida y alcance de tokens de automatización.
- Aislar runners y usar credenciales efímeras por job.
Qué debería cambiar en el backlog de seguridad
Más que un incidente puntual, StegaBin subraya una deuda estructural: muchas organizaciones invierten en seguridad de producción, pero mantienen bajo control débil los endpoints de desarrollo y la higiene de dependencias. En 2026, ese desbalance es una vía de entrada prioritaria para actores persistentes.
La mejora con mejor relación costo/impacto suele ser combinar tres decisiones: gobernanza de paquetes, secreto efímero en CI/CD y telemetría útil en estaciones de desarrollo. Sin esas bases, cada nueva técnica de evasión vuelve a poner al equipo en modo reactivo.
Cierre
El caso StegaBin confirma que la cadena de suministro de software sigue siendo un frente activo y en evolución. No alcanza con “instalar más herramientas”: hay que rediseñar cómo se aprueban dependencias, cómo circulan los secretos y cómo se limita el radio de impacto cuando una máquina de desarrollo cae. La buena noticia es que los controles prioritarios son conocidos y aplicables hoy; la diferencia está en ejecutarlos con disciplina operativa.
Fuentes consultadas: Socket (investigación técnica principal), The Hacker News (divulgación y contexto), kmsec.uk (análisis independiente e IOCs).




