Hunting the credentials harvester!
Recientemente encontré un tweet que hacía referencia a la recolección de credenciales a lo largo de una red con un video que me pareció sumamente ilustrativo (y gracioso).
Esto me hizo recordar que, durante unas pruebas de intrusión en las que el equipo de pentesting utilizaba técnicas de volcado de la SAM y el LSA Secrets de forma remota, los fabricantes de seguridad, de forma nativa, no parecían enterarse de lo que estaba ocurriendo ni facilitaban la telemetría necesaria para su detección.
Por ello, me lo apunté en el TODO con la idea de probar dichas técnicas en mi laboratorio para ver como funcionaban y que oportunidades de detección se generaban.
LABORATORIO
Como entorno de laboratorio he aprovechado el fantástico proyecto “DetectionLab” que da la posibilidad de desplegar de forma muy sencilla un entorno virtual simulando un pequeño entorno empresarial con multitud de herramientas y sistemas de seguridad ya desplegados.
A nivel de hardware lo he desplegado sobre un servidor ProLiant ML150 Gen9 que pude adquirir de segunda mano y al cual le he instalado la plataforma de virtualización EXSI 6.5. A nivel de hardware dispone de las siguientes características:
- 2 x Intel(R) Xeon(R) CPU E5–2609 v3 @ 1.90GHz
- 80 GB RAM
- 2.5 Tb
Remarcar que los requisitos mínimos para desplegar el proyecto son mucho menores y podría llegar a ser desplegado en un equipo convencional un poco potente sobre todo en cuanto a RAM se refiere.
De forma adicional al entorno descrito, he añadido una Kali Linux desde la que ejecuto las diferentes pruebas. En este caso, ejecutaremos las pruebas contra la máquina Windows 10 del entorno.
Antes de entrar en materia vamos a introducir un par de conceptos que nos ayudaran a situar la situación.
SAM: Security Account Manager
La SAM es un fichero de base de datos que contiene y gestiona los usuarios y grupos locales del sistema encargándose de autenticar los accesos de este tipo de usuarios. El fichero asociado a la SAM se encuentra bajo el directorio “C:\Windows\System32\config”. A su vez, las funciones HASH de las contraseñas de los usuarios locales que almacena la SAM pueden ser encontradas y accedidas bajo la clave de registro “HKEY_LOCAL_MACHINE\SAM” y son estas las que son comprobadas durante un proceso de autenticación local. Recalcar que, si el equipo se encuentra dentro de dominio, los accesos de usuarios de dominio son autenticados contra la base de datos del directorio activo correspondiente.
Pese a que el acceso a la SAM se encuentra restringido, se suelen requerir de permisos de administrador, la información que esta contiene puede ser de gran interés para los atacantes. El volcado de la SAM o SAM Dumping (T1003.002) es la técnica por la cual el atacante accede a la información que esta contiene ya sea a través del acceso directo al fichero o del volcado de la clave de registro.
LSA Secrets
Los secretos del LSA son objetos gestionados por el Local Security Authority Subsystem Service (LSASS) y que únicamente pueden ser accedidos con permisos de la cuenta SYSTEM. Estos secretos se encuentran almacenados y cifrados dentro del registro de Windows bajo la clave “HKEY_LOCAL_MACHINE/Security/Policy/Secrets”.
Según se dicta en la documentación de Microsoft relativa al proceso de gestión de credenciales realizada en los sistemas Windows, estos secretos pueden contener credenciales asociadas a diversos elementos:
- Contraseña de la cuenta de Servicios de Dominio de Active Directory (AD DS) del ordenador.
- Contraseñas de cuentas para los servicios de Windows configurados en el equipo.
- Contraseñas de cuentas relativas a las tareas programadas configuradas.
- Contraseñas de cuentas para grupos de aplicaciones y sitios web de IIS.
- Contraseñas de cuentas de Microsoft.
LETS HUNT!
Para empezar, ejecutamos el ataque desde nuestra máquina Kali con la herramienta crackmapexec. En la primera prueba ejecutamos el ataque asociado al volcado de la SAM valiéndonos de las credenciales de administrador vagrant/vagrant de la máquina Windows 10 de nuestro laboratorio.
Lo primero que vemos en la ejecución es que se utiliza el protocolo SMB por lo que es de esperar ver un evento de autenticación de red en el destino. De esta forma, observamos que se produce una autenticación tipo 3 derivada de la conexión SMB desde el host con dirección IP 192.168.0.13 correspondiente a la Kali desde la cual hemos lanzado el ataque. A esta sesión se le asigna el LogonID 0x1839666 el cual, junto con el SID, nos permitirá rastrear las acciones realizadas por el usuario durante la sesión.
Para acotar en el tiempo los eventos en los que tenemos que fijarnos buscamos cuando el usuario VAGRANT, con loggonID 0x1829666, cierra la sesión. A través del evento 4634 vemos que el proceso de acceso, volcado y transferencia de la SAM duró apenas 3 segundos.
Con una ventana temporal definida, continuamos analizando los eventos generados. El siguiente evento que nos llama la atención es el 7040 cuya fuente es el SCM (Service Control Manager) y es generado cuando se modifica el tipo de inicio de un servicio. El Administrador de Control de Servicios de Windows permite la configuración remota de servicios a través de RPC (Remote Procedure Call). A su vez ,es posible acceder a llamadas RPC a través de SMB.
Como se puede ver, el servicio modificado es el RemoteRegistry el cual permite a los usuarios acceder al registro de Windows de forma remota. Este servicio se encontraba deshabilitado y vemos como, a través del SCM, de forma remota se solicita su arranque. De esta forma los atacantes se aseguran que el servicio se encuentre en ejecución cuando intenten acceder al mismo.
El evento 13 de sysmon para la monitorización de modificaciones en el registro también nos corrobora esta acción sobre la clave “HKLM\System\CurrentControlSet\Services\RemoteRegistry\Start” estableciendo el valor “0x3” solicitando el inicio del servicio.
Lo siguiente que llama la atención es la generación de múltiples eventos 5145 y 5140 asociados con solicitudes de acceso para las acciones de lectura y borrado sobre el fichero “C:\Windows\System32\Hyylojmn.tmp”. Este comportamiento podemos corroborarlo analizando el código del proyecto “impacket” el cual utilia el script “secretsdump.py” utilizado en la herramienta crackmapexec.
- El usuario vagrant con sesión 0x1839666 solicita el acceso al recurso C:\Windows\SYSTEM32\Hyylojmn.tmp correspondiente al fichero en el que se han volcado los valores del registro asociados a la SAM. En este caso, los accesos que se comprueban son de lectura (0x1) para poder transferir los datos que este contiene.
2. De forma inmediata, a través del 5140, vemos como se produce el acceso a al recurso compartido para la transferencia de la información extraída.
3. A continuación, se vuelve a observar un evento 5145 solicitando acceso al mismo fichero. Presumiblemente esto se realiza para intentar no dejar rastro y dificultar su detección.
Adicionalmente, la creación del fichero la podemos ver con el evento 11 de SYSMON. Observando el proceso que crea el volcado del registro vemos que, al igual que el resto de servicios de Windows, el nuestro (RemoteRegistry) está siendo ejecutado a través de una instancia de “svchost.exe” con PID 1088.
Buscando por las acciones que ha realizado este proceso vemos que de forma previa a la creación del fichero, ha cargado la librería “REGSVC.DLL” en la cual se encuentran definidas las funcionalidades del servicio de registro remoto.
Por último, antes de cerrar la sesión, se registra una modificación del servicio de acceso remoto al registro por la cual se vuelve a deshabilitar tal y como se encontraba anteriormente.
Al igual que cuando se habilitó, también podemos verlo a través del evento 13 de Sysmon. En este caso, se evidencia a través de la modificación de la correspondiente clave de registro.
Las imágenes de los eventos mostrados son las asociadas a la ejecución de crackmapexec para el volcado de la SAM. Sin embargo, el proceso para el volcado de los secretos es exactamente igual y generan los mismos eventos por lo que lo visto ahora es totalmente extrapolable para el otro caso.
CONCLUSIONES
Como vemos en la siguiente tabla, durante todo el proceso se generan diferentes eventos que podrían llegar a suponer oportunidades de detección.
Algo interesante a probar en un entorno real podría ser la búsqueda de intentos de habilitación de forma remota del servicio de acceso remoto al registro (RemoteRegistry).
En este caso no se han encontrado que evidencien el acceso a las claves de registro relacionadas con la SAM o el LSA Secrets. Sysmon dispone de los eventos 12, 13 y 14 pero hacen referencia a acciones que implican modificaciones y en este caso únicamente se produce lectura. Por otra parte, si habilitamos la auditoría del registro de Windows y creamos las correspondientes SACLs relativas a las claves de registro que contienen la SAM y el LSA Secrets, podríamos generar nuevas oportunidades de detección a través de los eventos de Windows 4663 o 4656.
REFERENCIAS
- Security Account Manager (SAM) | Microsoft Docs
- Audit SAM (Windows 10) — Windows security | Microsoft Docs
- OS Credential Dumping: Security Account Manager, Sub-technique T1003.002 — Enterprise | MITRE ATT&CK®
- OS Credential Dumping: LSA Secrets, Sub-technique T1003.004 — Enterprise | MITRE ATT&CK®
- Credentials Processes in Windows Authentication | Microsoft Docs
- GitHub — clong/DetectionLab: Automate the creation of a lab environment complete with security tooling and logging best practices
- GitHub — byt3bl33d3r/CrackMapExec: A swiss army knife for pentesting networks
- Administrador de control de servicios — Win32 apps | Microsoft Docs
