NOTA: Las opiniones y puntos de vista expresados en esta publicación pertenecen a ESET y no reflejan necesariamente las opiniones ni las posiciones de MITRE Engenuity.
En la edición Enterprise de las Evaluaciones ATT&CK® de este año, MITRE planteó tres escenarios de ataque: uno asociado a la República Popular Democrática de Corea (RPDC) para poner a prueba actividades de ciberespionaje contra un sistema macOS; un escenario Cl0p para evaluar un ataque de ransomware contra un sistema Windows; y un escenario LockBit para simular un ataque de ransomware contra un entorno corporativo que incluía tanto un servidor Linux como estaciones de trabajo y servidores Windows.
ESET Inspect demostró una buena visibilidad en cada uno de los escenarios, al detectar cada etapa del ataque manteniendo, al mismo tiempo, un volumen total de detecciones bajo. Las detecciones generadas a partir de los ataques fueron correlacionadas automáticamente en incidentes por el Incident Creator de ESET Inspect, lo que brindó a nuestros analistas de seguridad una visión focalizada de los ataques y una comprensión clara de cómo se desarrollaron paso a paso.
Para comprender mejor el desempeño de ESET, repasaremos algunos de los cambios metodológicos introducidos por MITRE y luego analizaremos cómo Incident Creator optimizó la visualización y el flujo de trabajo de los analistas de seguridad que operan desde el panel de ESET Inspect.
Metodología
Esta evaluación incorporó varios cambios bien fundamentados en la metodología de los escenarios de detección, que consideramos reflejan mejor el trabajo real de los analistas de seguridad al enfrentarse a ciberataques en entornos productivos.
En primer lugar, la telemetría dejó de ser una categoría de detección, lo que implica que ya no es suficiente con demostrar que un evento ocurrió. La categoría de detección más baja ahora es General, que exige que la detección indique que un evento ocurrió y que es sospechoso o malicioso de alguna manera. Es importante destacar que un evento que ocurre en un sandbox no califica como un evento ocurrido dentro del entorno evaluado. Tal como se indica en su definición, una detección de tipo General debe responder al qué, dónde, cuándo y quién en relación con el entorno bajo prueba, y estos elementos no pueden determinarse a partir de ejecuciones en sandboxes externos.
En segundo lugar, algunos subpasos benignos fueron incorporados como una prueba para evaluar falsos positivos, y no como detecciones. Este es un cambio bienvenido, ya que desalienta el enfoque de “detectar todo”, que de otro modo puede generar un gran volumen de ruido, trabajo innecesario para los analistas de seguridad y un aumento en los costos de almacenamiento de datos. Otro beneficio de este ajuste es que permite calcular una métrica de precisión, que indica cuántas de las detecciones realizadas corresponden realmente a subpasos maliciosos o sospechosos.
En tercer lugar, se incluyeron algunos subpasos que no son evaluados. El objetivo de incorporar estos subpasos es simular de forma más realista un ciberataque, evitando saltos ilógicos en la progresión del ataque.
Por último, se introdujo una métrica de volumen que registra la cantidad de detecciones mostradas en el panel de control. Este es otro mecanismo para desalentar el enfoque de “detectar todo” y evitar que los proveedores permitan que sus paneles se vean saturados, en algunos casos, con millones de detecciones. Consideramos este ajuste como un avance positivo.
La métrica de volumen también registra la severidad de las detecciones, utilizando cinco niveles: crítico, alto, medio, bajo e informativo. Dado que ESET Inspect cuenta con tres niveles de severidad de incidentes (alto, medio y bajo) y tres niveles de severidad de detección (amenaza, advertencia e informativo), se acordó con el equipo de MITRE Engenuity el mapeo presentado en la Tabla 1.
Vale la pena aclarar por qué elegimos un puntaje de severidad de 22 como umbral para dividir los niveles de severidad bajo e informativo. Tal como se indica en nuestra documentación:
Las reglas con severidad 22 o inferior son reglas de telemetría. Por lo general, se utilizan únicamente como información adicional para la investigación de un incidente y, en muchos casos, pueden activarse por comportamientos legítimos. Si algunas de estas reglas generan demasiado tráfico en su entorno, puede considerarse desactivarlas.
A partir de este punto, nos referiremos a los niveles de severidad únicamente según la clasificación utilizada por ESET Inspect.
Una consecuencia importante de utilizar este mapeo es que las detecciones que no están correlacionadas con un incidente quedan fuera del alcance de la evaluación. Esto refleja en gran medida el uso previsto de ESET Inspect en escenarios reales: los incidentes conformados por detecciones correlacionadas constituyen el foco principal del trabajo de los analistas de seguridad. La información adicional y las detecciones no correlacionadas con incidentes, que en algunos casos pueden resultar valiosas, tienen un rol secundario.
Dado que los paneles de control suelen incluir distintas secciones que muestran detecciones y otra información en formatos detallados, resumidos o gráficos, se permitió a los proveedores indicar, a los fines de la evaluación, cuál es la vista estándar que se espera que utilicen los operadores de seguridad para gestionar los ataques. Solo la información presentada a través de esta vista es elegible para ser considerada como detección o falso positivo, y para la medición del volumen. En ESET Inspect, la vista estándar para los analistas de seguridad es Incidentes.
Incidentes
La vista Incidentes es el espacio principal que los operadores de seguridad deberían utilizar para gestionar su flujo de trabajo. Los incidentes se cargan automáticamente en esta vista de dos maneras:
- ESET Incident Creator, que utiliza un motor basado en inteligencia artificial para correlacionar múltiples detecciones en un único incidente.
- ESET Inspect, que actualmente cuenta con más de 100 reglas que generan un incidente al activarse, agrupando detecciones en un solo incidente según los equipos afectados, un período de tiempo determinado o ambos criterios.
Se recomienda a los operadores seguir el siguiente flujo de trabajo:
-Investigar cada incidente.
-Investigar las detecciones con severidad de amenaza que no estén correlacionadas con ningún incidente, siempre que el tiempo lo permita.
Al igual que en la evaluación del año pasado, cada escenario de ataque se ejecutó dos veces. En la segunda ejecución, se permitió a los proveedores realizar cambios de configuración con el objetivo de mejorar la visibilidad, reducir los falsos positivos y disminuir el volumen de detecciones. La Imagen 1 muestra la vista de Incidentes luego de la ejecución con los cambios de configuración.
Incident Creator no generó ningún incidente falso positivo durante la evaluación. Por el contrario, en la ejecución con cambios de configuración solo se creó uno o dos incidentes por escenario, y casi todas las detecciones relevantes disponibles en ESET Inspect fueron correlacionadas dentro de un incidente.
Aspectos destacados por escenario
En las siguientes secciones, repasaremos los principales puntos destacados de los resultados obtenidos por ESET en cada escenario.
- DPRK
ESET Inspect gestionó automáticamente el escenario de la DPRK como un incidente de severidad media creado por Incident Creator. Entre los aspectos más destacados de los resultados de ESET en este escenario se incluyen la detección de las dos backdoors depositadas en ubicaciones sospechosas, los procesos de backdoor que se hacían pasar por Docker y Zoom, el robo de información desde archivos del keychain y la ausencia de falsos positivos.
La Figura 2 muestra una parte del incidente correspondiente a las detecciones correlacionadas con este ataque, destacando una detección de la backdoor FULLHOUSE.DOORED que instala persistencia para una backdoor de segunda etapa, STRATOFEAR, como un launch daemon.
- Cl0p
En la ejecución con cambios de configuración, ESET Inspect gestionó automáticamente el escenario Cl0p como dos incidentes de alta severidad: uno creado por Incident Creator y otro generado por una regla que monitorea detecciones de filecoders en los endpoints.
Entre los aspectos más destacados de los resultados de ESET en este escenario se incluyen la detección de la carga de los instaladores y las DLL loader de SDBbot, la modificación de una clave del registro para lograr persistencia del RAT SDBbot, la eliminación de shadow copies, la desactivación de la recuperación de Windows tras un fallo de arranque y la ejecución del ransomware Cl0p.
La Figura 3 muestra una parte del incidente correspondiente a las detecciones correlacionadas con este ataque, destacando una detección asociada a escrituras o renombrados de archivos canary para la detección temprana de la ejecución de ransomware. La regla activada no solo finaliza el proceso malicioso, sino que también crea automáticamente un incidente en la vista Incidentes.
- LockBit
En la ejecución con cambios de configuración, ESET Inspect gestionó automáticamente el escenario LockBit como dos incidentes de alta severidad: uno generado por Incident Creator y otro activado por una regla específica que monitorea detecciones de spyware en endpoints.
Entre los principales hallazgos se destacan la detección del acceso inicial del atacante vía VNC, la modificación de un valor del registro para habilitar el inicio de sesión automático, el uso de SSH para conectarse a un servidor Linux dentro de la red interna, la propagación del ransomware LockBit a otros equipos mediante PsExec, su posterior ejecución y la limpieza de los registros de eventos de Windows para ocultar la actividad maliciosa.
La Figura 4 muestra un fragmento del incidente con las detecciones correlacionadas, donde se resalta la identificación de un proceso sospechoso que escribe o renombra archivos con las denominadas doble extensiones, un comportamiento característico de los filecoders.
Pensamientos finales
Creemos que el resumen anterior refleja de la mejor manera nuestro enfoque a la hora de diseñar ESET Inspect. Demuestra que los analistas de seguridad pueden tener un alto grado de confianza en que están gestionando amenazas reales de forma eficiente cada vez que ESET Inspect les presenta un incidente con detecciones correlacionadas.
Una vez más, queremos destacar que el equipo de MITRE ha ejecutado de manera profesional una nueva edición de la evaluación, introduciendo una serie de cambios pensados para incentivar a los proveedores a prepararse mejor frente a la diversidad de tácticas y técnicas que se observan en el mundo real, en lugar de competir por ser el “ganador” de una competencia que, en realidad, no existe.
Por nuestra parte, si bien buscamos seguir mejorando ESET Inspect en algunos aspectos para detectar subpasos adicionales verdaderamente positivos, este objetivo debe equilibrarse con el riesgo de que una expansión excesiva de la cobertura reduzca la precisión e incremente el volumen de alertas. Esto iría en detrimento de nuestro enfoque, aportando cada vez menos valor a un costo cada vez mayor.
En definitiva, esperamos que la visión de ESET sobre la evaluación de este año haya despertado tu interés por explorar con mayor profundidad nuestros resultados en la página de evaluaciones de MITRE ATT&CK.