Hipótesis en el campo de la detección de ciberamenazas

La detección de amenazas es el paso clave para la ciber defensa de las organizaciones, es la forma en la que con claridad alimentamos nuestros sistemas de protección y respuesta. Solo encontrando esa amenaza activa es que podemos actuar, aislar, eliminar, engañar o mejorar los modelos de ciberamenazas.

Explorando algunos ejemplos sobre la afirmación anterior es que notamos que hay muchos casos en los que SÍ es posible actuar a nuestro favor sin la necesidad de haber hecho una detección de algún tipo, activando por ejemplo un firewall, desplegando una solución antimalware, o utilizando una contraseña compleja. Esto no es del todo cierto, ya que todas las acciones de protección que aplicamos (sean preventivas o reactivas), están basadas en una comprensión de las amenazas que han sido modeladas previamente como el caso de estrategias más abarcativas como el Principio del Mínimo Privilegio (PoLP), la vieja y querida defensa en profundidad o el modelo de Confianza Cero o “Zero Trust”.

Entendiendo esta mirada es que haremos foco a continuación en el comportamiento de los ciberatacantes y cómo es posible destilar a partir de una serie de hipótesis reglas de detección utilizables. En este post analizaremos la lógica que se puede encontrar detrás de la detección basada en comportamiento, algunos lenguajes para la generación de reglas exportables y un modelo de detección dinámica conocido como “Detection as Code”.

De la técnica a la detección

Tomaremos algunas técnicas comúnmente utilizadas dentro de la cadena de ciberataque para analizarlas, en este caso usaremos de referencia la matriz de MITRE ATT&CK en contexto de caza de amenazas (podés introducirte en el tema en nuestro post anterior)

T1087.004 - Account Discovery: Cloud Account

Vamos a comenzar situándonos algo avanzados en las etapas de un ciberataque y tomar de referencia la técnica de enumeración “Descubrimiento de cuentas” en su variante “Cuentas de la nube”. Esta técnica, como la mayoría de técnicas de enumeración, está basada en la premisa de que el ciberatacante podría intentar recopilar una lista de elementos adicionales que le permitan expandir su ataque, para esta técnica en particular, los datos descubiertos pueden ser usuarios y roles dentro de un servicio en la nube (Azure AD, Google Workspace, IaaS, Office 365, SaaS).

Reconociendo este comportamiento, analizamos la forma específica en la que un ciberatacante podría llevarlo adelante en la práctica. Para ser específicos con nuestro ejemplo, haremos foco en la interfaz de comandos de Azure (AZ CLI). MITRE ATT&CK nos propone sobre esto el comando “az ad user list” como una muestra. Una posible salida de este comando con algunos parámetros entregaría datos específicos de los usuarios.

Salida de ejemplo de “az ad user list”

Una hipótesis entonces para comenzar con “nuestro destilado por la detección” podría ser:

“Si el comando ‘AZ AD USER LIST’ es ejecutado, un adversario está realizando un DESCUBRIMIENTO”

Desde la mirada de “la detección” podemos ver que el grado de precisión de esta aseveración es bajo, ya que podemos encontrar varios casos en los que encontremos este comportamiento y no se trate de un atacante. Por ejemplo en la implementación de algún tipo de solución por parte de un administrador de la nube, incluso algún software de gestión de identidades que realice consultas a través de la misma API. Debemos aquí refinar nuestra hipótesis para mejorar la precisión, por ejemplo:

“Si el comando ‘AZ AD USER LIST’ es ejecutado desde una terminal desconocida, un adversario está realizando un DESCUBRIMIENTO”

Esta nueva definición nos aumenta el grado de precisión, aunque por el contrario nos acota el alcance, sólo podemos detectar este comportamiento si la terminal de origen es desconocida (y no siempre lo es).

Una detección precisa nos acerca a la base de la pirámide. Una detección exhaustiva nos acerca a la punta. No hay respuestas correctas, constantemente combinamos ambas estrategias (Firmas + Heurística).

Por otro lado y ya avanzando sobre la implementación práctica de esta detección y desde la mirada de “los requerimientos” para llevarla adelante, el elemento disparador podría ser un monitoreo continuo de los comandos ejecutados a través de la interfaz “Azure CLI. Esta fuente de detección no es trivial, como un registro de auditoria pre-configurado, es por esto que debemos dar forma a la detección a partir de otros elementos observables según las tecnologías que disponemos, es necesario encontrar alternativas, como por ejemplo enfocarnos en las terminales que podrían ejecutar comandos en Azure CLI y monitorear el historial de ejecución en PowerShell, u otro tipo de estrategias para abarcar también las ejecuciones desde Azure Cloud Shell por ejemplo.

T0878 - Alarm Suppression

Vamos a movernos ahora a un entorno distinto y ubicarnos en las tácticas que están más relacionadas con algún tipo de impacto en los entornos industriales. “Supresión de alarmas” es un técnica que se encuentra dentro de la táctica de “Inhibición de funciones de respuesta” específica de la matriz de MITRE para ICS o Sistemas de control industriales (podés profundizar sobre ICS u OT en este post o pararte del lado del atacante en este otro post).

Esta técnica comprende la inhibición de una función de alarma que tiene como objetivo alertar a un operador de una situación crítica en el sistema. Este tipo de técnica al contrario de la anterior está enfocada en los dispositivos específicos de las redes industriales (Ej.: PLC / Sistemas Scada).

Esta técnica suele aplicarse por ejemplo modificando o suprimiendo un sistema de avisos y mensajes de reportes, o incluso con la alteración de los datos mostrados en una interfaz tipo HMI. Existen diversas formas de encarar esta técnica dependiendo los tipos de alarmas, y dispositivos involucrados en la operación, pero podemos trazar algunas hipótesis de ejemplo:

“Si se pierde una comunicación ASOCIADA A LOS PROTOCOLOS DE UN SISTEMA DE ALERTAS, un adversario está realizando una INHIBICIÓN DE FUNCIONES DE RESPUESTA”

Esta hipótesis requerirá como “orígen de datos” (o data source) algún tipo de monitoreo del tráfico de red, o el monitoreo de integridad de los programas involucrados en los dispositivos por ejemplo.

MITRE ATT&CK - Posibles Data Sources para la detección de T0878

La traducción de estas hipótesis a un lenguaje operable en formato de reglas lógicas será nuestro siguiente paso para luego desplegar distintos casos de usos sobre nuestra infraestructura. Siempre considerando los factores anteriores los cuales nos permitirán ajustar la precisión de cada una.

Sobre las reglas de detección

La detección a gran escala de actividad maliciosa dentro de la infraestructura se vuelve compleja entonces si queremos tomar una a una las técnicas y definirlas para cada una de sus variantes en particular.Podemos consumir reglas de detección de la comunidad, un proveedor u otras organizaciones, aunque esto tiene la dificultad de que cada uno de estos ambientes tiene distintas soluciones de detección, tipos de registros y estrategias para definir su protección. Cada SIEM incluso cuenta con su propio sistema de consultas (Query Languages).

¿Qué son las reglas SIGMA?

Las reglas SIGMA son un formato de firmas de código abierto que permite escribir reglas de detección considerando cualquier registro de entrada y en una forma estandarizada. Estas tienen una sintaxis en formato yaml y puede ser convertidas luego (o traducidas me gusta decir) a la sintaxis de nuestro SIEM preferido o la plataforma que se utilice en la organización.

Tomamos como ejemplo una regla sigma de un repositorio de la comunidad encontrado en una librería del proyecto SigmaHQ (aquí), en esta regla el comportamiento a detectar es la conexión de un posible atacante desde un sistema afectado a un servicio externo para “Comando y Control” (C&C TA0011) a través de la red onion (Multi-hop Proxy T1090.003). La técnica en particular hace uso del navegador TOR para cumplir su misión, esta es la regla de detección:

Podemos interpretar para este ejemplo que la detección está basada en principio en los nombres y ubicaciones de los binarios ejecutados, específicamente para entornos Windows. El lector atento sabrá que estas reglas deben refinarse para mejorar su precisión.

Podemos encontrar una guía para comprender la sintaxis de este tipo de reglas para la creación de nuevas reglas aquí.

A continuación y para poder hacer uso de esta regla sigma, podemos y convertirla a un formato entendible para nuestro solución de detección preferida, un SIEM como por ejemplo QRADAR de IBM dejándonos una consulta con la siguiente forma:

Esta conversión podemos realizarla manualmente comprendiendo la sintaxis de ambos pseudolenguajes o podemos utilizar herramientas disponibles como el traductor de undercoder.io

Las reglas Sigma es solo un ejemplo de formato para realizar volcar las decisiones de detección, también podemos encontrar con distintas aplicaciones y alcances:

• Reglas Yara (Orientado en la detección de archivos maliciosos)
• OpenIOC (Orientado a la gestión de Indicadores de Compromiso)
• Reglas de Snort (Orientado a la detección de intrusos en la red)
• Reglas de Suricata (También orientado a la detección de intrusos en la red)

Detección as a Code

Al final del día los analistas de seguridad ya cuentan con una regla de detección concreta, aplicable a sus sistemas de seguridad y fundamentada en un comportamiento bien conocido dentro de un ciberataque. Pero llevar adelante una ingeniería de detección requiere mucho más que la creación de una buena regla, requiere impulsar un conjunto de reglas que constantemente serán modificadas, refinadas, agregadas y desactivadas.

¿Y si llevamos adelante esta operación utilizando algún marco conocido que tenga ese dinamismo de integración y entrega continua? Es así como de hace unos años se está mejorando el concepto de Detections as a Code como un medio para sostener una detección dinámica y eficiente haciendo uso de DevOps.

Este enfoque nos permite entonces contar por ejemplo con algunas de estas características:

• Versionado de reglas de detección
• Proceso de Test/QA para la evaluación de las reglas
• Modularización de las reglas para su reutilización
• Métricas y mejoras en toda la operación

Aquí les compartimos un excelente diagrama de todo el flujo de creación y distribución de las reglas de detección, preparado por Matt Bromiley en su paper “Detecting Malicious Activity in Large Enterprises”:

Algunas conclusiones

En el proceso de destilar un comportamiento para obtener una forma de detectar la actividad maliciosa, estaremos tentados en pensar que un control lógico puede cerrar una puerta al atacante. Una regla firewall bien restrictiva que limita el acceso a internet es una excelente medida, pero no reemplazará la necesidad de detectar el tráfico de un C&C dentro de la red.

“La prevención puede fallar, pero la detección no puede darse ese lujo”
Felipe Alves - BASE4 Security Researcher

La detección “genérica” que podemos encontrar en el solo hecho de desplegar una solución de protección como un EDR, un WAF, o un IPS tiene muchísimo valor, la protección como buena práctica debe comenzar desde las medidas más abarcativas a las medidas más específicas. De nada sirve basarse en hipótesis para detectar comportamientos “avanzados” si por otro lado no podemos ver que es lo que privilegios están asignados a los usuarios por ejemplo.

El campo de la IA nos está dando servidos montones de herramientas cada vez más al alcance de la mano, incorporar machine learning a la “detección como código” es una práctica que potenciará aún más las capacidades de los equipos de SOCs para operar de manera más eficiente y efectiva.