¿Es posible defenderse completamente contra los ciberataques? Probablemente, puede hacerlo si se rodea de todos los medios de protección existentes y contrata a un gran equipo de expertos para administrar los procesos. Sin embargo, está claro que en realidad esto es imposible: el presupuesto para la seguridad de la información no es infinito y, sin embargo, se producirán incidentes. Y dado que sucederán, ¡entonces debes prepararte para ellos!
En este artículo, compartiremos escenarios típicos para investigar incidentes de malware, nos dirá qué buscar en los registros y daremos recomendaciones técnicas sobre cómo configurar las herramientas de protección de información para aumentar las posibilidades de éxito de una investigación.
El proceso clásico para
responder a un incidente relacionado con malware involucra etapas como detección, contención, recuperación, etc., sin embargo, todas sus capacidades, de hecho, se determinan en la etapa de preparación. Por ejemplo, la tasa de detección de infecciones depende directamente de qué tan bien esté configurada la auditoría en la empresa.
Ciclo de respuesta a incidentes SANS clásico
En términos generales, las acciones de los analistas durante la investigación son las siguientes:
- Generación de versiones que explican las causas del incidente (por ejemplo, "el malware se instaló en el host porque el usuario lo lanzó desde un correo electrónico de phishing" o "el incidente es una falsa alarma porque el usuario visitó un sitio legítimo ubicado en el mismo alojamiento que el servidor de administración malware ").
- Priorización de versiones por grado de probabilidad. La probabilidad se calcula (pero más bien se finge) en base a estadísticas de incidentes pasados, la criticidad del incidente o sistema, y también en base a la experiencia personal.
- Estudio de cada versión, búsqueda de hechos que lo prueben o refuten.
Por supuesto, no tiene sentido probar todas las hipótesis posibles, al menos porque el tiempo es limitado. Por lo tanto, aquí veremos las versiones más probables y los escenarios típicos para investigar incidentes de malware.
Escenario 1
Sospecha que un sistema no crítico ha sido comprometido por malware. Debido a la naturaleza acrítica del sistema, se ha asignado un poco de tiempo para la verificación.
Lo primero que hacen la mayoría de los ingenieros de respuesta es ejecutar una verificación antivirus. Sin embargo, como sabemos, un antivirus no es tan difícil de manejar. Por lo tanto, vale la pena generar y desarrollar la siguiente versión altamente probable: el malware es un archivo o servicio ejecutable separado.
Como parte del desarrollo de esta versión, hay tres pasos simples a seguir:
- Filtre el registro de seguridad por evento 4688, de modo que obtengamos una lista de todos los procesos que comenzaron.
- Filtre el registro del sistema por evento 7045, de modo que obtengamos una lista de las instalaciones de todos los servicios.
- Identifique nuevos procesos y servicios que no estaban previamente en el sistema. Copie estos módulos y analícelos en busca de código malicioso (escanee con varios antivirus, verifique la validez de la firma digital, descompile el código, etc.).
Enumere todos los procesos y servicios en ejecución en Event Log Explorer
En teoría, este es un proceso bastante trivial. Sin embargo, en la práctica hay una serie de dificultades para las que hay que estar preparado.
En primer lugar, la configuración de auditoría estándar de Windows no registra los hechos del inicio del proceso (evento 4688), por lo que debe habilitarse por adelantado en la política de grupo de dominio. Si sucedió que esta auditoría no se incluyó de antemano, puede intentar obtener una lista de archivos ejecutables de otros artefactos de Windows, por ejemplo, del registro de
Amcache . Puede
extraer datos de este archivo de registro utilizando la utilidad
AmcaheParser .
Un ejemplo de extracción de los hechos de los procesos de inicio de Amcache.hve
Sin embargo, este método no es muy confiable, ya que no proporciona información precisa sobre cuándo exactamente y cuántas veces se inició el proceso.
En segundo lugar, la evidencia del lanzamiento de procesos como
cmd.exe, powershell.exe, wscript.exe y otros intérpretes será de poca utilidad sin información sobre la línea de comandos con la que se iniciaron los procesos, porque contiene la ruta a un archivo de script potencialmente malicioso.
Ejecutar el intérprete de guiones sin información sobre qué guión se lanzó
Otra característica de Windows es que la auditoría de la línea de comandos del proceso iniciado se realiza configurando por separado la política de grupo de dominio:
Configuración de la computadora -> Políticas -> Plantillas administrativas -> Sistema -> Auditoría Creación de procesos -> Incluir línea de comandos en eventos de creación de procesos . Al mismo tiempo, el popular Windows 7/2008 no registra la línea de comandos sin la actualización
KB3004375 instalada , así que póngala con anticipación.
Si sucedió que no configuró nada por adelantado u olvidó la actualización, puede intentar averiguar la ubicación del script en los archivos de
Prefetch (una
utilidad para ayudar ). Contienen información sobre todos los archivos (principalmente DLL) cargados en el proceso en los primeros 10 segundos de vida. Y el guión contenido en los argumentos de la línea de comandos del intérprete seguramente estará presente allí.
Ejemplo de encontrar un argumento de línea de comando "perdido" en Prefetch
Pero este método no es del todo confiable: la próxima vez que inicie el proceso, se sobrescribirá el caché Prefetch.
Preparación para la investigación:
- Incluya una auditoría avanzada de la creación y finalización de procesos.
- Habilite el registro de argumentos de la línea de comandos del proceso.
- Instale la actualización KB3004375 en Windows 7 / Server 2008.
Escenario 2
Se registró un acceso al servidor de administración de malware en el enrutador perimetral. La dirección IP del servidor malicioso se obtuvo de una suscripción de inteligencia de amenazas de seguridad media.
En
uno de nuestros artículos anteriores, dijimos que los analistas de TI pecan al agregar a las listas de indicadores de direcciones IP de compromiso de servidores que alojan centros de control de malware y sitios web legítimos al mismo tiempo. Si acaba de comenzar a formular procesos de respuesta, en las primeras etapas es mejor abandonar el uso de dichos indicadores, porque cada intento de un usuario de ingresar a un sitio web legítimo se verá como un incidente completo.
Una de las opciones para responder a tales alarmas puede reducirse a verificar qué proceso realizó la conexión: si se trata de un navegador de Internet, en ausencia de otros hechos que indiquen compromiso, el incidente puede considerarse una falsa alarma.
Hay muchas formas de averiguar qué proceso inició la conexión: puede ejecutar
netstat y ver los sockets actuales o recopilar un volcado de memoria y luego configurar la
volatilidad en él, que también puede mostrar conexiones ya completadas. Pero todo esto es largo, no escalable y lo más importante, no es confiable. Es mucho más confiable obtener toda la información necesaria del registro de seguridad de Windows.
Correlación del evento de "acceso a direcciones IP maliciosas" en el sistema HPE Arcsight SIEM y el proceso correspondiente en el registro de seguridad de Windows
Preparación de investigación
Para resolver este escenario en una máquina de usuario, debe habilitar el registro de todas las conexiones de red al registro de seguridad. Esto se puede hacer en función de los eventos de
auditoría de
la plataforma de filtrado y la
auditoría de descarte de paquetes .
Al mismo tiempo, la revista puede comenzar a atascarse rápidamente, así que aumente su tamaño a 2-3 GB. En nuestra experiencia, en un host de usuario normal, esta cantidad es suficiente durante aproximadamente 3 días para registrar todos los sockets, y este período es suficiente para una investigación exitosa.
En servidores altamente cargados, como controladores de dominio, servidores web, etc., no debe hacer esto, el registro se desbordará mucho más rápido.
Escenario 3
Su sistema de detección de anomalías NG / ML / Anti-APT informa que 30 hosts están explorando para obtener las mismas cuentas.
Cuando ingresan a una nueva red, los atacantes generalmente intentan averiguar qué servicios están presentes en ella y qué cuentas se usan; esto ayuda mucho en el proceso de un mayor movimiento a lo largo de la infraestructura. En particular, esta información se puede obtener de Active Directory usando el comando
net user / domain .
Si la inteligencia potencial se lleva a cabo desde un host, puede investigarse, incluido el uso de los registros de los procesos en ejecución. Sin embargo, si hay muchos hosts y los ataques son del mismo tipo (ocurrieron al mismo tiempo o se solicitó el mismo conjunto de entidades de AD), entonces tiene sentido, en primer lugar, excluir un falso positivo típico. Para hacer esto, cree y verifique las siguientes versiones:
- La inteligencia se fija en 30 hosts para los mismos objetos AD porque el usuario legítimo de la red , el administrador, lanzó el comando net .
- La inteligencia se repara en 30 hosts para los mismos objetos AD, porque creó el mismo software legítimo.
El análisis estadístico de los registros ayudará a encontrar estos puntos nodales (un usuario o proceso común). Demostramos este método en un artículo anterior aplicado a
los registros del servidor DNS . Sin embargo, tales métodos de investigación efectivos no pueden usarse si el almacenamiento de datos no se organizó de antemano.
Preparación de investigación
Es necesario organizar el almacenamiento a largo plazo de al menos los siguientes datos de los registros de servicios de red comunes:
- Controladores de dominio: entradas, salidas de cuentas y emisión de tickets Kerberos (categoría Inicio de sesión de cuenta en la configuración avanzada de auditoría).
- Proxies: direcciones, puertos de origen y de servidor externo, así como la URL completa.
- Servidores DNS: consultas DNS exitosas y no exitosas y su fuente dentro de la red.
- Enrutadores perimetrales: construidos y desmontables para todas las conexiones TCP / UDP, así como conexiones que intentan romper las reglas de acceso lógico: por ejemplo, intenta enviar una consulta DNS directamente al exterior, sin pasar por el servidor DNS corporativo.
Escenario 4
Su dominio se ha visto comprometido y le preocupa que un atacante pueda establecerse en la infraestructura utilizando la técnica DCShadow.
Supongamos que sucede algo terrible: encuentra que la cuenta del administrador del dominio se ha visto comprometida.
Responder a un incidente de este tipo incluye una capa de trabajo muy grande, que incluye un análisis de todas las acciones cometidas en virtud de esta cuenta. Parte de esta investigación se puede hacer utilizando solo los registros del controlador de dominio. Por ejemplo, puede estudiar los eventos asociados con la emisión de tickets de Kerberos para comprender de dónde fueron con esta cuenta. O puede analizar los eventos asociados con el cambio de objetos AD críticos para verificar si la composición de los grupos altamente privilegiados (los mismos administradores de dominio) ha cambiado. Naturalmente, todo esto requiere una auditoría preconfigurada.
Sin embargo, existe el problema de que un atacante con derechos de administrador de dominio puede modificar objetos AD utilizando la técnica DCShadow, que se basa en el mecanismo de replicación entre controladores de dominio.
Su esencia es que el propio atacante parece ser un controlador de dominio, realiza cambios en AD y luego replica (sincroniza) estos cambios con controladores legítimos, evitando así la auditoría de los cambios de objetos configurados en ellos. El resultado de tal ataque puede ser agregar un usuario a un grupo de administradores de dominio o enlaces más complicados al cambiar el atributo
Historial de SID o al modificar el objeto ACL
AdminSDHolder .
Para verificar la versión sobre la presencia de cambios no confirmados en AD, debe estudiar los registros de replicación del controlador: si las direcciones IP distintas de los controladores de dominio estuvieron involucradas en la replicación, puede decir con gran confianza que el ataque fue exitoso.
Eliminar un controlador de dominio desconocido de la replicación de ADPreparación para la investigación:- Para investigar acciones cometidas por una cuenta comprometida, debe incluir de antemano:
- Auditoría de entradas y salidas de cuentas y emisión de tickets de Kerberos (categoría de inicio de sesión de cuenta en configuraciones de auditoría avanzadas).
- Auditoría de cambios en cuentas y grupos (categoría Gestión de cuentas ).
- Para investigar versiones relacionadas con posibles ataques DCShadow:
- Habilite la auditoría detallada de la replicación del servicio de directorio .
- Organice el almacenamiento a largo plazo de eventos 4928/4929, en los que el origen del evento no sea un controlador de dominio legítimo (atributo DCShadow).
Conclusión
En este artículo, hablamos sobre algunos escenarios típicos para investigar incidentes de seguridad de la información y medidas para su preparación preventiva. Si está interesado en este tema y está listo para ir más allá, le recomiendo que preste atención a
este documento , que describe en qué eventos de Windows puede encontrar rastros del uso de técnicas de piratería populares.
Me gustaría terminar con una cita de un estudio reciente de una empresa de seguridad cibernética:
“En su mayor parte, los directores rusos de seguridad de la información tienden a dar respuestas pesimistas [a las preguntas de investigación]. Por lo tanto, la mitad (48%) cree que el presupuesto no cambiará de ninguna manera, y el 15% piensa que se reducirán los fondos ".
Para mí personalmente, esto es una señal de que el presupuesto restante en el nuevo año se gasta mejor no en comprar SZI de última generación como detectores de Machine Learning, otros IDS de próxima generación, etc., sino en afinar aquellos SZI que ya existen. Y el mejor SZI está configurado correctamente en los registros de Windows. En mi humilde opinión.