Ataque a SAP CAP en npm expone tokens y credenciales mediante robo de memoria de runners por TeamPCP

Un conjunto de paquetes oficiales de SAP publicados en el registro npm fue comprometido y, según análisis de varios equipos de investigación, la intrusión coincide con la firma táctico‑operativa del grupo conocido como TeamPCP. Las versiones afectadas que fueron publicadas con código malicioso y ya han sido deprecadas en npm incluyen @cap-js/sqlite v2.2.2, @cap-js/postgres v2.2.2, @cap-js/db-service v2.10.1 y mbt v1.2.48, componentes vinculados al modelo Cloud Application Programming (CAP) y Cloud MTA que se usan en desarrollos empresariales.

Los investigadores de Aikido y Socket han documentado que el paquete comprometido añade un script de preinstalación que lanza un loader llamado setup.mjs, que a su vez descarga el runtime Bun desde GitHub y ejecuta un payload ofuscado llamado execution.js. Ese payload actúa como un ladrón de información diseñado para extraer tokens de npm y GitHub, claves SSH, credenciales de proveedores cloud (AWS, Azure, GCP), configuraciones y secretos de Kubernetes y variables de entornos de CI/CD, además de intentar leer memoria de runners de CI para evadir el enmascaramiento de secretos.

El mecanismo de exfiltración documentado incluye el cifrado de la información robada y su subida a repositorios públicos de GitHub creados bajo cuentas de víctimas, usando descripciones con la cadena "A Mini Shai‑Hulud has Appeared". Además, el malware emplea una técnica de “dead‑drop” por commit messages en GitHub con la forma "OhNoWhatsGoingOnWithGitHub:" para recuperar tokens, lo que permite ampliar el alcance y persistencia del atacante. Estos detalles están recogidos en los informes de Aikido y Socket: Aikido — Mini Shai‑Hulud y Socket — análisis del ataque a SAP CAP.

La capacidad del malware para leer /proc/pid/maps y /proc/pid/mem en runners Linux reproduce tácticas vistas en compromisos previos atribuidos a TeamPCP contra proveedores como Bitwarden y Checkmarx: se extraen secretos directamente de la memoria del proceso del runner para evadir cualquier mascarado de logs del proveedor CI. Con credenciales robadas, el actor intenta propagarse automáticamente modificando otros paquetes y repositorios para insertar la misma cadena maliciosa.

Sobre el vector inicial, no hay confirmación pública de SAP al cierre de los informes, pero investigadores apuntan a la posibilidad de que un token npm quedara expuesto por una configuración errónea de un job de CircleCI, lo que concuerda con patrones anteriores en los que credenciales de CI servían como pivote de publicación maliciosa. Mientras SAP investiga, las organizaciones que usan CAP o las librerías afectadas deben asumir riesgo de compromiso en sus cadenas de desarrollo.

Las acciones inmediatas recomendadas incluyen rotar y revocar cualquier token y credencial que pudiera haber estado presente en máquinas o en CI: regenerar tokens de npm y GitHub, rotar claves SSH, renovar credenciales de nube y regenerar secrets de CI. Es imprescindible inspeccionar los repositorios y cuentas en GitHub en busca de nuevos repos creados con la descripción indicada y revisar el historial de commits por patrones sospechosos como "OhNoWhatsGoingOnWithGitHub:". También conviene revocar los runners comprometidos y reconstruirlos desde imágenes limpias para eliminar cualquier backdoor en memoria o en el sistema de ficheros.

En un segundo plano, se deben endurecer las prácticas de desarrollo y despliegue: habilitar autenticación multifactor y el uso de tokens con el menor privilegio posible, migrar a mecanismos de autenticación federada o OIDC para CI donde sea viable, activar el escaneado de secretos y la protección avanzada de repositorios (por ejemplo, GitHub Advanced Security), y fijar versiones de dependencia mediante lockfiles y políticas de aprobación de cambios en la pipeline. Las herramientas de escaneo de software de terceros (SCA) y la monitorización de integridad de paquetes ayudan a detectar modificaciones no autorizadas en artefactos publicados.

Desde el punto de vista operativo, es crítico auditar logs de accesos a repositorios y APIs cloud por actividad inusual, bloquear exfiltración no autorizada con controles de egress y revisar la configuración de CI para evitar que variables sensibles queden embebidas en builds o expuestas en jobs públicos. Considerar el uso de tokens efímeros, rotación automática y separación estricta de credenciales de publicación frente a las de ejecución reduce la ventana de exposición ante un compromiso futuro.

Este incidente vuelve a subrayar que las cadenas de suministro de software son un objetivo de alto valor y que un solo token o pipeline mal configurado puede dar acceso a entornos corporativos completos. La defensa requiere tanto controles técnicos (hardening de CI, rotación de secretos, least privilege) como gobernanza: políticas claras sobre publicación de paquetes, revisiones humanas y respuestas rápidas ante señales de compromiso. Para guías prácticas sobre manejo de tokens y credenciales se pueden consultar las recomendaciones de GitHub sobre tokens personales y de acceso: GitHub — Personal Access Tokens, y la documentación de npm sobre seguridad y tokens: npm — Access Tokens.

Si tu organización utiliza SAP CAP o las librerías afectadas, actúa ahora: evalúa exposición, asume compromiso hasta demostrar lo contrario, ejecuta rotaciones y reconstrucciones, y aprovecha este incidente para elevar las defensas de la cadena de suministro y la higiene de secretos a nivel corporativo.