IBo nefig: las mejores exposiciones de seguridad de la información de 2020 según JSOC

La primera mitad del año está llegando a su fin y decidimos recordar los casos más interesantes de la vida de JSOC que encontramos este año. Una reunión con un ciberdelincuente "viejo amigo" en un nuevo cliente, un script malicioso en el Programador de tareas y el acertijo de la curva de configuración del equilibrador: leemos y penetramos debajo del corte.





Tomada de la serie South Park

Lo reconocimos por su letra

Durante la existencia de JSOC, nos enfrentamos a diferentes infraestructuras de TI y varios deseos de los clientes de monitorear la cobertura de su panorama de TI. A menudo sucede, por ejemplo, que un cliente desea monitorear solo los servidores, privándose de la oportunidad de ver lo que está sucediendo alrededor del segmento monitoreado. Este enfoque puede resultar en una detección tardía de ataques, cuando la mayor parte de la infraestructura ya está comprometida. Y si nuestros clientes actuales no tienen tales situaciones, entonces en los proyectos piloto esta es una historia común.



Entonces, durante uno de los pilotos, el cliente estaba en el proceso de reconstruir su propio panorama de TI y quería ver cómo encajaría el SOC con su nueva infraestructura y procesos. Debido a diversas circunstancias fuera de nuestro control, no teníamos una sola fuente de red conectada, lo quekapets cuánto nos limitó en la detección de diversos incidentes. Solo se conectaron un controlador de dominio, un par de servidores Windows, un servidor de correo y un antivirus. El piloto pasó con bastante calma y fue estándar para nosotros : se encontraron varios malware en la infraestructura, el uso de TOR y RAT prohibidos. Pero un buen día, una gran cantidad de nuestras reglas comenzaron a funcionar, entre ellas estaban las reglas de la categoría Threat Hunting, que automatizan el proceso de identificación de los rastros de un atacante. El analista responsable rápidamente se dio cuenta de que el caso olía a queroseno e incluso se dio cuenta de con quién estaba tratando.



¿Que pasó? Lo primero que vimos fue agregar nuevas cuentas al grupo de administradores de dominio. Pero una regla más funcionó, a saber, el nombre sospechoso de las cuentas, que ya hemos encontrado. Un viejo conocido nuestro, un atacante, cuando realiza ataques, crea dos cuentas que están escritas en su guión: estos dos nombres "vagan" de una víctima a otra; un pequeño cambio solo puede ser causado por las reglas para nombrar las cuentas de la organización atacada. Lo hemos conocido muchas veces mientras investigábamos incidentes. Ataca organizaciones de todos los tamaños e industrias con el mismo método y, por lo general, termina encriptando los servidores clave de la empresa.



Desafortunadamente, la primera máquina comprometida estaba fuera del alcance de las fuentes conectadas, por lo que no se pudo registrar el momento de iniciar el script. Luego de la creación de las cuentas, capturamos un cambio de regla en el firewall local que permitió el uso de una herramienta de administración remota específica, y luego se creó el servicio de agente de esa misma herramienta. Por cierto, el antivirus que utiliza el cliente no reconoce esta herramienta, por lo que la controlamos creando el servicio correspondiente e iniciando el proceso.







La guinda del pastel fue la distribución de una utilidad de cifrado legal a los hosts comprometidos. No tuvo tiempo de subirlo a todos los hosts. El atacante fue "expulsado" de la infraestructura 23 minutos después del primer desencadenamiento de este incidente.



Por supuesto, el cliente y yo queríamos tener una imagen completa del incidente y encontrar el punto de entrada del atacante. Basándonos en nuestra experiencia, solicitamos registros de equipos de red, pero, desafortunadamente, el nivel de registro no nos permitió sacar ninguna conclusión. Sin embargo, habiendo recibido la configuración del equipo de red de borde de los administradores, vimos lo siguiente:



ip nat inside source static tcp "gray address" 22 "white address" 9922

ip nat inside source static tcp "gray address" 3389 "white address" 33899



De lo que se concluyó que, muy probablemente, uno de los servidores donde se configuró dicha NAT se convirtió en el punto de entrada. Analizamos los registros de estos servidores y vimos una autenticación exitosa bajo la cuenta de administrador, lanzando Mimikatz y luego lanzando un script que creaba administradores de dominio. A través de este incidente, el cliente realizó una auditoría completa de las reglas de firewall, contraseñas y políticas de seguridad e identificó varias fallas más en su infraestructura. Y también obtuve una comprensión más sistemática de por qué se necesita el SOC en su organización.

Enrutadores remotos y domésticos: el paraíso de los hackers

Obviamente, en el contexto de las empresas que pasan al control remoto, se ha vuelto mucho más difícil monitorear los eventos en los dispositivos finales. Hay dos razones clave:

1. un gran número de empleados utiliza dispositivos personales para trabajar;
2. VPN , .

También es un hecho obvio que incluso los atacantes experimentados se han interesado en las redes domésticas, ya que ahora es el punto ideal de penetración en el perímetro corporativo.



Uno de nuestros clientes hizo que el 90% de los empleados cambiaran a un modo de trabajo remoto y todos tenían computadoras portátiles de dominio; por lo tanto, podíamos continuar monitoreando los dispositivos finales, por supuesto, teniendo en cuenta el punto 2 anterior. Y fue este punto el que jugó en nuestra contra.



Uno de los usuarios no se conectó a la VPN durante casi un día entero durante el autoaislamiento. Al final de la jornada laboral, todavía necesitaba acceso a los recursos corporativos. Usó una VPN, obtuvimos registros de su máquina de trabajo y vimos algo extraño. Se creó una tarea sospechosa en el Programador de tareas: ejecutaba un determinado archivo todos los miércoles a las 5:00 pm. Empezaron a comprender.







Los rastreos llevaron a dos archivos doc: uno de ellos creó la tarea, el segundo fue el archivo ejecutable en la tarea. El usuario los descargó de Google Drive.



En esta etapa de nuestra búsqueda, el servicio de seguridad del cliente ya estaba conectado y comenzó una investigación interna. Resultó que el usuario recibió una carta a su correo personal, que contenía un enlace a Google Drive, desde donde se descargaron los documentos. Poco a poco llegamos al enrutador del usuario; por supuesto, el nombre de usuario / contraseña era admin \ admin (¿como si fuera de otra manera?). Pero lo más interesante se encontró en la configuración del servidor DNS del enrutador: allí se indicaba la dirección IP de uno de los países europeos. Introdujimos esta dirección en VirusTotal; la mayoría de las fuentes se iluminaron en rojo. Una vez finalizada la investigación, el cliente nos envió dos archivos para investigar, y vimos que el archivo lanzado por la tarea comenzó a “caminar” a través de varios directorios y descargar datos desde allí.



La cronología del incidente fue la siguiente: el atacante obtuvo acceso al enrutador del usuario, cambió la configuración en él, especificando su propio servidor como servidor DNS. Durante algún tiempo miré a mi "víctima" y envié una carta al correo personal del usuario. En este paso lo encontramos, impidiéndonos profundizar en la infraestructura corporativa.

Ellos también rompen los suyos

En la etapa inicial de trabajar con un SOC de outsourcing, siempre recomendamos conectar las fuentes de eventos por etapas, para que el cliente de su lado depure los procesos, defina claramente las áreas de responsabilidad y, en general, se acostumbre a este formato. Entonces, en uno de nuestros nuevos clientes, primero conectamos fuentes básicas, como controladores de dominio, firewalls, proxies, varias herramientas de seguridad de la información, servidores de correo, DNS y DHCP y varios otros servidores diferentes. También ofrecimos conectar las máquinas de los administradores de la casa matriz a nivel de logs locales, pero el cliente dijo que por ahora esto es innecesario y confía en sus administradores. Aquí, de hecho, comienza nuestra historia.



Un día, los acontecimientos dejaron de llegarnos. Nos enteramos por el cliente que, supuestamente, debido a un ataque DDoS a gran escala, su centro de datos "cayó" y ahora está comprometido con la recuperación. Esto inmediatamente generó muchas preguntas; después de todo, el sistema de protección DDoS estaba conectado a nosotros.



La analista inmediatamente comenzó a buscar en sus registros, pero no encontró nada sospechoso allí, todo estaba en el modo normal. Luego miré los registros de la red y llamé la atención sobre el extraño trabajo del balanceador, que distribuía la carga entre dos servidores que procesan el tráfico entrante. El balanceador de carga no distribuyó la carga, sino que, por el contrario, la dirigió a un solo servidor hasta que se "estranguló", y solo entonces redirigió el flujo al segundo nodo. Pero es mucho más interesante que en cuanto cayeron ambos servidores, este tráfico fue más allá y "puso" todo en general. Mientras se realizaba el trabajo de restauración, el cliente descubrió quién había cometido un error. Esto, al parecer, es el final del incidente: no tiene nada que ver con la seguridad de la información y simplemente se asocia con manos torcidas.error del administrador. Pero el cliente decidió investigar hasta el final. Después de verificar los AWP de los administradores, descubrió que todos los registros del sistema operativo se habían limpiado para el mismo posible artesano, y luego nos pidió que revisáramos sus acciones durante la última semana.



Curiosamente, este administrador fue objeto de nuestras investigaciones un par de semanas antes del incidente. Habló desde la red local a un host externo en el puerto 22. Entonces este incidente fue marcado como legítimo, porque Los administradores no tienen prohibido usar recursos externos para automatizar su propio trabajo o probar cualquier configuración de equipo nuevo. Quizás esta conexión entre la caída del centro de datos y la llamada a un host externo nunca se hubiera notado, pero hubo otro incidente: llamadas de uno de los servidores del segmento de prueba al mismo host en Internet que el administrador había contactado previamente - este incidente también fue notado por el cliente como legítimo. Después de observar la actividad del administrador, vimos solicitudes constantes a este servidor desde el segmento de prueba y le pedimos al cliente que lo probara.



Y aquí está el desenlace: se implementó un servidor web en ese servidor que implementa una funcionalidad parcial del sitio web principal del cliente. Resultó que el administrador planeaba redirigir parte del tráfico entrante a su sitio falso para recopilar datos del usuario para sus propios fines.

Salir

A pesar de que ya estamos en 2020, muchas organizaciones aún no se adhieren a las verdades comunes de la seguridad de la información, y la irresponsabilidad de su propio personal puede tener consecuencias catastróficas.



En este sentido, aquí hay algunos consejos:

1. Nunca exponga RDP y SSH al exterior, incluso si los oculta detrás de otros puertos, no ayuda.
2. Ajuste el nivel de registro más alto posible para acelerar la detección de intrusos.
3. Threat Hunting . TTPs , . .
4. , . , , .

, Solar JSOC (artkild)