Se ha instalado un paquete malicioso: contener la ejecución antes de sustituir las credenciales

Objetivo

Estado al 25 de octubre de 2026. Contener la ejecución de paquetes maliciosos y recuperar las identidades y los artefactos a los que pudiera afectar. Este protocolo propuesto se basa en la documentación de respuesta de GitHub y npm, el aviso de Tensorlake publicado el 8 de octubre y el registro de LiteLLM en OSV modificado el 21 de octubre a las 22:01:01 UTC. Volver a consultar las advertencias específicas del paquete y los indicadores actualizados antes de actuar.

Requisitos previos

Un equipo de administración limpio; autorización para aislar los sistemas afectados y pausar las publicaciones; acceso a los controles del registro de paquetes, del repositorio y de los emisores de credenciales; y almacenamiento protegido para las pruebas. Asignar un responsable del incidente y registrar las acciones en UTC. Utilizar herramientas de confianza para examinar los archivos sospechosos sin ejecutar sus scripts de instalación, el código de inicio del intérprete ni las tareas del proyecto.

Pasos

1. Contener la ejecución y la distribución. Aislar las estaciones de trabajo y los ejecutores afectados, cancelar los trabajos implicados y pausar la publicación. Antes de limpiar, conservar los registros disponibles, los metadatos de paquetes, los archivos de bloqueo de dependencias, los resúmenes criptográficos de artefactos y las pruebas pertinentes del sistema de archivos. Utilizar controles administrativos externos al entorno sospechoso. No introducir credenciales de sustitución en un equipo que siga bajo investigación.
2. Comprobar de inmediato si hay persistencia destructiva. Tensorlake 0.5.144 requiere desactivar gh-token-monitor antes de revocar los tokens de GitHub. Sus instrucciones para Linux comienzan con systemctl --user disable --now gh-token-monitor.service, ejecutado en la sesión del usuario afectado; completar la limpieza específica para la plataforma que indica el aviso. Si no se puede asegurar la contención, detener el equipo afectado y examinar su almacenamiento sin conexión antes de continuar. En LiteLLM 1.107.0, el inicio de Python puede ejecutar los archivos maliciosos: no iniciar Python ni pip para investigar ese entorno.
3. Revocar las credenciales expuestas desde el equipo limpio. Dar prioridad al acceso de publicación y de escritura en repositorios; después, incluir en la revocación todos los demás secretos y sesiones accesibles con el emisor correspondiente. Para npm, ejecutar npm token list, identificar el ID del token afectado y utilizar npm token delete TOKEN_ID, sustituyendo el marcador por ese ID. Volver a enumerar los tokens. npm documenta que la revocación puede demorarse, por lo que se debe mantener la contención mientras se comprueba el estado en el emisor. Emitir credenciales de sustitución solo para los sistemas que las utilizan y que ya se hayan recuperado.
4. Determinar el alcance completo de la exposición. Registrar cada equipo afectado, la hora de instalación, las identidades accesibles y los artefactos generados después. La guía de respuesta de GitHub recomienda hacer un inventario de los flujos de trabajo y las credenciales afectados, y revisar la contención cuando aparezcan nuevas pruebas. Examinar las caches de CI y de los registros de paquetes como posibles fuentes de reinstalaciones posteriores.
5. Inspeccionar el acceso y la persistencia. Revisar los cambios en flujos de trabajo, las aprobaciones de publicaciones, los nuevos ejecutores y los ejecutables desconocidos. Las recomendaciones de GitHub sobre cuentas también indican revisar las claves de despliegue, las claves SSH, las autorizaciones de aplicaciones, los webhooks, los colaboradores y los commits recientes. Comparar los hallazgos con el estado aprobado anterior al incidente. Revisar las versiones publicadas con las identidades de publicación expuestas y coordinar con el registro la retirada de los artefactos que se haya confirmado que son maliciosos.
6. Reconstruir y verificar. Sustituir los entornos afectados utilizando imágenes de confianza, código fuente revisado y un conjunto aprobado de dependencias; no reutilizar caches ni ejecutables sospechosos. Registrar las identidades de los artefactos de sustitución y probar la aplicación. Confirmar la revocación de credenciales y que los accesos estén autorizados; después, restablecer el servicio por etapas mientras se supervisan los registros de repositorios, publicación, acceso a la nube y equipos.

Resultado esperado

El registro del incidente vincula cada identidad expuesta y cada artefacto afectado con una acción de contención y una comprobación de recuperación. La publicación se reanuda desde un entorno aprobado con credenciales de alcance limitado. Un responsable sigue a cargo de revisar las actividades sospechosas posteriores y cualquier exposición pendiente de resolver.

Límites y base de verificación

Esta es una propuesta de respuesta basada en fuentes, no un ejercicio de recuperación probado. La ausencia de indicadores no demuestra que no se produjeran robos ni ejecuciones secundarias. La eliminación del paquete por sí sola no restablece la confianza. Las precauciones frente a la persistencia destructiva son específicas de cada incidente; seguir las instrucciones actuales del proveedor mientras se continúa la contención urgente mediante controles administrativos limpios.