Las últimas campañas del ransomware VECT 2.0 confirman una tendencia especialmente peligrosa: bajo la apariencia de un ataque de cifrado clásico, las víctimas sufren en realidad un borrado permanente de información. Un análisis de Check Point Research revela un fallo crítico en la implementación criptográfica que hace imposible recuperar los archivos afectados, incluso para los propios operadores criminales, independientemente de que se pague o no el rescate.
VECT 2.0: ransomware-as-a-service con fachada de extorsión y comportamiento de wiper
VECT, rebautizado como VECT 2.0, se comercializa en la dark web como una plataforma de ransomware-as-a-service (RaaS). El grupo promueve un modelo «Exfiltration / Encryption / Extortion», que combina robo de datos, cifrado de sistemas y chantaje económico. Para unirse al programa de afiliados, los delincuentes deben abonar alrededor de 250 dólares en Monero (XMR), aunque el pago se elimina para usuarios de países de la Comunidad de Estados Independientes, una estrategia clara para atraer operadores de esa región.
A pesar de este enfoque comercial agresivo, en el portal de filtraciones de VECT solo aparecen por ahora dos víctimas confirmadas, comprometidas mediante una cadena de suministro vinculada al grupo TeamPCP. No obstante, la arquitectura del servicio, su integración con foros de la dark web y las alianzas con otros actores maliciosos evidencian la intención de construir una plataforma industrializada de ataques de ransomware.
El error criptográfico que convierte el ransomware en un wiper
Cifrado moderno en ransomware: qué debería ocurrir
Los grupos de ransomware actuales suelen utilizar esquemas criptográficos robustos, como ChaCha20-Poly1305 AEAD, que proporcionan confidencialidad y verificación de integridad. En este tipo de diseños, cada archivo se cifra con una clave y un valor de inicialización único (nonce), y se incluye información suficiente para que, en teoría, los atacantes puedan descifrar los datos tras el pago.
Cómo VECT 2.0 destruye archivos de más de 131 KB
En el caso de VECT 2.0, la implementación real se aleja de este estándar. Para archivos superiores a 131 072 bytes (aprox. 128–131 KB), el malware no realiza un cifrado recuperable, sino que corrompe irreversiblemente el contenido. Esto afecta de lleno a documentos empresariales, repositorios de código y, sobre todo, bases de datos, que suelen superar ampliamente ese tamaño.
El código, escrito en C++ para Windows, Linux y ESXi, divide los archivos grandes en cuatro bloques y los cifra con ChaCha20-IETF, generando un nonce aleatorio distinto para cada bloque. El problema es que solo se guarda en disco el último nonce. Los tres primeros, imprescindibles para descifrar las primeras tres cuartas partes del archivo, se generan, se usan y se pierden: no se almacenan ni localmente, ni en el registro, ni en la infraestructura del atacante.
Dado que cada bloque requiere tanto la clave como su nonce específico, las primeras tres cuartas partes de cualquier archivo grande son irrecuperables para todos, incluidos los operadores de VECT. En la práctica, VECT 2.0 se comporta como un wiper camuflado de ransomware: los datos se destruyen de forma definitiva aunque la negociación culmine y el rescate se pague.
BreachForums, TeamPCP y la explotación de la cadena de suministro
Los operadores de VECT 2.0 han tejido alianzas con el mercado criminal BreachForums y con la agrupación TeamPCP. Este ecosistema les permite aprovechar credenciales robadas y accesos previos, reduciendo la barrera de entrada para nuevos afiliados y acelerando la ejecución de ataques a través de proveedores y terceros. La combinación de RaaS maduro, grandes bases de datos de credenciales filtradas y foros especializados impulsa un modelo de distribución de ransomware cada vez más industrializado.
Versiones para Windows, Linux y ESXi: técnicas y errores de diseño
La variante de VECT 2.0 para Windows cifra unidades locales, extraíbles y recursos compartidos de red. Incorpora un amplio conjunto de mecanismos anti-análisis dirigidos contra numerosas herramientas de seguridad y depuración. Destaca el uso del modo seguro: con el parámetro --force-safemode, fuerza el siguiente arranque en Safe Mode y se registra para ejecutarse automáticamente, aprovechando que en este estado se cargan menos servicios y defensas.
Sin embargo, los controles de detección de máquinas virtuales y sandboxes en la versión para Windows no llegan a utilizarse en la práctica, lo que facilita el trabajo de analistas y soluciones de defensa, ya que el malware no activa parte de sus capacidades de evasión.
Las variantes para Linux y ESXi comparten gran parte del código. La compilación para ESXi aplica geofencing y comprobaciones anti-depuración antes de cifrar, e intenta propagarse por la red mediante SSH. Si detecta que se ejecuta en determinados países de la CEI, se detiene sin cifrar; de forma llamativa, Ucrania figura entre las exclusiones, algo poco habitual en RaaS recientes. Esta lista de países, unida a las fallas criptográficas y a comprobaciones de entorno sin uso real, sugiere que los desarrolladores son operadores relativamente inexpertos, probablemente apoyados en código heredado o fragmentos generados de forma automática.
Lecciones clave: por qué pagar el rescate no es una estrategia de recuperación
El caso de VECT 2.0 ilustra con claridad que el pago del rescate no puede considerarse un plan de recuperación. En muchos incidentes de ransomware documentados, las víctimas no recuperan todos sus datos pese a pagar; en VECT 2.0, la arquitectura del cifrado hace que la restauración sea técnicamente imposible para buena parte de los archivos afectados. El riesgo para la organización es doble: pérdida económica por el pago y pérdida permanente de la información crítica.
Para reducir el impacto de amenazas similares, las empresas deben priorizar copias de seguridad aisladas y probadas regularmente, segmentación de red, gestión estricta de privilegios, supervisión proactiva de la cadena de suministro y soluciones de detección y respuesta en endpoints y servidores. La formación continua de usuarios para reconocer señales tempranas de compromiso y la existencia de planes de respuesta a incidentes actualizados marcan la diferencia entre un incidente contenido y una pérdida catastrófica de datos. VECT 2.0 es un recordatorio de que incluso grupos aparentemente «amateurs», apoyados en modelos RaaS y recursos de la dark web, pueden poner en jaque infraestructuras críticas en Windows, Linux y ESXi; anticiparse, prepararse y ensayar la recuperación es hoy una obligación, no una opción.
