Defensa Activa: Cyber Deception en el Directorio Activo 2/2

¡Hola de nuevo!

En el post de hoy vamos a continuar el artículo sobre tecnologías de engaño o Deception Technologies, cuya primera parte tenéis aquí. Si no la has leído aún, échale un ojo antes de comenzar este ;) ¡Arrancamos!

Creando una campaña de engaño para proteger el Directorio Activo

Simplifiquémoslo, para cazar adversarios que estén intentando atacar nuestro DA, vamos a partir de la hipótesis de que un/os adversario/s han comprometido - o comprometerán - uno o varios equipos de usuario y reduciremos nuestro objetivo a los atacantes que estén tratando de realizar las siguientes acciones de reconocimiento con el posible objetivo de acceder a información confidencial.

Con nuestro objetivo claro, tenemos que analizar nuestro entorno y, a continuación:

Definir qué activos de deception vamos a desplegar
Definir dónde los vamos a desplegar
Y, además, crear la historia

Qué y dónde lo tenemos claro: usuarios y políticas de deception en nuestro DA de producción y en endpoints de usuarios comprometidos o susceptibles de serlo.

Crear la historia

La historia en este caso es sencilla, para detectar adversarios que estén intentando obtener credenciales de usuarios del directorio activo para, por ejemplo, acceder a información confidencial, crearemos un nuevo subdominio y nueva unidad de trabajo con dos usuarios nuevos para un proyecto confidencial y atractivo para el atacante de reciente creación - por ejemplo, el desarrollo de algún software. Este grupo de usuarios tendrá una GPO que cargue una carpeta compartida en su entorno - que estará abierta erróneamente a cualquier usuario -. En esta carpeta se encontrarán varios documentos relacionados con el supuesto proyecto y, entre ellos, un documento con información sobre cómo acceder a un servidor para probar el software que se está desarrollando.

Por tanto, para montar este entorno necesitaremos:

Crear un nombre atractivo para el nuevo proyecto: NuevoProyectoSuperSecreto
Crear los elementos de engaño en el Directorio Activo
Desplegar la máquina que contendrá el supuesto software
Crear los documentos a incluir en la carpeta compartida
Inyectar los breadcrumbs en los equipos de usuario elegidos

Preparar el entorno

Vamos paso a paso, primero vamos a crear el subdominio, la OU, los usuarios, las políticas y la carpeta compartida. En nuestro caso, hemos creado la carpeta compartida en un Windows Server cuya localización es «\\SERVFOLDERS\documents», el subdominio «secretproject.labo.deception», la OU «NuevoProyectoSuperSecreto», la GPO «shared» para cargar la carpeta compartida como una unidad al inicio y los usuarios «User4» y «User5» dentro de la nueva OU.

A continuación, vamos a desplegar el servidor que contendrá el portal web en la red de producción, en alguna localización creíble y apetecible para el adversario. Nosotros - como esto es una prueba de concepto - hemos añadido una máquina linux a nuestro laboratorio y hemos desplegado un portal web con una página de login para descargar y probar el supuesto software. El portal es sencillo, si se accede con las credenciales correctas saltará un mensaje de WIP - Work In Progress.

Ahora es el momento de crear los documentos que encontraremos en la carpeta compartida. Dado que se trata de un proyecto de desarrollo de un software, en esta carpeta dejaremos varios documentos relacionados con el diseño del software, planes de pruebas, guías de usuario y un documento Microsoft Excel con información sobre la infraestructura donde se encuentra - o se encontrará - el portal web para la descarga del software.

Crear la campaña de engaño

Bien, ya que lo tenemos todo preparado, es momento de crear nuestro entorno de engaño: vamos a crear e instrumentar nuestros activos de engaño y a crear las reglas de monitorización.

Vamos a la consola de gestión de CounterCraft y creamos la nueva campaña. Aunque parezca que nuestra campaña tiene muchos elementos, realmente tan solo necesitaríamos uno o dos servidores de engaño: el servidor que contiene el portal para la descarga del software y, si hemos creado un servidor dedicado para ello, el servidor que contiene la carpeta compartida. Dependiendo de la campaña, la carpeta compartida puede estar en un servidor de producción, por lo que no se instalará ningún agente de monitorización, sino que se controlarán solo los accesos a esa carpeta.

El siguiente paso es desplegar nuestras pistas o breadcrumbs. Por un lado, vamos a «beaconizar» los documentos que desplegaremos en la carpeta compartida - por motivos de confidencialidad no podemos explicar aquí cómo se crean los «beacon».

Nuestra carpeta compartida tiene la siguiente estructura:

README.txt
Diseño (carpeta)
- NuevoProyectoSuperSecreto_diseño.docx
- NuevoProyectoSuperSecreto_requisitos.docx
Desarrollo (carpeta)
- NuevoProyectoSuperSecreto_plan_de_implementación.pdf
Pruebas (carpeta)
- NuevoProyectoSuperSecreto_plan_de_pruebas.docx
- NuevoProyectoSuperSecreto_ejecución_de_pruebas.xlst
- NuevoProyectoSuperSecreto_infraestructura_dev.xlst

A continuación, vamos a inyectar los breadcrumbs en los equipos de usuarios que creamos que están comprometidos o que los consideremos susceptibles de serlo. Para ello, inyectamos en el LSSAS las credenciales del usuario User4 en el equipo COMP2 y del usuario User5 en el equipo COMP3.

En la siguiente imagen podemos ver el escenario:

Y en la siguiente, los dos attack tree que seguiría un adversario:

Por último, vamos a configurar las reglas de detección:

Acceso a breadcrumb: regla para detectar los accesos a los documentos de la carpeta compartida
Acceso a carpeta compartida: regla para detectar los accesos a la carpeta compartida
Login válido en el portal web: regla para detectar los login válidos en el portal web
Login inválido en el portal web: regla para detectar los intentos de login en el portal web

Monitorización de la campaña - actividad del adversario

Ya lo tenemos todo montado, ahora sería el momento de esperar a que nuestros adversarios encuentren nuestro entorno de engaño, pero como esto es una prueba de concepto, nosotros vamos a simular la actividad del adversario.

Siguiendo el Attack Tree 1, partimos de la hipótesis de que un adversario ha comprometido el equipo COMP2 del usuario User1 mediante el envío de spear-phishing y ha escalado privilegios a administrador local de la máquina. Entre las actividades maliciosas que realiza, está la de hacer un DUMP del LSSAS. Entre las credenciales, encontrará los del usuario User4 que pertenece al dominio «secretproject.labo.deception».

A continuación, utiliza estas credenciales para iniciar sesión en el mismo equipo COMP2. Al iniciar sesión con este usuario, se carga la carpeta compartida. El adversario la encuentra y accede a ella.

En este punto, recibimos una notificación que nos indica el acceso a la carpeta compartida con el usuario User4 y la IP desde donde se ha accedido. Esto nos indica que el equipo User1 - y el equipo COMP2 - ha sido comprometido.

Siguiendo el Attack Tree 2, partimos de la hipótesis de que un adversario está realizando actividades de reconocimiento, y encuentra información sobre el nuevo proyecto: dominio, la OU, los usuarios, los equipos y la GPO que carga la carpeta compartida.

Haciendo uso de un usuario previamente comprometido - diferente al User4 y User5 - accede a la carpeta compartida.

En este punto, recibimos una notificación que nos indica el acceso a la carpeta compartida con el usuario User2 y la IP desde donde se ha accedido. Esto nos indica que el usuario User2 está comprometido.

Siguiendo el Attack Tree 3, un adversario puede estar haciendo un escaneo de la red donde se encuentra nuestra carpeta compartida en red y acceder a ella con un usuario comprometido.

En este punto, recibimos una notificación que nos indica el acceso a la carpeta compartida con el usuario User3 y la IP desde donde se ha accedido. Esto nos indica que el usuario User3 está comprometido.

Aquí convergen nuestros tres primeros Attack Trees. Una vez en la carpeta compartida, el adversario navegará por los documentos hasta encontrar el excel con la información del portal para la descarga del software en pruebas.

Mientras tanto, recibiremos notificaciones que nos indican apertura de estos documentos:

Si abrimos las notificaciones, podemos ver más información sobre la apertura: user-agent y el breadcrumb al que se accede:

El siguiente paso que realizará el adversario será acceder al portal web:

E introducir las credenciales que ha encontrado en el documento excel. Una vez iniciada sesión, se encontrará con el mensaje de WIP - Work In Progess.

Mientras tanto, nosotros recibiremos la notificación del inicio de sesión válido:

Veamos ahora el último Attack Tree. Un adversario puede estar haciendo un escaneo de la red donde se encuentra nuestro portal web de deception e intentar acceder, hacer fuerza bruta, etc.

Mientras tanto, recibiremos notificaciones de toda la actividad e información sobre los usuarios y contraseñas que se están utilizando, el user-agent, etc.

Para terminar...

Vamos a destacar tres puntos principales que, con solo crear unos pocos activos de engaño, hemos conseguido:

Detectar adversarios que estaban paseándose a sus anchas por nuestra red sin ser detectados.
Obtener inteligencia sobre estos adversarios, es decir, inteligencia específica sobre nuestros adversarios: qué quieren, cómo se mueven, qué les motiva, qué recursos tienen, qué nivel de conocimiento, etc.
Y, por supuesto, hemos conseguido que nuestros adversarios malgasten recursos y pierdan el tiempo intentando atacar nuestro entorno de engaño.

Pero esto es solo un pequeño ejemplo de todo lo que podemos hacer con las plataformas de deception.

Podemos inyectar credenciales de engaño de manera masiva en equipos de usuario y monitorizar su uso desde otras herramientas de seguridad. Cualquier uso de esos usuarios será ilegítimo y, por tanto, será un indicador que el equipo donde se encuentra ese breadcrumb está comprometido.

Podemos crear campañas para proteger nuestra DMZ, para protegernos de los ataques en fase de reconocimiento, campañas enfocadas en la Dark Web, campañas para OT, IoT, ..., en conclusión: los límites están allá donde nos llegue la imaginación - y los recursos por supuesto.

Y aquí termina la segunda y última parte de este artículo sobre Deception Technologies. Espero que os haya parecido interesante y hayáis aprendido algo nuevo. ¡Hasta la próxima!

Marta de la Cruz

Deception Specialist & Threat Hunter

Entelgy Innotec Security

Referencias

[1] https://arxiv.org/pdf/2104.03594.pdf
[2] https://military.wikia.org/wiki/Military_deception#cite_note-Handel215-10
[3] https://books.google.es/books/about/The_Cuckoo_s_Egg.html?id=9B1RfCAar2cC&printsec=frontcover&source=kp_read_button&hl=en&redir_esc=y#v=onepage&q&f=false
[4] https://www.countercraftsec.com/
[5] https://attack.mitre.org/
[6] https://engage.mitre.org/

Investigaciones