Identidades NO Humanas (NHI "Non-Human Identities"): La Gestión de un Riesgo de Seguridad Emergente

Las Identidades No Humanas o Non Human identities (NHI) están últimamente en boca de todos los profesionales de la seguridad de la información y la ciberseguridad que centran su profesión en la gestión de Identidades Digitales. Es cierto que en este mundo Post-Covid, donde se produjo una proliferación del trabajo desde cualquier lugar, utilizando cualquier dispositivo (Anywhere and Anydevice) trajo asociado, en muchos casos, la eliminación del perímetro de red como capa de protección, al igual que las medidas de seguridad a nivel de puesto de trabajo.

Figura 1: Identidades NO Humanas (NHI "Non-Human Identities").

La Gestión de un Riesgo de Seguridad Emergente

Todo esto se produjo gracias a que se comenzó a fomentar que los usuarios se pudieran conectar desde cualquier dispositivo y desde cualquier ubicación. Ee esta manera la identidad, y más concretamente la seguridad en la identidad, pasa a ser el nuevo perímetro, la capa principal y, en muchas casos, única donde puedes poner medidas de seguridad ya que no hay control del dispositivo o la red de conexión desde la que el empleado se conecta.

La mayoría de las empresas entendieron muy pronto este desafío de seguridad y se pusieron manos a la obra implementando medidas de seguridad focalizadas en la protección de la identidad de los usuarios que consumían sus aplicaciones o servicios digitales, donde implementando un factor de autenticación robusto en la autenticación, como pueden ser los basados en Push notificaciones en dispositivos móviles, los basados en Biometría o incluso optando por Passkeys o Yubikeys para obtener una seguridad adicional y eliminar las passwords ya conseguías protegerte en gran medida.

Figura 2: Las Yubikeys

Adicionalmente, si esto lo combinabas con un sistema de “Unknown login location” simplemente geolocalizando la dirección IP pública desde la que los usuarios consumen los servicios digitales, y respondiendo con una verificación de la legitimidad cuando los usuarios intentan conectar de localizaciones que varían significativamente de las habituales, entonces ya estarías gestionando y controlando bastante bien el uso de las identidades digitales, al menos en lo que al proceso de autenticación se refiere.

Identidades No Humanas

Fenomenal, con lo que hemos explicado brevemente en la parte superior entendemos a grandes rasgos el paradigma de gestión las identidades digitales de los empleados (Humanos) que consumen los servicios digitales de nuestra organización. ¿Pero qué pasa con las Identidades No Humanas? O, mejor dicho, ¿Qué son las identidades no Humanas? ¿Por qué son importantes? ¿Hay algún motivo que nos haga pensar que el riesgo relacionado con las mismas está en aumento? 

Pues bien, a estas preguntas intentaremos darlas respuesta en este artículo y así clarificar igualmente si la gestión de las Identidades no Humanas (NHI) es simplemente una moda potenciada por los equipos marketing de los diferentes fabricantes de software de identidad que quieren subirse a este barco, o por el contrario es un riesgo emergente sobre el cual deberíamos empezar a actuar si aún no lo hemos hecho.

¿Qué son las Identidades No Humanas?

Empecemos explicando qué se entiende como una Identidad No Humana, donde de una manera muy simplista podemos definirla como toda aquella identidad que ejecuta una carga de trabajo y/o existe en un directorio de identidades pero que no está relacionado con una persona física (Humana). De esta manera, y desglosando un poco más, entendemos como Identidades No Humanas todas aquellas relacionadas con máquinas y dispositivos, como servidores, contenedores, estaciones de trabajo, dispositivos móviles, dispositivos de OT, dispositivos IOT, etcetera.

A estas hay que sumar todas las identidades relacionadas con cargas de trabajo de software, como cuentas de servicio, APIS, cuentas de conexión a Bases de Datos o Aplicaciones utilizadas por software, cuentas de ejecución de scripts, Robotic Process Automation (RPA), Chatbots, Agentes AI basados en LLMs., y un largo etcétera de cuentas que antes simplemente llamábamos "Cuentas de Servicios" y que ahora se están multiplicando por doquier, y empiezan a ser manejadas por modelos de Inteligencia Artificial o directamente Robots o Humanos Digitales, haciendo muchas más funciones y actividades que lo que haría un simple "servicio".

Por lo tanto, tenemos una gran variedad en cuanto a su tipología y que además se ha incrementado significativamente en los últimos años, donde hemos pasado de tener la sorprendente proporción de 1 Identidad Humana por cada 10 Identidades No Humanas, que era la figura que reportaban los analistas en 2020, a una proporción de 1 Identidad Humana por cada 50 Identidades No Humanas en 2025. Donde a día de hoy, incluso ciertos analistas consideran que la figura puede ser mayor y en algunos casos la proporciona se reporta como 1 Identidad Humana por cada 80 Identidades No Humanas.

Figura 3: Datos del "2025 Identity Security Landscape de CyberARK"

Tras observar la tendencia creciente en la proporción de Identidades Humanas versus Identidades No Humanas, y por lo tanto la necesidad de gestionar y proteger cada vez más identidades no humanas, procedamos dar respuesta a la segunda de nuestras preguntas.  

¿Por qué son importantes las Identidades No Humanas?

Son importantes porque en la mayoría de los casos tienen un nivel de privilegios alto y porque la gestión de las mismas no siempre es la ideal, pensemos simplemente si en algún caso tenemos una cuenta de servicio en nuestro directorio activo donde las credenciales llevan tiempo sin rotarse o si tenemos alguna API configurada para su acceso con un Clientid + Secret y si los mismos están o han podido estar "hardcodeados" en algún código, seguro que todos tenemos casos y estoo sin querer meternos en la gestión de los agente de IA que hacen uso de las tools mediante MCP Servers o escenarios más novedosos y de los que somos menos conscientes y por lo tanto tenemos menos sistemas protección, detección respuesta.

¿Está aumentando el riesgo asociado a las Identidades No Humanas?

Una vez hemos llegado a este punto estaremos en posición de determinar si el riesgo con la Identidades No Humanas está en aumento, donde teniendo en cuenta su incremento exponencial en las empresas y organizaciones, combinado con que en muchos casos la identidad es la única capa de seguridad que se dispone, que además estas NHI suelen privilegiadas, y que no se cuenta en la mayoría de los casos con herramientas o sistemas que permitan tener un monitorización y/o trazabilidad del uso y comportamientos de ellas, podemos fácilmente afirmar que las Identidades No Humanas y especialmente aquellas que tengan unos privilegios más altos, representan un botín más grande sin son comprometidas y son un objetivo claro y en aumento para cibercriminales.

Figura 4: Ciberataque contra Dropbox Sign en Incibe

Hoy en día ya se conocen públicamente graves incidentes de seguridad que de una manera u otra están relacionadas con la gestión - o errores en esta mejor dicho - de las Identidades No Humanas, como por ejemplo el incidente  de seguridad que sufrió Beyondtrust con la API Key que usaba para varios clientes en software de soporte remoto o el incidente de seguridad con el servicio Dropbox sign tras ser comprometida una cuenta de servicio y sobre el cual el propio Incibe hacía eco.

Conclusiones sobre Identidades No Humanas

Concluimos pues que la gestión de las Identidades No Humanas no es simplemente una moda. Es realmente es un riesgo de seguridad de emergente que muy probablemente ira apareciendo como un riesgo residual, con un riesgo residual cada más alto en los análisis de riesgos de todo tipo de compañías si no se empiezan a implementar controles mitigantes, donde la acciones que deberíamos empezar a plantearnos desde ya para las Identidades No Humanas deberían ser:

• Descubrir: Para poder gestionar o realizar cualquier otra acción primero debemos conocer nuestras identidades no humanas y esto no es una tarea sencilla

• Inventariar y clasificar: Debemos al menos ser capaces de asignar un propietario de cada identidad no humana, así como distinguir las privilegiadas de las no privilegiadas

• Gestionar el ciclo de vida: Por supuesto asegurando la terminación de las identidades no humanas que ya no son necesarias, la creación de nuevas identidades siguiendo las fases pertinentes de aprobación y con un propietario asignado, e idealmente realizando una revisión de privilegios o permisos de manera periódica, idealmente cada 6 meses

• Gestión de credenciales: Aquí deberíamos tener en cuenta el rotado de credenciales, el cifrado, el almacenamiento de la mismas en vaults de secretos cuando proceda, así como evitar que los secretos estén en repositorios de código o similar donde puedan ser accedidos sin mayores controles.

Una vez que tengamos estos cuatro puntos conseguidos o medio conseguidos, ya podríamos pensar en escenarios más avanzados como la detección de anomalías de uso de Identidades No Humanas o la protección en tiempo real de las mismas.

Saludos,

Autor: Samuel López Trenado, especialista en Gestión de Identidades Digitales

Contactar con Samuel López Trenado

Pentesting en Active Directory: Pass-the-ticket & Mimikatz

En el lado del mal hemos hablado de mucho Ethical Hacking durante años. Hemos hablado de herramientas como Mimikatz, quizá una de las más potentes y utilizadas en el Hacking de redes Windows internamente. Técnicas como, pass-the-hash, pass-the-ticket, golden & silver ticket, que Benjamin Delpy se ha encargado de ir metiendo a su querido Mimikatz. Con Benjamin Delpy coincidimos en la Euskalhack 2018 y fue bastante emocionante poder disfrutar de sus conocimientos en el congreso y en las cenas.

Figura 1: Pentesting en Active Directory: Pass-the-ticket & Mimikatz

Hoy no voy a hablar de algo nuevo que trae Mimikatz, si no que quiero hablar de conceptos de autenticación en el Active Directory, en este caso en Windows Server 2016, y cómo podemos aplicar la técnica Pass-the-ticket. Esta técnica tiene su análoga con pass-the-hash, de la cual ya hemos hablado en el blog en más de una ocasión.

 

Figura 2: Libro de Hacking Windows

Antes de entrar en materia, quiero recordar algunos de los artículos relacionados con Mimikatz que hemos ido haciendo y viendo en su momento. Es una navaja suiza en toda regla, con más de 9 años de desarrollo y sigue dando mucha guerra. Es algo digno de admirar. Recuerdo cuando salió DCShadow y la foto del niño que quería llegar a ser un Domain Controller. Hemos visto cómo poner una Skeleton Key al Domain Controller. Con Mimikatz hemos visto cómo extraer credenciales de memoria haciendo un minidump al proceso lsass.exe. También vimos como Zerologon llegaba a Mimikatz hace unos meses.

Kerberos in a nutshell

Si nos preguntamos qué es Kerberos, lo encontramos muy bien explicado en este post de los compañeros de Tarlogic. Podemos decir que es un protocolo de autenticación utilizado, por ejemplo, en el Active Directory. La idea del protocolo es que se sirvan una serie de tickets (o "vales" en alguna traducción al castellano, en alguna documentación) para poder acceder a ciertos recursos en el dominio. Podemos decir que existen tres roles diferentes dentro del esquema de autenticación en Kerberos:

- Usuario o cliente. Éste será el que pida el ticket y tenga que autenticarse para poder acceder al recurso. 

 

- KDC o Key Distribution Center. Éste es el servicio Kerberos. Se encarga de gestionar y emitir los tickets que serán utilizados por los clientes para acceder a los recursos o servicios. 

 

- AP o servicio de aplicación. Al final es el recurso al que el cliente quiere acceder. Lo hará a través del uso de un ticket que verifique que puede acceder al recurso.

Hay una serie de elementos clave que juegan un papel fundamental en la ecuación. A continuación, os dejo un resumen de las diferentes claves:

- Del usuario: Ésta será un hash (o un derivado más bien) ntlm. 

 

- De la cuenta krbtgt: El hash ntlm de la cuenta del KDC en el Domain Controller. 

 

- Del servicio: El servicio expuesto en el dominio tendrá una cuenta de servicio o de usuario que será el que lo habrá lanzado. 

 

- De sesión: Clave obtenida entre la negociación del KDC y del cliente. 

 

- De sesión de servicio: Clave obtenida para utilizarla entre el cliente y el servicio.

Ahora hablemos de los tickets. El primer ticket que trataremos es el TGT o Ticket Granting Ticket. Lo presentaremos ante el KDC para obtener el TGS o Ticket Granting Service. El TGT será cifrado con la clave del KDC, es decir, la clave derivada de la cuenta del krbtgt. A esto volveremos más adelante. El TGS se obtiene de un TGT enviado al KDC. El TGS lo presentaremos al servicio que tiene el recurso al que queremos acceder. El TGS es cifrado con la clave de servicio.

¿Cuál es el flujo normal de todo esto?

A priori, puede parecer algo complejo, pero no es así. Vamos a intentar simplificar el proceso. Partimos de tres máquinas con las siguientes configuraciones:

- Máquina Windows 10, la llamaremos A, en la que estoy yo.

- Domain Controller, la llamaremos KDC, con Windows Server 2016.

- Máquina Windows Server 2016, la llamaremos R de recurso, que no es Domain Controller o máquina Windows 10 que tiene un servicio al que queremos acceder.

Lo primero es solicitar un ticket TGT. Para ello mi máquina A envía una petición KRB_AS_REQ a la máquina KDC. En este mensaje la máquina A envía información como un timestamp que está cifrado con una clave derivada del hash del usuario, es decir, del hash de mi contraseña de dominio. En esta petición se envía el nombre de usuario, el SPN para la cuenta krbtgt y un nonce.

Cuando el KDC recibe esto, se valida la información cifrada, para ver si la clave de dicho usuario es correcta, es decir, descifra el contenido del timestamp. El KDC va a producir la respuesta KRB_AS_REP. En esta respuesta se envían varias cosas como, por ejemplo, el nombre de usuario, el ticket TGT y unos datos cifrados con la clave del usuario.

Estos datos cifrados con la clave del usuario, al volver a la máquina A podrían ser descifrados. ¿Qué me está devolviendo el KDC? La clave de sesión, que será importante, la fecha de expiración del TGT y un nonce. El ticket suele tener una validez de 10 horas. Esto puede ser alterado, y mucho, en un ataque Golden Ticket o Silver Ticket. ¿Qué encontramos en el TGT? Encontraremos el nombre de usuario, la clave de sesión de nuevo, la fecha de expiración y el PAC. El PAC es una estructura de datos que trae información sobre los privilegios. El TGT está cifrado con la clave de la cuenta krbtgt, es decir, con el KDC.

 

Figura 3: Máxima Seguridad en Windows Gold Edition

Ahora tenemos un ticket TGT en la máquina A. Este ticket nos vale para solicitar un TGS y poder acceder al recurso dentro del Active Directory que me interese y tenga acceso, claro. Desde la máquina A a la máquina KDC enviamos una petición KRB_TGS_REQ. Esta petición contiene lo siguiente:

- El nombre de usuario y timestamp cifrados con la clave de sesión. 

 

- El TGT que nos ha enviado en el paso previo, el cual se encuentra cifrado con la clave de krbtgt, es decir, con el KDC. 

 

- El SPN y un nonce.

Si todo sigue su curso, ¿qué nos devuelve el KDC? La máquina KDC envía una respuesta KRB_TGS_REP a la máquina A. En ella encontraremos:

- El nombre de usuario. 

 

- La clave de sesión, la fecha de expiración del TGS y un nonce cifrados con la clave de sesión. 

 

- La clave de sesión de servicio (esta es importante), nombre de usuario, fecha expiración del TGS y el PAC. Todo ello cifrado con el hash de la cuenta propietaria del servicio.

Ahora tenemos el ticket TGS. Ahora solo debemos enviarlo a la máquina R, la cual es la que tiene el recurso al que queremos acceder. Desde la máquina A se hace una petición KRB_AP_REQ a la máquina R. En esta petición se envía el ticket TGS cifrado con la clave de la cuenta propietaria del servicio.

Figura 4: Esquema de funcionamiento de Kerberos

Luego el nombre de usuario y el timestamp van cifrados con la clave de sesión de servicio. Cuando esta información llega a la máquina R, se valida y se da acceso al recurso. En la imagen del artículo de Tarlogic se detalla muy bien.

Ahora: Pass-the-ticket

Tras explicar el funcionamiento básico del protocolo Kerberos, vamos a ver un ataque llamado Pass-the-ticket y que consiste en hacer algo similar al Pass-the-hash pero en un entorno de Windows Server 2016 con un Active Directory. Es decir, haremos una suplantación de usuario, en vez de utilizando el hash ntlm de la cuenta del usuario, utilizaremos un ticket Kerberos con validez y que pertenezca a dicho usuario.

Figura 5: Libro Windows Server 2016:
Administración, Seguridad y Operaciones

¿Dónde podemos encontrar estos tickets? Al final cualquier máquina de un dominio hace uso de Kerberos, por lo que los tickets se encuentran en cada una de esas máquinas. Al llegar a una máquina de dominio, comprometerla y escalar privilegios, podemos hacer uso de Mimikatz para sacar partido en el Ethical Hacking.

Figura 6: Uso de klist

Con la herramienta klist podemos ver los tickets que se encuentran almacenados en la sesión del usuario. Es decir, los que utilizara cuando quiera acceder a los recursos de una máquina del dominio. Los tickets pueden ser TGT o TGS. En el caso de tener el TGT se hará el proceso para conseguir el TGS y llegar al recurso deseado. Si utilizamos Mimikatz con su módulo sobre Kerberos tenemos muchas opciones:

- La opción ptt. Nos permitirá hacer el Pass-the-ticket. 

 

- La opción list. Nos lista los tickets que tenemos en memoria en nuestra sesión. 

 

- La opción purge. Permite eliminar tickets de memoria en nuestra sesión. 

 

- La opción tgt. Para ver qué ticket estamos usando en memoria. 

 

- La opción golden. Nos permite generar Golden Tickets y Silver Tickets, pero esto lo hablaremos en otro artículo.

Con la instrucción “sekurlsa::tickets” podemos ver los tickets que hay en memoria en la máquina, los nuestros y los de otros usuarios. Esto es bastante poderoso, ya que podemos sacarle mucho juego. Por ejemplo, hacer la suplantación de otro usuario. Con la opción “sekurlsa::tickets /export” exportaremos todos los tickets a disco, con extensión *.kirbi.

Si nos quedamos con los ficheros kirbi que contienen “*Administrador@krbtgt*” tendremos un TGT y viendo la palabra Administrador o Administrator podemos pensar que estamos de suerte. En otras ocasiones, quizá solo nos interesa utilizar otros tickets para poder llegar a ciertos recursos. No todo es ser admin.

Figura 7: Ejecución de kerberos::ptt en Mimikatz

Ahora, nos vamos con los tickets recogidos a otra máquina. Podemos usarlos en máquinas que estén o no estén en el dominio. Es decir, podemos llevárnoslo a nuestra máquina y trabajar tranquilamente. Para hacer el pass-the-ticket ejecutamos "kerberos::ptt [ticket.kirbi]". Con el ticket anterior, intentamos leer el recurso c$ del Domain Controller y obtenemos la respuesta deseada. Tenemos acceso al Domain Controller.

Figura 8: Acceso al Domain Controller conseguido

La idea del artículo es mostrar cómo funciona Kerberos y mostrar un ejemplo de ataque en el Active Directory  a Kerberos. Existen muchas posibilidades y es un mundo interesante que se debe conocer para un pentesting interno en una organización. Sin duda, interesante el mundo Kerberos y sus ataques.

Saludos,

Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters: Gold Edition", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell (2ª Edición)”, "Pentesting con Kali Silver Edition" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox

 Contactar con Pablo González

Blue Team & Red Team: Cómo Parallels RAS Gateway Secure revela el espacio de direcciones IP interno de la organización. Leak++

Con la llegada apresurada del teletrabajo, muchas empresas han tenido que buscar soluciones rápidas para llevar los puestos de trabajo a la nube. Parallels RAS (Remote Application Server), es una solución de entrega de aplicaciones e infraestructura de escritorio virtual (VDI: Virtual Desktop Infrastructure) que permite a empleados y clientes de una organización acceder y utilizar aplicaciones, escritorios y datos desde cualquier dispositivo, gracias a las capacidades de virtualización que ofrece.

Figura 1: Blue Team & Red Team: Cómo Parallels RAS Gateway Secure revela el espacio de direcciones IP interno de la organización. Leak++

Con el uso de clientes VDI para acceder a los escritorios de trabajo, tenemos un entorno de tecnologías web para dar acceso a las redes de trabajo de una organización, y, por supuesto, para los que los que se dedican al Hacking de Web Technologies, esto es algo que hay que entender bien, pues nos vamos a encontrar expuestos a Internet estos puntos de acceso de las organizaciones.

Figura 2: Libro de Hacking Web Technologies (2ª Edición) en 0xWord de

Chema Alonso, Pablo González, Enrique Rando, Ricardo Martín y Amador Aparicio

En el artículo de hoy vamos a ver cómo es posible encontrar el espacio direcciones IP internas de una organización a partir de RAS Gateway Secure, lo que llevará a dar más información para futuros ataques de red IPv4&IPv6. Vamos a ver cómo funciona esto.

Arquitectura RAS

En la siguiente Figura 3 muestra un escenario en el que el RAS Secure Gateways HTML5 Portal se implementan en la DMZ. El servicio de  RAS Secure Gateway reenviará las peticiones vía HTTP a un host de sesión de escritorio remoto, RAS RD, que tendrá instalada la función de Servicios de Escritorio Remoto (RDS). 

Figura 3:Arquitectura de red para una infraestructura Parallels RAS Secure Gateway y RAS RD.

Como se aprecia, el Host RDP se encuentra dentro de la LAN de la organización, aunque también cabría la posibilidad de que estuviese dentro de una DMZ y así reducir la superficie de exposición de los activos de la red interna de la organización. 

Búsqueda de Parallels Remote Application Server

Buscar dispositivos RAS HTML5 Gateway accesibles desde Internet para un pentester es relativamente sencillo. Basta con consultar la Guía de administración del dispositivo para poder extraer patrones de las URLs y luego hacer un poco de Hacking con Buscadores, o usar las funciones avanzadas en el Pentesting con FOCA para llevar a nuestra herramienta a localizar esos puntos de entrada a la infraestructura RAS de la organización.

Figura 4: Guía de administración del dispositivo con información de las URL de acceso.

Como se ve en la imagen superior, las URLs de acceso a estos dispositivos tienen presentes las singularidades “/RASHTML5Gateway/” y “/RASHTML5Gateway/#/login”, lo que facilita en gran medida la localización del formulario de acceso de estos dispositivos conectados en Internet.

Figura 5: Resultados de las búsquedas con las singularidades en la URL.

Se observa que sin mucho esfuerzo en la realización de un dork, Google ofrece un buen número de resultados relacionados con el formulario HTML5 de acceso al portal web de los dispositivos, lo que sin duda hace fácil utilizar las opciones de búsqueda avanzada de FOCA.

Análisis del tráfico HTTP generado por el RAS de Parallels

Uno de aspectos más importantes en cualquier Ethical Hacking o auditoría relacionada con tecnologías web, sean del tipo que sean, es analizar las peticiones y respuestas HTTP para ver si el dispositivo revela información interesante que, a simple vista, y sin la ayuda de un proxy HTTP, podría pasar desapercibida. Para ello se selecciona uno de los resultados devueltos por Google y se observa que el formulario del RAS solicita en el campo del login un usuario centralizado un Active Directory (user@domain) y un password.

Figura 6: Formulario web de acceso al RAS de Parallels.

Utilizando ZAProxy, se observa como al pulsar directamente sobre le botón login, sin la necesidad de introducir un user@domain con contraseña, el RAS Secure Gateway genera una petición HTTP por POST al RAS RD donde releva cuál es su dirección IPv4.

Figura 7: Dirección IPv4 del RAS RD que recibe las peticiones de los recursos de virtualización.

Si el RAS RD se encuentra en la red interna de la organización, el espacio de direccionamiento IPv4 de la organización estaría quedando expuesto. En el mejor de los casos, si el RAS RD se encuentra en una zona desmilitarizada (DMZ), su espacio de direccionamiento IPv4 estaría quedando expuesto, aunque el impacto sería menor.

Cómo minimizar la fuga de información

Consultado la información ofrecida por el fabricante, cabe la posibilidad de que el RAS Secure Gateway pueda realizar las funciones de RAS RD dentro de la misma máquina. Como la máquina es la misma, todas las peticiones HTTP hacia los recursos virtualizados podrían realizarse sobre “localhost”. El resultado para este escenario sería el siguiente:

Figura 8: Petición HTTP desde el servicio del RAS Secure Gateway hacia el servicio RAS RD en la propia máquina.

La dirección IPv4 del RAS RD no estaría siendo revelada, pero sí que se estarían revelando los puertos TCP relacionados con el servicio RAS Secure Gateway (8080/TCP) y el RAS RD (8081/TCP).

Figura 9: Opciones de configuración del RAS Secure Gateway para referenciar al RAS RD. 

En el caso de que el RAS Secure Gateway y el RAS RD se encuentren en redes diferentes, parece muy complicado eliminar la fuga de información presentada en este artículo, debido a que el RAS Secure Gateway tiene que realizar una petición HTTP por POST para comunicarse con el RAS RD.

Saludos y Feliz Navidad,  

Autor: Amador Aparicio (@amadapa), escritor de los libros “Raspberry Pi para Hackers & Makers: PoCs & Hacks Just for Fun!” y "Hacking Web Technologies 2ª Edición" , CSE (Chief Security Envoy) de ElevenPaths. 

Figura 10: Contactar con Amador Aparicio en MyPublicInbox

Hacking Windows con Zerologon: Vulnerabilidad crítica que puede comprometer tu Domain Controller #Parchea

Zerologon es una de esas vulnerabilidades que sacuden al mundo de la ciberseguridad por varias razones. Es una de esas vulnerabilidades que aparecen cada cierto tiempo y que nos dejan un sabor agridulce. ¿Por qué? Las razones son obvias: sencillez de explotación, cualquiera puede obtener el exploit público y ejecutar con Python una línea que le dé el control total del dominio. Tan sencillo como lo pintan estas líneas. Detrás de ese exploit público y de las diferentes versiones que han salido, mucho trabajo de investigación, sin duda. Y tú debes actualizar cuanto antes.

Figura 1: Hacking Windows con Zerologon:

Vulnerabilidad crítica que puede comprometer tu Domain Controller

Otra de las razones es por lo que provoca, es una escalada de privilegios de 0 a 100, quizá en este caso de 0 a 1000, ya que provoca que un usuario cualquier, que ni siquiera está en el dominio pueda cambiar la contraseña de la máquina del DC y apoderarse de todo un dominio de una empresa, lo que hace que sea una de las técnicas que hay que tener presentes de hoy en adelante dentro de las formas en las que hacemos el Hacking de Windows. Cuando uno empieza leyendo la documentación de Zerologon de la empresa Secura se da cuenta de la gravedad y criticidad de la vulnerabilidad. 

Figura 2: Libro de Hacking Windows de 0xWord

Todo comenzó el pasado 11 de agosto cuando Microsoft habló de la vulnerabilidad del servicio Netlogon, pero, ¿qué es Netlogon Remote Protocol? Como bien han indicado los compañeros de hackplayers, Netlogon Remote Protocol es una interfaz RPC para los Controladores de Dominio (DC - Domain Controllers) - de los Directorios Activos (AD - Active Directory), el cual es utilizado para tareas, diferentes, de autenticación de usuarios y máquinas.

Figura 3: Detalles de la implementación del parche

El objetivo de este protocolo es facilitar que los usuarios inicien sesión en servidores utilizando NTLM, aunque no es solamente eso. También autenticación de respuestas NTP o permitir que un equipo actualice la contraseña en el dominio. Y una vez que se supo de la vulnerabilidad,  Microsoft publicó un parche en agosto, pero no será hasta febrero cuando la actualización se lleve por completo. 

Figura 4: Detalles de la implementación del parche (parte 2)

¿Esto quiere decir que la primera fase de la actualización no sirve? No es así. El parche funciona, pero hay que aplicar alguna configuración extra para asegurarse de que funciona. Así podíamos leer a mi compañero Sergio de los Santos hablando sobre esto.  Aparte de aplicar el parche de agosto, y esperar al de febrero, debemos verificar, para forzar, que la clave FullSecureChannelProtection tiene valor a “1”. 

Figura 5: Recomendaciones de Sergio de los Santos

Hay un debate sobre si la aplicación de la fase 1 del parche evita ya la posible explotación. Al menos verificando FullSecureChannelProtection y aplicando el parche los exploits públicos de hoy en día no funcionan. Lo que parece claro es que Microsoft no las tiene todas consigo y que matar la posibilidad de la conexión no segura es el camino que marca Microsoft para que podamos estar “más tranquilos”. Seguramente, en febrero obtendremos mayor detalle.

Cómo funciona Zerologon

Netlogon no usa un esquema de autenticación similar a otros servicios RPC. Utiliza un protocolo criptográfico personalizado. La idea es que cliente y servidor se demuestren que conocen el secreto compartido. El secreto compartido es un hash de la contraseña de la cuenta de equipo del cliente. Esto es debido a que Windows NT no podía hacer uso de esquemas estándar como NTLM o Kerberos. Si quieres conocer más sobre los mecanismos de autenticación en Windows, el libro de Máxima Seguridad en Windows Gold Edition escrito por nuestro compañeros Sergio de los Santos lo explica al detalle.

Figura 6: Máxima Seguridad en Windows Gold Edition

de Sergio de los Santos publicado en 0xWord

La implementación basada en AES-CFB8 no estaba correctamente realizada. El cliente y el servidor utilizan una función llamada ComputeNetlogonCredential, la cual no define IVs aleatorios y si los hace fijos con ceros (hasta 16 bytes). La probabilidad de “predecir” y obtener un bloque con todo ceros es baja para una clave aleatoria dada. 

Figura 7: Esquema de ataque Zerologon

En ese caso, comienza el despliegue que indica Secura en su paper. Aquí tenéis el esquema del ataque con detalle, el cual se puede ver en el paper.  A continuación resumimos los pasos:

Paso 1: Spoofing sobre las credenciales del cliente

Tras el intercambio de desafíos con NetrServerReqChallenge, el cliente se autentica así mismo haciendo una llamada a NetrServerAuthenticate3. El parámetro ClientCredential de la anterior llamada se calcula aplicando ComputeNetlogonCredential al desafío que se envío anteriormente. Este desafío puede ser elegido por nosotros, por lo que no hay que impida poner este desafío a 8 ceros. Como se indica en el paper, 1 de cada 256 claves de sesión, constará de 8 ceros. 

 

No podemos saber que nuestra sesión utiliza una de estas claves, pero cada vez que intentamos autenticar, el servidor seguirá generando un desafío único de servidor. Esto significa que la clave de sesión será diferente y, uniformemente distribuida. Las cuentas de equipo no se bloquean después de varios intentos fallidos, aquí hay un punto importante, por lo que podemos hacer fuerza bruta. El promedio esperado será de 256, lo que nos llevaría unos 3 segundos. De esta forma, se podrá iniciar sesión como cualquier equipo del dominio, incluyendo controladores de dominio.

Paso 2: Deshabilitando signing y sealing

En el paso anterior se puede lograr el bypass de la llamada de autenticación. Pero en este instante no se sabe cuál es el valor de la clave de sesión. Esto es un problema ya que el mecanismo de cifrado de Netlogon, firma y sellado RPC, se encuentra en otro esquema diferente al de la función ComputeNeglogonCredential que es la vulnerable. 

 

Por suerte, el firmar y sellar es opcional y se puede deshabilitar con el simple hecho de omitir un flag en la llamada a NetrServerAuthenticate3. Los clientes más actuales se negarán por defecto a conectarse cuando este flag no esté fijado por el servidor, sería una protección para prevenir ataques de downgrade, pero los servidores no rechazarán a estos clientes que no soliciten ningún tipo de cifrado. Este es un factor con un poco de suerte. En el momento que el servidor obligue, se solventaría en parte, aunque la función pueda seguir siendo vulnerable.

Paso 3: Falsificando una llamada

Cada llamada que puede aportar algo debe contener un valor de autenticación. El valor es calculado con ComputeNeglogonCredential, es decir, con la clave de sesión aplicado a ClientStoredCredential + Timestamp. ClientStoredCredential es un valor incremental que mantiene el cliente. Cuando se realiza el handshake se inicializa al mismo valor que el ClientCredential. Esta credencial de cliente consiste únicamente en varios ceros, por lo que ClientStoredCredential será 0 para la primera llamada realizada después de la autenticación.

El sello de tiempo o timestamp debe contener la hora actual de Posix y es incluido en la llamada del cliente. El servidor no pondrá muchas restricciones sobre cuál puede ser ese valor y tiene sentido, ya que cualquier mínima desviación del reloj podría dar problemas. Se puede “fingir” que es 1 de enero de 1970 y establecer el valor en 0. Se puede autenticar la primera llamada simplemente proporcionando un autenticador con todo cero y un timestamp con todo cero.

Paso 4: Cambiando el password de un equipo del AD

Aquí se utiliza la llamada NetrServerPasswordSet2, la cual es utilizada para establecer una nueva contraseña de equipo. La contraseña está cifrada con la clave de sesión utilizando el cifrado AES-CFB8 comentado anteriormente. La contraseña de texto en Netlogon constan de 516 bytes. Los últimos 4 bytes indica la longitud de la contraseña (en bytes). Los bytes que no forman para de la función de contraseña se verán como un relleno y pueden disponer de valores arbitrarios o aleatorios. 

 

Si se utilizan 516 ceros, se descifrará a 516 ceros. En otras palabras, contraseña de longitud cero, por lo que tendríamos una contraseña vacía y en una cuenta de equipo está permitido. Por ello en los ejemplos de explotación que se ven por Internet podemos ver el hash de la contraseña vacía, cuando se recupera con, por ejemplo, secretsdump.py.

Aquí ya se tiene gran parte del proceso hecho. Ahora se puede crear una nueva conexión de Netlogon en nombre de dicho equipo. Una vez hecho esto, se podrá cambiar a la contraseña que se quiera y restaurar, que es algo que también se ha estado viendo en Internet y que en los repositorios de Github dónde se puede encontrar las PoC se hace hincapié.

Paso 5: Administrador de dominio

En el documento de Zerologon se muestra cómo, a uno de los equipos que se puede cambiar la contraseña, es al propio Controlador de Dominio. En el momento que se hace, se consigue la escalada de privilegios total en el dominio. Pero antes de acabar hay que tener en cuenta que la contraseña del DC que se almacena en el AD o Active Directory es diferente de la contraseña almacenada en su registro local, cuya ruta es HKLM\SECURITY\Policy\Secrets\$machine.ACC.

Como esto puede generar comportamientos impredecibles, se utiliza secretsdump.py de Impacket con la nueva contraseña del equipo del DC. Este script puede volcar toda la información referente a los hashes.

Mimikatz actualizado con Zerologon

Una de las herramientas más utilizadas en los proyectos de Ethical Hacking y con más funcionalidades para el pentesgting de los sistemas Windows y de la que hablamos largo y tendido en nuestro libro de Hacking Windows, Mimikatz, ya ha lanzado una actualización para poder hacer la explotación de Zerologon.

Figura 8: GIF de ejemplo de Mimikatz explotando Zerologon

En la Figura 8 os dejamos el GIF que ha publicado GentilKiwi en su Github sobre la implementación de Mimikatz con Zerologon.

Test & PoC’s & Detección de Zerologon

La gente de Secura publicó una herramienta a modo de test para que los administradores comprobasen si su DC es vulnerable a esta técnica. La herramienta indica claramente que no realiza ninguna modificación, simplemente chequea que la vulnerabilidad está ahí y hay que parchear. Para poder ejecutarla hay que instalar las dependencias de Python.

Figura 9: instalando las dependencias con Python

Posteriormente, se indica el nombre de la máquina y la dirección IP y ahí lo tenemos. En este ejemplo se ve como mi DC sería vulnerable. 

Figura 10: Comprobando si el DC es vulnerable o no

    
Ahora, si probamos sobre mi dominio la herramienta secretsdump.py introduciendo la contraseña de dominio veremos que la máquina HC-SERVER$ tiene un hash, que no corresponde con el hash nulo.

Figura 11: Explotando la vulnerabilidad Zerlogon

Si lanzáramos alguna de las versiones de exploits públicos que hay por Internet veríamos como el hash de la cuenta de equipo HC-SERVER$ cambia a su representación del hash nulo. Por lo que podríamos autenticar con ese hash una cuenta de equipo y poder acceder a la información.

Figura 12: Ejemplo de cómo se puede volcar el domino completo

En Twitter son muchos los mensajes de ejemplo que muestran que diferentes exploits públicos funcionan, lo que muestra la necesidad de parchear ya. En la Figura 12, se puede ver cómo tras lanzar el exploit y utilizar secretsdump.py se puede hacer un volcado completo del dominio. Si mirásemos la cuenta de la máquina del DC, veríamos que está con el valor del hash nulo. Y en la siguiente imagen os dejo un hilo de Carlos García hablado de la detección de Zerologon con ejemplo sobre los eventos a los que poner el foco. Recomendado.

Also, look for 2 password changes (event 4742) of the DC computer account in a short period of time. This password is only changed automatically every 30 days by default, so 2 changes in a short period of time is suspicious.
Anyway, patch now :) [3/3] pic.twitter.com/WnQjkMoosr

— Carlos García ciyi (@ciyinet) September 16, 2020

Sin duda es momento de verificar que las actualizaciones de agosto están aplicadas, de verificar que el parámetro FullSecureChannelProtection está a 1 y utilizar la herramienta de Secura para verificar que nuestros DCs no son vulnerables. Pronto vendrá el módulo de Metasploit, seguramente, y todo será, si cabe, más sencillo. Por último, hay repositorios de Github de BlackArrow, NCC o Dirk-janm los cuales han implementado diferentes versiones de este exploit. Hay que #ParchearYa.

Patch, Patch & Patch!!!

 Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell”, "Pentesting con Kali Silver Edition" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox

Figura 14: Contactar con Pablo González

Hacking Windows: Introducción a los ataques de “Abuse Active Directory ACLs & ACEs”

Las empresas han tenido y tienen un directorio activo para la organización de los recursos, la gestión de políticas de seguridad, para controlar las acciones, para un montón de finalidades. Es uno de los elementos clave cuando se hace un Ethical Hacking interno. Hay que saber manejarse con él, ya que las posibilidades que éste ofrece son casi infinitas.

Figura 1: Hacking Windows: Introducción a los ataques de
“Abuse Active Directory ACLs & ACEs”

En el pasado, hemos hablado de cómo llevar a cabo enumeración de usuarios con herramientas de Kali Linux a través de llamadas RPC. El pentesting a Directorio Activo abarca un gran número de técnicas, tanto de enumeración como de ataque que son interesantes estudiarlas. Es casi un “must” en los proyectos de Ethical Hacking.

Figura 2: Pentesting con Kali Silver Edition

Antes de hablar del tema del artículo de hoy, el cual es el cómo detectar que tenemos ACLs y ACEs en el Active Directory mal configuradas y que se puede aprovechar en un Hacking Windows de ello para tomar la identidad o privilegios de otro usuario, incluyendo alguna escalada de privilegio a "admin". del dominio, quería ver algunos comandos de interés que se pueden utilizar en las pruebas de hoy.

Figura 3: Hacking Windows: "Ataques a sistemas y redes Microsoft"

Pero antes de nada vamos a ver algunas órdenes útiles, ya que si se compromete un proceso de un usuario de dominio en un pentesting, se pueden ejecutar algunos de los siguientes comandos para recopilar cierta información. Lo primero es saber que el proceso que se ha comprometido pertenece a un usuario que está en dominio y no es un usuario local. Tenemos una serie de variables de entorno que estarán configuradas con información como, por ejemplo:

• USERDOMAIN. Indica el usuario de dominio que somos. Esto es equivalente al “getuid” de un Meterpreter. 

 

• LOGONSERVER. Esta variable de entorno nos dará información sobre el controlador de dominio que se ha utilizado para la autenticación. 

 

• El comando net user [usuario] /domain nos dará información sobre un usuario del dominio concreto. Lógicamente, esa máquina debe estar “atada” al dominio. 

 

• El comando net users /domain proporciona información sobre los usuarios del dominio. 

 

• El comando net groups /domain nos devuelve los grupos que hay en el dominio. 

 

• El comando net group [grupo] /domain devuelve información concreta de un grupo.

Para el artículo de hoy vamos a trabajar con Powersploit y, en particular, con PowerView. De este tipo de conjunto de scripts se habla bastante en el libro de Pentesting con Powershell 2ª Edición.

Abuse: Derechos de Generic All en grupos. A por la escalada

Existen muchas formas de detectar una mala configuración de permisos en el directorio activo. En algunas ocasiones se delegan permisos de forma no segura, quedando una mala configuración de permisos en el directorio activo. Esto es lo que vamos a aprovechar para poder escalar privilegios, metiéndonos en el grupo de administradores de dominio o tomando la identidad de otro usuario con o sin privilegios.

Figura 4: PowerSploit

Dar permisos de control total a un grupo de usuarios o a un usuario en concreto sobre algún objeto de Active Directory puede tener consecuencias graves. Con el comando Get-ObjectAcl de PowerView podemos encontrar este tipo de permisos interesantes.  Si nos fijamos en la siguiente instrucción:

‘Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Admins. del dominio,CN=Users,DC=hc,DC=local" -and $_.SecurityIdentifier -eq “[SID]”}’ 

nos vamos a fijar en el CN de Admins. Del Dominio y vamos a ver si el SID del usuario que hemos comprometido tiene algún tipo de permiso. El SID acabado en 1103 de la Figura 4 pertenece al usuario del proceso que hemos comprometido, es decir, tengo algún tipo de derecho sobre el CN de Administradores del Dominio. La sorpresa viene cuando vemos que ActiveDirectoryRights es ‘GenericAll’. 

 

Figura 5: Pentesting con PowerShell

Si revisamos la información del usuario ‘pablo’, que es el del SID acabado en 1103, vemos que no pertenece al grupo de Administradores del Dominio, pero tiene la posibilidad de pertenecer, ya que tiene permisos para ello, por una mala configuración. Este es un caso llevado al extremo, quizá no encontremos un usuario concreto, pero sí un grupo al que pertenece el usuario y podamos hacer lo mismo. O en otras ocasiones, no tendrá derechos ‘GenericAll’, pero quizá otro tipo de derechos menos ‘potentes’, pero que pueden dar el mismo resultado. Todo es ir mirando la configuración de las ACLs y los ACEs. 

Figura 6: Usuario 'pablo' no es Admin, pero podría serlo

Ahora, ejecutamos la instrucción net group “Admins. del dominio” pablo /add /domain y el usuario pertenecerá a los Administradores del Dominio, ya que por la mala configuración detectada se puede hacer. Como se puede ver en la imagen, se ha conseguido una escalada de privilegio de manera sencilla en el dominio.

Figura 7: Hemos hecho al usuario pablo administrador del dominio

Generic All sobre un usuario

En el caso de encontrarte un derecho ‘GenericAll’ sobre un usuario concreto podremos tomar la identidad de dicho usuario de manera sencilla. Puede haber o no escalada, dependiendo de los privilegios que tenga el usuario en el dominio, y de lo bien o mal que haya sido fortificado el servidor Windows Server a la hora de configurar su seguridad.

Figura 8: Windows Server 2016: Administración, Seguridad y Operaciones

La instrucción para consultar este hecho es la siguiente:

‘Get-ObjectAcl -SamAccountName [nombre_usuario] -ResolveGUIDs | ? {$_.ActiveDirectoryRights -eq "GenericAll"}’

De esta forma consultamos los permisos. En este caso lo hacemos sobre el usuario ‘fran’ y observamos que el usuario con SID acabado en 1103, es decir, el usuario ‘pablo’ tiene un control total sobre el objeto ‘fran’. De nuevo una mala configuración que permite, entre otras cosas, cambiar la credencial.

Figura 9: Pablo tiene control total sobre Fran

Para comprobar un posible cambio de credencial, ejecutamos el siguiente comando ‘net user fran [contraseña_nueva] /domain. Lo normal sería no poder hacer esto, pero en este caso, y debido a una mala configuración, obtenemos un premio.

Figura 10: Cambio de contraseña para el usuario Fran

Ahora podemos ejecutar un terminal o un proceso con la identidad del usuario ‘fran’, tal y como puede verse en la siguiente imagen.

Figura 11: Suplantando a Fran para ejecutar un terminal

Write Property & Self-Membership

Estos ‘rights’ son también interesantes. Cuando los encontramos combinados tenemos muchas posibilidades de poder hacer escalada. En este caso hemos vuelto a poner la lupa sobre el CN de Admins. del dominio.

Figura 12: CN=Admins. del dominio

Este tipo de derecho permite al usuario poder escribir y modificar o agregar usuario al grupo, en este caso. Cuando este tipo de situación se detecta podemos pasar al grupo de Administradores del Dominio, como hemos hecho anteriormente. 

Figura 13:  Pasando al grupo de "Administradores del Dominio"

El estar revisando la configuración de las ACLs puede ser un trabajo de tiempo, aunque es fundamental para mantener la seguridad de los sistemas operativos Windows. Para ello tenemos herramientas que nos ayudan a detectar este tipo de situaciones. Además, haciendo uso del lenguaje y filtros de Powershell podemos optimizar este tiempo.

Figura 14: Máxima Seguridad en Windows Gold Edition

Existen más situaciones en las ACLs y ACEs del Directorio Activo que debemos tener en cuenta:

• ForceChangePassword 

 

• WriteOwner sobre un grupo concreto 

 

• GenericWrite sobre un usuario 

 

• WriteDACL + WriteOwner

Como se puede ver es un tema que requiere de conocimiento de cómo funcionan los permisos en un nivel avanzado en el directorio activo y de tener ciertos conceptos identificados. Es un tema bastante interesante y que se puede poner en práctica y es necesario para evaluarlo en un pentesting.

Saludos,

 Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell”, "Pentesting con Kali Silver Edition" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox

Figura 15: Contactar con Pablo González