Password Spraying Overview

El rociado de contraseñas puede permitir el acceso a sistemas y, potencialmente, la entrada en la red objetivo. El ataque consiste en intentar iniciar sesión en un servicio expuesto utilizando una contraseña común y una lista extensa de nombres de usuario o direcciones de correo electrónico. Los nombres de usuario y los correos electrónicos pueden haberse recopilado durante la fase OSINT de la prueba de penetración o durante nuestros intentos iniciales de enumeración. Recuerde que una prueba de penetración no es estática, sino que itera constantemente con diversas técnicas y repite procesos a medida que descubrimos nuevos datos. A menudo, trabajaremos en equipo o ejecutaremos varias TTP a la vez para optimizar nuestro tiempo. A medida que avanzamos en nuestra carrera, descubriremos que muchas de nuestras tareas, como escanear, intentar descifrar hashes, etc., requieren bastante tiempo. Debemos asegurarnos de utilizar nuestro tiempo de forma eficaz y creativa, ya que la mayoría de las evaluaciones tienen un límite de tiempo. Por lo tanto, mientras realizamos nuestros intentos de envenenamiento, también podemos utilizar la información disponible para intentar obtener acceso mediante el rociado de contraseñas. Ahora cubramos algunas de las consideraciones para la pulverización de contraseñas y cómo hacer nuestra lista de objetivos a partir de la información que tenemos.

La hora del cuento

El rociado de contraseñas puede ser una forma muy efectiva de establecerse internamente. En muchas ocasiones, esta técnica me ha ayudado a establecerme durante mis evaluaciones. Tenga en cuenta que estos ejemplos provienen de evaluaciones de "caja gris" no invasivas en las que tuve acceso a la red interna con una máquina virtual Linux y una lista de rangos de IP dentro del alcance, y nada más.

Escenario 1

En este primer ejemplo, realicé todas mis comprobaciones estándar y no encontré nada útil, como una sesión SMB nula o un enlace anónimo LDAP, que me permitiera recuperar una lista de usuarios válidos. Por lo tanto, decidí usar la Kerbruteherramienta para crear una lista de nombres de usuario objetivo enumerando los usuarios válidos del dominio (una técnica que abordaremos más adelante en esta sección). Para crear esta lista, tomé la jsmith.txtlista de nombres de usuario del repositorio de GitHub statistically-likely-usernames y la combiné con los resultados que obtuve al rastrear LinkedIn. Con esta lista combinada, enumeré los usuarios válidos con Kerbrutey luego usé la misma herramienta para rociar contraseñas con la contraseña común Welcome1. Obtuve dos coincidencias con esta contraseña para usuarios con privilegios muy bajos, pero esto me dio suficiente acceso dentro del dominio para ejecutar BloodHound y, finalmente, identificar las rutas de ataque que llevaron a la vulneración del dominio.

Escenario 2

En la segunda evaluación, me enfrenté a una configuración similar, pero al enumerar usuarios válidos del dominio con listas de nombres de usuario comunes, los resultados de LinkedIn no arrojaron ningún resultado. Busqué en Google archivos PDF publicados por la organización. Mi búsqueda generó muchos resultados y, en las propiedades del documento de cuatro de ellos, confirmé que la estructura interna del nombre de usuario tenía el formato F9L8, GUID generados aleatoriamente usando solo letras mayúsculas y números ( A-Z and 0-9). Esta información se publicó con el documento en el Authorcampo y demuestra la importancia de depurar los metadatos del documento antes de publicar nada en línea. A partir de aquí, se pudo usar un breve script de Bash para generar 1 679 616 posibles combinaciones de nombres de usuario.

#!/bin/bash

for x in {{A..Z},{0..9}}{{A..Z},{0..9}}{{A..Z},{0..9}}{{A..Z},{0..9}}
    do echo $x;
done

Luego usé la lista de nombres de usuario generada Kerbrutepara enumerar todas las cuentas del dominio. Este intento de dificultar la enumeración de nombres de usuario me permitió enumerar todas las cuentas del dominio gracias al GUID predecible en uso, combinado con los metadatos PDF que pude localizar, lo que facilitó enormemente el ataque. Normalmente, solo puedo identificar entre el 40 % y el 60 % de las cuentas válidas usando una lista como jsmith.txt. En este ejemplo, incrementé significativamente mis probabilidades de éxito en un ataque de rociado de contraseñas al iniciar el ataque con todas las cuentas del dominio de mi lista objetivo. A partir de aquí, obtuve contraseñas válidas para algunas cuentas. Finalmente, pude seguir una compleja cadena de ataque que incluía la Delegación Restringida Basada en Recursos (RBCD) y el ataque de Credenciales en la Sombra para finalmente obtener el control del dominio.

Consideraciones sobre la pulverización de contraseñas

Si bien la pulverización de contraseñas es útil para quienes realizan pruebas de penetración o para quienes participan en equipos de seguridad, su uso descuidado puede causar daños considerables, como el bloqueo de cientos de cuentas de producción. Un ejemplo son los intentos de fuerza bruta para identificar la contraseña de una cuenta utilizando una larga lista de contraseñas. En cambio, la pulverización de contraseñas es un ataque más controlado, que utiliza contraseñas muy comunes en diversos sectores. La siguiente tabla muestra una pulverización de contraseñas.

Visualización de Password Spray

Ataque	Nombre de usuario	Contraseña
1	[e-mail]	Bienvenido1
1	[e-mail]	Bienvenido1
1	[e-mail]	Bienvenido1
DEMORA
2	[e-mail]	Contraseña
2	[e-mail]	Contraseña
2	[e-mail]	Contraseña
DEMORA
3	[e-mail]	Invierno2022
3	[e-mail]	Invierno2022
3	[e-mail]	Invierno2022

Implica enviar menos solicitudes de inicio de sesión por nombre de usuario y es menos probable que bloquee cuentas que un ataque de fuerza bruta. Sin embargo, la pulverización de contraseñas aún presenta el riesgo de bloqueos, por lo que es esencial introducir un retraso entre los intentos de inicio de sesión. La pulverización interna de contraseñas puede utilizarse para moverse lateralmente dentro de una red, y se aplican las mismas consideraciones respecto a los bloqueos de cuentas. No obstante, es posible obtener la política de contraseñas del dominio con acceso interno, lo que reduce significativamente este riesgo.

Es común encontrar una política de contraseñas que permite cinco intentos fallidos antes de bloquear la cuenta, con un límite de desbloqueo automático de 30 minutos. Algunas organizaciones configuran límites de bloqueo de cuentas más amplios, incluso requiriendo que un administrador desbloquee las cuentas manualmente. Si desconoce la política de contraseñas, una buena regla general es esperar unas horas entre intentos, lo cual debería ser suficiente para que se restablezca el límite de bloqueo de la cuenta. Es recomendable obtener la política de contraseñas antes de intentar el ataque durante una evaluación interna, pero esto no siempre es posible. Podemos ser precavidos y optar por un solo intento de rociado de contraseñas dirigido utilizando una contraseña débil o común como medida de salvaguardia si se han agotado todas las demás opciones para obtener un punto de acceso o ampliar el acceso. Dependiendo del tipo de evaluación, siempre podemos pedir al cliente que aclare la política de contraseñas. Si ya tenemos un punto de acceso o se nos proporcionó una cuenta de usuario como parte de las pruebas, podemos enumerar la política de contraseñas de varias maneras. Practiquemos esto en la siguiente sección.