Loading
_ DESCIFRANDO CONEXIÓN SEGURA...

Endurecer y detectar

5 tareas · 45 min · Principiante

La segunda mitad de la ruta, y pesa igual que la primera. Ahora te sientas del lado que defiende Marisma: por cada puerta que abriste en los módulos anteriores, el control que la cierra y el evento que la detecta cuando alguien la prueba. Trabajas sobre el mismo dominio de laboratorio, dentro del alcance autorizado, pero el entregable cambia: no es acceso, es una lista de endurecimientos y de detecciones. Se mapea a NIST NICE Defensive Cybersecurity PD-WRL-001 y al perfil ENISA ECSF de Cybersecurity Implementer. La sala es de criterio: elegir el control que corta cada abuso de raíz y la señal que lo hace visible, sabiendo que una detección sin la telemetría encendida no ve nada.

0 de 5 · 0%

Objetivo de la sala

La segunda mitad de la ruta, y pesa igual que la primera. Ahora te sientas del lado que defiende Marisma: por cada puerta que abriste en los módulos anteriores, el control que la cierra y el evento que la detecta cuando alguien la prueba. Trabajas sobre el mismo dominio de laboratorio, dentro del alcance autorizado, pero el entregable cambia: no es acceso, es una lista de endurecimientos y de detecciones. Se mapea a NIST NICE Defensive Cybersecurity PD-WRL-001 y al perfil ENISA ECSF de Cybersecurity Implementer. La sala es de criterio: elegir el control que corta cada abuso de raíz y la señal que lo hace visible, sabiendo que una detección sin la telemetría encendida no ve nada.

Contra el abuso de tickets de cuentas de servicio, prohibir que se pidan tickets no es opción: Kerberos funciona así. El control que corta el ataque está en la contraseña de la cuenta de servicio. Una cuenta gestionada por el propio directorio, con contraseña larga, aleatoria y que rota sola, no cede al crackeo aunque pidan su ticket mil veces; además, exigir cifrado fuerte en los tickets quita la variante vieja y débil que acelera el crackeo. Y para verlo cuando ocurre, la señal está en el registro de seguridad del controlador: una ráfaga de solicitudes de ticket de servicio con el cifrado débil, para muchos servicios distintos, desde una sola cuenta.

El control es la contraseña gestionada y el cifrado fuerte; la detección es la ráfaga de solicitudes de ticket de servicio con cifrado débil en el evento de concesión de tickets del controlador.

Responde para continuar

¿Qué cierra Kerberoasting de raíz y qué lo detecta en Marisma?

Ver pista de ayuda

No se prohíbe pedir tickets; se blinda la contraseña. La señal es la ráfaga con cifrado débil hacia muchos servicios.

El AS-REP roasting solo existe porque una cuenta tiene desactivada la comprobación previa de Kerberos. El control es directo: volver a exigir esa comprobación en toda cuenta que la tenga desactivada, y comprobar que ninguna cuenta nueva nace así por herencia de una plantilla vieja. La detección, cuando queda alguna por compatibilidad, está en el evento de concesión del ticket inicial: una petición de ticket inicial que llega sin la prueba de comprobación previa delata que alguien está cobrando el ticket de una cuenta sin protección.

El control es reactivar la comprobación previa en las cuentas que la perdieron; la detección es la petición de ticket inicial sin prueba de comprobación previa en el registro del controlador.

Responde para continuar

¿Cómo se cierra y se detecta el AS-REP roasting?

Ver pista de ayuda

El ataque vive de una casilla desactivada. Se vuelve a exigir la comprobación previa y se vigila el ticket inicial sin ella.

Los caminos de privilegio y las delegaciones se cierran atacando los eslabones, no el final. A una cuenta con poder se le marca que su identidad no se puede delegar, de modo que ningún servidor con delegación —mal puesta o no— pueda capturar y reusar su ticket; la delegación sin restricción se retira de todo lo que no sea estrictamente necesario; y los permisos de reescritura de un grupo de rutina sobre otro que da acceso a servidores se revisan y se quitan. Detrás está la idea de separar por niveles: las cuentas que mandan en el dominio no se usan ni se exponen en servidores corrientes. Para verlo, la telemetría son los cambios sobre objetos del directorio —modificaciones de pertenencia de grupo y de permisos— que casi nadie audita por defecto.

Se corta la cadena: cuentas con poder marcadas como no delegables, delegación sin restricción retirada, permisos de reescritura revisados; y se auditan los cambios de pertenencia y de permisos en el directorio.

Responde para continuar

¿Cómo se endurece y se vigila la cadena de privilegio y delegación de Marisma?

Ver pista de ayuda

Se atacan los eslabones, no la punta: no delegables, sin delegación abierta, permisos revisados, y auditar cambios de objeto.

El abuso del servicio de certificados se cierra en la plantilla concreta, no apagando la autoridad de la que depende media empresa. Se quita la propiedad que deja al solicitante fijar a quién representa el certificado, o se exige que un administrador apruebe la emisión, y se cierra el enrolamiento abierto a cualquiera; donde la emisión se alcanza por la red, se desactiva la autenticación débil en el punto de emisión y se exige enlace de canal, para que no se pueda relear hasta allí. La detección está en el registro de la propia autoridad: cada solicitud y cada certificado emitido queda anotado, y un certificado pedido por una cuenta común pero emitido a nombre de un administrador es la firma del abuso.

Se corrige la plantilla y se protege el punto de emisión; la detección es la solicitud de certificado cuyo titular no coincide con la cuenta que la pidió, en el registro de la autoridad.

Responde para continuar

¿Cómo se cierra y se detecta el abuso del servicio de certificados?

Ver pista de ayuda

El arreglo es la plantilla, no la autoridad. La señal está en el registro de emisión: titular que no coincide con el solicitante.

El hilo que une toda la mitad defensiva: cada detección de las tareas anteriores depende de que la telemetría esté encendida. El registro de concesión de tickets, la auditoría de cambios sobre objetos del directorio, el registro de la autoridad de certificados y los eventos de autenticación no vienen todos activos por defecto, y sin ellos las alarmas que diseñaste no tienen de qué dispararse. Endurecer sin encender la telemetría deja puertas cerradas y ciegas a la vez; encender la telemetría sin endurecer ve el ataque pero no lo para. La ruta insiste en las dos mitades porque una sola no basta.

Antes de dar por cerrada la defensa, se comprueba que la auditoría de tickets, de cambios en el directorio y de emisión de certificados está activada y llegando al punto donde se vigila.

Responde para continuar

Diseñaste los controles y las alertas de Marisma. ¿Qué falta comprobar antes de darlo por cerrado?

Ver pista de ayuda

Una alerta sin su registro encendido no se dispara nunca. Endurecer y detectar son dos mitades, y ninguna sobra.

Inicia sesión para registrar tus puntos y progreso en el ranking.

Whoami-Labs Pro

Whoami-Labs Pro utiliza cookies

Utilizamos cookies y almacenamiento local para el funcionamiento del sitio, seguridad de sesión y, si lo autorizas, analítica y marketing. Puedes aceptar, rechazar o personalizar. Política de Privacidad