Técnicas varias
Última actualización
¿Te fue útil?
Última actualización
¿Te fue útil?
El 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
Un ejemplo clásico es , 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.
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.
Una vez creado el nuevo archivo, podemos usar la flag -decode para decodificar el archivo a su contenido original.
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.
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 Installer
User Configuration\Administrative Templates\Windows Components\Windows Installer
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.
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 SYSTEM.
Podemos cargar este archivo MSI en nuestro destino, iniciar un escucha Netcat y ejecutar el archivo desde el CMD de la siguiente manera:
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.
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 se 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.
Nota: Los pasos anteriores se realizaron utilizando el navegador Chrome y pueden diferir ligeramente en otros navegadores.
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.
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 NT AUTHORITY\SYSTEM en el 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.
Enumeración del campo Descripción de equipo con el cmdlet Get-WmiObject
Técnicas varias
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.
En la siguiente sección profundizamos más sobre esta técnica:
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).
Utilizando las técnicas de esta sección, busque la contraseña en texto plano de una cuenta en el host de destino.
Una vez conectador por RDP abrimos un Powershell como administrador..
Al enumerar los usuarios del sistema vemos que en el campo Description del usuario secsvc tenemos las credenciales del usuario. Eso es bastante común en entornos Active Directory, y es algo que siempre deberíamos comprobar cuando tenemos acceso a un sistema Windows unido a un dominio.
Se puede utilizar un binario como 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.
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 como , 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 ( ) que contiene un certificado con el campo SpcSpAgencyInfo rellenado con un hipervínculo.
Microsoft lanzó un 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 enumera todas las versiones de Windows Server y Workstation vulnerables.
Podemos utilizar el comando para enumerar las tareas programadas en el sistema.
También podemos enumerar tareas programadas utilizando el cmdlet de PowerShell
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 .
También podemos enumerar el campo de descripción de la computadora a través de PowerShell usando el cmdlet con la clase .
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 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.
En Windows, podemos hacer clic derecho sobre el archivo y elegir Mount, o usar la utilidad Disk Management para montar un archivo .vhdo .vhdx. Si lo preferimos, podemos usar el cmdlet 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 archivo .vmdk, podemos hacer clic derecho y elegir Map Virtual Disk del 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 en VMWare Workstation File --> Map Virtual Disks para asignar el disco a nuestro sistema base. También podríamos agregar el archivo .vmdk 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 archivo vmdk . Esta ilustra muchos métodos para obtener acceso a los archivos de un archivo .vmdk.
¿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 directorio C:\Windows\System32\Config y extraer los subárboles de registro SAM, SECURITY y SYSTEM. Luego podemos usar una herramienta como para extraer los hashes de contraseñas de los usuarios locales.
