Get best of the week

Investigación de incidentes de seguridad de la información en la naturaleza: fuentes inesperadas de información

imagen

Se ha escrito mucho sobre la investigación de incidentes informáticos, o análisis forense digital, hay muchas herramientas de hardware y software listas para usar, los principales artefactos de los sistemas operativos son bien conocidos y se describen en manuales, libros y artículos. Parece que es difícil: lea el manual y encuentre el requerido. Pero hay casos técnicamente difíciles cuando el análisis de esos artefactos muy conocidos no proporciona suficiente información para restaurar la cronología de los eventos. ¿Cómo estar en esta situación? Lo analizamos con ejemplos reales de nuestras investigaciones.

¿Por qué hay una falta general de artefactos básicos? Puede haber varias razones:

  1. La infraestructura no está preparada adecuadamente para el monitoreo completo y la respuesta a los eventos ( escribimos sobre esto aquí )
  2. , ( Digital Forensic)
  3. , ( – , MFT-).

Por lo tanto, si la infraestructura es grande y variada, el incidente se desarrolló durante mucho tiempo y el atacante es un "kalach triturado", se necesitan fuentes adicionales de información para divulgar todas sus acciones y restaurar la cronología de los eventos.

Dependiendo de la situación, los sistemas SIEM, el análisis de los flujos de red de Netflow o el tráfico sin procesar (aunque en realidad en el 90% de los casos esto no es posible), así como los artefactos inusuales que se relacionan con cualquier software de terceros, por coincidencia, pueden venir al rescate. en la infraestructura del cliente.

Es en el último tipo de artefactos que detendremos.

Ivanti Endpoint Manager (anteriormente LANDESK Management Suite). Sistema de gestión de activos de TI

www.ivanti.ru/company/history/landesk

Conectándose al monitoreo de uno de nuestros nuevos clientes, detectamos en su infraestructura la limpieza de registros de eventos en uno de los servidores, mientras que no hubo otras manifestaciones de actividad maliciosa en el sistema SIEM. Durante el análisis, se descubrió que el servidor estaba comprometido y el atacante usó un equipo especial para pasar desapercibido. Consistió en lo siguiente:

  1. Los eventos de registro de seguridad se redirigieron a un archivo temporal separado,
  2. un atacante realizó las acciones necesarias,
  3. los eventos se redirigen de nuevo al registro de seguridad,
  4. Se eliminó el archivo temporal.
  5. ¡Lucro!

Como resultado, a pesar del hecho de que el diario de seguridad se configuró adecuadamente, no contenía ningún evento relacionado con actividades maliciosas, mientras que en sí mismo parecía intacto.

Después de un breve análisis, descubrimos que el atacante ha estado "viviendo" en la infraestructura durante aproximadamente 2-3 años, lo que permitió comprometer todos los servidores clave. En tales casos, el valor de cualquier fuente adicional de información aumenta, ya que algunos artefactos básicos están deshilachados o no son informativos y no permiten una imagen completa del incidente.

En busca de fuentes adicionales de información, realizamos un inventario oral de los servicios y sistemas utilizados en la infraestructura y descubrimos que, junto con la implementación de nuestro monitoreo, el cliente comenzó a implementar un sistema de gestión de activos de TI
Ivanti Endpoint Manager.

Como el sistema todavía era inestable (los eventos de los agentes no se enviaron parcialmente
al servidor), no pudimos ver de manera central los eventos de los hosts en el servidor. Sin embargo, después de haber decidido buscar artefactos almacenados por Ivanti Endpoint directamente en el host, encontramos que este software almacena información sobre los lanzamientos de procesos localmente en la siguiente rama del registro:

HKLM \ SOFTWARE \ Wow6432Node] \ LANDesk \ ManagementSuite \ WinClient \ SoftwareMonitoring \ MonitorLog \ < La ruta al archivo ejecutable>

La siguiente información se almacena en las claves correspondientes:

  • primera hora de inicio (en formato FILETIME)
  • último tiempo de ejecución (en formato FILETIME)
  • numero de arranques
  • usuario con derechos sobre los cuales se inició el archivo ejecutable


Artefactos de inicio del proceso de Ivanti Endpoint

Gracias a esta información, pudimos determinar el momento de la aparición del atacante en algunos sistemas que antes no conocíamos. Además, parte de su kit de herramientas se divulgó basándose únicamente en el nombre de los archivos ejecutables.

Citrix NetScaler Sistema para proporcionar acceso a recursos y aplicaciones corporativas.

www.citrix.com/en-us/products/citrix-adc


Citrix NetScaler Workflow

Otra investigación interesante. Un atacante ingresó a la infraestructura de la empresa a través de una VPN. Trabajó en la zona horaria UTC +8. Después de la autenticación, se comportó de forma bastante agresiva (escaneó internamente subredes internas utilizando la máscara / 24 y / 16), como resultado de lo cual, de hecho, se notó.

La VPN se configuró en Citrix NetScaler Enterprise Resource and Application System. Después de estudiar sus registros, pudimos establecer el momento de la primera "visita" (lea la fecha de compromiso), las cuentas de los empleados utilizadas por el atacante (por cierto, más de 5 cuentas estaban comprometidas) y las direcciones IP de los servidores proxy desde los que trabajó.

La investigación en sí misma finalizó con éxito: logramos establecer una fuente de compromiso; resultó que el sistema interno para restablecer las credenciales accesibles desde Internet estaba sujeto a la inyección de SQL.

Pero ahora quiero señalar algo más: después de pasar la autenticación VPN en Citrix NetScaler, todas las solicitudes de usuarios HTTP se registraron correctamente. El atacante probablemente no lo sabía o confundió sus interfaces de red y envió sus propias consultas a los motores de búsqueda a través de la red corporativa del cliente. Esto nos permitió obtener información sobre los sistemas de interés para el atacante, sus competencias y las herramientas utilizadas.


Archivo de registro de Citrix NetScaler


Información que buscaba un atacante a través de Citrix NetScaler


Información que buscaba un atacante a través de Citrix NetScaler

Secret Net Studio. Sistema para proteger la información del acceso no autorizado.

www.securitycode.ru/products/secret_net

Un buen día, un boleto con un incidente de autenticación sospechoso cayó en nuestra primera línea bajo la cuenta de un empleado de TI de la compañía en el servidor de administración por la noche (el empleado estaba de vacaciones en ese momento, tenía una VPN no tenía). Arquitectónicamente, el servidor de administración se ubicó en un segmento de red separado junto con varios otros servidores clave de la compañía (incluido el servidor Secret Net), mientras que SIEM solo recibió eventos del propio servidor de administración (desafortunadamente, los clientes no siempre están de acuerdo en conectar todas las fuentes potenciales )

La primera línea, que procesa el ticket y recopila información sobre lo que sucedió después de la autenticación, se topa con varios lanzamientos de procesos sospechosos (rutas no estándar, nombres de archivos binarios en una letra) y el lanzamiento de mstsc.exe, lo que indica una posible sesión RDP.

Al darnos cuenta de que esto era un compromiso potencial, solicitamos imágenes de todos los servidores
y comenzó su análisis. Al abrir la primera imagen (servidor Secret Net), recibimos una "gran sorpresa" como regalo: los registros del sistema, la seguridad y las aplicaciones se eliminaron y se eliminaron, de modo que incluso los intentos de recuperación no tuvieron éxito. Solo fue posible comparar que las entradas en los registros de TerminalServices del servidor SecretS coincidieron en el tiempo con el lanzamiento de mstsc.exe en el servidor de administración, lo que significa que el atacante definitivamente estaba en Secret Net. El análisis de los servidores restantes también falló.

Como resultado, nos encontramos en una situación en la que se sabe con certeza que el atacante está allí (definitivamente hizo algo y lo inició), pero no tenemos registros de host, porque se eliminan las trazas
y no hay registros de red, porque todos los servidores están en la misma subred.

Se encontró una solución incluso a partir de esta situación. El sistema Secret Net es muy versátil y consta de muchos componentes, tanto a nivel de kernel como a nivel de usuario. Después de analizar cada archivo de registro registrado y guardado por varios componentes de Secret Net, nos encontramos con varios artefactos excelentes que dejó el control de archivos. Cuando reunimos todo, obtuvimos información sobre las acciones del atacante (realmente estaba en cada servidor desde esta subred) y sobre sus herramientas.

Por cierto, la información recibida ayudó a eliminar por completo la presencia de un atacante en la infraestructura.


Esquema de un atacante que trabaja a través del servidor de Secret Net Studio Secret Log Studio


archivo de control de archivos

KVRT. Herramienta antivirus gratuita

www.kaspersky.ru/downloads/thank-you/free-virus-removal-tool

Se nos contactó para ayudarnos a investigar un incidente relacionado con la actividad maliciosa saliente (actividad de botnet y minero) desde las direcciones públicas de la compañía. Después de recibir las imágenes y los registros del sistema, comenzamos el análisis y encontramos algunos artefactos que indican un compromiso del servicio web público de la organización y los archivos maliciosos que quedan. Desafortunadamente, esto no fue suficiente para responder a todas las preguntas formuladas por el cliente: entre otras cosas, no encontramos rastros de archivos del minero, aunque no hubo mucho tiempo entre arreglar la actividad maliciosa y nuestra investigación.

Volviendo una vez más a los artefactos y registros, llamamos la atención sobre los rastros de varios escáneres antivirus gratuitos. Quedó claro que los archivos que nos faltaban estaban encriptados y en cuarentena, y las marcas de tiempo del sistema de archivos se borraron de manera segura.

Entre los escáneres utilizados estaba KVRT, que detectó algunos archivos maliciosos y los puso en cuarentena. La ubicación estándar de los archivos de cuarentena es C: \ KVRT_Data \ Quarantine, y descifrarlos es muy fácil: un XOR simple con una clave conocida es e2 45 48 ec 69 0e 5c ac.


Cuarentena descifrada de KVRT

Como resultó más tarde, el administrador de TI aún logró escanear el sistema con escáneres antivirus gratuitos antes de nuestra llegada, a pesar de la recomendación de no tocar nada.
Como resultado, los archivos en cuarentena ayudaron a cerrar las brechas en la cronología de los eventos y a responder todas las preguntas.


Cada investigación es siempre algo inusual, único y versátil. Sí, existen artefactos conocidos de los sistemas operativos, pero antes de que comience la investigación, es difícil predecir la integridad de la información que se puede obtener después de su análisis. Por lo tanto, antes de una investigación técnica del incidente, le recomendamos que haga un inventario del software y los sistemas y no sea flojo para estudiarlos como una posible fuente en la investigación.

More articles:


All Articles