En el artículo de hoy os traigo otra herramienta que como pentesters deberemos de añadir a nuestro arsenal, se trata de VMInjector bypass authentication, con este script podremos hacer bypass authentication de los principales sistemas operativos instalados como máquinas virtuales en VMWare.
También puede servir para aquellos administradores de sistema que se olviden el password de alguna máquina virtual.
Tabla de Contenido
VMInjector bypass authentication bajar VMInjector
Primero de todo bajamos VMInjector del repositorio de Github.
https://github.com/batistam/VMInjector
Tiene soporte para sistemas x86 y x64.
¿Qué necesitamos?
- Una máquina Windows con permisos de administrador
- VMWare Workstation o VMWare player corriendo el sistema operativo.
- Python, VMInjector y como dependencia el módulo psutil.
Si estamos haciendo una auditoría, nos encontraríamos con esto:
Ahora lo que haremos es conseguir entrar en la máquina sin tener que conocer la contraseña.
Arrancamos VMINjector desde el CMD con permisos de administrador.
Escogemos el target que corresponde.
Ahora nos pregunta cual es el sistema operativo del que queremos hacer unlock.
Una vez que hagamos continuar nos dirigimos hacia la máquina virtual y…
Alguno puede pensar que no ha funcionado, pero solo deberemos de darle a INTRO para iniciar sesión.
Ya podremos iniciar sesión 😀
¿Cómo funciona VMInjector?
Inyecta una DLL (x86 y x64) en el proceso VMWare para obtener acceso a la memoria. Una vez mapeados sus recursos, parchea la función correspondiente para evadir la autenticación y así acceder al sistema operativo de la máquina virtual, ya sea Windows, Ubuntu o Mac OS X.
El parcheo en memoria no es persistente, así que al reiniciar la máquina virtual el proceso de autenticación volverá a la normalidad
Actualización 2026: el estado real de VMInjector
VMInjector es un proyecto congelado, no una herramienta vigente. El repositorio oficial (github.com/batistam/VMInjector) sigue siendo público y descargable: fue creado el 14 de noviembre de 2012, tiene apenas 3 commits, 238 estrellas y 82 forks, no está archivado pero no recibe actividad desde hace años. Fue escrito por Marco Batista en 2012 para demostrar que inyectar una DLL en el proceso del hipervisor permitía manipular la memoria del huésped y evadir la pantalla de autenticación de Windows, Ubuntu y Mac OS X; el parcheo en memoria nunca fue persistente y dependía de los formatos y firmas de sistemas operativos de su época.
Hay un detalle que delata la edad del artículo original: el enlace de la dependencia psutil apunta a code.google.com/p/psutil. Google Code anunció su cierre el 12 de marzo de 2015, pasó a solo lectura el 24 de agosto de 2015 y cerró definitivamente el 25 de enero de 2016. Ese enlace ya no funciona; psutil sigue siendo un paquete mantenido e instalable por los canales estándar (pip), pero el enlace del artículo original está muerto.
El concepto, sin embargo, sigue siendo peligrosamente relevante en otro nivel. Quien controla el host controla el huésped, y los atacantes modernos lo saben: en julio de 2024 Microsoft documentó la explotación como zero-day de la vulnerabilidad CVE-2024-37085, un bypass de autenticación en la integración de Active Directory de VMware ESXi, usada por al menos media docena de operaciones de ransomware (incluyendo Akira y Black Basta) para obtener privilegios administrativos completos sobre hipervisores ESXi unidos a dominio y cifrar sus sistemas de archivos de una sola vez. El objetivo de VMInjector (el plano de control de la virtualización) es exactamente el que persiguen los grupos de ransomware hoy.
Del PoC de 2010 al threat model actual
Desde la época de VMInjector, la defensa del hipervisor evolucionó de forma radical. vSphere 8.0 soporta vTPM 2.0 (módulo TPM virtual para cada máquina), que requiere firmware EFI, Secure Boot activado, hardware virtual 14 o superior y cifrado de la VM con un proveedor de claves; además, ESXi puede medirse y atestiguarse con TPM 2.0 y TXT antes de permitir cargas sensibles. En la práctica esto significa que un ataque como el de VMInjector —inyección en el proceso del hipervisor desde el propio host— choca hoy contra capas que no existían en 2012: arranque medido, atestación del host, VMs blindadas con estado de ejecución cifrado y bloqueo (lockdown) del plano de gestión.
Para la investigación de memoria de máquinas virtuales, la herramienta de referencia es hoy Volatility, que soporta los formatos de estado guardado de VMware (.vmss, .vmsn y .vmem) junto con raw dumps, crash dumps y volcados de VirtualBox. Con plugins como pslist, netscan, malfind e hivelist, un analista puede examinar la RAM de un huésped a partir de una instantánea o de un archivo .vmem suspendido: la misma disciplina forense de leer la memoria del huésped desde fuera, pero con un framework mantenido y orientado a respuesta a incidentes en lugar de un PoC de 2012.
¿Tu infraestructura virtualizada aguantaría un ataque al hipervisor?
VMInjector nació como prueba de concepto, pero el vector que explotaba es hoy un objetivo prioritario del ransomware: el host, el plano de gestión y la configuración de seguridad de tus máquinas virtuales. En DragonJAR evaluamos la seguridad real de entornos virtualizados —endurecimiento de hipervisores, revisión de configuraciones de vCenter/ESXi, gestión de privilegios y pruebas de intrusión sobre la infraestructura— antes de que un atacante lo haga. Conoce nuestros servicios de seguridad informática y pide una auditoría de tu plataforma de virtualización.
