Get best of the week

Una vez en un pentest, o Cómo romper todo con la ayuda de un urólogo y Roskomnadzor


Este artículo se basa en un pentest muy exitoso, realizado por especialistas del Grupo IB hace un par de años: sucedió una historia que dice ser una adaptación cinematográfica en Bollywood. Ahora, probablemente, la reacción del lector seguirá: "Oh, otro artículo de relaciones públicas, una vez más estos están dibujados, qué buenos son, no te olvides de comprar un pentest" Bueno, por un lado, lo es. Sin embargo, hay varias razones por las que apareció este artículo. Quería mostrar qué están haciendo exactamente los pentesters, cuán interesante y no trivial puede ser este trabajo, qué circunstancias divertidas pueden desarrollarse en los proyectos y, lo más importante, mostrar material en vivo con ejemplos reales.

Para restablecer el equilibrio de la modestia en el mundo, después de un tiempo escribiremos sobre el pentest, que no fue. Mostramos cómo los procesos bien establecidos en una empresa pueden proteger contra toda una gama de ataques, incluso los bien preparados, simplemente porque estos procesos existen y realmente funcionan.

El cliente de este artículo, también, todo estaba bien en general, al menos mejor que el 95% del mercado en la Federación de Rusia, según nuestros sentimientos, pero hubo una serie de pequeños matices que formaron una larga cadena de eventos, lo que condujo primero a un largo informe sobre el trabajo. , y luego a este artículo.

Entonces, abastecerse de palomitas de maíz, y bienvenido al detective. Doy la palabra a Pavel Suprunyuk , Director Técnico del Grupo de Auditoría y Consultoría-IB.

Parte 1. Doctor Pochkin


Año 2018. Hay un cliente, una empresa de TI de alta tecnología, que a su vez sirve a muchos clientes. Quiere obtener una respuesta a la pregunta: ¿es posible, sin ningún conocimiento inicial y acceso, trabajando a través de Internet, obtener derechos de administrador para un dominio de Active Directory? Ninguna ingeniería social es de interés ( eh, pero en vano ), no van a interferir específicamente con el trabajo, pero pueden recargar accidentalmente un servidor extraño que funciona, por ejemplo. Una tarea adicional es identificar tantos otros vectores de ataque como sea posible con respecto al perímetro externo. La compañía realiza regularmente tales pruebas, y ahora la fecha límite para una nueva prueba. Las condiciones son casi típicas, adecuadas, comprensibles. Bajando.

Hay un nombre de cliente: déjelo ser "Empresa", con el sitio principal www.company.ru. Por supuesto, el cliente recibe una llamada diferente, pero en este artículo todo se despersonalizará.
Realizo inteligencia de red: averiguo qué direcciones y dominios están listados por el cliente, dibujo un diagrama de red, cómo se distribuyen los servicios a estas direcciones. Obtengo el resultado: más de 4000 direcciones IP activas. Miro a través de los dominios en estas redes: afortunadamente, la gran mayoría son redes destinadas a clientes clientes, y no nos interesan formalmente. El cliente cree lo mismo.

Sigue habiendo una red con 256 direcciones, para lo cual en este momento ya se comprende la distribución de dominios y subdominios por direcciones IP, hay información sobre los puertos escaneados, lo que significa que puede mirar los servicios para ver los interesantes con sus ojos. Paralelamente, todos los tipos de escáneres se lanzan en direcciones IP accesibles y por separado, en sitios web.

Hay muchos servicios. Esto suele ser una alegría para el pentester y la anticipación de una victoria rápida, ya que mientras más servicios, mayor es el campo de ataque y más fácil es encontrar un artefacto. Un vistazo rápido a los sitios web mostró que la mayoría de ellos son interfaces web de los productos conocidos de grandes compañías mundiales que dicen que no están contentos con usted. Solicitan un nombre de usuario y una contraseña, desde el umbral sacuden el campo para ingresar el segundo factor, solicitan un certificado de cliente TLS o los envían a Microsoft ADFS. Algunos simplemente no están disponibles en Internet. Para algunos, obviamente necesita tener un cliente especial pagado por tres salarios o saber la URL exacta para ingresar. Omitiremos otra semana de desánimo gradual en el proceso de tratar de "romper" el software por versión para detectar vulnerabilidades conocidas, buscar contenido oculto en rutas web y cuentas filtradas de servicios de terceros como LinkedIn,intenta seleccionar contraseñas para ellos, así como excavar vulnerabilidades en sitios web autodescritos, por cierto, según las estadísticas, este es el vector más prometedor de un ataque externo hasta la fecha. Inmediatamente noto la pistola de cine, que posteriormente disparó.

Entonces, había dos sitios que se destacan de cientos de servicios. Estos sitios tienen una cosa en común: si no realiza un reconocimiento meticuloso de la red por dominio, pero busca "en el frente" puertos abiertos o envenena el escáner de vulnerabilidades en un rango de IP conocido, entonces estos sitios desaparecerán de la verificación, simplemente no serán visibles sin conocer el nombre DNS. Tal vez se perdieron antes, al menos, y nuestras herramientas automáticas no encontraron problemas en ellas, incluso si se configuraron directamente en el recurso.

Por cierto, sobre el hecho de que generalmente se encontraron escáneres previamente lanzados. Permítame recordarle: para algunas personas, "pentest" equivale a "escaneo automatizado". Y los escáneres de este proyecto no dijeron nada. Bueno, las vulnerabilidades medias mostraron el máximo (3 de 5 en términos de peligro): algunos servicios tienen un certificado TLS incorrecto o algoritmos de cifrado obsoletos, y la mayoría de los sitios tienen Clickjacking. Pero en esto no llegarás a la meta. Probablemente, los escáneres serían más útiles aquí, pero permítame recordarle: el cliente mismo puede comprar dichos programas y probarse con ellos, y a juzgar por los aburridos resultados, ya lo comprobó.

Volver a los sitios "anormales". El primero es algo así como un Wiki local en una dirección no estándar, pero deja que wiki.company [.] Ru esté en este artículo. También solicitó inmediatamente un nombre de usuario y contraseña, pero ya a través de NTLM en el navegador. Para el usuario, esto parece una ventana ascética que solicita un nombre de usuario y contraseña. Y esta es una mala práctica.

. NTLM - . — Active Directory. company.ru, «» DNS-. , - , , - . — NTLM (, ?), «» , . , . — , . — . — , , . — pass-the-hash-. ADFS .

Hay una característica negativa de los productos de Microsoft: incluso si no ha publicado específicamente tal NTLM, al menos estará en la instalación predeterminada en OWA y Lync.

Por cierto, el autor de este artículo una vez de la misma manera bloqueó accidentalmente aproximadamente 1000 cuentas de empleados de un gran banco en solo una hora y luego tuvo una apariencia algo pálida. Los servicios de TI del banco también fueron pálidos, pero todo terminó bien y de manera adecuada, incluso nos felicitaron por ser los primeros en encontrar este problema y provocar una corrección rápida y decisiva.
El segundo sitio tenía la dirección "obviamente-algún-apellido.company.ru". Encontrado a través de Google, algo así en la página 10. El diseño comienza a mediados de 2000, y una persona respetable miró desde la página principal, algo como esto:


Luego tomó un cuadro de "Dog’s Heart", pero créanme, era remotamente similar, incluso el esquema de color en colores similares. Deje que el sitio se llame preobrazhensky.company.ru .

Era un sitio personal ... de un urólogo. Se volvió interesante lo que hace el sitio del urólogo en el subdominio de una empresa de alta tecnología. Una búsqueda rápida en Google mostró que este médico era cofundador de una de las entidades legales de nuestro cliente e incluso contribuyó con alrededor de 1000 rublos de capital registrado. El sitio probablemente se creó hace muchos años, y los recursos del servidor del cliente se usaron como alojamiento. El sitio ha perdido relevancia durante mucho tiempo, pero por alguna razón se ha dejado funcionando durante mucho tiempo.

En términos de vulnerabilidades, el sitio web en sí era seguro. Mirando hacia el futuro, diré que fue un conjunto de estadísticas: páginas html simples con insertos de ilustraciones en forma de riñones y vejigas. "Romper" tal sitio es inútil.

Pero el servidor web debajo era más interesante. A juzgar por el encabezado del servidor HTTP, había IIS 6.0, lo que significa que Windows 2003 se utilizó como sistema operativo. El escáner reveló previamente que este sitio web particular del urólogo, a diferencia de otros hosts virtuales en el mismo servidor web, respondió al comando PROPFIND, es decir, WebDAV trabajó allí. Por cierto, el escáner emitió esta información con la marca Información (en el idioma de los informes del escáner, este es el peligro más bajo); por lo general, estas cosas simplemente se omiten. En combinación, esto dio un efecto interesante, que se reveló solo después de otra excavación en Google: una vulnerabilidad de desbordamiento de búfer rara asociada con un conjunto de Shadow Brokers, a saber, CVE-2017-7269, que ya tenía un exploit listo. En otras palabras, será un desastre si tiene Windows 2003 y WebDAV se está ejecutando en IIS.Aunque trabajó en la producción de Windows 2003 en 2018, esto es en sí mismo un desastre.

El exploit terminó en Metasploit y se probó inmediatamente con una carga que envió una consulta DNS a un servicio controlado: Burp Collaborator se usa tradicionalmente para atrapar consultas DNS. Sorprendentemente, funcionó la primera vez: se recibió una sacudida en DNS. Luego hubo un intento de crear una conexión de fondo a través del puerto 80 (es decir, una conexión de red del servidor al atacante, con acceso a cmd.exe en el host víctima), pero luego ocurrió un fiasco. La conexión no llegó, y después del tercer intento de operación, el sitio, junto con todas las fotos entretenidas, desapareció definitivamente.

Por lo general, esto es seguido por una carta en el estilo de "cliente, despierta, hemos dejado todo". Pero nos dijeron que el sitio no tiene nada que ver con los procesos comerciales y funciona allí en general, no está claro por qué, como todo el servidor, y que podemos usar este recurso como queramos.
Después de aproximadamente un día, el sitio de repente comenzó a funcionar por sí solo. Después de construir un soporte de WebDAV en IIS 6.0, descubrí que la configuración predeterminada es reiniciar los flujos de trabajo de IIS cada 30 horas. Es decir, cuando el control salió del código de shell, el flujo de trabajo de IIS terminó, luego se reinició un par de veces y luego se detuvo durante 30 horas.

Desde la primera vez que falló bekconnect en tcp, descarté este problema en un puerto cerrado. Es decir, sugirió la presencia de algún firewall que no permitía la salida de las conexiones salientes. Comencé a ejecutar códigos de shell que clasifican muchos puertos tcp y udp, no hubo ningún efecto. La conexión inversa se carga a través de http (s) desde Metasploit - meterpreter / reverse_http (s) no funcionó. De repente, se estableció la conexión con el mismo puerto 80, pero se interrumpió de inmediato. Él lo descartó por la acción del todavía imaginario IPS, al que no le gustaba el tráfico del metro metro. En vista del hecho de que la conexión de tcp puro al puerto 80 falló, pero http lo hizo, concluí que el proxy http estaba configurado de alguna manera en el sistema.

Intenté incluso meterpreter a través de DNS (graciasd00kiepor sus esfuerzos, salvó muchos proyectos), recordando el primer éxito, pero ni siquiera trabajó en el stand: el código de shell era demasiado voluminoso para esta vulnerabilidad.

En realidad, se veía así: 3-4 intentos de ataque en 5 minutos, luego esperar 30 horas. Y así durante tres semanas seguidas. Incluso configuré un recordatorio para no perder el tiempo. Además, había una diferencia en el comportamiento de los entornos de prueba y combate: para esta vulnerabilidad había dos exploits similares, uno de Metasploit, el segundo de Internet, rehecho de la versión de Shadow Brokers. Entonces, en el combate, solo Metasploit funcionó, en el estrado, solo el segundo, lo que complicó aún más la depuración y rompió el cerebro.

Al final, el código de shell demostró ser efectivo, que descargó un archivo exe de un servidor determinado a través de http y lo ejecutó en el sistema de destino. El shellcode era lo suficientemente pequeño como para caber, y al menos funcionó. Dado que al servidor TCP no le gustaba el tráfico y se inspeccionó http (s) en busca de meterpreter, decidí que la forma más rápida es descargar el archivo exe que contenía el DNS-meterpreter a través de este código shell.

Aquí nuevamente surgió el problema: al descargar el archivo exe y, como lo mostraron los intentos, no importa qué, la descarga se interrumpió. Una vez más, a algún tipo de dispositivo de protección entre mi servidor y el urólogo no le gustó el tráfico http con exe dentro. Parecía una solución "rápida" para cambiar el código shell para que ofuscara el tráfico http sobre la marcha, de modo que se transfirieran datos binarios abstractos en lugar de exe. Finalmente, el ataque fue exitoso, el control llegó a través del delgado canal DNS:


Inmediatamente se hizo evidente que tenía los derechos más simples para el flujo de trabajo de IIS que me permitían no hacer nada. Así es como se veía en la consola Metasploit:


Todas las metodologías más recientes sugieren fuertemente que necesita aumentar los derechos al obtener acceso. Por lo general, no hago esto localmente, ya que el primer acceso se considera simplemente como un punto de entrada a la red, y comprometer otra máquina en la misma red suele ser más fácil y rápido que aumentar los privilegios en un host existente. Pero este no es el caso, ya que el canal DNS es muy estrecho y no permitirá que el tráfico circule.

Suponiendo que este servidor con Windows 2003 no se reparó de la famosa vulnerabilidad MS17-010, estoy canalizando el tráfico al puerto 445 / TCP a través del túnel DNS meterpreter a localhost (sí, esto también es posible) e intento ejecutar un exe previamente descargado a través de la vulnerabilidad. El ataque funciona, obtengo una segunda conexión, pero con privilegios de SYSTEM.


Curiosamente, el servidor todavía estaba tratando de protegerse contra MS17-010: había deshabilitado los servicios de red vulnerables en la interfaz externa. Esto realmente protege contra ataques a través de la red, pero el ataque desde dentro del localhost funcionó, ya que no puede simplemente tomar y apagar rápidamente SMB en localhost.
A continuación, se revelan nuevos detalles interesantes:

  1. Al tener permisos de SISTEMA, puede instalar fácilmente la conexión a través de TCP. Obviamente, la prohibición del TCP directo es exclusivamente un problema de usuario limitado de IIS. Spoiler: el tráfico de usuarios de IIS estaba envuelto de alguna manera en el Proxy ISA local en ambas direcciones. Cómo funciona exactamente esto no se reproduce.
  2. Estoy en un cierto "DMZ" (y esto no es un dominio de Active Directory, pero GRUPO DE TRABAJO) - suena lógico. Pero en lugar de la dirección IP privada ("gris") esperada, soy bastante "blanco", exactamente lo mismo que ataqué antes. Esto significa que la compañía es tan antigua para el mundo del direccionamiento IPv4 que puede permitirse mantener la zona DMZ en 128 direcciones "blancas" sin NAT según el esquema, como se ilustra en los manuales de Cisco de 2005.

Como el servidor es antiguo, Mimikatz está garantizado para trabajar directamente desde la memoria:


Recibo la contraseña del administrador local, hago un túnel del tráfico RDP a través de TCP y entro en un escritorio acogedor. Como puede hacer cualquier cosa con el servidor, elimino el antivirus, encuentro que solo se puede acceder al servidor desde Internet en los puertos TCP 80 y 443, y 443 no estaba ocupado. Elevo el servidor OpenVPN a 443, agrego las funciones NAT para mi tráfico VPN y obtengo acceso directo a la red DMZ de forma ilimitada a través de mi OpenVPN. Es de destacar que ISA, con algunas funciones de IPS no desactivadas, bloqueó mi tráfico con escaneo de puertos, por lo que tuvo que ser reemplazado por un RRAS más simple y flexible. Entonces los pentesters a veces todavía tienen que administrar todo.


Un lector atento preguntará: "¿Y cuál es el segundo sitio: un wiki con autenticación NTLM, sobre el que tanto se ha escrito?" Sobre esto más allá.

Parte 2. ¿Todavía no estás encriptando? Entonces vamos a ti ya aquí


Entonces, hay acceso al segmento de red DMZ. Debe ir al administrador del dominio. Lo primero que viene a la mente es verificar automáticamente la seguridad de los servicios dentro del segmento DMZ, más aún porque ahora están mucho más abiertos a la investigación. Una imagen típica en una prueba de penetración: el perímetro externo está mejor protegido que los servicios internos, y cuando obtiene acceso a una infraestructura grande, es mucho más fácil obtener derechos extendidos en un dominio solo porque este dominio comienza a ser accesible para las herramientas, y en segundo lugar, Siempre hay un par de problemas críticos en la infraestructura para varios miles de hosts.

Cargo escáneres en DMZ a través del túnel OpenVPN, espero. Abro el informe; de ​​nuevo, nada serio, aparentemente alguien caminó de la misma manera hacia mí. El siguiente paso es examinar cómo se comunican los hosts dentro de la red DMZ. Para hacer esto, para empezar, se lanza un Wireshark regular con escucha de solicitudes de transmisión, principalmente ARP. Los paquetes ARP fueron recolectados todo el día. Resulta que se utilizan varias puertas de enlace en este segmento. Esto será útil más tarde. Al pegar datos en la solicitud de respuesta ARP y los datos de escaneo de puertos, encontré los puntos de salida del tráfico de usuarios desde dentro de la red local además de los servicios que se conocían anteriormente, como la web y el correo.

Como en este momento no tenía acceso a otros sistemas y no había una sola cuenta para servicios corporativos, se decidió obtener al menos alguna cuenta del tráfico utilizando ARP Spoofing.

Cain & Abel se lanzó en el servidor del urólogo. Teniendo en cuenta los flujos de tráfico identificados, se seleccionaron los pares más prometedores para el ataque "hombre en el medio", luego, mediante un lanzamiento a corto plazo durante 5-10 minutos, con un temporizador para reiniciar el servidor en caso de "congelamiento", se recibió algo de tráfico de red. Como en la broma, había dos novedades:

  1. Bien: se tomaron muchas credenciales y el ataque en su conjunto funcionó.
  2. Malo: todas las credenciales eran de clientes del propio cliente. Al proporcionar servicios de soporte, los especialistas del cliente se conectaron a servicios al cliente que no siempre tenían configurado el cifrado de tráfico.

Como resultado, obtuve muchas credenciales que eran inútiles en el contexto del proyecto, pero definitivamente interesantes como una demostración del peligro de un ataque. Enrutadores fronterizos de grandes empresas con telnet, reenvío de depuración de puertos http a CRM interno con todos los datos, acceso directo a RDP desde Windows XP en la red local y otro oscurantismo. Resultó una especie de compromiso de la cadena de suministro según la matriz MITRE .

También encontré una oportunidad divertida para recopilar correos electrónicos del tráfico, algo como esto. Este es un ejemplo de una carta terminada que pasó de nuestro cliente al puerto SMTP de su cliente, nuevamente, sin encriptación. Cierto Andrei le pide a su homónimo que reenvíe la documentación, y se presenta en un disco en la nube con un nombre de usuario, contraseña y enlace en una carta de respuesta:


Este es otro recordatorio de que necesita cifrar todos los servicios. No se sabe quién y cuándo leerá y aplicará específicamente sus datos: un proveedor, un administrador del sistema de otra compañía o un pentestador. Estoy en silencio porque muchos simplemente pueden interceptar el tráfico no cifrado.

A pesar del aparente éxito, esto no se acercó a la meta. Era posible, por supuesto, sentarse durante mucho tiempo y obtener información valiosa, pero no el hecho de que hubiera aparecido allí, y el ataque en sí mismo es muy arriesgado en términos de integridad de la red.

Después de otra búsqueda en los servicios, se me ocurrió una idea interesante. Existe una utilidad llamada Responder (es fácil encontrar ejemplos de aplicaciones con este nombre) que, al "envenenar" las solicitudes de difusión, provoca conexiones a través de una variedad de protocolos como SMB, HTTP, LDAP, etc. de diferentes maneras, a cada persona que se conecta se le pide que se autentique y se ajuste para que la autenticación pase a través de NTLM y en un modo transparente para la víctima. Muy a menudo, un atacante recopila los apretones de manos NetNTLMv2 y de ellos, según el diccionario, recupera rápidamente las contraseñas de dominio del usuario. Quería algo similar aquí, pero los usuarios estaban sentados "detrás de la pared", o mejor dicho, estaban separados por un firewall, y en la WEB pasaron por el clúster proxy de Blue Coat.

Recuerde, especifiqué que el nombre de dominio de Active Directory coincidía con el dominio "externo", es decir, ¿era company.ru? Entonces, Windows, más precisamente Internet Explorer (y Edge, y Chrome), permiten al usuario autenticarse de forma transparente en HTTP a través de NTLM, si consideran que el sitio está en alguna "Zona de Intranet". Una de las señales de "Intranet" es una llamada a una dirección IP "gris" o un nombre DNS corto, es decir, sin puntos. Como un servidor con una IP "blanca" y un nombre DNS preobrazhensky.company.ru estaba a su disposición, y las máquinas de dominio generalmente obtienen el sufijo de dominio de Active Directory a través de DHCP para simplificar la entrada de nombres, solo tenían que escribir la URL preobrazhensky en la barra de direccionespara que encuentren el camino correcto hacia un servidor de urólogos comprometido, sin olvidar que ahora se llama "Intranet". Es decir, al mismo tiempo que me da el usuario de apretón de manos NTLM sin su conocimiento. Queda por hacer que los navegadores de los clientes piensen en la urgente necesidad de acceder a este servidor.

La maravillosa utilidad Intercepter-NG vino al rescate (graciasInterceptor) Le permitía cambiar el tráfico sobre la marcha y funcionaba perfectamente en Windows 2003. Incluso había una funcionalidad separada para modificar solo archivos JavaScript en el flujo de tráfico. Se planeó una especie de scripting masivo entre sitios.

Proxies de Blue Coat a través de los cuales los usuarios accedían periódicamente al contenido estático en caché de la WEB global. Al interceptar el tráfico, quedó claro que trabajan las 24 horas del día, solicitando sin cesar estadísticas de uso frecuente para acelerar la visualización del contenido durante las horas pico. Además, BlueCoat tenía un User-Agent específico, que lo distinguía claramente de un usuario vivo.

Se preparó Javascript, que con la ayuda de Intercepter-NG por la noche pasó una hora completa implementando cada respuesta con archivos JS para Blue Coat. El guión hizo lo siguiente:

  • Detectado el navegador actual por User-Agent. Si era Internet Explorer, Edge o Chrome, funcionó.
  • Esperado hasta que se forme el DOM de la página.
  • Inserté una imagen invisible con el atributo src del tipo preobrazhensky en el DOM : 8080 / NNNNNNN.png, donde NNN son dígitos arbitrarios para que BlueCoat no se almacene en caché.
  • Establezca una variable de marca global que indique que se realizó la inyección y que ya no necesita insertar imágenes.

El navegador intentó cargar esta imagen, en el puerto 8080 del servidor comprometido, estaba esperando el túnel TCP a mi computadora portátil, donde se lanzó el mismo Respondedor, que requiere el inicio de sesión NTLM desde el navegador.


A juzgar por los registros del Respondedor, por la mañana las personas vinieron a trabajar, encendieron sus estaciones de trabajo, luego comenzaron a visitar el servidor del urólogo en masa e imperceptiblemente, sin olvidar "fusionar" los apretones de manos NTLM. Los apretones de manos llovieron todo el día y claramente acumuló material para un ataque de recuperación de contraseña notoriamente exitoso. Así es como se veían los registros del Respondedor:

Visitas secretas masivas al servidor del urólogo por parte de los usuarios

Probablemente ya haya notado que toda esta historia se basa en el principio "todo estuvo bien, pero hubo un fastidio, luego hubo superación y luego todo llegó al éxito". Entonces, hubo un fastidio. De los quinientos apretones de manos únicos, ninguno fue revelado. Y esto tiene en cuenta el hecho de que incluso en una computadora portátil con un procesador inactivo, estos apretones de manos NTLMv2 se superan a la velocidad de varios cientos de millones de intentos por segundo.

Tuve que armarme con técnicas de mutación de contraseña, una tarjeta gráfica, un diccionario más grueso y esperar. Después de mucho tiempo, se abrieron varias cuentas con contraseñas de la forma "Q11111111 ... .1111111q", lo que sugiere que todos los usuarios se vieron obligados a encontrar una contraseña muy larga con un caso diferente de caracteres, lo que se suponía que era complicado. Pero no puede fallarle a un usuario experimentado, y de esta manera él lo hizo más fácil de recordar. En total, se abrieron alrededor de 5 piezas, y solo una de ellas tenía derechos valiosos sobre los servicios.

Parte 3. Roskomnadzor contraataca


Entonces, se recibieron las primeras cuentas de dominio. Si en este punto no se quedó dormido después de una lectura larga, probablemente recordará que mencioné un servicio que no requería un segundo factor de autenticación: este es un wiki con autenticación NTLM. Por supuesto, lo primero que hicieron fue entrar. Profundizar en la base de conocimiento interna rápidamente trajo resultados:

  • La compañía tiene una red WiFi con autenticación de cuenta de dominio con acceso a una red local. Con el conjunto de datos actual, este ya es un vector de ataque funcional, pero debe ir a la oficina con los pies y ubicarse en algún lugar de la oficina del cliente.
  • , , … « » , . «» «» . , DMZ.

Por supuesto, el "segundo factor" se agregó inmediatamente a la cuenta comprometida como una aplicación en mi teléfono. Hubo un programa que puede enviar en voz alta una solicitud de inserción al teléfono con los botones "aprobar" / "desaprobar", o mostrar silenciosamente el código OTP en la pantalla para una entrada independiente adicional. Además, se suponía que el primer método era la única instrucción correcta, pero no funcionó, a diferencia del método OTP.

Con el "segundo factor" roto, logré iniciar sesión en el correo de Outlook Web Access y acceder de forma remota a Citrix Netscaler Gateway. En Outlook, una sorpresa esperaba en el correo:


En esta rara toma se puede ver cómo Roskomnadzor ayuda a los pentesters.

Estos fueron los primeros meses después del famoso bloqueo de fan de Telegram, cuando redes enteras a miles de direcciones desaparecieron inexorablemente del acceso. Quedó claro por qué empujar no funcionó de inmediato y por qué mi "víctima" no hizo sonar la alarma porque comenzaron a usar su cuenta en horario abierto.

Aquellos que están familiarizados con Citrix Netscaler imaginan que generalmente se implementa de tal manera que es posible transmitir al usuario solo una interfaz de imagen, tratando de no darle las herramientas para lanzar aplicaciones de terceros y transferir datos, restringiendo de todas las formas posibles las acciones a través de shells de control estándar. Por mi ocupación, solo obtuve 1C:


Después de caminar un poco en la interfaz 1C, descubrí que hay módulos de procesamiento externos allí. Se pueden cargar desde la interfaz y se ejecutarán en el cliente o servidor, según los derechos y la configuración.

Le pedí a mis amigos programadores de 1C que crearan un procesamiento que tomara una cadena y la ejecutara. En 1C, el lanzamiento del proceso se parece a esto (tomado de Internet). De acuerdo, ¿la sintaxis del lenguaje 1C golpea a una persona de habla rusa con su inmediatez?



El procesamiento se ejecutó perfectamente, resultó lo que los Pentesters llaman el "shell": Internet Explorer se lanzó a través de él.


Anteriormente, la dirección del sistema se encontraba en el correo, lo que le permite ordenar pases al territorio. Pedí un pase en caso de que tenga que usar el vector de ataque a través de WiFi.


En Internet, dicen que en la oficina del cliente todavía había un sabroso servicio de catering gratuito, pero todavía prefería desarrollar un ataque a través de un sitio remoto, es más tranquilo.

AppLocker se activó en el servidor de aplicaciones con Citrix, pero se omitió. El mismo Meterpreter se cargó e inició a través de DNS, porque las versiones http (s) no querían conectarse, y entonces no conocía la dirección proxy interna. Por cierto, a partir de este momento, el pentest externo se convirtió esencialmente en el interno.

Parte 4. Derechos de administrador para los usuarios: esto es malo, p-nyatnenko?


Lo primero que hace un Pentester cuando toma el control de la sesión de un usuario de dominio es recopilar toda la información sobre los derechos en el dominio. Existe tal utilidad BloodHound, que automáticamente le permite descargar información sobre usuarios, computadoras, grupos de seguridad a través del protocolo LDAP desde el controlador de dominio, e información sobre qué usuario ha iniciado sesión recientemente y quién es el administrador local a través de SMB.

Una técnica típica para capturar privilegios de administrador de dominio parece simplificada como un ciclo de acciones monótonas:

  • Vamos a las computadoras de dominio, donde hay derechos de administrador local, basados ​​en cuentas de dominio ya capturadas.
  • Mimikatz , Kerberos NTLM , . lsass.exe . Windows 2012R2/Windows 8.1 .
  • , . . - .

"Fin del ciclo", como los programadores de 1C escribirían aquí.

Entonces, nuestro usuario resultó ser un administrador local en un solo host con Windows 7, cuyo nombre era la palabra "VDI", o "Infraestructura de escritorio virtual", máquinas virtuales personales. Probablemente, el diseñador del servicio VDI dio a entender que dado que VDI es el sistema operativo personal del usuario, permita que el usuario cambie el entorno del software, como lo desee, de todos modos el host puede ser "recargado". También pensé que, en general, la idea es buena, fui a este host VDI personal e hice un socket allí:

  • Instalé el cliente OpenVPN allí, que hizo un túnel a través de Internet a mi servidor. El cliente tuvo que pasar por el mismo Blue Coat con autenticación de dominio, pero OpenVPN se las arregló, como dicen, fuera de la caja.
  • Instalado en VDI OpenSSH. Bueno, realmente, ¿qué es este Windows 7 sin SSH?

Así es como se veía vivo. Les recuerdo que todo esto debe hacerse a través de Citrix y 1C:


Una de las técnicas para promover el acceso a las computadoras vecinas es verificar las contraseñas de los administradores locales para encontrar una coincidencia. Aquí la suerte estaba esperando de inmediato: el hash NTLM del administrador local predeterminado (que de repente se llamó Administrador) se acercó a los hosts VDI vecinos, de los cuales había varios cientos, a través del ataque de pasar el hash. Por supuesto, el ataque fue inmediatamente sobre ellos.
Luego, los administradores de VDI se dispararon dos veces en el pie:
  • La primera vez que LAPS no activó las máquinas VDI, esencialmente guardó la misma contraseña de administrador local de una imagen que se implementó masivamente en VDI.
  • — , pass-the-hash . , , — .
¿Por qué el servicio SSH en ese Windows? Muy simple: ahora el servidor OpenSSH no solo proporcionó un conveniente shell de comandos interactivos sin interferir con el trabajo del usuario, sino también un proxy socks5 en VDI. A través de estos calcetines, me conecté a través de SMB y recopilé cuentas en caché de todos estos cientos de máquinas VDI, luego busqué la ruta al administrador del dominio en los gráficos de BloodHound. Con cientos de hosts a mi disposición, encontré este camino bastante rápido. Se han obtenido derechos de administrador de dominio.

Aquí hay una imagen de Internet, que muestra una búsqueda similar. Los enlaces muestran quién es el administrador y quién ingresó dónde.


Por cierto, recuerde la condición desde el inicio del proyecto: "no aplique la ingeniería social". Por lo tanto, propongo reflexionar sobre cuánto se cortaría todo este Bollywood con efectos especiales, si de todos modos se pudiera aplicar el phishing banal. Pero personalmente estaba muy interesado en hacer todo esto. Espero que te haya interesado leer esto. Por supuesto, no todos los proyectos parecen tan intrigantes, pero el trabajo en su conjunto es muy desconcertante y no se estanca.

Probablemente, alguien tendrá una pregunta: ¿cómo protegerse? Incluso en este artículo, se describen muchas técnicas, los administradores de Windows ni siquiera conocen muchas de ellas. Sin embargo, propongo mirarlos desde la perspectiva de principios tristes y medidas de seguridad de la información:

  • no use software desactualizado (¿recuerda Windows 2003 al principio?)
  • no mantenga los sistemas innecesarios encendidos (¿por qué estaba el sitio del urólogo?)
  • verifique las contraseñas de los usuarios para obtener fortaleza (de lo contrario, los soldados ... los pentesters harán esto )
  • No tiene las mismas contraseñas para diferentes cuentas (compromiso de VDI)
  • y otra

Por supuesto, es muy difícil de implementar, pero en el próximo artículo mostraremos en la práctica que esto es bastante posible.

More articles:


All Articles