Técnicas varias
Living Off The Land Binaries and Scripts (LOLBAS)
El proyecto LOLBAS documenta archivos binarios, scripts y bibliotecas que se pueden utilizar para técnicas de "vivir de la tierra" en sistemas Windows. Cada uno de estos archivos binarios, scripts y bibliotecas es un archivo firmado por Microsoft que es nativo del sistema operativo o se puede descargar directamente desde Microsoft y tiene una funcionalidad inesperada que puede resultar útil para un atacante. Algunas funciones interesantes pueden incluir:
Ejecución de código
Compilación de código
Transferencias de archivos
Persistencia
Omisión de UAC
Robo de credenciales
Proceso de volcado de memoria
Registro de teclas
Evasión
Secuestro de DLL
Transferencia de archivos con Certutil
Un ejemplo clásico es certutil.exe , cuyo uso previsto es gestionar certificados, pero también se puede utilizar para transferir archivos, ya sea descargando un archivo al disco o codificando/decodificando base64 un archivo.
Codificación de archivos con Certutil
Podemos usar la flag -encode para codificar un archivo usando base64 en nuestro host de ataque de Windows y copiar el contenido a un nuevo archivo en el sistema remoto.
Decodificación de archivos con Certutil
Una vez creado el nuevo archivo, podemos usar la flag -decode para decodificar el archivo a su contenido original.
Se puede utilizar un binario como rundll32.exe para ejecutar un archivo DLL. Podríamos utilizarlo para obtener un shell inverso ejecutando un archivo .DLL que descargaríamos en el host remoto o que alojaríamos nosotros mismos en un recurso compartido SMB.
Vale la pena revisar este proyecto y familiarizarse con tantos binarios, scripts y bibliotecas como sea posible. Podrían resultar muy útiles durante una evaluación evasiva o una en la que el cliente nos restrinja a una instancia de servidor/estación de trabajo Windows administrada para realizar la prueba.
Always Install Elevated
Esta configuración se puede establecer a través de la Política de grupo local configurando Always install with elevated privileges en Enabled en las siguientes rutas.
Computer Configuration\Administrative Templates\Windows Components\Windows InstallerUser Configuration\Administrative Templates\Windows Components\Windows Installer
Enumerar configuraciones "Always Install Elevated"
Enumeremos esta configuración.
Nuestra enumeración nos muestra que la key AlwaysInstallElevated existe, por lo que la política está habilitada en el sistema de destino.
Generar paquete MSI malicioso
Podemos explotar esto generando un paquete MSI malicioso y ejecutándolo a través de la línea de comandos para obtener un shell inverso con privilegios de SISTEMA.
Ejecutando el paquete MSI
Podemos cargar este archivo MSI en nuestro destino, iniciar un escucha Netcat y ejecutar el archivo desde la línea de comando de la siguiente manera:
Recibiendo la shell
Si todo va según lo previsto, recibiremos una conexión de vuelta como NT AUTHORITY\SYSTEM.
Este problema se puede mitigar deshabilitando las dos configuraciones de política de grupo local mencionadas anteriormente.
CVE-2019-1388
CVE-2019-1388 era una vulnerabilidad de escalada de privilegios en el cuadro de diálogo de certificado de Windows, que no aplicaba correctamente los privilegios de usuario. El problema estaba en el mecanismo UAC, que presentaba una opción para mostrar información sobre el certificado de un ejecutable, abriendo el cuadro de diálogo de certificado de Windows cuando un usuario hace clic en el enlace. El campo Issued By en la pestaña General se representa como un hipervínculo si el binario está firmado con un certificado que tiene Identificador de objeto (OID) 1.3.6.1.4.1.311.2.1.10. Este valor de OID se identifica en el encabezado wintrust.h como SPC_SP_AGENCY_INFO_OBJID , que es el campo SpcSpAgencyInfo en la pestaña de detalles del cuadro de diálogo del certificado. Si está presente, un hipervínculo incluido en el campo se representará en la pestaña General. Esta vulnerabilidad se puede explotar fácilmente utilizando un antiguo ejecutable firmado por Microsoft ( hhupd.exe ) que contiene un certificado con el campo SpcSpAgencyInfo rellenado con un hipervínculo.
Al hacer clic en el hipervínculo, se abrirá una ventana del navegador que se ejecutará como NT AUTHORITY\SYSTEM. Una vez abierto el navegador, es posible "salir" de él aprovechando la opción View page source del menú para iniciar un cmd.exe o PowerShell.exe como SYSTEM.
Repasemos la vulnerabilidad en la práctica.
Primero haga clic derecho en el ejecutable hhupd.exe y seleccione Run as administrator
A continuación, haga clic en Show information about the publisher's certificate para abrir el cuadro de diálogo del certificado. Aquí podemos ver que el campo SpcSpAgencyInfo está completo en la pestaña Detalles.
A continuación, volvemos a la pestaña General y vemos que el campo Issued by está lleno con un hipervínculo. Haga clic en él y luego en OK. Se cerrará el cuadro de diálogo del certificado y se abrirá una ventana del navegador.
Si abrimos Task Manager, veremos que la instancia del navegador se lanzó como SYSTEM.
A continuación, podemos hacer clic derecho en cualquier parte de la página web y elegir View page source. Una vez que se abra la fuente de la página en otra pestaña, haga clic derecho nuevamente y seleccione Save as, y Save Asse abrirá un cuadro de diálogo.
En este punto, podemos iniciar cualquier programa que queramos como SYSTEM. Escriba la ruta c:\windows\system32\cmd.exe y presione Enter. Si todo sale como lo planeado, tendremos una instancia de cmd.exe ejecutándose como SYSTEM.
Microsoft lanzó un parche para este problema en noviembre de 2019. Aun así, como muchas organizaciones no aplican los parches, siempre debemos verificar esta vulnerabilidad si obtenemos acceso a la GUI de un sistema potencialmente vulnerable como un usuario con pocos privilegios.
Este enlace enumera todas las versiones de Windows Server y Workstation vulnerables.
Nota: Los pasos anteriores se realizaron utilizando el navegador Chrome y pueden diferir ligeramente en otros navegadores.
Tareas programadas
Enumeración de tareas programadas
Podemos utilizar el comando schtasks para enumerar las tareas programadas en el sistema.
Enumeración de tareas programadas con PowerShell
También podemos enumerar tareas programadas utilizando el cmdlet de PowerShell Get-ScheduledTask .
De forma predeterminada, solo podemos ver las tareas creadas por nuestro usuario y las tareas programadas predeterminadas que tiene cada sistema operativo Windows. Lamentablemente, no podemos enumerar las tareas programadas creadas por otros usuarios (como los administradores) porque se almacenan en C:\Windows\System32\Tasks, a las que los usuarios estándar no tienen acceso de lectura. No es raro que los administradores del sistema vayan en contra de las prácticas de seguridad y realicen acciones como proporcionar acceso de lectura o escritura a una carpeta generalmente reservada solo para administradores. Es posible que nos encontremos (aunque es poco frecuente) con una tarea programada que se ejecuta como administrador configurado con permisos de archivo/carpeta débiles por diversas razones. En este caso, es posible que podamos editar la tarea en sí para realizar una acción no deseada o modificar un script ejecutado por la tarea programada.
Comprobación de permisos en el directorio C:\Scripts
Consideremos un escenario en el que nos encontramos en el cuarto día de un ensayo de penetración de dos semanas. Hemos obtenido acceso a un puñado de sistemas hasta el momento como usuarios sin privilegios y hemos agotado todas las opciones de escalada de privilegios. Justo en ese momento, notamos un C:\Scriptsdirectorio en el que se puede escribir que pasamos por alto en nuestra enumeración inicial.
Observamos varios scripts en este directorio, como db-backup.ps1, mailbox-backup.ps1, etc., que también son todos editables por el BUILTIN\USERSgrupo. En este punto, podemos agregar un fragmento de código a uno de estos archivos con la suposición de que al menos uno de ellos se ejecuta a diario, si no con mayor frecuencia. Escribimos un comando para enviar una señal de vuelta a nuestra infraestructura C2 y continuamos con las pruebas. A la mañana siguiente, cuando iniciamos sesión, notamos una sola señal en NT AUTHORITY\SYSTEMel host DB01. Ahora podemos asumir con seguridad que uno de los scripts de respaldo se ejecutó durante la noche y ejecutó nuestro código adjunto en el proceso. Este es un ejemplo de lo importante que puede ser incluso la más mínima información que descubrimos durante la enumeración para el éxito de nuestro compromiso. La enumeración y la postexplotación durante una evaluación son procesos iterativos. Cada vez que realizamos la misma tarea en diferentes sistemas, podemos estar ganando más piezas del rompecabezas que, cuando se juntan, nos llevarán a nuestro objetivo.
Campo de descripción de usuario/equipo
Comprobación del campo de descripción del usuario local
Aunque es más común en Active Directory, es posible que un administrador de sistemas almacene detalles de la cuenta (como una contraseña) en un campo de descripción de la cuenta de un usuario o de una computadora. Podemos enumerar esto rápidamente para usuarios locales mediante el cmdlet Get-LocalUser .
Enumeración del campo Descripción de equipo con el cmdlet Get-WmiObject
También podemos enumerar el campo de descripción de la computadora a través de PowerShell usando el cmdlet Get-WmiObject con la clase Win32_OperatingSystem .
Técnicas varias
Montar VHDX/VMDK
Durante nuestra enumeración, a menudo nos encontraremos con archivos interesantes tanto a nivel local como en unidades compartidas de red. Podemos encontrar contraseñas, claves SSH u otros datos que se pueden utilizar para facilitar nuestro acceso. La herramienta Snaffler puede ayudarnos a realizar una enumeración exhaustiva que de otro modo no podríamos realizar a mano. La herramienta busca muchos tipos de archivos interesantes, como archivos que contienen la frase "pass" en el nombre de archivo, archivos de base de datos de KeePass, claves SSH, archivos web.config y muchos más.
Tres tipos de archivos específicos de interés son los archivos .vhd, .vhdxy .vmdk. Estos son Virtual Hard Disk, Virtual Hard Disk v2(ambos utilizados por Hyper-V) y Virtual Machine Disk(utilizados por VMware). Supongamos que llegamos a un servidor web y no hemos tenido suerte escalando privilegios, por lo que recurrimos a la búsqueda a través de recursos compartidos de red. Nos encontramos con un recurso compartido de copias de seguridad que aloja una variedad de archivos .VMDKy .VHDXcuyos nombres de archivo coinciden con los nombres de host en la red. Uno de estos archivos coincide con un host en el que no pudimos escalar privilegios con éxito, pero es clave para nuestra evaluación porque hay una sesión de administrador de Active Domain. Si podemos escalar a SYSTEM, es probable que podamos robar el hash de contraseña NTLM del usuario o el ticket TGT de Kerberos y tomar el control del dominio.
Si encontramos alguno de estos tres archivos, tenemos opciones para montarlos en nuestros equipos de ataque locales de Linux o Windows. Si podemos montar un recurso compartido desde nuestro equipo de ataque de Linux o copiar uno de estos archivos, podemos montarlos y explorar los distintos archivos y carpetas del sistema operativo como si estuviéramos conectados a ellos usando los siguientes comandos.
Montar VMDK en Linux
Técnicas varias
Montar VHD/VHDX en Linux
Técnicas varias
En Windows, podemos hacer clic derecho sobre el archivo y elegir Mount, o usar la Disk Managementutilidad para montar un archivo .vhdo .vhdx. Si lo preferimos, podemos usar el cmdlet Mount-VHD de PowerShell. Independientemente del método, una vez que lo hagamos, el disco duro virtual aparecerá como una unidad con letras que luego podremos explorar.
Para un .vmdkarchivo, podemos hacer clic derecho y elegir Map Virtual Diskdel menú. A continuación, se nos solicitará que seleccionemos una letra de unidad. Si todo va según lo previsto, podemos explorar los archivos y directorios del sistema operativo de destino. Si esto falla, podemos usar VMWare Workstation File --> Map Virtual Diskspara asignar el disco a nuestro sistema base. También podríamos agregar el .vmdkarchivo a nuestra VM de ataque como un disco duro virtual adicional y luego acceder a él como una unidad con letra. Incluso podemos usarlo 7-Zippara extraer datos de un vmdkarchivo . Esta guía ilustra muchos métodos para obtener acceso a los archivos de un .vmdkarchivo.
Recuperación de hashes mediante Secretsdump.py
¿Por qué nos importa un disco duro virtual (especialmente Windows)? Si podemos localizar una copia de seguridad de una máquina activa, podemos acceder al C:\Windows\System32\Configdirectorio y extraer los SAMsubárboles de registro SECURITYy SYSTEM. Luego podemos usar una herramienta como secretsdump para extraer los hashes de contraseñas de los usuarios locales.
Técnicas varias
Es posible que tengamos suerte y recuperemos el hash de la contraseña del administrador local para el sistema de destino o encontremos un hash de contraseña de administrador local antiguo que funcione en otros sistemas del entorno (ambas cosas que he hecho en bastantes evaluaciones).
Caso práctico
Pregunta 1
Acceda a la máquina de destino con las credenciales de Peter y verifique qué aplicaciones están instaladas. ¿Qué aplicación está instalada y se utiliza para administrar y conectarse a sistemas remotos?
Última actualización
¿Te fue útil?
