Saludos! Habiendo visto suficiente interés en lo que está sucediendo en The Standoff en las filas de defensores en PHDays 9, decidimos hablar sobre cómo la preparación y el "enfrentamiento" tuvieron lugar a través de los ojos del Jet CSIRT como parte del Equipo Jet Security.
Guo Standoff, creé
Algo así, los colegas informaron que una vez más estábamos participando en The Standoff, y naturalmente estuvimos de acuerdo.
Vale la pena mencionar de inmediato que para los defensores de este año, el formato de la competencia ha cambiado un poco. Todos los equipos recibieron infraestructuras de oficina muy similares, y esto permitió a los organizadores ingresar una calificación de defensores en ciertos loros. Y para el equipo de Jet Security, esta fue la primera "confrontación", donde se defendió la oficina, y no la infraestructura industrial.
Tenemos acceso a la infraestructura para prepararnos para la batalla cibernética a fines de abril. Después de la auditoría de la infraestructura, se montó todo un vagón de deficiencias, aquí hay algunas de ellas. Absolutamente en toda la infraestructura no había parches reales. Las contraseñas de todos los usuarios se pueden obtener a través de Ntds.dit en texto sin cifrar. Además, algunos usuarios tenían contraseñas de la lista TOP-500 o contraseñas con un hash fácilmente reversible. El endurecimiento del sistema era casi nulo o nada en absoluto. Algunos hosts en la DMZ tenían una interfaz en la subred del servidor.
Con base en los resultados de la auditoría, desarrollamos ciertas medidas de seguridad, a su vez, los organizadores, después de la aprobación preliminar, nos permitieron aplicar las políticas que necesitábamos y llevar todas las herramientas y herramientas de seguridad que se pueden implementar en un entorno virtual. Debido a los plazos ajustados, algunas ideas sobre medidas de protección se cayeron al principio. La configuración principal y el perfil del SPI se llevaron a cabo durante las vacaciones de mayo (hola a todos los que arrojaron fotos de los picnics, nosotros también los amamos), y algunos de los equipos de protección tuvieron que ajustarse justo antes del inicio en el sitio. Además, varios servicios tenían prohibido parchear y reconfigurar fuertemente. Por ejemplo, uno de estos fue Oracle Weblogic con CVE-2019-2725, que PoC se lanzó en los primeros días de mayo de 2019.
Bueno, y una lista de lo que trajimos con nosotros:
- Cortafuegos (proporcionado por los organizadores ha sido reemplazado);
- Solución antivirus;
- WAF;
- EDR
- Un par de soluciones de engaño;
- Un par de escáneres de vulnerabilidad;
- Pila ELK para análisis adicional de Netflow;
- SIEM
También deberíamos hablar sobre lo que iba a SIEM. Como fuentes de eventos, teníamos a nuestra disposición los registros de Windows, Sysmon, registros de Auditd y, como se puede adivinar, eventos del propio SZI. Si no hubo problemas especiales con los dos primeros, y rápidamente acordamos cambios en la política y configuración de Sysmon, entonces tuvimos que luchar con los organizadores para la configuración de Auditd.
Paralelamente a esto, identificamos los principales vectores de ataque y, en base a esto, seleccionamos y adaptamos escenarios relevantes y reglas de correlación, un total de aproximadamente 160 reglas de correlación. Además, se ensambló un conjunto de paneles variados para nodos críticos, SZI y lo que requería atención especial en la infraestructura del juego.
El enfrentamiento
Para The Standoff, decidimos adherirnos al concepto de separar los incidentes en externos e internos, ya que existía un entendimiento exacto de que afuera trataríamos activamente de escanear y operar la web. Los incidentes relacionados con el escaneo y los intentos de evadir WAF se monitorearon por separado, con una prioridad más baja, esto nos permitió centrarnos en incidentes internos. Se distribuyeron paneles para SPI entre los defensores en áreas de responsabilidad, y se asignaron al menos 2 personas a cada herramienta, para la posibilidad de rotación y descanso.
Todo sucedió, como esperábamos. El enfrentamiento comenzó alrededor de las 10 de la mañana, y tan pronto como se inició, el sistema SIEM comenzó a emitir un montón de incidentes relacionados con un escaneo externo y los intentos de los atacantes de explotar la red. En algunos casos, incluso el grupo no guardó. Junto con esto, los verificadores de los organizadores comenzaron a trabajar, verificando el estado de varios servicios en la oficina, lo que nos obligó a volver a realizar perfiles hasta cierto punto para cortar los falsos positivos asociados con ellos.
En las primeras horas del juego, el equipo de Hack.ERS logró encontrar las credenciales estándar del administrador (admin / admin) en el CMS de uno de los recursos y detectar una posible vulnerabilidad de LFI. Estos intentos no pasaron desapercibidos, nuestros defensores llevaron a cabo una respuesta operativa y los atacantes al final no pudieron avanzar más.
Hasta el final del primer día del juego, los métodos no cambiaron, WAF aún superó todos los intentos de subir algo interesante a los sitios web de la compañía, y las mismas "direcciones externas", sin cesar, intentaron escanear nuestros recursos.
En total, para todo el evento, se registraron 3000 incidentes relacionados con intentos de escaneo, sin tener en cuenta la agrupación de eventos en incidentes.
Y alrededor de 2500 incidentes con intentos de evadir WAF, también sin tener en cuenta la agrupación de eventos en incidentes.
Hacia la noche, la intensidad de todas las actividades disminuyó; hubo varias razones para esto. Parte de los defensores y atacantes no pudieron resistir la prueba de sonido y el ensayo del concierto, que se suponía que se celebraría al día siguiente. Algunos equipos atacantes decidieron tomar un descanso y continuar los ataques más cerca de la mañana con la esperanza de que los defensores y el monitoreo tuvieran menos recursos de monitoreo y algo de fatiga.
En la mañana del segundo día, los atacantes cambiaron de táctica. La información sobre una parte de sus empleados se publicó en uno de los sitios web de la compañía. Los hackers aprovecharon esta información y comenzaron a recopilar activamente cuentas de usuario a través de Exchange (estadísticas de intentos en la captura de pantalla).
Un poco más tarde, se hicieron intentos inseguros para seleccionar una contraseña en la puerta de enlace VPN, las cuentas que no estaban en nuestra infraestructura participaron en el bruto. Con alta probabilidad, los atacantes intentaron usar cuentas de la infraestructura ya hackeada con la esperanza de que los organizadores los dejaran igual en todas partes. Como resultado, toda la situación con fuerza bruta nos llevó a crear un grupo de paneles sobre tendencias en términos de autenticación de usuarios. Además, reforzamos el monitoreo de incidentes relacionados con la fuerza bruta exitosa, pero, afortunadamente, no se detectaron tales casos.
Aproximadamente una hora antes del final del juego, las tendencias vieron intentos únicos exitosos de autenticar a varios usuarios, incluidos los de Exchange, el análisis operativo mostró que las fuentes eran máquinas de usuario directamente, la mayoría de los eventos indicaron que los organizadores iniciaron sesión desde la consola VMware Vcenter
Al mismo tiempo, grabamos un escaneo interno desde un nodo que se conectó con éxito a través de VPN. Después de un análisis operativo de los eventos relacionados con el incidente, quedó claro que los atacantes podían comprometer las credenciales de varios usuarios y, a juzgar por la ausencia de intentos de autenticación fallidos, es probable que los datos del usuario se hayan "filtrado".
Se transmitió información a los defensores. Durante todo el tiempo de respuesta en las computadoras personales de los usuarios comprometidos, la solución de punto final se puso en modo de protección preventiva para reducir la capacidad de afianzarse en el sistema. Las sesiones de ataque en la puerta de enlace VPN se dejaron caer por la fuerza, y los atacantes fueron expulsados del perímetro protegido. En UZ comprometida, las contraseñas se cambiaron rápidamente.
En ese mismo momento, los muchachos del equipo True0xA3 subieron al escenario y usaron con éxito OSINT e informaron el compromiso de la oficina de Behealthy, que está bajo la protección de otro equipo. Los atacantes lograron comprometer al administrador del dominio. Los organizadores fueron notificados de nuestro incidente y se proporcionaron pruebas.
La última hora fue especialmente calurosa debido al repentino OSINT, todos esperaban más preparativos de los organizadores. El equipo de monitoreo, a su vez, monitoreó todas las anomalías e incidentes sospechosos, pero después de un intento fallido de penetrar nuevos intentos de piratería, no lo siguió. Así que pasaron los últimos minutos de tiempo de juego, y el pirateo exitoso de la oficina protegida por el Equipo de Seguridad de Jet no ocurrió.
Y un poco de estadísticas finales para dos días de juego:
- 1200 EPS en promedio y un poco menos de 3000 EPS en el pico;
- Cerca de 7000 incidentes;
- Más de 120 millones de eventos.
Factores que nos ayudaron a ganar
- Distribución competente de roles. Cada uno se preparó y participó en la mayoría de lo que hace en proyectos cotidianos. Nadie tuvo que estudiar materiales de la categoría de "cortafuegos para tontos".
- Perfil operativo de las reglas de correlación. Todos los falsos positivos se procesaron y se hicieron correcciones relacionadas con las características de la infraestructura de juego.
- Pronta respuesta. Debido al hecho de que se asignaron varias personas a cada tipo de SZI y sistemas, no tuvimos problemas con el hecho de que la persona responsable descansara o simplemente se fuera por un par de minutos. Toda la información del monitoreo se procesó lo más rápido posible.
- Experiencia en el endurecimiento y seguimiento de diversas infraestructuras.
PD: Un agradecimiento especial a todos los que vinieron y formularon preguntas, y nos disculpamos con aquellos que no pudieron decir algo en el proceso: el equipo estaba esperando "cosacos mal manejados" de los atacantes y no pudo revelar todos los detalles.
Dmitry Lifanov, experto en el Centro de Monitoreo y Respuesta a Incidentes de Seguridad de la Información Jet CSIRT