Continuamos la conversación para casos interesantes en el trabajo de pentesters. En la última
publicación, hablamos sobre las pruebas de penetración externa, hoy hablaremos sobre los pentests internos más interesantes que hemos implementado recientemente. Su esencia es que, al estar en el perímetro interno del cliente, deberíamos recibir los máximos privilegios en el dominio y obtener datos importantes. Resultó estar sorprendido. Pero lo primero es lo primero.
Caso 1. El administrador de contraseñas es bueno, pero necesitan poder usar
Realizamos pruebas de penetración interna para un gran cliente que ya contaba con administradores de sistemas y un servicio de SI. En el transcurso del trabajo, recibimos varias cuentas con las que ya pudimos acceder a la red y conectarnos a las máquinas de otros usuarios. En algún momento, se acomodaron en el automóvil de uno de los administradores del sistema y encontraron un eldorado allí. El administrador del sistema utilizó contraseñas realmente complejas (sería difícil encontrarlas) e incluso las almacenó en keepass. Pero aquí está la mala suerte: el administrador de contraseñas nunca fue bloqueado, no después de 15 minutos, o en el momento en que la pantalla estaba bloqueada. Con este bono, obtuvimos derechos administrativos en sistemas críticos del cliente sin ruido ni polvo.
Otro cliente tuvo un caso similar. También contraseñas complicadas, también keepass, aunque todavía había un bloqueo automático después de 15 minutos. ¿Cómo podríamos usar esto? Esperaron hasta que el administrador bloqueó el escritorio y se fue (¿para almorzar?). Entonces fue un asunto pequeño.
Si usa administradores de contraseñas, úselos con prudencia: active la opción de bloqueo con una pantalla de bloqueo y en ausencia de actividad durante 1 a 5 minutos.
Caso 2. Empleados despedidos
Muy a menudo durante los pentests internos obtenemos acceso seleccionando contraseñas: los usuarios suelen ser demasiado vagos para encontrar combinaciones complejas, especialmente cuando la política de contraseñas requiere actualizarlas todos los meses. A menudo, los números simplemente cambian, por lo que superpassword_03.2019 un mes después se convierte en superpassword_04.2019 y más abajo en la lista.
Pero a veces los clientes se encuentran de la nada. Entonces, al realizar un ataque de rociado de contraseña en una de las compañías, obtuvimos varias cuentas y una de ellas fue especialmente interesante para nosotros: tenía derechos bastante amplios, aunque no derechos administrativos. Se estableció una contraseña fácil para ella (qaz12345), y los comentarios sobre esta entrada en AD indicaron que la empleada fue despedida, a juzgar por la fecha, hace casi un año. Es decir, después del rechazo, la cuenta no se bloqueó, sino que simplemente restableció la contraseña a "predeterminada" y configuró la opción "cambiar contraseña en el primer inicio de sesión". Para la felicidad del cliente, fuimos los primeros en ser invitados a hacer esto.
Caso 3. ¿Parches? No, no
La parte más difícil del pentest interno es obtener la primera cuenta. Hay muchas herramientas y formas de hacerlo, comenzando con un desfile de moda de espionaje en la oficina en busca de calcomanías preciadas con contraseñas y atrapando a los afectados con un Wi-Fi clonado de la oficina, que termina con ataques a Kerberos y descifrado de contraseñas. Pero a veces, incluso con el escaneo inicial, puede encontrar software que nadie ha estado actualizando durante diez mil años (¿por qué molestarse en actualizar el software en la infraestructura interna?).
En uno de esos proyectos, se encontraron con el software de gestión de HP, en el que se encontró RCE sin autenticación; de allí obtuvieron parte de las cuentas.
¯ \ _ (ツ) _ / ¯
Parecía que todo sería más simple: Mimikatz, y la cosa está en el sombrero, pero resultó que las cuentas recibidas no poseían los privilegios que necesitábamos. Como dicen, nuestra fortaleza está en la preparación para la nube: usando la magia de nmap y el script smb-enum-shares, descubrimos que una de las cuentas tenía derechos de administrador local en el servidor de prueba, en el que los administradores de dominio participaron activamente en ese momento =).
Caso 4. Cerraduras
Finalmente, hablemos un poco sobre el posible bloqueo de acceso. Trabajamos en el "vnutryanka" que realizamos con mayor frecuencia con acceso remoto. El esquema se ve así: nos conectamos a la VPN, obtenemos la dirección interna, luego nos aferramos a la máquina asignada para nosotros a través de RDP. Y con esta máquina ya estamos comenzando a llevar a cabo el trabajo, pero para esto necesitamos transmitir de alguna manera nuestras herramientas. Muchos de nuestros clientes usan servidores proxy con listas blancas de sitios, a veces incluso con listas blancas de puertos, para acceder a Internet (por ejemplo, puede conectarse a un sitio web con el puerto 80, pero ya no puede conectarse a 8081). Esto realmente hace que el trabajo sea un poco más difícil, especialmente si está prohibido copiar y pegar a través de RDP.
Pero donde en nuestro negocio sin matices. Un cliente tenía reglas muy estrictas y no se nos permitió llenar nuestras herramientas de manera oficial, por así decirlo, impidieron la penetración a través de la "entrada principal". Por ejemplo, aquí hay una máquina virtual y derechos mínimos para usted: sufra como verdaderos hackers.
No tuve que sufrir por mucho tiempo. El proxy realmente bloqueó mucho, ni siquiera era posible conectarse simplemente a su servidor http (no está en las listas blancas), se prohibió copiar y pegar, el navegador se negó a ir a cualquier lugar excepto http (80 / tcp) y https (443 / tcp), y en otro lugar que no sean los portales internos. Intentamos wget a través de powershell: tampoco funciona, no funciona sin proxy y los proxies lo prohíben. Pero la utilidad FTP incorporada de Windows funcionó bien: no había reglas en el firewall que pudieran bloquear ese tráfico. Así que arrastramos todas nuestras herramientas dentro del perímetro y pudimos hacer un gran trabajo.
Al final
Repetiré las recomendaciones de la parte anterior, porque la repetición es la madre de las enseñanzas
tartamudeantes . Realice pruebas de penetración periódicas: lo ayudarán a encontrar puntos delicados en su defensa, como, por ejemplo, en el caso 3. Puede considerar que no es necesario parchear los sistemas en el perímetro interno, pero a veces tiene graves consecuencias.
Cree un sistema de administración de parches: elimine no solo las vulnerabilidades de "alto perfil" (como EternalBlue o BlueKeep), sino también menos conocidas, pero no menos peligrosas en el caso de su funcionamiento (como es el caso de HP AM). En resumen, realice un seguimiento de todos sus sistemas.