Jugando con GPOs III - Cómo detectar ataques sobre GPOs en tu Directorio Activo

¡Muy buenas a todos!

Como ya comentamos en el primer artículo de esta serie, Windows permite activar el registro de modificaciones, creaciones y eliminaciones de las GPO de manera nativa en cualquier Controlador de Dominio. Esto nos permitiría, entre otras cosas, detectar posibles cambios no esperados en las GPO desplegadas en el Dominio. Dicho esto, visto lo que hemos reflejado en el artículo anterior, ¿con cuanto detalle podremos llegar a detectarlo con estos logs? Veámoslo.

Supongamos que conocemos conocemos lo que ha pasado con exactitud: El usuario Gauss ha creado una GPO (con permisos laxos) llamada GPO_Vulnerable y la ha asignado a la unidad organizativa Servidores_Web. Por otro lado, Pitágoras, usuario sin priivlegios, ha abusado de dicha política para añadirse como administrador local de WEB-01 y , posteriormente, se ha conectado por Powershell Remota.

Detectando el despliegue

1. ¿Cuándo y quién creó la política GPO_Vulnerable?

Sencillo, el evento 5137 tiene la respuesta. La GPO con ID {E2FE8993-F346-41F9-8C27-B1CC4E8C9D40} fue creada por el usuario Gauss (Domain Admin), el día 22/11/2020 a las 8:08 AM.

Fig 1: Contenido del evento 5137.

2. ¿Es una política transversal para todo el dominio o solo aplica a un grupo o unidad organizativa específica?

En este caso, el evento 5136 nos da la respuesta. El campo gPLink nos indica que se ha registrado el enlace de esta política a todos los miembros de la unidad organizativa Servidores_Web.

Fig 2: Contenido del evento 5136.

3. ¿Dónde podemos confirmar que estos datos son ciertos?

Para confirmar que lo que acabamos de observar en los logs es correcto y no hemos sido engañados, podemos acceder al Group Policy Management.

Fig 3: El ID único pertenece a la GPO_Vulnerable que, a su vez, aplica al OU Servidores_Web.

Detectando el abuso

4. ¿Quién ha abusado de la GPO?

De nuevo, el evento 5136 tiene la respuesta. Nuestro querido amigo Pitágoras ha modificado la política GPO_Vulnerable aunque, poco más podemos intuir.

Fig 4: Contenido del evento 5136 tras la modificación de Pitágoras.

Nota: Este evento es un tanto traicionero porque bajo el mismo identificador puede registrar cambios de mucha índole; enlace de política a un nuevo grupo o unidad organizativa, una manipulación vacía (abrirla y cerrar simplemente en el gestor de políticas) o, como en este caso, una modificación por parte de un usuario no deseado. ¡Mucho ojo con lo que parseais! 

5. ¿Cómo podemos saber qué cambios se han realizado sobre la GPO?

A nivel de detección, creo poder afirmar que con los logs de Windows no hay manera de saberlo con exactitud. Sin embargo, suponiendo que el atacante sea algo chapuzas, siempre podremos revisar la configuración actual de dicha política. Como podemos ver, Pitágoras ha modificado las características de la política para que se añada como usuario administrador cada vez que se despliegue.

Fig 5: Caracteristicas de la GPO.

Jugando a correlar

Como hemos comentado en el apartado anterior, no hay manera de detectar los cambios realizados sobre la GPO mediante el análisis del evento 5136. Sin embargo, Windows posee otros muchos logs interesantes que podemos emplear para hacer lo que tanto gusta en los SOC: CORRELAR.

6. ¿Qué podemos correlar?

Como mostramos en el artículo anterior, SharpGPOAbuse nos permite, entre otras cosas, añadir nuestro usuario como administrador local de las máquinas afectadas por la GPO vulnerada. Como bien sabemos, Windows tiene activado por defecto los eventos de seguridad que registran, tanto la adición de usuarios a grupos administrativos (evento 4732) como la creación de una sesión remota (evento 4624) y el cierre de esta (evento 4634). Si analizamos los logs del servidor WEB-01, podremos ver lo siguiente:

• El usuario Pitágoras ha sido añadido al grupo de Administradores local por un proceso ejecutado por SYSTEM (la GPO).

Fig 6: Contenido del evento 4732.

• Unos segundos después, Pitágoras ha iniciado sesión en dicho servidor.

Fig 7: Contenido del evento 4624.

• Una vez dentro, ha listado los usuarios pertenecientes al grupo de Administradores locales (net localgrup Administrators).

Fig 8: Contenido del evento 4799.

• Por último, cerró sesión.

Fig 9: Contenido del evento 4634.

Recapitulando

Hemos podido compensar la falta de información proporcionada por el evento 5136 (modificaciones sobre GPO) con otros eventos proporcionados por Windows. Gracias a esto, podemos asegurar con total certeza que el usuario Pitágoras modificó las características de la política GPO_Vulnerable para añadirse como Administrador local en todas las máquinas a las que les aplica esta GPO (en este caso, WEB-01). Tras desplegarse la política, Pitágoras se conectó de manera remota al servidor web, listó los usuarios pertenecientes al grupo de Administradores y, acto seguido, se desconectó. Todo detectado con los logs de Windows.

Para terminar, me gustaría destacar que aunque esto parezca un caso de uso bastante real y sencillo, el número de eventos generado por Windows es bastante alto en cuanto a modificaciones de GPO se refiere. En este labo, se generaron una media de 300 eventos sin prácticamente actividad, por lo que, imaginad lo que puede generar en un entorno productivo

Postdata

Como nota final, si nos topáramos con alguien travieso que decidiera borrar una GPO, también existe un evento que lo registra, el 5141. Nadie se salva 😈.

Fig 10: Contenido del evento 5141.

Nos vemos en el próximo artículo. Happy Juancking!