Crates de Rust que aparentan utilidades de tiempo y roban secretos de tus pipelines

Hace poco la comunidad de seguridad volvió a encender las alarmas: se han detectado paquetes maliciosos escritos en Rust que llegaban a crates.io con aspecto inocente y una promesa simple: utilidades para sincronizar o calibrar la hora local sin depender de NTP. Sin embargo, bajo esa fachada se escondía un comportamiento mucho más peligroso: extracción de secretos desde los entornos de desarrollo —especialmente archivos .env— y su envío a servidores controlados por los atacantes.

La investigación, detallada por la firma Socket, identifica cinco crates publicados entre finales de febrero y principios de marzo de 2026 con nombres que imitaban utilidades de tiempo, entre ellos chrono_anchor, dnp3times, time_calibrator, time_calibrators y time-sync. Según los analistas, todos comparten una misma técnica de exfiltración y una infraestructura común de recepción de datos que utiliza un dominio imitador de servicios legítimos de hora, lo que apunta a la acción de un único actor malicioso. Puedes leer el análisis técnico en el blog de Socket: socket.dev.

Lo especialmente inquietante de este caso es la selección del objetivo: los archivos .env son un blanco habitual porque suelen contener claves de API, tokens de acceso y otras credenciales sensibles que, si caen en manos equivocadas, permiten escalar hasta servicios en la nube, bases de datos o incluso la publicación en registros y repositorios con permisos elevados. Los paquetes maliciosos estaban diseñados para leer estos ficheros cuando el código se ejecutaba en entornos de desarrollo o en pipelines de integración continua, y transmitir su contenido a la infraestructura del atacante.

Entre los paquetes detectados, chrono_anchor destacaba por su intento explícito de camuflar la funcionalidad maliciosa: la lógica de extracción se encontraba en un archivo llamado guard.rs y se invocaba desde una función auxiliar opcional, reduciendo la probabilidad de que un desarrollador desconfiara. Además, en lugar de intentar mantener persistencia mediante servicios o tareas programadas en el sistema, la estrategia aquí consistía en repetir la exfiltración cada vez que el crate se ejecutaba en un flujo de CI, multiplicando así el impacto si el paquete se integraba en un pipeline automatizado.

La recomendación inmediata, que ya han puesto sobre la mesa tanto Socket como otras firmas, es asumir la peor hipótesis para cualquier equipo que haya podido descargar o integrar estos paquetes: rotación de claves y tokens, auditoría exhaustiva de los trabajos de CI/CD que tengan permisos de publicación o despliegue, y reducción de la capacidad de salida a red desde los runners donde se ejecutan los pipelines. Socket resume bien la lección: controles que bloqueen dependencias maliciosas antes de que se ejecuten son mucho más eficaces que intentar contener la fuga una vez que ha empezado.

Este incidente no llega aislado. En paralelo hemos visto campañas automatizadas que atacan directamente las pipelines de GitHub Actions con bots impulsados por inteligencia artificial. Un ejemplo documentado por StepSecurity describe cómo un agente automatizado, autodenominado hackerbot-claw, inspeccionó repositorios públicos para buscar flujos de trabajo mal configurados, creó forks y solicitó pull requests aparentemente inocuas para forzar la ejecución de workflows y así capturar secretos presentes en los runners. El reporte de StepSecurity explica con detalle este modus operandi y cómo el uso de flujos como pull_request_target puede ser aprovechado por atacantes: stepsecurity.io.

Uno de los casos más mediáticos recientes involucró a la herramienta Trivy de Aqua Security, donde un workflow explotado permitió al atacante publicar una versión maliciosa de la extensión de Visual Studio Code en el registro Open VSX. Esa extensión incluía instrucciones para ejecutar asistentes de código AI de forma muy permisiva y reunir información del sistema, que luego era canalizada a un repositorio usando las credenciales de quien había ejecutado el flujo. Aqua Security publicó detalles y mitigaciones en su foro oficial, mientras que Socket investigó y publicó sus propias conclusiones sobre la ejecución no autorizada de agentes AI: declaración de Aqua y análisis de Socket.

Estos incidentes plantean una lección clara para desarrolladores y equipos de seguridad: la cadena de suministro de software es una superficie crítica y cada dependencia, por pequeña que parezca, puede convertirse en un vector de ataque. Además de las acciones reactivas —eliminación de las dependencias afectadas y rotación de credenciales— es imprescindible adoptar medidas preventivas en dos frentes: control de dependencias y endurecimiento de pipelines. Herramientas como RustSec y cargo-audit ayudan a identificar paquetes vulnerables o comprometidos en proyectos Rust, y las guías de seguridad de GitHub sobre Actions ofrecen prácticas para reducir el riesgo de ejecución de código no confiable en runners: Security hardening for GitHub Actions. Es recomendable además revisar las políticas de acceso a tokens, evitar usar credenciales con permisos de escritura en workflows disparados por pull requests de contribuciones externas, y establecer barreras de salida a red desde runners cuando sea posible.

Si tu proyecto pudiera haber consumido alguno de estos crates, lo prudente es suponer que ha habido exposición: elimina las dependencias afectadas, revoca y sustituye claves y tokens que pudieron haber sido utilizados por las pipelines, inspecciona los repositorios tanto locales como remotos en busca de actividad inesperada y revisa los permisos en los flujos de CI. La comunidad y las plataformas han sido rápidas en borrar los paquetes maliciosos de los registros, pero eso no elimina el riesgo si ya se descargaron y ejecutaron.

En última instancia, estos incidentes ponen de manifiesto que incluso código de baja complejidad puede causar daños significativos si se ejecuta en el lugar y el momento adecuados. Proteger la cadena de suministros y privilegiar la detección temprana de dependencias maliciosas son acciones que ya no pueden dejarse para después. Mantener prácticas de seguridad en el desarrollo y en las pipelines se ha convertido en una necesidad operativa, no en una opción.