Alerta: el paquete de NuGet que fingía ser un SDK bancario para robar credenciales y certificados PFX

Investigadores de seguridad han detectado un paquete malicioso en NuGet que se hacía pasar por un SDK legítimo para Sicoob, una de las mayores cooperativas financieras de Brasil, y cuyo objetivo era robar credenciales de API y certificados PFX utilizados por empresas para autenticarse ante la red bancaria y automatizar pagos y cobros. La amenaza no es solo técnica: explota la confianza de desarrolladores que buscan integrar servicios bancarios, convirtiendo una instalación rutinaria en una brecha potencialmente crítica para pagos y datos financieros.

Técnicamente, el paquete interceptaba el flujo normal de inicialización del cliente: cuando un desarrollador proporcionaba un client ID, la ruta a un archivo PFX y su contraseña, el código malicioso leía el archivo PFX desde disco, codificaba su contenido y enviaba ese paquete —junto con el client ID y la contraseña— a endpoints preconfigurados que actuaban como receptores de exfiltración. Además, había canales dedicados para capturar respuestas crudas de la API de Boleto, lo que expone no solo credenciales sino también detalles de transacciones, montos, vencimientos e identificadores sensibles.

Hay varios puntos de interés en esta campaña que deben preocupar a la comunidad: primero, el paquete fue distribuido desde NuGet y alcanzó cientos de descargas antes de ser bloqueado, lo que demuestra que los registros públicos siguen siendo un vector eficaz para propagar código malicioso. Segundo, los atacantes emplearon una táctica de “manufactured legitimacy” al asociar el paquete con un repositorio GitHub aparentemente legítimo, creando una discordancia entre el código público y el binario distribuido por NuGet; esa separación dificulta la detección manual y engaña a verificadores superficiales.

Otro amplificador del problema fue la aparición del paquete en resultados generados por herramientas de búsqueda basadas en IA, que lo recomendaron como una biblioteca válida para integrar con Sicoob. Esa combinación —registro público + apariencia legítima + recomendaciones automáticas— hace que desarrolladores desprevenidos instalen dependencias sin controles adecuados, exponiendo así credenciales de producción y activos críticos.

Este incidente se inserta en una oleada más amplia de ataques a la cadena de suministro de software que han afectado principalmente al ecosistema npm, con campañas que usan typosquatting, postinstall hooks y técnicas de dependencia para extraer credenciales de entornos locales, pipelines CI/CD y archivos .env. Analistas de seguridad y empresas como Sonatype han documentado cómo los atacantes han dejado atrás simples faltas de ortografía y ahora diseñan nombres de paquetes y versiones que parecen completamente plausibles en flujos de trabajo reales, una práctica que describen como fabricación de legitimidad. Para leer análisis y recomendaciones sobre estas técnicas, son útiles recursos públicos como el blog de Sonatype https://www.sonatype.com/blog y proyectos que promueven firma y verificación de artefactos como Sigstore https://sigstore.dev.

Las implicaciones prácticas son severas: con un PFX y su contraseña un atacante puede suplantar integraciones bancarias, crear pagos o recibir fondos a nombre de la víctima, o filtrar información financiera de terceros. A nivel organizacional esto puede traducirse en pérdidas económicas directas, fraude, sanciones regulatorias y daño reputacional, especialmente en mercados donde métodos como Pix y Boleto están ampliamente adoptados.

Para reducir el riesgo inmediato se deben tomar medidas tanto de emergencia como estratégicas. En la respuesta inmediata, cualquiera que haya instalado el paquete en cuestión debe eliminarlo de su código y repositorios, considerar el material PFX como comprometido, revocar o reemplazar los certificados expuestos, rotar contraseñas y deshabilitar o regenerar los client IDs afectados. Paralelamente, se recomienda auditar los logs de autenticación y transacciones en Sicoob en busca de actividad anómala y coordinar con el equipo de seguridad del banco si hay indicios de abuso.

En un plano preventivo más amplio, las organizaciones y desarrolladores deben evitar almacenar material sensible en texto plano dentro de repositorios o discos compartidos; en su lugar conviene usar cofres de secretos y HSM/Vaults que minimicen la presencia de llaves en el filesystem. La cadena de suministro debe protegerse mediante políticas de bloqueo de paquetes no verificados, uso de registries internos o whitelists, validación de firmas de paquetes, generación de SBOMs y adopción de controles como SLSA. Implementar escaneo automático de dependencias, revisar diferencias entre el paquete publicado y el código fuente enlazado, y restringir el acceso de CI/CD a secretos sensibles son contramedidas que reducen la superficie de ataque.

Finalmente, este caso sirve como recordatorio de que la seguridad de la infraestructura de pagos depende tanto de buenas prácticas criptográficas como de higiene en la gestión de dependencias. Las herramientas automáticas de recomendación y búsqueda pueden acelerar el desarrollo, pero también amplifican riesgos cuando no se combinan con verificación humana y controles técnicos. La industria necesita avanzar hacia flujos donde la procedencia y la integridad de cada dependencia sean verificables por defecto, y los equipos de desarrollo deben incorporar revisiones de seguridad en cada paso del ciclo de vida del software.